emmonks, yesterday a friend and I tried out your United DX version of the game. It's good, that everything is together now, in this version. In our opinion, there are only two things that could potentially be improved in a possible upcoming v1.1 of the game and I wanted to make these suggestions. Whether you implement this, is of course entirely up to you. (1) A fastloader could be used for reloading, that would make the loading-process significantly faster. For hardware like for example the SD2IEC, a version without fastloader can remain, because only kernel loaders run there, but for normal drives or for hardware like 1541Ultimate, Turbo Chameleon, etc, a fastloader would definitely make sense. (2) These loading-commands in the C64 BASIC, which appears during reloading, are looking a bit odd, inside a game. Here, all the colors in BASIC could simply be made black (text and background) so that players wouldn't see these commands. Then it would seem to the player more as if the individual reloaded versions, were directly connected to each other and no longer separate programs. That would be my last suggestions. It's a good game.
Sparky-D,
Thank you for the detailed feedback! It’s great to know you’ve been testing the UNITED version with a friend. Regarding your suggestions:
- The Fastloader (Item 1): This is definitely more complex. Memory management is already a tight 'puzzle' in these versions, and maintaining compatibility across different hardware while adding a fastloader makes it tricky. I’ve done some tests with SJLOAD, as it seems like one of the simplest options, but I haven't made much progress yet. Since I usually play via MiSTerFPGA or C64 Ultimate, I hadn't prioritized this, but I completely understand that for users on original drives, reducing loading times is essential. I'll keep testing this as time allows.
- Hiding BASIC commands (Item 2): This is a great idea and very straightforward to implement! Making the text and background black to hide the loading process is a simple fix that I can definitely do in a future update. It will certainly make the transitions feel much more professional and seamless.
I really appreciate these contributions! It’s this kind of feedback that helps a 'tourist' like me improve the experience for the whole community. Cheers!
This is a very simple question: I am not a programmer! :)
I've uploaded a new version of 4goalux.d64 featuring much cleaner transitions between game modes. By hiding the loading commands, the experience now feels a lot more seamless and professional.
Regarding a fastloader: this is a significantly more complex task. Due to the tight memory management of the current engine, implementing one would require a major overhaul to avoid conflicts. I will continue to explore simpler alternatives, but for now, I'm focusing on these low costs improvements to make the collection as polished as possible.
Thanks for the ongoing feedback and support!
Nice, that you've hidden the loading commands now, it looks more professional than before now. I thought about, what you had written about the fastloader-thing and it's understandable. By the way, I tried the game with a speeder-kernel, to see, if the reloading-process in this case, is also accelerated then and it luckily is. This also works with fastloader-cartridges like the FC3 or the AR6 etc. That's good. If a AR6 is used, the load-commands are visible again, I found out, because the AR6 changes the BASIC color for text into white, which is probably the reason for that.But that's tolerable.
By the way, I've also noticed, that unpacking the reloaded parts takes quite a while. Are they packed with "Exomizer"? This packer has a very good compression-rate, so it makes the programs very small, but it takes a relatively long time, to unpack them. If you pack with "NuCrunch", for example, unpacking only takes about half the time and the files aren't much larger. But it must be tried out, to see, if the whole loading and unpacking process is shorter with "NuCrunch" or with "Exomizer" here in these cases. It could be worth a try. But it's always difficult to predict exactly, without testing it. If you always load the game with a speeder-kernel or a fastloader-cartridge, the unpacking-time naturally plays a much bigger role, since the reloading-process itself, is relatively fast, regardless of the filesize. Without a fastloader, the situation is quite different, as the filesize then becomes a much more significant factor, because loading a larger file then naturally takes noticeably longer and the unpacking-process is then only a small part, in terms of time.
Thank you so much for the detailed tests! It’s very interesting to know that speeder-kernels and cartridges like the AR6 or FC3 are working, even if the AR6 forces the text back to white.
Regarding the performance and the packing:
- Hardware context: I don't have the original disk drive hardware to perform real-world performance benchmarks. I usually conduct my tests using VICE (with true drive emulation) or on the MiSTerFPGA and C64 Ultimate.
- Compression choices: I used Pucrunch to pack the files to ensure everything fits on a single .D64 disk. I chose it mainly for compatibility, as I previously found that Exomizer caused some issues with the way I handle load chaining via BASIC.
- Next steps: Your suggestion about NuCrunch is excellent! If it provides a faster unpacking time while maintaining compatibility with my loading logic, it could be the perfect middle ground.
I will definitely run some tests with NuCrunch as soon as possible to compare the results. If it works without breaking the chain, it should significantly improve the experience for those using fastloaders where unpacking time becomes the main bottleneck.
Thanks again for the support and the invaluable technical tips!