Next 1K hires game, BREAKOUT
Re: Next 1K hires game, BREAKOUT
I moved the ballscreen to the end of memory.
I had to "erase" the examplescreen for it, but the program will rebuilt screens soon.
The bat is set to a reasonable size.
The bricks are defined up to 6 layers, so 6 levels to play.
The stack is located directly before the ballscreen and is defined in 34 bytes.
This leaves a block of codeable space for the actual game of : 500 bytes.
In this space is NOT added: 30 bytes of codeable sysvar.
So of to go coding.....
I had to "erase" the examplescreen for it, but the program will rebuilt screens soon.
The bat is set to a reasonable size.
The bricks are defined up to 6 layers, so 6 levels to play.
The stack is located directly before the ballscreen and is defined in 34 bytes.
This leaves a block of codeable space for the actual game of : 500 bytes.
In this space is NOT added: 30 bytes of codeable sysvar.
So of to go coding.....
Re: Next 1K hires game, BREAKOUT
Still 68 bytes left.
To do:
score after brickhit
end of level
end of game
hiscore test
fingers crossed
To do:
score after brickhit
end of level
end of game
hiscore test
fingers crossed
Re: Next 1K hires game, BREAKOUT
Getting somewhere.
a small bug on the bat.
no scoring yet
Q=up
A=down
NL=start game
Space= release ball
a small bug on the bat.
no scoring yet
Q=up
A=down
NL=start game
Space= release ball
Last edited by dr beep on Sun Sep 03, 2017 10:59 pm, edited 1 time in total.
Re: Next 1K hires game, BREAKOUT
Good work so far.
Re: Next 1K hires game, BREAKOUT
So I had to give up some things...
Not in the game:
Display of the name of the game
Hiscore tracking
I was however able to:
Add the 6 levels completed check
repair the BAT-bug
Fit the game in EXACTLY 1K
The stack is at its MINIMUM.
1 byte more and code gets corrupted and game crashes.
Official release will follow later......
Not in the game:
Display of the name of the game
Hiscore tracking
I was however able to:
Add the 6 levels completed check
repair the BAT-bug
Fit the game in EXACTLY 1K
The stack is at its MINIMUM.
1 byte more and code gets corrupted and game crashes.
Official release will follow later......
Re: Next 1K hires game, BREAKOUT
I like it, thanks Dr!
I imagine that ~200 t-states isn't a lot, so good work. So far not got past level two though.
Regards,
Shaun
I imagine that ~200 t-states isn't a lot, so good work. So far not got past level two though.
Regards,
Shaun
Re: Next 1K hires game, BREAKOUT
207 tstates per line.
Display of 240 pixels is already 120 tstates, rest is used for other code.
Some lines need over 130 tstates for other code. This is partly done over the display.
Re: Next 1K hires game, BREAKOUT
I'll get to know this at some point in the hopefully near future; at the moment, I am just an assistant to an apprentice ZX programmer. One day I will be the apprentice.
Regards,
Shaun.
Regards,
Shaun.
Re: Next 1K hires game, BREAKOUT
To keep learning you have, young padawan , heuu sorry, 'assistant'
So do I, i just test the game on 81 emulator and guess what ? My older son (13 y.o.) stopped Zelda on his nintendo switch and is now playing on Breakout !!
Dim_75, Yodas' apprentice's assistant' assistant
Re: Next 1K hires game, BREAKOUT
I was trying to find room for the hires routine.
I would need 27 bytes for this.
I found 13 bytes.
Then it hit me.
The display of top and bottom line is an inverted linebuffer with data from the linebuffer of the ball.
This is how the program is and already saved 29 bytes.
The stack used to display the bricks only holds values from #81 to #87, the pointers to the thickness of the walls.
These values can be used as inverted displaybuffer. At the end I only need to add a RET and in the calling I need a few bytes more (2).
So I save 25 bytes at once. A total of 64 bytes.
I need 26 for the stack, 27 for the hiscore. Leaving room for the name too.
I can add the hiscore check AND the namedisplay.
I would need 27 bytes for this.
I found 13 bytes.
Then it hit me.
The display of top and bottom line is an inverted linebuffer with data from the linebuffer of the ball.
This is how the program is and already saved 29 bytes.
The stack used to display the bricks only holds values from #81 to #87, the pointers to the thickness of the walls.
These values can be used as inverted displaybuffer. At the end I only need to add a RET and in the calling I need a few bytes more (2).
So I save 25 bytes at once. A total of 64 bytes.
I need 26 for the stack, 27 for the hiscore. Leaving room for the name too.
I can add the hiscore check AND the namedisplay.