Heaven/TQA Posted December 24, 2003 Author Share Posted December 24, 2003 fröhn... this is true for c64 vic but on atari you can alter the sprite registers "on the fly" in a scanline... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 24, 2003 Author Share Posted December 24, 2003 small progress made... to make more visible have a look on the new version... player data is filled with the numbers 1-4 to make the hardware sprites visible... unknown still what is happeing if f.e. players 1-4 are sitting on one scanline............ as at the moment the DLIs (white lines...) are mapping each scanline one virtual sprite to one hardware sprite... plex2.zip Quote Link to comment Share on other sites More sharing options...
emkay 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. Take a look at this screenshot: You can see two vertical sinewave-text-scrollers The "endless BOBs" are done by bitmap The Sinewave is doubled by doubling all Player-positions every scanline. In theory you can build up to 4x240 "one line Sprites" (the demo uses approx. 200 lines) and here they are doubled though for "boring" scrollers Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 24, 2003 Author Share Posted December 24, 2003 emkay... i would call this "hardware multiplex", what i am doing is software multiplexing... sort of... btw. which demo is your screenshot from? Quote Link to comment Share on other sites More sharing options...
emkay Posted December 24, 2003 Share Posted December 24, 2003 emkay... i would call this "hardware multiplex", what i am doing is software multiplexing... sort of... btw. which demo is your screenshot from? Bitter Reality Quote Link to comment Share on other sites More sharing options...
analmux Posted December 25, 2003 Share Posted December 25, 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. Take a look at this screenshot: You can see two vertical sinewave-text-scrollers The "endless BOBs" are done by bitmap The Sinewave is doubled by doubling all Player-positions every scanline. In theory you can build up to 4x240 "one line Sprites" (the demo uses approx. 200 lines) and here they are doubled though for "boring" scrollers 3 @ Emkay I think Frohn means that you can not change the graphics data of PM in the same scanline. You can see that the multiplexed PMs in your demo don't change any PM data or color registers. It doesn't make any sense to change the PMBASE register mid-scanline. ...but on the other hand.... @ Frohn You CAN actually change the graphics data by a simple write (at the right time) to GRAFP0-3 registers (for non-DMA PM graphics). Indeed you're right, with DMA on the graphics data is loaded automatically by hardware on the start of a scanline. But when player 0 is on the far left side you'll have enough time to change the three needed registers to multiplex player 0 completely (color, position and SHAPE!), however you're limited to the far right side to reposition player 0. ..sounds like a nice little programming/demo project for me to proove this ----- mux Quote Link to comment Share on other sites More sharing options...
emkay Posted December 25, 2003 Share Posted December 25, 2003 @Analmux I am pretty shure, it would be possible to change the "face" of a sprite mid Scanline. But I would be "not" possible to multiplex 4 players in cause of some lacking CPU cycles... What do you think about a "PM" Interlace mode...Instead of normal flickering? Do you remember? Interlace with moving elements does not hurt the eyes. And it is only necessary when more objects are needed... Give it some "sorting" routines like Heaven's and build doubling of Players with line-by line Interlace. If they are on different vertical positions, you don't need the Interlace... Quote Link to comment Share on other sites More sharing options...
analmux Posted December 25, 2003 Share Posted December 25, 2003 @Analmux I am pretty shure, it would be possible to change the "face" of a sprite mid Scanline. But I would be "not" possible to multiplex 4 players in cause of some lacking CPU cycles... Yup, that's what I said too. Here, watch this demo I wrote today (after the Xmas Turkey ). Be sure to run it on a real machine or a perfect emulator that supports midscanline changes. [source code included] Player 0 is multiplexed on the right side of the screen, so the changing of the PM graphics mid-scanline is proven. There are also several other player-positions changed every scanline, and there's random background bitmap graphics (in the highest DMA mode possible: 40 cycles stolen per scanline) I must admit it takes a lot of cpu-cycles, especially with background graphics on and lots of other changing registers. It should even be possible (when there are not much other registers to be changed) to multiplex 2 (maybe 3) players each scanline. Which gives us 7 or 8 players (included 4 missiles as 5th player!). What do you think about a "PM" Interlace mode...Instead of normal flickering?Do you remember? Interlace with moving elements does not hurt the eyes. And it is only necessary when more objects are needed... Like before, you have some vague ideas, Emkay . I don't understand. Can you illustrate your idea? Maybe a picture?? ----- mux Quote Link to comment Share on other sites More sharing options...
analmux Posted December 25, 2003 Share Posted December 25, 2003 {OOPS double posted} Quote Link to comment Share on other sites More sharing options...
analmux Posted December 25, 2003 Share Posted December 25, 2003 Okay, some explanation of the demo: The DLI kernel: topdli pha txa:pha tya:pha ldy #0 sta wsync mva #3 gractl ...Turn on GTIA's PM fetch data enable on first line... ldx z_resx lda sintab_32_d,x sta hposp0+3 lda #191 sta z_count tdli_0 sta wsync lda sintab_32_a,x sta hposp0 lda sintab_32_b,x sta hposp0+1 lda sintab_32_c,x sta hposp0+2 lda sintab_32_e,x sta hposp0 lda pmb0,x sta grafp0 Writing postitions of player 0,1,2. Repositioning and reshaping player 0. Color unchanged! inx dec z_count bne tdli_0 lda #0 sta hposp0 sta hposp0+1 sta hposp0+2 sta hposp0+3 sta gractl sta grafp0+4 pla:tay pla:tax pla:rti Turning off GTIA's data fetch, and making PMs disappear again. ----------- Here is a screenshot of the demo: imagine the sine-shaped bars moving up. From left to right: player 0 [orange] player 1 [red] player 2 [purple] player 3 [blue] missiles 0-3 (as 5th player) [white] player 0 again (multiplexed) [orange] Pmbase = $c800-$cfff (fine resolution) ----- mux Quote Link to comment Share on other sites More sharing options...
emkay Posted December 25, 2003 Share Posted December 25, 2003 Like before, you have some vague ideas, Emkay . I don't understand. Can you illustrate your idea? Maybe a picture?? Correct me if I am wrong... Flickering sprites are because of the usage of sharing one HW "Sprite" every other Frame. Frame 1 : Face a, pos a Frame 2 : Face b, pos b Frame 3 : Face a, pos a Frame 4 : Face b, pos b ... The interlace means a number of DLIs splitting the pos. The face can be exchanged by VBI... Frame 1: pos a.........pos b 11111111...0000000 00000000...1111111 11111111...0000000 00000000...1111111 Frame 2: 00000000...1111111 11111111...0000000 00000000...1111111 11111111...0000000 When leaving the Background without Interlace and while moving the Players, the interlace in the sprites will not be recognized that easy By using a backgroundcolor with a near brightness to the Sprites, the sprites will perhaps only look some kind of transcluent... Quote Link to comment Share on other sites More sharing options...
analmux Posted December 26, 2003 Share Posted December 26, 2003 @ emkay, I've wrote another demo. I think this is what you mean. Indeed it seems to be somewhat less flickery with interlace. See picture of two consecutive frames: The upper sprites are the same as the lower sprites, except that they are drawed over background bitmap gfx. The middle sprites show what you see without any interlacing or flickering. The two left players use the flickering method, the two right players use the interlacing method. That makes it easy to compare the concepts. ----- mux Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 26, 2003 Author Share Posted December 26, 2003 @ analmux nice done... my engine is nearly finished... i haven't coded for 2 days now just thinking and playing with code in my head... but i am sure that i am nearly at the "joust" status... the only thing what my engine is missing at the moment is flickering of 2 sprites via interlace like in joust... at the moment it's like on c64 engines that you will never have more than 4 hardwaresprites per scanline... you may ask yourself why? what do we gain then? well... the engine is flexible to be adaptable for any kind of game (i hope so... ) so you might get 8,16,24,32 virtual sprites which you can move around the screen... the resolution of the objects will be 8x8x1. your game just needs to take care that positions & move patterns will not overlapp and produce more than 4 sprites per scanline... Quote Link to comment Share on other sites More sharing options...
emkay Posted December 26, 2003 Share Posted December 26, 2003 @ emkay, I've wrote another demo. I think this is what you mean. Indeed it seems to be somewhat less flickery with interlace. See picture of two consecutive frames: The upper sprites are the same as the lower sprites, except that they are drawed over background bitmap gfx. The middle sprites show what you see without any interlacing or flickering. The two left players use the flickering method, the two right players use the interlacing method. That makes it easy to compare the concepts. ----- mux Superb I am pretty shure too that the Interlace will not be recognized on a PAL TV when the Sprite ist h.&v. moving. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 26, 2003 Author Share Posted December 26, 2003 small step ahead... horizontal movement is done... right now the engine can easily handle 16 8x8 sprites... attachted the latest version... you will recognise an bug... one of the damned 16 sprites is positioned wrong... but i am too lazy to fix that now... thanks, ps. don't ask my girlfriend what she thinks what i am doing whole christmas... plex3.zip Quote Link to comment Share on other sites More sharing options...
analmux Posted December 26, 2003 Share Posted December 26, 2003 ps. don't ask my girlfriend what she thinks what i am doing whole christmas... Sooner or later she'll find out, dude. She may be watching your internet actions from another PC. Lucky me, my girlfriend knows about my atari obsession. She finds it kind of cool ----- mux Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 26, 2003 Author Share Posted December 26, 2003 @ analmux she knows my obsession for coding as well... she has no problem with it... but try to explain a non nerd what a sprite multiplexor is... so no worries here... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 29, 2003 Author Share Posted December 29, 2003 its nearly here... started more than 2 weeks ago... with heavy help from c64 guys (in terms of multiplexing basics)... heavy coding with damned debugging weird code... here is again a new alpha of the engine... the only thing which was possible to transfer from c64 was the "green beret" fast sprite sorter & the concept... all other code had to be adapted & rechanged by me... (as on c64 you have hardware sprites...simple to update by some STAs in terms of positioning, color, shape... on atari except for horizontal positioning and color everything is done "by hand"...) if you have any questions & comments... just drop me a line... now back to bed... (after coding & thinking more than 12 hours in a row...) to do: - optimise code (no music anymore...) - optimise code - optimise code - comment source code... (i am a hacker... no structured coder... ) plex4_debug.zip plex4_8.zip plex4_16.zip Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 29, 2003 Author Share Posted December 29, 2003 bigger picture Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 29, 2003 Author Share Posted December 29, 2003 and the one with music...causing some more flickering... later today i'll start optimising, like switching OS complete off using own TQA mini-kernel, sorter routine will be moved into zeropage, important lookup tables into zero page or alligned on page boundaries, etc... plex4_mus.zip Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 29, 2003 Author Share Posted December 29, 2003 ah... the flickering is caused by more than 4 hardwaresprites per scanline... i forgot to implement the rejector... another task for later today... good night... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 4, 2004 Author Share Posted January 4, 2004 after leaving the code for more than 1 week i discovered several a-bugs... which means logical errors in the mapper... i have a DLI running which should display the players depending on how many are in one region of the screen... but a test showed that it displays not more than 2 hardware sprites per scanline & DLI which is causing the flickering... after reducing the max. sprites to 4 (so they are mapped every time to the hardware correctly) and placing a "jmp $e473" in the DLI code where it should display 3 or 4 sprites the emulator do not crashed but it crashed when placing this command into the 1-2 sprite section... this let me to the mapper and it showed that the mapper does not what it should do... counting how many virtual sprites are overlapping and where... so now i am stucked again... but i'll solve this tonight.... for me its not so trivial... here is an example virtual sprite1 = 70,40 (x,y) virtual sprite2 = 50,40 virtual sprite3 = 90,40 virtual sprite4 = 110,40 as you can see the sorter would sort these 4 sprites in this order 1,2,3,4 (all y-positions are the same... 40) so the mapper would now just set 1 DLI at display list position 40 and should copy the sprite data of each sprite into p0+40,p1+40,p2+40,p3+40 the DLI should now position all 4 players in putting 70,50,90,110 into hposp0,hposp0+1,hposp0+2,hposp0+3... the actual code does correctly the copy of the sprite data, the sorting but not the DLI... you see... sometimes even for humans easy tasks are complicated in assembler... or take this example: have in mind that sprite size is 8x16 virtual sprite1 = 50,40 (x,y) virtual sprite2 = 60,50 virtual sprite3 = 70,60 virtual sprite4 = 80,50 virtual sprite5 = 90,40 the sorter gives this result: virtual sprite order 1,5,2,4,3 (sorted in y direction) mapper would copy the sprite data into p0+40 and p0+40 (sprite 1+5) p1+50 p2+60 p3+50 DLIs are set at 40,50,60 for simplicity writing the 50,60,70,80 into hposp0,... so... here you can see the problem... sprite 1 and sprite 5 are overlapping as the hardware can just display 4 sprites per scanline (without nasty tricks... not discussed here...) so the engine must mark sprite 5 as "to be rejected" as the mapper is not allowed to copy data into p0 twice because of overlapping areas (when writing the player data of sprite 5 into p0 it would overwrite sprite data being copied from sprite 1) and the DLI is not allowed to set player0 twice otherwise it sprite0 would be not visible (set some cpu cycles before...) the mapping order is sprite1 to player0, sprite2 to player1, sprite3 to player2, sprite4 to player3, sprite5 to player0 etc... i hope somebody might understand my writings... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 4, 2004 Author Share Posted January 4, 2004 aarg... some error in my writing. here again the example: have in mind that sprite size is 8x16 virtual sprite1 = 50,40 (x,y) virtual sprite2 = 60,44 virtual sprite3 = 70,48 virtual sprite4 = 80,44 virtual sprite5 = 90,40 the sorter gives this result: virtual sprite order 1,5,2,4,3 (sorted in y direction) mapper would copy the sprite data into (order for processing the operations is now the sorted table 1,5,2,5,3) p0+40 and p1+40 (sprite 1+5) p2+44 p3+48 p0+50 DLIs are set at 40,44,48 for simplicity writing the 40,44,48,40 into hposp0, hposp1, etc... so... here you can see the problem... virtual sprite 1 and virtual sprite 3 are overlapping as the hardware can just display 4 sprites per scanline (without nasty tricks... not discussed here...) check the sorted order created by the sorter (1,5,2,4,3) so the engine must mark sprite 3 as "to be rejected" as the mapper is not allowed to copy data into p0 twice because of overlapping areas (when writing the player data of sprite 3 into p0 it would overwrite sprite data being copied from sprite 1). sprite 1 covers p0 area 40- 55 (40+16-1) and sprite 3 (50-65) so 4 pixels are overlapping... and the DLI is not allowed to set player0 twice otherwise it sprite0 would be not visible (set some cpu cycles before...) the mapping order is sprite1 to player0, sprite2 to player1, sprite3 to player2, sprite4 to player3, sprite5 to player0 etc... the engine logic does not recognise yet that f.e. if no sprite isoverlapping another one (f.e. y-coordinates 0,24,48,72,96,etc...) could be mapped directly to one player only by setting just DLIs at 0,24,48,72, etc... altering just hposp0. i hope there is no mistake here again... Quote Link to comment Share on other sites More sharing options...
analmux Posted January 4, 2004 Share Posted January 4, 2004 ...Heaven, just one question, I'm curious: How much time (cpu-cycles) does the sprite-sorter need (for sorting 16 sprites) ?? Can you show me a demo-pic? Just put a: mva #15 colbk at the beginning of the routine, and a: mva #0 colbk at the end, and make sure the routine starts at the top of screen. Then (counting white scanlines) you can determine the amount of needed time. I would like to know. ----- mux Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 4, 2004 Author Share Posted January 4, 2004 @ analmux here we are... screenshot taken with 16 virtual sprites. please have in mind, it's just the sorted... no data copy & moving objects nor music player nor DLIs... all switched of just the pure sorter. "Dragon Breed" sorting routine ; www.student.oulu.fi/~loorni/covert/rants/sprite.htm ;sprite sorter sprite_sort ldx #0 sortloop ldy sortorder+1,x lda spry,y ldy sortorder,x cmp spry,y bcs sortskip stx sortreload+1 sortswap lda sortorder+1,x sta sortorder,x sta temp2 tya sta sortorder+1,x ; lda temp2 ;really necessary? ; sty sortorder+1,x cpx #0 beq sortreload dex ldy sortorder+1,x lda spry,y ldy sortorder,x cmp spry,y bcc sortswap sortreload ldx #0 sortskip inx cpx #max_sprites-1 bcc sortloop ;now copy sprite variables to the sorted table ;sprites must be rejected who want to be on the same scanline ;copy the 1st 4 virtual sprites as they are accepted anyway to the ;4 hardware sprites ldx #0 ldy sortorder lda spry,y sta sortspry lda sprx,y sta sortsprx lda sprc,y sta sortsprc inx ldy sortorder,x lda spry,y sta sortspry,x lda sprx,y sta sortsprx,x lda sprc,y sta sortsprc,x inx ldy sortorder,x lda spry,y sta sortspry,x lda sprx,y sta sortsprx,x lda sprc,y sta sortsprc,x inx ldy sortorder,x lda spry,y sta sortspry,x lda sprx,y sta sortsprx,x lda sprc,y sta sortsprc,x inx sort3 ldy sortorder,x lda spry,y sort4 sta sortspry,x sub spry-4,y ;actual position - 10 pixel (y-size of sprite) cmp #10 bcs sort5 ;reject if less than 10 scanlines lda #$80 sta reject,x ;mark which sprite to reject inc 712 lda #0 ;move off the screen beq sort6 sort5 lda sprx,y sort6 sta sortsprx,x lda sprc,y sta sortsprc,x inx cpx #max_sprites bcc sort3 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.