Working on new 1K hires : Marble Racer

Any discussions related to the creation of new hardware or software for the ZX80 or ZX81
dr beep
Posts: 2060
Joined: Thu Jun 16, 2011 8:35 am
Location: Boxmeer

Working on new 1K hires : Marble Racer

Post by dr beep »

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)
dr beep
Posts: 2060
Joined: Thu Jun 16, 2011 8:35 am
Location: Boxmeer

Re: Working on new 1K hires : Marble Racer

Post by dr beep »

When I make the playfield 24 columns instead of 30 now, then I can reduce the screen data by 50%. The total screen would become 270 bytes. In previous post I made a calculation error. Total size would be 460.
So for 190 bytes I will give up some size, but no gameplay. And it will fit my 8 bit register.
RWAP
Posts: 1348
Joined: Thu May 08, 2008 8:42 am
Location: Stoke-on-Trent, UK
Contact:

Re: Working on new 1K hires : Marble Racer

Post by RWAP »

A great idea - this should be fun :)
User avatar
PokeMon
Posts: 2264
Joined: Sat Sep 17, 2011 6:48 pm

Re: Working on new 1K hires : Marble Racer

Post by PokeMon »

Marble racer sounds exciting - looking forward to see the first screens. :mrgreen:
dr beep
Posts: 2060
Joined: Thu Jun 16, 2011 8:35 am
Location: Boxmeer

Re: Working on new 1K hires : Marble Racer

Post by dr beep »

PokeMon wrote:Marble racer sounds exciting - looking forward to see the first screens. :mrgreen:
as requested....
marble.jpg
marble.jpg (22.28 KiB) Viewed 3589 times
first screen, not the final track, but the routine is working.

I had to choose between a large screen with more memory use or smaller screen with app 50% less data needed.
I will start with the larger screen. I can always go back to smaller screen (which would be 3 columns per part less.)

Now I need for this screen 438 bytes, so enough room to code movement and timing.

The display is divided in 3 parts, top, mid and bottom.
Each part has a pointer to a piece of memory. All possible lines are stored once and addressed by a pointer. In the mid part the next pointer is
retrieved in the box in the middle. The lines with the marble will save the original pointer, copy the pointer data on marble lines, place marble, set marblepointer in display. On movement : set original pointers back (and thus erasing marble) and do move, start all over.
The display in the mid got so effective that I could come to 272 pixels in reach. So I reduced it to 240.
marble2.jpg
marble2.jpg (34.68 KiB) Viewed 3589 times
Baggers
Posts: 65
Joined: Wed Dec 19, 2012 8:49 pm

Re: Working on new 1K hires : Marble Racer

Post by Baggers »

Looking forward to this dr beep, looks amazing for 1K well done!
User avatar
PokeMon
Posts: 2264
Joined: Sat Sep 17, 2011 6:48 pm

Re: Working on new 1K hires : Marble Racer

Post by PokeMon »

Yes - looks like a great game idea ! 8-)
dr beep
Posts: 2060
Joined: Thu Jun 16, 2011 8:35 am
Location: Boxmeer

Re: Working on new 1K hires : Marble Racer

Post by dr beep »

On the screens the marble was fixed in display.
Working on the moving marble display was tough (any position possible), but it looks like it is almost done.

To do:
Input, movement, timing

Free memory : almost 256 bytes.
Program must be compressed on loading, otherwise too much memory.
Right now I need 2K to load the program because stack is overwritten on loading.
Last edited by dr beep on Fri Jun 19, 2015 8:58 pm, edited 1 time in total.
dr beep
Posts: 2060
Joined: Thu Jun 16, 2011 8:35 am
Location: Boxmeer

Re: Working on new 1K hires : Marble Racer

Post by dr beep »

174 bytes still free.

Marble can now be displayed on any position. Collision with track now detected.

To do:
reset to previous position on collision
add movement
add timing.
add timing display
dr beep
Posts: 2060
Joined: Thu Jun 16, 2011 8:35 am
Location: Boxmeer

Re: Working on new 1K hires : Marble Racer

Post by dr beep »

Movement is now added.
Only problem is collision that goes out of boundary. I think I will alter the walls to keep it in 1 byte.

Horizontal collision now solved. Now only trouble with collision in upwards direction.

Must think of a way for this.
Post Reply