THE SEUCK VAULT
Main | Menus | Tips | Links | Contact
SEUCK REDUX by Martin Piper
Professional programmer Martin Piper has spent some time this year creating a new game engine that runs SEUCK data files. The aim was to reduce the amount of flickering and glitching caused by having too many sprites onscreen, and to free up screen time to run music alongside the game.
Martin has used the changing border colour (shown in these two screenshots) to demonstrate the spare runtime, which makes SEUCK Redux more efficient and able to display more sprites without flicker than the original.
Martin has fixed the collision detection, and created a new version of the code to add spells to LEGION OF THE DAMNED. He explains:
The question why I did it is very much linked to the technical details of how the original SEUCK worked. All those years ago the SEUCK guys didn't have access to all the modern ideas we now have about the C64. For example te multiplexor in the original SEUCK compared to modern multiplexors is not that good, the sorting is slow, the collision detection routine has a bug in it and it generally cannot cope well with many sprites. The SEUCK game code also doesn't use that much optimisation and this is partly because some of the memory has to be used for the editor code. In general, problems can be optimised by throwing memory at them for look-up tables or unrolling code. But with all these shortcomings I still like the original SEUCK, as do a few other active people on the modern C64 scene.
But I'm a professional programmer with a long history in the games industry so it pains me to see SEUCK games with flickering sprites, or slowing down, or buggy collision detection. Many years ago code reuse wasn't such a hot topic for programmers, much like revision control wasn't much thought of. But these days I'm a much wiser programmer because I have had times in the past when code would get lost with a floppy or drive failing. :) So recently I've been playing around in my spare time with C64 code and documenting my old projects from nearly twenty years ago so I can give it all to the community that is active today. I then started thinking about how these separate routines could be made to play data from SEUCK games and provide an example of how a complete game engine is put together from reusable parts. So after reverse engineering the SEUCK data formats I wrote new code to display the SEUCK games, this code was then optimised using modern knowledge. For example the multiplexor sort uses a much more elegant solution knows as the "Ocean sort" method where the previous sort results mean only the changes in sprite positions are sorted the following frame. The collision was also improved by using the VIC collision register and doing a more robust search than the original SEUCK did for colliding sprites. Other general optimisations were in the scroller where only part of the screen is moved over several frames which saves CPU time for the game play code.
Writing code from scratch without needing to have a working SEUCK editor also means it has been documented so other can understand the code and importantly expand upon the original SEUCK games or even use bits of code for their own projects. For example completely new title screens can be written without needing to hunt around for spare blocks of memory, or for example super bomb spell effects like those in Legion of the Damned can be added. The spell effects in particular would have been very hard to add in the original SEUCK because someone would have had to figure out how its multiplexor and object animation code works. But also now with the optimisations and fixes old SEUCK games can suddenly play better with the new code because they don't often slow down, or flicker and the collisions are better.
Click here to visit the Codebase64 site for more details