Jump to content

Tron Bike Walls


Recommended Posts

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 by Traxx
Link to comment
Share on other sites

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

        .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


  • Like 2
Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

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
.macro TextZone row
        ; Text
        .byte   <(_screen + row * charsperline)
        .byte   $60
        .byte   >(_screen + row * charsperline)
        .byte   12
        .byte   0

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.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...