Tron Bike Walls

[Traxx]

I'm thinking how to implement this on 7800,I'd like other programmers ideas on how they would handle the walls and how to implement it.I don't need code example,an explanation is good enough for me to understand.A lot of the other parts of the game are quite easy but those walls are a problem.

Edited April 3, 2022 by Traxx

[+karri]

Building walls while you drive could be implemented by using a frame buffer where you can mark your track while you drive. Two XHeader  zones can cover 40 tiles on a line in 320A mode.

[Traxx]

Thanks Karri,can you go more into detail,not the the zones I understand that.

Edited April 3, 2022 by Traxx

[+karri]

2 hours ago, Traxx said:

Thanks Karri,can you go more into detail,not the the zones I understand that.

I hope I don't misunderstand your question.

 

If you have a framebuffer like

        .bss
_screen:
        .res    charsperline * screenrows
 

Then you can group your tiles like
tiles with index > N are wall elements
tiles wih index <= N are elements you can drive on

 

So if you drive over element (x,y) you mark it in the screen buffer by tile N+1.

If someone else wants to drive over (x,y) you can read the content of that location and if it is larger than N it is a crash.

 

Of course you have to zero the screen before driving on it.

 

The wall elements could be
drive up/down
drive left/right
from left to up
from left to down

from right to up

from right to down

 

[RevEng]

Looking at the game and the minimum spacing between walls, you can tell it's drawing the walls with characters. Using character/tile displays instead of bitmap ram is also generally "the arcade way" of machines of this era. (notable exceptions include Qix. Can't think of any others offhand.) Compared to using ram bitmaps, using character graphics like this is both cheaper and ridiculously faster.

 

Anyway, for Tron lightcycles you have a bunch of character graphics that represent a wall in-progress. (and some for completed walls.) Assuming 4 frames of wall in-progress (not sure if 4 is what the arcade uses, but it seems a reasonable implementation) you have 4 sets of in-progress walls coming from each edge of the character cell, each of those containing 2 frames until they get to the "center" of the tile, and then another 2 frames of leaving the center in one of the 3 remaining cardinal directions. So you need 48 (4*2*2*3) characters defined for in-progress walls. I think I have that math right, but this is all off-the-cuff, so I may have missed some factor.

[RevEng]

Actually, looking at the arcade game some more, I think it may even be simpler - the sprites of the cycles are moving smoothly, but they hide the characters underneath. So you likely only need to draw the completed tiles once the light cycle has passed the middle point of the tile. No need to draw any in-progress tiles, since they only get revealed once the light cycle has passed by. Clever.

[Traxx]

Thank you both

[+karri]

I am currently experimenting with ca65 trying to make a conio target that uses a frame buffer as well. Here is a snippet on defining the zones.

.macro NullHeader offset, zero
        .byte   offset
        .byte   zero
.endmacro
.macro TextZone row
        ; Text
        .byte   <(_screen + row * charsperline)
        .byte   $60
        .byte   >(_screen + row * charsperline)
        .byte   12
        .byte   0
.endmacro

_zones:
zone0:  TextZone 0
nh:     NullHeader 0, 0
zone1:  TextZone 1
        NullHeader 0, 0
zone2:  TextZone 2
        NullHeader 0, 0
...

The TextZone is just a XHeader with some fixed values coded in.