Heaven/TQA Posted December 12, 2003 Share Posted December 12, 2003 thanks to TMR and others @ lemon64 i discovered what i wanted to code for ages since i have seen hard's scroller (2nd screen in joyride with the amiga animation) a sprite multiplexor... the basics are quite simple and i decided to use the stuff for 4pac highscore table (kind of PSone name entry with rotating chars band etc...) TMR, unfortunatly i'll start it on atari as there i dont have to bother with IRQs and rasterroutines... if you don't mind... i'll put 32 8x8 players on screen at once but will make sure that there are not more than 4 per scanline... find attachted the turbobasic test file where you can see that its possible... more infos here: http://www.student.oulu.fi/~loorni/covert/...ants/sprite.htm have fun reading that... boot atr and then type "LOAD "d:*.tur" + "RUN" multiplex.zip Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 13, 2003 Author Share Posted December 13, 2003 ok. more time now to explain the basic program. i have written this small tiny tool just to show me how many chars (imagine that these chars will be later real hardware player/missles) would be overlapping. so i just draw a circle and point 16-32 chars on the circle, the "scanlines" show how near these chars would be and how many are overlapping. as you can see (hope i have interpreted the results correct) i should be able to display all of the chars without any hardware restrictions... i hope to get a 1st assembler example this afternoon Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 13, 2003 Author Share Posted December 13, 2003 ok... after spending 5 hours of coding... i am stucked... as i havent here my orginial 130xe can someone please test my 1st attempt of a sprite multiplexor? at the moment it looks like the sentines attacking zyon... i have NO clue why the hardware registers are f... up (player sizes, pmbase lost, etc... check in atari800win the GTIA registers...) after rethinking the whole sprite multiplexor techniques from c64 my question is now that is this even necessary for atari machines? i mean the sorting of the virtual sprites? as i have to build the tables anyway from scratch for the player missle display as the atari sprites are 8x256 and not 24x21 pixels... hmmm... but 1st i'll fix this bug... attachted the whole dev zip incl. sources + atr + xasm... any help appreciated and sorry for not posting in the programming forum.... i assume that here atari computer related guys are browsing more often. multiplex.zip Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 13, 2003 Author Share Posted December 13, 2003 ok...some bugs found... the subroutines were not synced properly together thats why the garbage appeared. when reducing the max. sprite amount down to 16 virtual sprites you the garbage is gone BUT still not like it should be... attachted the new archive... what i have discovered is that the sprites are now distorted in x-direction... if you check the xpos tables in memory you see that they are all inced by one each scanline... why? i have no clue... when not adding offsets to move the sprites right and down the xpos tables in memory are not altered...but i definitly cant see how an "inc sortsprx,x" could affect the mapper... maybe i have to reverse engineer activision titles like river raid which are doing multiplexing as well (but not in freedom like i want the engine to be...) multiplex.zip Quote Link to comment Share on other sites More sharing options...
analmux Posted December 13, 2003 Share Posted December 13, 2003 Maybe I can help. I'm not sure I completely understand your problem. Firstly, what kind of gfx mode do you use, and are you using DLIs or some kind of kernel routine? ----- mux Quote Link to comment Share on other sites More sharing options...
analmux Posted December 13, 2003 Share Posted December 13, 2003 I had a look in the asx file. Could it be that the sorting routine takes too much time???? Quote Link to comment Share on other sites More sharing options...
analmux Posted December 13, 2003 Share Posted December 13, 2003 ...just one detail. Instead of ;init hardware sprites pm_init ldx #0 tax pm0 lda #$0 sta p0,x sta p1,x sta p2,x sta p3,x+ bne pm0 I would code: ;init hardware sprites pm_init ldx #0 tax lda #$0 pm0 sta p0,x sta p1,x sta p2,x sta p3,x+ bne pm0 That would be faster. The accu would not need to be redefined by zero everytime. I don't see why you'd need a spritesorting routine. Many parts of the code can be optimized, and would save a lot of time. Maybe then 32 sprites are possible. ----- mux Quote Link to comment Share on other sites More sharing options...
Fröhn Posted December 13, 2003 Share Posted December 13, 2003 I would code: ;init hardware sprites pm_init ldx #0 tax lda #$0 pm0 sta p0,x sta p1,x sta p2,x sta p3,x+ bne pm0 That would be faster. The accu would not need to be redefined by zero everytime. i would do unrolled STA STA STA... because then you safe the BNE and you only have 4 cycles per STA rather than 5 for STA ...,X Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted December 13, 2003 Share Posted December 13, 2003 Unrolled? Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 13, 2003 Author Share Posted December 13, 2003 @ all yes. of course the code can be optimised but 1st i wanted to have a running system and then try to optimise. there aer a lot of places where you can apply standard 6502 optimisations to speed up code... - unroll loop - put code / varialbles into zeropage - avoid CLCs - allign loops on memory pages - use clever interrupts - reuse old valvulated values - lookup tables @ nukey unroll = unfold looos. so you get ridd off the overhead cycles for managung the loop... imagine this: ldx #3 loop sta p0,x dex bpl loop can be written as or as ldx #3 sta p0,x dex sta p0,x dex sta p0,x dex sta p0,x @ all the code at the moment doesnt use any gfx mode right now... it uses the unbelievable display list for max speed $80,$41,dlist and then one DLI handles the writing into the hardware registers for 200 scanlines... of course this can be done like setting DLIs every frame by setting the DLI bits into a display list where sprites appear. http://www.geocities.com/SiliconValley/Vis...6084/progs.html to get a better feeling of what i want to achieve, download joyride from the above link. you can load the DCM file into atari800win like normal ATR image. machine is 800xl PAL 64k. run the demo and after the plot tunnel the scroller based on players is coming up... and this is kind of multiplexer as well... (but done in another way but just to get an idea...) or load armalyte into your c64 demo and on the title screen you have a multiplexer as well running remember that you normally have 8 sprites max. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 13, 2003 Author Share Posted December 13, 2003 maybe i'll rewrite completly my mapper tomorrow and write the engine in that way that it uses multiple DLIs then i can get away from building xpos, color tables for the sprite? on c64 you can easily setup new sprites by altering the xpos,ypos,sprite pointers with some STAs... but on atari 1st thought this can be done as well... yes and no... i have to setup the whole player data each frame as they cover the whole screen & because of the vertical movement. altering the shape needs additional code coping sprite data into the player area when multiple sprites are used per 1 hardware player... on c64 you simply set a new y-value and new sprite pointer to new gfx data...rest is done by hardware... i mean this kind of problem & engine must be used by 2600 programmers whith 2 hardware sprites as well??? Quote Link to comment Share on other sites More sharing options...
analmux Posted December 14, 2003 Share Posted December 14, 2003 Yes, I know the joyride text scroller that bounces like a sine-wave, on top of some other graphics. In fact it's the same as your idea, but sprites move over a different path now. If you're adding the Playfield graphics later, be careful when using charmodes. Every first rasterline (of an antic 4 line f.e.) eats away more cpu time than usual. You can't change too much (PM) registers in such a line, say 3 or 4 reg-changes. ----- mux Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 14, 2003 Author Share Posted December 14, 2003 @ anamux yup... i am afraid of real background gfx... but maybe it's better to optimise and to rewrite the code just for the highscore table for my 4pac project and not a generic one... thanks for your help here... Quote Link to comment Share on other sites More sharing options...
analmux Posted December 14, 2003 Share Posted December 14, 2003 @ anamux You seem to hate the 'l' in 'analmux' I almost regret to have chosen this nickname it's just an abbreviation of ANALogue MUltipleXer, but you can indeed make something else out of it. ----- mux Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 14, 2003 Author Share Posted December 14, 2003 @ mux sorry for that... i have rethought the whole engine so what about the following: 1. sorter the sorter will sort the 16 virtual sprites as mentioned above. i am still not sure if this is really necessary on atari hardware but we will see at the end. 2. mapper the mapper will have several different tasks: 1st build the DLI chain and 2nd build the player/missle data based on the sorter & on the virtual sprite list. the mapper will take care of not mapping more than 4 virtual sprites to hardware sprites per scanline. the 1st step in implementing will be to have 1 generic DLI for remapping 4 sprites. scheme could be DLI pha lda #xpos0 sta wsync sta hposp0 lda #xpos1 sta hposp0+1 lda #xpos2 sta hposp0+2 lda #xpos3 sta hposp0+3 lda #next_dli sta dliv lda #>next_dli sta dliv+1 pla rti the mapper will build up the DLI chain and insert directly the position data in the DLI code so we do not need special position tables for the display kernel... if this works later on maybe it is enough time for the mapper to use different DLIs specialist for 1,2,3,4 players per scanline so the executing time gets lower per frame... so... looks good...i'll start to recode the stuff now. Quote Link to comment Share on other sites More sharing options...
analmux Posted December 14, 2003 Share Posted December 14, 2003 If you're using a bitmap mode behind the PMs, why not horizontally multiplexing, to have more than 4 players on a scanline. You can easily add a 5th player by a mid-scanline regchange to HPOSP0 and GRAFP0 (and eventually COLPM0) By the way, do you leave the missiles (as 5th player) unused? Off course they would need much more cpu time to move/multiplex. ----- mux Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 14, 2003 Author Share Posted December 14, 2003 at the moment i've planned not to use the missles for 5th player as it needs additional handling because of the 4 new registers just to gain the 5th player... midline changes not yet... 1st the "normal" 4 player multiplexor should work... otherwise it gets too complicated at the 1st stage... ps. unfortunatly i havent worked on the code guess why... i've played for hours koronis rift... what a nice and well decined game... ("which upgrade does what?" "where is the next hidden one") Quote Link to comment Share on other sites More sharing options...
Sheddy Posted December 15, 2003 Share Posted December 15, 2003 This'll be really nice I can't fully follow your code, but I figure you must have a sorter of some kind as you must still update x positions and colours in the display order of the screen (y position) - maybe it doesn't need to be as accurate as the C64 method though? A Radix/bucket sort could be OK? The Y data can be written anytime of course Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 15, 2003 Author Share Posted December 15, 2003 @ sheddy radix sort is implemented and working... next will be the mapper... stay tuned. yesterday i have ripped the font from armalyte for my sprite demo... it took me nearly 2 hours just to find the font in vice... it drove me crazy that i haven't realised the c64 $dd00 register... i just followed $d018 and tried to find the font... but without knowing the $dd00 "VIC BANK" its kind of endless search... fortunatly i found a website describing the VIC registers + mentioning the BANK register $dd00... so i could ripp it (its @ $7800 btw...) then another hour for remapping the font to atari font and i have it now... stay tuned... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 23, 2003 Author Share Posted December 23, 2003 in meantime while i am coding this engine further check joust which seem to have a similiar engine running as you have more than 4 players on screen... (and the flickering is obvious...) Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 23, 2003 Author Share Posted December 23, 2003 ok... joust definitly uses a mapper, just enter following command in the monitor c a51e 20 and continue the game. best is on expert level to get more sprites on screen in wave 1.... i hope you see how the engine is fooled... and you see as well that the missles are used as well... the DLIs are at $a4ca ff. check out $a511 ff.... now i have just to find the sorter and the mapper... btw. the DLIs do not use any WSYNC... strange... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 23, 2003 Author Share Posted December 23, 2003 another interesting point is that the collissions seems to be checked virtually not via hardware (esp. on the background) as you see the white missles "hitting" the platforms correct as there would be a joust hitting it... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 23, 2003 Author Share Posted December 23, 2003 ok... the engine is slowly progression... attachted the new version with a "DLI chain"... right now there are no player objects on screen, this version is just to test... the engine generates custom display lists (here antic e) and sets depending on the y-positions of the virtual sprites DLI bits... similar to the raster interrupts on c64... the white rasterlines reflect where a raster split appears and where repositioning of the hardware sprites should be done... i let the basic movement in just to see if there are any glitches... not at the moment... (ok... here a frame missed, there one... nevermind) next to implement are the sprite data to be copied quickly into the pmbase and the mapper filling the "hardware slots" with virtual sprite data.... oops... it's christmas... merry x-mas guys... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 23, 2003 Author Share Posted December 23, 2003 forgotten to attach... plex2.zip Quote Link to comment Share on other sites More sharing options...
Fröhn Posted December 24, 2003 Share Posted December 24, 2003 If you're using a bitmap mode behind the PMs, why not horizontally multiplexing, to have more than 4 players on a scanline. You can easily add a 5th player by a mid-scanline regchange to HPOSP0 and GRAFP0 (and eventually COLPM0) horizontal multiplexing will not work since the sprite shifters are only loaded once per rasterline. 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.