25 December 2015, 04:29 | #1 |
Registered User
Join Date: Oct 2015
Location: Landsberg / Germany
Posts: 526
|
AGA: Using 32 pixel sprites twice per scanline
Hi guys!
I´m currently developing a new game for AGA called RESHOOT. One obstacle I´m currently facing is: How could I possibly re-use a 32 pixel sprite twice in one scanline, each carrying different bitplane data in SPRrxDATA? I was successful with repositioning the sprite several times on one scanline, but can´t copy new 32 pixel data into SPRrxDATA for each re-used sprite, neither using copper nor the cpu. Anyone ever solved this? |
25 December 2015, 14:44 | #2 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,570
|
AFAIK it is not possible. CPU and copper <> custom register accesses are still 16-bit in AGA.
|
25 December 2015, 21:32 | #3 |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,641
|
yes, since there's only 8 SPRxDAT's, I guess having sprites wider than 16 pixels is not possible without DMA...
|
27 December 2015, 13:14 | #4 |
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
i did try hammering the SPRxDATs with the CPU (longword writes), it did seem to affect the full 32-pixel width but not in any useful way, it is a shame they didn't design this feature in because it would have been really useful. i don't suppose turning sprite DMA off and on again mid-line does anything?
At least with 64-pixel wide sprites, you can cover the entire screen with only 5 of them, and then there's that bit you can set that makes all sprites appear twice on a scanline (with the same data) |
28 December 2015, 03:20 | #5 |
Registered User
Join Date: Oct 2015
Location: Landsberg / Germany
Posts: 526
|
I´m aware of that "one sprite twice per scanline"-bit, and maybe I´ll use it for displaying a 16-color-background some other day. For RESHOOT though it´s kind of useless ...
Thanks for all your answers. So it seems I´ll have to choose another solution for displaying several score items within the playfield ... |
31 December 2015, 15:50 | #6 |
Registered User
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 213
|
Mrs Beanbag: which bit??! I remember one that repeats the same data on two consecutive scanlines, so it doubles the sprite height. But not the one you say
Please enlighten me! :-) |
31 December 2015, 16:32 | #7 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,570
|
|
31 December 2015, 17:03 | #8 |
Registered User
Join Date: Oct 2015
Location: Landsberg / Germany
Posts: 526
|
That bit repeats every sprite at x-position + 256, with the same pixel content. Therefore can be used for 16 color scrolling backgrounds with 4 attached 64-pixel sprites (64+64+64+64=256, then repeat) provided that background consists of repeating patterns. Not of use for RESHOOT, but valuable nonetheless.
|
03 January 2016, 17:44 | #9 | |
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
Quote:
SPRxDATwith the copper and see if this works any better. At least timing is more controllable this way in case this matters. |
|
03 January 2016, 21:47 | #10 |
Registered User
Join Date: Oct 2015
Location: Landsberg / Germany
Posts: 526
|
I tried writing to SPRxDAT with both, CPU and Copper. No controllable results whatsoever.
|
04 January 2016, 14:54 | #11 |
Registered User
Join Date: Oct 2015
Location: Landsberg / Germany
Posts: 526
|
Okay, it´s reliably working now. By using the copper, I reuse sprite7 twice on some scanlines. The sprite is initialised by DMA, then (on some scanlines) the copperlist takes over for sprite reuse. As I can rewrite the first word of SPRxDAT only, I´m reusing sprite7 only at the very right border and only the leftmost 16 pixels of it. The border covers all remaining pixelgarbage. SPRxDAT is written by the copper, which is filled by cpu elsewhere in the code. For my game RESHOOT I use sprite7 to display simple messages concerning highscore achievements.
This is how part of the copperlist looks like: copGame cwait $2001 cmove $1fc,%0000000000001011 ;32 pixel sprites cwait $ffdf ; wait needed for correct re-init of coplist cwait spriteScoreYPosition<<8+spriteHiXPosition+8 ; drawing symbols to hSprite7 cmove $178,spriteHiXPosition+$10 copSprite7PixelData cmove $17e,0 ; filled by cpu elsewhere in the code cmove $178,spriteHiXPosition cwait (spriteScoreYPosition+1)<<8+spriteHiXPosition+8 cmove $178,spriteHiXPosition+$10 copSprite7PixelDataOffset=*-copSprite7PixelData cmove $17e,0 cmove $178,spriteHiXPosition cwait (spriteScoreYPosition+2)<<8+spriteHiXPosition+8 cmove $178,spriteHiXPosition+$10 cmove $17e,0 cmove $178,spriteHiXPosition cwait (spriteScoreYPosition+3)<<8+spriteHiXPosition+8 cmove $178,spriteHiXPosition+$10 cmove $17e,0 cmove $178,spriteHiXPosition cwait (spriteScoreYPosition+4)<<8+spriteHiXPosition+8 cmove $178,spriteHiXPosition+$10 cmove $17e,0 cmove $178,spriteHiXPosition ; cmove $09c,$8010 ; init copper interrupt -> yet not needed cwait $3801 ; wait for end of frame, then restart coplist dc.w $80 copGameH dc.w 0,$82 copGameL dc.w 0,$88,0 cend |
04 January 2016, 15:02 | #12 |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,641
|
neat.. is there any particular reason for waiting for end of display and then explicitly triggering coplist0?
|
04 January 2016, 15:13 | #13 |
Registered User
Join Date: Oct 2015
Location: Landsberg / Germany
Posts: 526
|
Yes. I´m using the same copperlist-main-initialisation for all views in the game (title, game...). This keeps the code organised and also helps to keep one visual style in all parts of the game. At the end of copperlist-main-initialisation, copper is pointed to dedicated sub-copperlists which serve dedicated needs of the different displays. At its end each dedicated sub-copperlists is pointed back to the copperlist-main-initialisation. Registers $80 and $82 are loaded with the addresses by the cpu, register $88 (or COPJMP1) inits the jumps.
The titlescreen for example uses 64-pixel-sprites, the game-display 32-pixel-sprites and could do display changes every scanline, as it does by reusing sprite7. Therefore what I´ve copied from my code is only part of the sub-copperlist for the ingame-display. Last edited by buzzybee; 04 January 2016 at 15:43. |
04 January 2016, 20:30 | #14 |
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
that's a cunning trick...
by the way, when i was testing i noticed a slightly different behaviour when hammering the SPRxDAT, between the two different types of 32-pixel wide sprites. For the benefit of the spectators, you can get 32-pixel wide sprites either by doubling the bus width or by doubling the data fetch, to get 64 pixel wide sprites you do both of these things. So there are two ways to get 32 pixel wide sprites. I don't know how exactly this makes a difference but anecdotally, it seemed to, although neither mode appeared very useful. I wonder what happens if you prod the SPRxDAT in the middle of a sprite being displayed? |
05 January 2016, 02:44 | #15 | |
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
Quote:
This means that these registers probably are not at risk of suffering of the "must wait one DMA cycle after access from the chips" problem so upon writing the SPRxDATregisters, they are probably transferred immediately into Denise and used immediately for display. I am obviously just guessing but I am fairly sure Toni must have more grounded ideas about it. |
|
05 January 2016, 09:36 | #16 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,570
|
Yeah, Denise has two sets of sprite data registers, one that stores Agnus DMA/CPU writes (SPRxDATA, SPRxDATB) and output shift registers where SPRxDATA/SPRxDATB gets copied when sprite's X coordinate matches Denise's internal horizontal counter.
Bitplanes use very similar setup but have 3rd set (DMA storage, copy to temp storage when BPL1DAT is written, copy to output shift registers when BPLCON1 matches) All CPU/Copper accesses to custom registers are always 16-bit. Technically there could have been some logic in Budgie that detects 32-bit CPU's 32-bit write and allows it to be full 32-bit also from Denise point of view (instead of telling the CPU that bus is 16-bit, you need to do 2x16-bit accesses to address+0 and address+2) Remember that in hardware level single long read or write to address X is not necessarily same as 2xword write/read to addresses X+0 and X+2. I think the main reason was compatibility and cost. Practically every software that hits the hardware does long writes to DMA pointer registers. I assume there is also programs that do long writes to DAT registers to clear them quickly and would break if single long write does not hit 2 16-bit DAT registers instead of single in 32-bit mode. Handling this fully would have required extra (possible a lot more), internal logic to bus controller (Budgie in A1200). |
05 January 2016, 11:50 | #17 |
Registered User
Join Date: Jun 2014
Location: milan / italy
Posts: 174
|
If I load in a 32 pixel sprite ABCD via DMA and then I write EF via Copper what I will see 256 pixel later? EFCD, ABEF, EFRR, RRCD (R=random) ?
And what will happen with 64 pixel sprites? |
05 January 2016, 12:05 | #18 | |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,570
|
Quote:
I'd assume first 16 pixels are replaced but this is most likely undefined situation (I don't think hardware designers cared about "manual" sprite mode in 32/64 wide fetch modes) and there may be some unknown hardware side-effects that can cause odd behavior. |
|
05 January 2016, 20:26 | #19 |
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
hm, maybe time for some more tests then...
are the output shift registers internally 64 bit? Can you "catch it with its pants down" and write 32/64 bit data by writing to SPRxDAT sequentially at the right time? |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Alien Breed II title pixel by pixel logo removal | dex | project.Sprites | 17 | 06 May 2020 15:23 |
AGA border sprites | mark_k | support.WinUAE | 9 | 06 January 2014 14:35 |
Scanline modifications wanted | Retro-Nerd | support.FS-UAE | 8 | 20 August 2013 20:31 |
EHB sprites with AGA chipset ? | FrenchShark | Coders. General | 4 | 17 September 2009 06:37 |
Scanline option request | Christian | request.UAE Wishlist | 3 | 26 May 2009 22:24 |
|
|