tjb Posted May 3, 2006 Share Posted May 3, 2006 I'm currently working on an Asteroids clone entitled Rasteroids. My goal is to make a clone that is closer to the arcade game that the versions I've seen (Asteroids, Meteorites, etc.) available on the 8-bit. There is much work to be done but basic asteroid and ship movement, firing, and some collision detection has been implemented. I'm curious to see if there is any interest in the community for such a game. I've attached a couple of screenshots and a short AVI of the game running under Atari800Win Plus. Please bear in mind that the game is very much a work in progress at this point (i.e. Ship graphics need lots of work, Asteroids do not explode when hit, the player's ship cannot be destroyed, etc.). -tjb rastvideo.zip Quote Link to comment Share on other sites More sharing options...
sku_u Posted May 3, 2006 Share Posted May 3, 2006 Sweet! I moved this thread to the 8-bit programming forum, but left a shadow link in the regular 8-bit forum. Best of luck to you. This looks like it will shape up to be a fun game when all is said and done. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 3, 2006 Share Posted May 3, 2006 looks good so far questions: 1) why artifacting turned on? 2) Antic F used? with 40 Byte scanlines? 3) sprite routines are based on EOR right? 4) how many objects will it possible to display? 5) double buffering? i am just asking as i have played around years ago with a quick softsprite routine based on zoneranger by Activision. Quote Link to comment Share on other sites More sharing options...
Bryan Posted May 3, 2006 Share Posted May 3, 2006 I've wanted to see someone do a better Asteroids for a long time. -Bry Quote Link to comment Share on other sites More sharing options...
tjb Posted May 3, 2006 Author Share Posted May 3, 2006 looks good so far questions: 1) why artifacting turned on? 2) Antic F used? with 40 Byte scanlines? 3) sprite routines are based on EOR right? 4) how many objects will it possible to display? 5) double buffering? i am just asking as i have played around years ago with a quick softsprite routine based on zoneranger by Activision. I'd love to hear about these routines as well as the ones in ZoneRanger. In regards to your questions: 1) why artifacting turned on? I assume you are referring to having artifacting turned on in Atari800Win plus? I have it turned on to better approximate what the game will look like on real hardware. I've run it on a real Atari and the artifacting is actually not as bad. 2) Antic F used? with 40 Byte scanlines? Yes, it uses Antic F. 3) sprite routines are based on EOR right? Yes. 4) how many objects will it possible to display? It really depends on the size of the objects. This is one area I realize I need to proceed with caution. Currently, the size of the largest asteroid is 32 x 32 pixels! Depending on how things work out I may have to shink it down somewhat. 5) double buffering? At present I am not using double buffering but that is an interesting possibility. Are you referring to the use of page flipping? I know you have alot of experience in sprite routines. Any suggestions/hints would be most appreciated. -tjb Quote Link to comment Share on other sites More sharing options...
Rybags Posted May 3, 2006 Share Posted May 3, 2006 Looks good. Are you implementing more ship angles than the original? That was one of the big weaknesses of the original conversion. I assume you're using a table lookup in the sprite routine to get the screen address based on the sprite's YPOS? You can gain extra speed by creative table lookups. I also would assume you are using pre-shifted sprite definitions? A really nice feature would be tumbling/turning rocks but it might be rather expensive on memory - maybe do a 128K version? Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 3, 2006 Share Posted May 3, 2006 http://www.atariage.com/forums/index.php?s...&hl=zone+ranger Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 3, 2006 Share Posted May 3, 2006 it seems that i spend hours with disassembling ZR back in 2002... huj...time passes by... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 3, 2006 Share Posted May 3, 2006 Rybags turning rocks might not so mem consuming... Quote Link to comment Share on other sites More sharing options...
Rybags Posted May 3, 2006 Share Posted May 3, 2006 (edited) You could get turning rocks cheaply by having pre-shifted sprites with the animation dependant on the XPOS MOD 7 - slow moving rocks would turn slowly, fast moving rocks turn faster. I would recommend using 2 sprite routines - the big rocks could be drawn faster with logic like: LDA ROCKDATA,X BEQ NOSTORE EOR (SCREEN),Y STA (SCREEN),Y NOSTORE ... 2 extra cycles for a failed branch but several more saved for each blank byte in the sprite - the big ones would have a fair few. Or, if double-buffer is used - just OR the data - no problems since only 1 bitplane is used... the "restore" routine would just store zeros where each sprite was. Self-modifying code would be the way to go I think. Unrolled loops may or may not save time - the 6502 really needed postindexing modes like the 68000. The time you save with STA xxxx,Y vs STA (xx),Y can often be lost since you have to later do multiple updates to non-zero page locations rather than just having to update one or two z-page pointers. It all comes down to the individual application. I'm using SM code in Impossible Mission for the robot sprites - that allows me to merge and store a 8x24 pixel sprite (implemented in MC character mode) in well under 40 scanlines. Edited May 3, 2006 by Rybags Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 3, 2006 Share Posted May 3, 2006 just an excerpt of the link i have posted ok... another morning another info by heaven - the code spy... the sprite engine is straight forward in zone ranger (s.a.) 0400-04bf 0500-057f lookuptables of scanline adresses 0e00 - 0ebf 0f00 - 0fbf lookuptables with 9er increment... this was interesting... 9er? it seems so unusual on 6502... but take a look again into the code at $0600... how many bytes does it take to put one byte into vram? lda ($fe),y ; 2 ora vram,x ; 3 sta vram,x ; 3 iny ;1 voila, 9 bytes.... this table is used for self modifing code... the core engine is located at $0260. RTS ($60) is written directly via these look up tables into the code, with other lookup tables the engine knows how many scanlines has to be computed for each sprite and on which x-position... at $02aa you find the entry JSR into the sprite copy routine at $0600 depending on y-position of the sprite... the game itself does this at beginning: 1st init 5200 hardward 2nd generate lookup tables 3rd generate unrolled loops at $0600 4th unknown yet... well... still some mysteries left... how are the sprites shifted? so they can be positioned on each pixel in x-direction? and what are the lookuptables at $ae60,$ad40,$add0, $aef0 made for??? they seem to contain the sizes of the sprites and other information... play around with these values and you see that the game will not crash but the sprites will differ & change... more to come tomorrow morning... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 3, 2006 Share Posted May 3, 2006 and the next one... more you might find in the old time pilot thread another day...another try: i had a closer look into the code at $0260 - the core sprite engine... $ae60 - x-size of the sprites in bytes stored in $fc $aef0 - y-size of the sprites in byts stored in $fd & y-register for the loop $fa hold the byte which stands in the unrolled sprite copy routine and will be stored back when the sprite engine quits... f.e. enter in the monitor "f $aef0 $af3f 2f" and all sprites turn into 32 pixel ones... "f $ae60 $aeef 07" same in x direction... now every sprite turned into 32x32 one... and you can continue the game with "cont" and see how fast zoneranger sprite engine really is... $0260 combined with the unrolled copy code seems to be the core sprite engine... what i havent found yet is where are the preparations made so every sprite can be positioned on pixel bases... but when you make the above modifications in the table...it might be obvious that they are preshifted in ram...because while moving slowly the 32x32 sprites change there shape because the data is switched every pixel... so they are definitly not preshifted in realtime... $fe contains the sprite data adress and is changed every next sprite (wow...what a trick... ... maybe tomorrow i have more informations... the engine is quite tough... with EORing the stuff you get definitly rid off a clear screen routine...you jusr run twice through the sprite engine... and you can have this lovely game logo staying there without the need to copy it there... hve ps. i will go for this engine for timepilot... seems quite usefull for that... and time pilot has same amount of sprites and sizes... so it could work really good... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 3, 2006 Share Posted May 3, 2006 don't do eor (screenvector),y sta (screenvector),y as your screen vram is fixed anyway... so you can have lda (spritedata),y eor vram,x sta vram,x iny eor vram+1*40,x sta vram+1*40,x iny lda (spritedata),y eor vram+2*40,x sta vram+2*40,x ... iny lda (spritedata),y eor vram+31*40,x sta vram+31*40,x rts so you can have a long runrolled loop f.e. 32 bytes vertical (as you said 32x32 = 4x32 bytes total). with a nice lookup table the sprite engine can put the RTS command directly into the sprite draw code draw a vertical stripe, increase X register (remember 4 collums do we need to draw for a 32x32 sprite) , draw next stripe until all 4 are drew. then restore the RTS with the old command in the sprite draw code. with this you can update your spritedata pointer for animation etc... how many different sprites will there be on screen? Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 3, 2006 Share Posted May 3, 2006 oh...and you might know that already with your eor-engine... when your drawing order is sprite 1-32 then first draw 32-1 oldposition to whipe them on screen... Quote Link to comment Share on other sites More sharing options...
Rybags Posted May 3, 2006 Share Posted May 3, 2006 More potential time saving can be had by storing the sprites in a data structure similar to an actual screen. For a 32x32, have each group of 4 bytes on a 40 byte boundary. Then, you can use the same index register for sprites and screen. Plus, use a slightly unrolled loop - utilizing the index register to its full capability means you only go through the time-consuming process of updating the screen and sprite pointers for every 6th line. LDA #5 STA VCOUNT; 5 iterations of the outer loop DOSPTRITE1 ; outer loop starts here LDX #6; do 6 lines (6x40 = 240) LDY#0 DOSPRITE2 LDA (SPRITEPTR),Y ; get the sprite data (1st byte of line) EOR (SCREENPTR),Y ; EOR with existing STA (SCREENPTR),Y ; store it INY LDA (SPRITEDATA),Y ; get the sprite data (2nd byte of line) EOR (SCREENPTR),Y ; EOR with existing STA (SCREENPTR),Y ; store it INY LDA (SPRITEDATA),Y ; get the sprite data (3rd byte of line) EOR (SCREENPTR),Y ; EOR with existing STA (SCREENPTR),Y ; store it INY LDA (SPRITEDATA),Y ; get the sprite data (4th byte of line) EOR (SCREENPTR),Y ; EOR with existing STA (SCREENPTR),Y ; store it TYA CLC #37 TAY DEX BNE DOSPRITE2 DEC VCOUNT BEQ FINISHED; outer loop complete - now exit LDA SCREENPTR CLC ADC #240; 6 x 40 STA SCREENPTR BCC NOINC1 INC SCREENPTR+1 NOINC1 LDA SPRITEPTR CLC ADC #240 BNE NOINC2 INC SPRITEPTR+1 NOINC2 JMP DOSPRITE1; back for outer loop FINISHED RTS; exit Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 3, 2006 Share Posted May 3, 2006 i cant see why you want to use a loop and your indirect screenptr approach... Quote Link to comment Share on other sites More sharing options...
Rybags Posted May 3, 2006 Share Posted May 3, 2006 That ZR routine looks interesting ... so potentially such code could be used for any sprite size - 2.5K is pretty cheap considering the speed advantage. Quote Link to comment Share on other sites More sharing options...
tjb Posted May 3, 2006 Author Share Posted May 3, 2006 Looks good. Are you implementing more ship angles than the original? That was one of the big weaknesses of the original conversion. I assume you're using a table lookup in the sprite routine to get the screen address based on the sprite's YPOS? You can gain extra speed by creative table lookups. I also would assume you are using pre-shifted sprite definitions? A really nice feature would be tumbling/turning rocks but it might be rather expensive on memory - maybe do a 128K version? >>Looks good. Are you implementing more ship angles than the original? Thanks. Currently the player's ship has 24 different positions. I believe Atari's has 16? >>I assume you're using a table lookup in the sprite routine to get the screen address based on the sprite's YPOS? >>You can gain extra speed by creative table lookups. >>I also would assume you are using pre-shifted sprite definitions? You're right on the money. I am using both a table lookup to find the screen address of the beginning of the row based on the sprite's Y position and pre-shifted sprite definitions. >A really nice feature would be tumbling/turning rocks but it might be rather expensive on memory - maybe do a 128K version? I had rotating rocks initially. It got pretty expensive as you mentioned in terms of memory - especially when you have several frames to make the animation smooth. I'd like to try adding them back at some point. Maybe there will be another version as you suggested - "Rasteroids Deluxe" -tjb Quote Link to comment Share on other sites More sharing options...
tjb Posted May 3, 2006 Author Share Posted May 3, 2006 I really like the in-depth discussion on sprite engine techniques. If I would have known posting would have led to this I would have posted much sooner Please, continue... -tjb Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 3, 2006 Share Posted May 3, 2006 can you post or send me the sprites of the 3 rocks? thanks! i would like to make a test... Quote Link to comment Share on other sites More sharing options...
Rybags Posted May 3, 2006 Share Posted May 3, 2006 I think that unwound loop ZR method Heaven posted would be the way to go. Probably split the big asteroids into 5 "strips" ie - 1 strip for left/right columns and the 2nd column 2 strips for the 3rd column - looks like there are a lot of zeros in there. Although, circumstances change depending on the XPOS value I suppose. Maybe reduce the size of the asteroids from 32 to 28 pixels wide? That way, you only do 4 columns instead of 5 of them 50% of the time. Probably do some cycle counting exercises on the rendering of the smaller asteroids - might be quicker to render them a different way? Investigate using page flip (double-buffer) - then you can just ORA the data, and store in zeros instead of the second call with EOR. Big extra memory cost, but a saving in cycles, plus any flickering issues will go away. How will you be doing collision detection (ie shots to rocks)? Apparently, the arcade version uses "collision hexagons" where somehow objects are mapped into hexagon shapes. Quote Link to comment Share on other sites More sharing options...
tjb Posted May 3, 2006 Author Share Posted May 3, 2006 can you post or send me the sprites of the 3 rocks? thanks! i would like to make a test... I'm actually at work at the moment. I can send them later today. What format? Can I send you .bmp files? -tjb Quote Link to comment Share on other sites More sharing options...
tjb Posted May 3, 2006 Author Share Posted May 3, 2006 I think that unwound loop ZR method Heaven posted would be the way to go. Probably split the big asteroids into 5 "strips" ie - 1 strip for left/right columns and the 2nd column 2 strips for the 3rd column - looks like there are a lot of zeros in there. Although, circumstances change depending on the XPOS value I suppose. Maybe reduce the size of the asteroids from 32 to 28 pixels wide? That way, you only do 4 columns instead of 5 of them 50% of the time. Probably do some cycle counting exercises on the rendering of the smaller asteroids - might be quicker to render them a different way? Investigate using page flip (double-buffer) - then you can just ORA the data, and store in zeros instead of the second call with EOR. Big extra memory cost, but a saving in cycles, plus any flickering issues will go away. How will you be doing collision detection (ie shots to rocks)? Apparently, the arcade version uses "collision hexagons" where somehow objects are mapped into hexagon shapes. Thanks for all the ideas. I'll have to look into them. The only collision at present is checking to see if a bullet hits an asteroid. It uses the simple bounding-rectangle method. I'm open for suggestions. -tjb Quote Link to comment Share on other sites More sharing options...
Rybags Posted May 3, 2006 Share Posted May 3, 2006 Maybe have a two-level collision routine: You should keep the screen X-index of the asteroids (0-39) in a buffer (for the restore operations). Then, just convert the missile X to a 0-39 value. Create a similar table for the Y values (0-23). For each missile, subtract the Y value of the asteroid. Then CMP #4. Carry set=out of area. Do the same for X value. Both tests satisfied means the missile/asteroid are in the same viscinity - so go onto level 2 collision detect code: Have a table for each Y value of the asteroid (e.g. 32 entries). Each entry has the actual offset of the start X and end X of the rock in relation to it's screen X value. You then just have to do a range check on 1 or 2 Y entries comparing with the missile's position. Probably better ways to do it. Maybe even have a 5 bytes (40 bits) x24 bitmap where you can represent the presence or absence of the asteroids. Then for each missile, you have a single bit which has to be tested within that bitmap to see if it's a candidate for a collision. The bitmap entries for big asteroids would have a 2x40 byte table, possible values would be (assuming here that x is the byte offset for the object within a screen line) %11110000, %00000000 (x=0) %01111000, %00000000 (x=1) ... %00000001, %11111110 (x=7) Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 3, 2006 Share Posted May 3, 2006 a bmp is fine but i can do my own asteroids for testing in turbo basic xl... the collision description looks interesting i have to think about it... what about the following... who said that you need to use bitmap gfx for the shots as well? what about using 7 player/missles for the "missles" and 1 remaining player for the ufo? whould this destroy the highres look and feel as you can not define player/missles in antic F pixel size? but you could then use the hardware collision checking which might quicker than the boundary box one... but this would mean that you have to sync the collision checking very carefully with the sprite engine otherwise the missles might get inside an asteroid... oh...how many shots can you fire at once in the arcade? as we need bullets for the ufo as well... Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.