Okay, nice to hear. I think it's really great, that you take user suggestions into account, because not all programmers do that.
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!