Thank you so much! I’m really glad you liked the final result.
It was a great challenge to implement your suggestion and find a way to group everything together, but it was definitely worth it. 4GOAL UNITED feels like the proper way to experience the series, especially as a party game with the multiplayer adapter!
I hope you and your friends have a lot of fun on the pitch. Enjoy the games, and thanks again for being part of this journey!
Cheers!
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:
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:
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!
