Heaven/TQA Posted April 21, 2002 Share Posted April 21, 2002 to speed up development...i need your help... i started to code timepilot... the vram is organized 120x256 bytes as well as the sprite tables... (16x256) the sprites are stored in stripes. the timepilot sprites most have 16x16 pixels so they take on atari 4x16 = 64 bytes... here is my actual sprite copy routine... i used a strange trick as the 6502 has no lda/sta (zero) adress mode... ;--------------------------------------------------- ;copies testwise player sprite in the middle of the screen ;si contains start adress of the sprite ;--------------------------------------------------- test_copy mwa si si0 ;set 4 pointers mva si+1 si1+1 mva si+1 si2+1 mva si+1 si3+1 lda si add #1 sta si1 lda si add #2 sta si2 lda si add #3 sta si3 mwa #screen+14+52*256 di0 mwa #screen+15+52*256 di1 mwa #screen+16+52*256 di2 mwa #screen+17+52*256 di3 ;4 stripes a 16 bytes per sprite (16x16 pixel) ldy #15 ldx #0 test_copy0 lda (si0,x) ;get sprite data sta (di0,x) ;on screen lda (si1,x) sta (di1,x) ;on screen lda (si2,x) sta (di2,x) ;on screen lda (si3,x) sta (di3,x) ;on screen inc si0+1 inc si1+1 inc si2+1 inc si3+1 inc di0+1 inc di1+1 inc di2+1 inc di3+1 dey bpl test_copy0 rts this can not be the fastes copy routine??? what would be the cleverst data structure to be very fast in coping sprites on screen??? the routine should be excepting a source adress (which sprite) and the destination screen adress... so it becomes most flexible (f.e. when animating the sprite...and even moving...) any good ideas??? i thought it would help when the structure is in 256 byte lengths... even the vram... but really??? is this the fastes way? atari 7800 does it in this way... thoughts & ideas welcome... heaven ps this is really crucial before developing further... timepilot on atari 8bit depends on the sprite engine...and the sprite engine depends on the data structure...and this structure must be optimized for 6502... Quote Link to comment Share on other sites More sharing options...
DanBoris Posted April 21, 2002 Share Posted April 21, 2002 It might just be me being dense, but what system are we talking about? Dan quote: Originally posted by Heaven/TQA: to speed up development...i need your help... i started to code timepilot... the vram is organized 120x256 bytes as well as the sprite tables... (16x256) the sprites are stored in stripes. the timepilot sprites most have 16x16 pixels so they take on atari 4x16 = 64 bytes... here is my actual sprite copy routine... i used a strange trick as the 6502 has no lda/sta (zero) adress mode... ;--------------------------------------------------- ;copies testwise player sprite in the middle of the screen ;si contains start adress of the sprite ;--------------------------------------------------- test_copy mwa si si0 ;set 4 pointers mva si+1 si1+1 mva si+1 si2+1 mva si+1 si3+1 lda si add #1 sta si1 lda si add #2 sta si2 lda si add #3 sta si3 mwa #screen+14+52*256 di0 mwa #screen+15+52*256 di1 mwa #screen+16+52*256 di2 mwa #screen+17+52*256 di3 ;4 stripes a 16 bytes per sprite (16x16 pixel) ldy #15 ldx #0 test_copy0 lda (si0,x) ;get sprite data sta (di0,x) ;on screen lda (si1,x) sta (di1,x) ;on screen lda (si2,x) sta (di2,x) ;on screen lda (si3,x) sta (di3,x) ;on screen inc si0+1 inc si1+1 inc si2+1 inc si3+1 inc di0+1 inc di1+1 inc di2+1 inc di3+1 dey bpl test_copy0 rts this can not be the fastes copy routine??? what would be the cleverst data structure to be very fast in coping sprites on screen??? the routine should be excepting a source adress (which sprite) and the destination screen adress... so it becomes most flexible (f.e. when animating the sprite...and even moving...) any good ideas??? i thought it would help when the structure is in 256 byte lengths... even the vram... but really??? is this the fastes way? atari 7800 does it in this way... thoughts & ideas welcome... heaven ps this is really crucial before developing further... timepilot on atari 8bit depends on the sprite engine...and the sprite engine depends on the data structure...and this structure must be optimized for 6502... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 22, 2002 Author Share Posted April 22, 2002 dan, of course plain atari 800xl with 64kb ram... so it will not run on 5200... mva, mwa = pseudo built in instruction in xasm mva = move value with accu mvx = move value with x mvy = move value with y mwa = move word with accu mwx = etc... just for those who might be confused... heaven ps. activision's zone ranger should have a quite good sprite engine incl. scrolling... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 22, 2002 Author Share Posted April 22, 2002 a quick look into the 5200 code of zone ranger (with atari800win monitor) shows this code @ $09a8 lda ($fe),y eor $2140,x sta $2140,x iny lda ($fe),y eor $2168,x sta $2168,x iny ... adding $28 = 40 to the adress seems to be too obvious... this must be the vram. a double check with DLIST shows that the vram is organized as mode e with 40 bytes per scanline... the gfx data is @ $b000 - $bfff try to enter in the monitor f b000 bfff aa this turns the flame of the rocket engine into brown squares.... hmmm.... why the hell it is so fast??? hve Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 22, 2002 Author Share Posted April 22, 2002 well... the rocket flame is from $b000 $b0ff the asteroids are at $3400 - $34ff could some of the atari pro's look into the code and figure out how the gfx engine really works? it is interesting... every speed up which i had in mind is not used in the code... the vram is from $1000 - $2e00 with 40 bytes per line... no double buffering in the area $a000 - $afff seems to be some position tables of the sprites incl. there modes and there resolution for the sprite engine... i am impressed how fast this thing works... i even haven't found that the sprites are preshifted for pixel positioning... it seems that the sprite engine is doing this in realtime... crazy... the reason could be because it is an atari 5200 game and 16 kram with ~8k for video ram... well...not much space... any comments welcome... heaven Quote Link to comment Share on other sites More sharing options...
Sheddy Posted April 22, 2002 Share Posted April 22, 2002 Not much time to look at it but........... Looks like Zone Ranger has sprite copy pretty optimized from your fragment. no indirect access to screen, no add to next screen line, x reg for the x pos on the screen, y reg for position in sprite strip. But how does it exit when done? Does it self modify the code? Makes sense to use indirect y rather than x. Working with the y register not against it. iny only 2 cycles inc zp 5 cycles... Chris PS my routines not optimized for fixed width they'd be not as fast as this for time pilot Guess this should go here now too.... quote: Heaven, no big deal on the masks. just an "or" then an "and" with the mask. slower than eor of course though... the mask should have bits set when there is a seethrough pixel in the data though, otherwise the mask bits should be the same as the data, for the most straightfoward "seethrough" effect. some eg using 2 bit pixel, data ends up on top: screen pixel=00, data pixel=01, mask=01 01 or 00 = 01. 01 and 01 = 01. screen pixel=10, data pixel=01, mask=01 01 or 10 = 11 11 and 01 = 01 screen pixel=10, data pixel=00, mask=11 00 or 10= 10 10 and 11= 10 If anyone knows a better way, now would be a good time to share! Of course you want to avoid masking at all if you can...you could draw the big clouds with no masking, then underlay the enemies, using the same method. PS I don't think having a wider, shorter normal "landscape" screen would affect the gameplay much - Unless you're going for arcade exactness, or for speed/memory reasons. [ 04-22-2002: Message edited by: Sheddy ] Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 23, 2002 Author Share Posted April 23, 2002 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... hve Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 24, 2002 Author Share Posted April 24, 2002 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 April 25, 2002 Author Share Posted April 25, 2002 does VSS 5200 emulator have a single step debugger and brake points etc??? that would be cool because this is missing in atari800win 3.0 hve Quote Link to comment Share on other sites More sharing options...
DanBoris Posted April 25, 2002 Share Posted April 25, 2002 quote: Originally posted by Heaven/TQA: does VSS 5200 emulator have a single step debugger and brake points etc??? that would be cool because this is missing in atari800win 3.0 hve Sure does! Dan Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 26, 2002 Author Share Posted April 26, 2002 excellent... what the hell are "brake points"... but seems to fit there, too... of course i ment break points.... hve Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 26, 2002 Author Share Posted April 26, 2002 well... dan, zoneranger in vss .80 debug version runs quite fast...is the reason NTSC? if yes...then the sprite engine is really good... on this weekend i will start to code the 1st enemies... hve Quote Link to comment Share on other sites More sharing options...
Jetboot Jack Posted April 26, 2002 Share Posted April 26, 2002 Heaven, I dug up a ZR cart and had a play - I see what you mean - that really is a pretty fast engine both on PAL and NTSC systems - they seem to use the same sprite masking technique as Donkey Kong - giving neat overlap colors when s/w sprites are overlaid - can't wait to see your stuff! sTeVE Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 28, 2002 Author Share Posted April 28, 2002 another few things discovered in zoneranger... as we found out that at $ae60 you find the sizes of the the sprites in bytes...but we had no clue how the position on pixel bases is done here are my comments... f.e. at ae60 is the size of the asteroid. (try to change it to 02 or 07 with the "C" command in the monitor...) but wait... if we assume that zoneranger (ZR) is not shifting the sprites in realtime there must be an indicator because sprites on pixel positions 0,4,8,12,16, etc... do not need extra byte in x position but on 1,9,13,17, etc... why? (here just for the newbies)... take a look on this sprite (4x4 pixel...but in multicolor mode!!! antic e) 1111 1..1 1..1 1111 this sprite would need 4 bytes in total...as 1 byte can hold 4 pixel... if we want to position the sprite on screen position 0,0 than we can copy it straigth forward into the video ram... lda #%11111111 sta vram lda #%11000011 sta vram+40 lda #%11000011 sta vram+80 lda #%11111111 sta vram+120 seems logical... now the tricky part starts: what if we want to put the sprite on position 1,0??? on 6502 we can just copy bytewise...but this would not work here... we have to shift the sprites by ourself...best of course not doing it in realtime but precalculated... the sprites are stored in memory prepared to be positioned on every pixel position: for "0 position" 1111 0000 1001 0000 1001 0000 1111 0000 for "1 position" 0111 1000 0100 1000 0100 1000 0111 1000 for "2 position" 0011 1100 0010 0100 0010 0100 0011 1100 for "3 position" 0001 1110 0001 0010 0001 0010 0001 1110 so that this doubles the memory for each sprite... and this is exactly what ZR is doing... getting the sprites out of ROM. shifting them "manually" at the beginning in RAM so the spriteengine is more or less an intelligent "COPY" routine... as you may see is that positioning on 0,4,8,12, etc... is useless top copy the right bytes because they are 0... this is useless... and here you see that ZR takes this in consideration... the tables at $ae60 are holding the X-size in bytes of each sprite even from the shifted ones!!! $ae60 = 3 as the astoid is 16 pixel wide (4x4 pixel -1 because of the loop in the code) $ae61 = 4 same as above but with 1 extra byte $ae62 $ae63 these 4 bytes refer to one sprite depending on the x-position. if you change them manually than you see flickering while the asteroids are moving to the right/left... because 1 byte which is needed for smooth moving is left out... knowing this structure makes it easier to understand the sprite-management. the sprite engine has lookup tables for each sprite which is stored later in $fe (compare yourself with the loop at $0600 ff.) which are indexed by the x-pos divided to 4... (as 4 bytes in the lookuptables refer to one sprite...) so the adresses at $ad40-$ad43 (lo-bytes) and $add0-$add3 (hi-bytes) point to the 4 sprites or "shapes" of the asteroid talked before... and have a close look to add0-add3 $af80 asteroid non shifted $33d0 asteroid shifted 1 pixel $3414 asteroid shifted 2 pixel $3458 asteroid shifted 3 pixel to the right now the sprite engine can easily positon an asteroid to every pixel position... (well... actually it does not know what it really does... ) now it was easy to search for the routine where all of the sprites are shifted... and you find the routine at $4141 - $4197 puuuh... another secret solved... hve ps. later today i start with the core engine of timepilot sprite engine... voila... at $afd0 is the asteroid non shifted... (and this is ROM space of 5200? isn't it???) $33xx Quote Link to comment Share on other sites More sharing options...
Sheddy Posted April 28, 2002 Share Posted April 28, 2002 It's a cool engine, maybe you can get 50/60 frames per second, with luck (and skill of course! ). It really does looks ideal for Time Pilot - Can't wait to see more. I'm just sad I can't steal more of its tricks too - (but I saved 450 cycles on my background drawing using self modifying code inspired by it) Do you know how you're going to do the clouds yet? I take it you're using all the player/missiles just for extra colours now? Chris Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 28, 2002 Author Share Posted April 28, 2002 450 cycles are a lot... i am happy that my "tutorial" helps others in speeding up their work, too... the clouds will be software sprites. steve had the brilliant idea to modify the color sheme combined with player/missle gfx (ok... they have to be reduced to 2 colors instead of the original 3 colors but anyway...) i don't believe that the engine will be capable to do 50/60 frames per second as most of timepilot sprites are 16x16 pixels... and the clouds are even bigger size as well the zeppelin & bombers... so compared to zoneranger it seems more action on screen as in ZR... but we will see... btw... the my technical concept looks like i will use 1) sprite engine1 for the player itself 2) sprite engine2 for the enemies 3) sprite engine3 for the shots & missles 4) sprite engine4 for the clouds (...) the core sprite engine is the same for all of the 4 engines... but i guess you can tweak the engines by having more constant values instead of table lookups... f.e. the shots are 4x4 pixel, the player is standing always on the same screen position. the enemies are same sizes... i think in ZR the RAM was very shorten as it fits into the 32k rom & 16kram of 5200... but as 800xl version with 64k... why not trying to sperate them... hve Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 29, 2002 Author Share Posted April 29, 2002 well... time pilot (space pilot) on c64 sux... any real conversion avaible? c64.com does not show anything... hve Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 29, 2002 Author Share Posted April 29, 2002 guys, help me... i updated the files again... http://www.s-direktnet.de/homepages/k_nadj...j/timepilot.zip i started to code the shot-sprite engine...it works...but when the shot is getting closer to the plane sprite it leaves f... artifacts...why???? maybe some of you have an idea why? maybe even looking into the provided source code??? you can assemble it with "ASM time2" the time.asx is the old one... time2.asx is the actual source code...just load it into any ascii text editor... and another really strange bug is that the plane when turning backwards down is completly destroyed... but just in time2...in time.asx it is all ok... cheers & thanx for any support even when it is moral... hve ps. have to go sleeping...i have to prepare tomorrow e3 presentation... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 29, 2002 Author Share Posted April 29, 2002 oops... http://www.s-direktnet.de/homepages/k_nadj...g/timepilot.zip http://www.s-direktnet.de/homepages/k_nadj.../timepilot.html Quote Link to comment Share on other sites More sharing options...
Jetboot Jack Posted May 1, 2002 Share Posted May 1, 2002 Heaven, I get corruption in both demos - a blank line randomly appears in the ship in the 1st demo, and the "junk" frames in the second... sTeVE Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 1, 2002 Author Share Posted May 1, 2002 well...that are exactly my problems... i don't find the bugs... well... the destruction of the sprites is fixed the same with the scanline... but what i am not able to fit right now is the flying shot... when it comes close to the ship the engine seems to put 2 of them there and after passing the ship the 2nd disappears... fox, our main coder, gave me some hints concerning his kernel so i can use now DLIs as well... stay tuned... hve Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 6, 2002 Author Share Posted May 6, 2002 bugs fixed... find new archive on my site... unfortunatly i have made or missed some sprites... check it out... that is the reason why the player is rotating wrong... (but i am on the right way... does it not look good anyway???) the bug in the sprite engine is found and solved... it was a tricky one... the code was correct BUT: you have to be sure when you are drawing what... the general sprite engine is working with EORs so if you draw the sprite twice it will disapear when the position is the same... the player sprite is drawn via direct copy into vram so no EORs needed because you draw always on the same position... ergo: the correct way to avoid the "double" shot when getting in the sprite area of the plane is: 1st clear the shot 2nd draw plane (the player sprite in the middle of the screen) 3rd move & draw the new shot in the 1st version i had this order 1st draw plane 2nd erase old shot 3rd draw new shot and...of course it could be that the sprite is putting some "unknown" pixels in the "shot" so erasing via EOR does not work anymore because of the "unknown" pixels from the plane... hmmm...sounds more complicated than it is... but with thism new order it works.... my intuition is telling me that this problem will maybe occure when not just 1 pixel is moved but with tons of sprites on screen... but f.e. move sprite 1,2,3,4,5,6,7 draw sprite plane,1,2,3,4,5,6,7 erase 7,6,5,4,3,2,1 should avoid this ghost pixels... what do you think? hve Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 3, 2002 Author Share Posted June 3, 2002 as you may have seen... core engine works... next step will be to implement smooth positioning in the engine...further then different cloud shapes & lookup tables to be more flexible. hve (tired) Quote Link to comment Share on other sites More sharing options...
Jetboot Jack Posted June 4, 2002 Share Posted June 4, 2002 WOW! Demo 4 is great - your approaches potential looks VERY promising sTeVE Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 24, 2002 Author Share Posted June 24, 2002 i need help in converting the sprite data into suitable format for timepilot... if someone could help me to cut out the sprites out of the "screenshots" from mame and send the stuff to me as BMP or PCX or PNG would be a great help. you don't have to reduce the gfx to 4 colors...i will do that... the only restriction is that the sprites must be aligned correct which means on every 4th pixel... 0,4,8,12, etc... who will help me? so i can spend more time on the gfx engine and game logic... hve ps. of course your credits will be included in the game Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.