Posts for paulko64

Experienced Forum User
Joined: 9/7/2014
Posts: 3
Mmm, that's interesting. The building algorithm depends on your speed, so you can indeed influence randomness by slowing down. However, not sure how the "jump moment" can influence the randomness... Perhaps I included the player y-position in there or something, I don't remember...
Experienced Forum User
Joined: 9/7/2014
Posts: 3
@dwangoAC: I checked in my source-code and the actual speed is stored at $0019 (low-byte) and $001a (high-byte). The speed is stored in pixels/second, and should therefore be maximum 800 (or $320 in hex). Also, although the button is the only input, pressing the button itself (inside the game) does not influence the randomness. I use a 64K and 32K linked random generator, that is seeded at the start of the title screen and updates its value each screen-refresh (as well as during the building contruction in the background for random window layouts). I.e. you can manipulate the randomness by waiting more/less frames before pressing the button and starting the game. But once started, the building layout cannot be manipulated anymore... Regards, Paul
Experienced Forum User
Joined: 9/7/2014
Posts: 3
Hi there, My name is Paul Koller, and I wrote C64anabalt. Really interesting what you did there! I'd like to share some insights on what I think is happening... C64anabalt is a conversion of the Flash version of Canabalt by Adam Saltsman. It uses a similar building generation algorithm as the original and the same acceleration profile. I.e. if you are not being slowed down by the obstacles, the speed accelerates till you reach 16 pixels/frame, which is about 800 pixels/second on a PAL system. I.e. there IS a speed-cap! The game dynamically determines the height and width of the next building based on your current speed. I.e. the faster you go, the wider the buildings will get (to make it a bit more fair). However, there is always a random factor involved. The original Flash version determines the next building's height and width at the moment it scrolls on the screen. However, because of the limited CPU power of the C64 (remember this is only a 1MHz machine!) this was not possible, since the building also needs to be built up. So what I did is that the next building is actually already being constructed in memory when the previous building is shown. Now we get to the point where I think the glitching comes from... When a new building should scroll onto the screen, the code assumes that the construction of it in memory has already been finished. However, for very high speeds, and a building width which is at the smaller side of the (random) spectrum, it can occur that it already wants to scroll on the new building when it's not finished yet. This probably leads to the weird glitching behavior... Another interesting item is that I think I coded the distance meter for 5 digits only. I.e. not sure what happens after 99999m... But I can imagine that there is no volunteer to try to find out :) Btw, I also coded C64 ports of SuperCrateBox (SuperBreadBox) and SuperHexagon (MicroHexagon) which have a similar endless gameloop... Regards, Paul Koller twitter.com/paulko64