Working on new 1K hires : Marble Racer
Posted: Thu Jun 11, 2015 11:33 pm
Jim's racegame was already mentioned to make a 1K hires version. After making the initial screen I noticed a large problem which I then couldn't solve.
After coding THE EDGE I had a brainwave to solve this problem.
At first it didn't work as planned due to the fact you can't divide 207 Tstates by 2 and solving it costed too much time to fill the gap the display would create.
But then With another brainwave I was able to reduce the gap to just 16 pixels.
Now my problem is that my width of the game reaches 36*8= 288 pixels where I want to keep the x-coordinate in 8 bits.
So for the first time I must bring back the size of the screen not for a lack of memory, but a lack of registersize.
For synchronization I will reduce the screen to 240x160 pixels and a few lowreslines for score.
The game will get an almost fullsize filled racing track that will cost just 390 bytes of screendata.
The game is an adaption of a small game I coded for Cambridge 2012, but was never released.
This game had a gyroscopic ball that had to be rolled on a target as quickly as possible.
The ball could get more speed in X and Y direction and you could brake in the X-Y direction, but not alter direction by a single keypress. Ie when you move speed 1 to left and you press right, the speed would become 0.
With this effect you spin out of a corner. I could code the game like this, but then I must built a collision test to define target hit. So I decided to make a round track and use the ball as a kind of racecar where in time you must finish 10 laps, like Jim's game. Now when a collision is found it will be on the edge of the track. This will stop the marble from rolling (like Jim's car in racing).
When display is ready I only need to set the marble, make move possible and count the laps.
This must be possible in 500 bytes.
Other tracks are possible. This might cost max. 35 bytes for alternative trackdata.
With multiloader. ( while typing I am thinking of reducing screen data by half)
After coding THE EDGE I had a brainwave to solve this problem.
At first it didn't work as planned due to the fact you can't divide 207 Tstates by 2 and solving it costed too much time to fill the gap the display would create.
But then With another brainwave I was able to reduce the gap to just 16 pixels.
Now my problem is that my width of the game reaches 36*8= 288 pixels where I want to keep the x-coordinate in 8 bits.
So for the first time I must bring back the size of the screen not for a lack of memory, but a lack of registersize.
For synchronization I will reduce the screen to 240x160 pixels and a few lowreslines for score.
The game will get an almost fullsize filled racing track that will cost just 390 bytes of screendata.
The game is an adaption of a small game I coded for Cambridge 2012, but was never released.
This game had a gyroscopic ball that had to be rolled on a target as quickly as possible.
The ball could get more speed in X and Y direction and you could brake in the X-Y direction, but not alter direction by a single keypress. Ie when you move speed 1 to left and you press right, the speed would become 0.
With this effect you spin out of a corner. I could code the game like this, but then I must built a collision test to define target hit. So I decided to make a round track and use the ball as a kind of racecar where in time you must finish 10 laps, like Jim's game. Now when a collision is found it will be on the edge of the track. This will stop the marble from rolling (like Jim's car in racing).
When display is ready I only need to set the marble, make move possible and count the laps.
This must be possible in 500 bytes.
Other tracks are possible. This might cost max. 35 bytes for alternative trackdata.
With multiloader. ( while typing I am thinking of reducing screen data by half)