English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 25 December 2015, 04:29   #1
buzzybee
Registered User

 
Join Date: Oct 2015
Location: Landsberg / Germany
Posts: 407
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?
buzzybee is offline  
Old 25 December 2015, 14:44   #2
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,736
AFAIK it is not possible. CPU and copper <> custom register accesses are still 16-bit in AGA.
Toni Wilen is online now  
Old 25 December 2015, 21:32   #3
hooverphonique
ex. demoscener "Bigmama"

 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,245
yes, since there's only 8 SPRxDAT's, I guess having sprites wider than 16 pixels is not possible without DMA...
hooverphonique is online now  
Old 27 December 2015, 13:14   #4
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
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)
Mrs Beanbag is offline  
Old 28 December 2015, 03:20   #5
buzzybee
Registered User

 
Join Date: Oct 2015
Location: Landsberg / Germany
Posts: 407
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 ...
buzzybee is offline  
Old 31 December 2015, 15:50   #6
TheDarkCoder
Registered User
 
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 211
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! :-)
TheDarkCoder is offline  
Old 31 December 2015, 16:32   #7
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,736
http://eab.abime.net/showpost.php?p=401996&postcount=15
Toni Wilen is online now  
Old 31 December 2015, 17:03   #8
buzzybee
Registered User

 
Join Date: Oct 2015
Location: Landsberg / Germany
Posts: 407
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.
buzzybee is offline  
Old 03 January 2016, 17:44   #9
ReadOnlyCat
Code Kitten

 
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 49
Posts: 1,176
Quote:
Originally Posted by Mrs Beanbag View Post
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)
I guess the test which remains to be done is writing to
SPRxDAT
with the copper and see if this works any better. At least timing is more controllable this way in case this matters.
ReadOnlyCat is offline  
Old 03 January 2016, 21:47   #10
buzzybee
Registered User

 
Join Date: Oct 2015
Location: Landsberg / Germany
Posts: 407
I tried writing to SPRxDAT with both, CPU and Copper. No controllable results whatsoever.
buzzybee is offline  
Old 04 January 2016, 14:54   #11
buzzybee
Registered User

 
Join Date: Oct 2015
Location: Landsberg / Germany
Posts: 407
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
buzzybee is offline  
Old 04 January 2016, 15:02   #12
hooverphonique
ex. demoscener "Bigmama"

 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,245
neat.. is there any particular reason for waiting for end of display and then explicitly triggering coplist0?
hooverphonique is online now  
Old 04 January 2016, 15:13   #13
buzzybee
Registered User

 
Join Date: Oct 2015
Location: Landsberg / Germany
Posts: 407
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.
buzzybee is offline  
Old 04 January 2016, 20:30   #14
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
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?
Mrs Beanbag is offline  
Old 05 January 2016, 02:44   #15
ReadOnlyCat
Code Kitten

 
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 49
Posts: 1,176
Quote:
Originally Posted by Mrs Beanbag View Post
I wonder what happens if you prod the SPRxDAT in the middle of a sprite being displayed?
I suspect Denise caches the content of each sprite into its own registers instead of relying on Agnus to store them: it would be too costly and slow if it had to read them from Agnus using the internal bus every time the horizontal comparator matched.

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
SPRxDAT
registers, 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.
ReadOnlyCat is offline  
Old 05 January 2016, 09:36   #16
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,736
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).
Toni Wilen is online now  
Old 05 January 2016, 11:50   #17
ovale
Registered User

 
Join Date: Jun 2014
Location: milan / italy
Posts: 159
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?
ovale is offline  
Old 05 January 2016, 12:05   #18
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,736
Quote:
Originally Posted by ovale View Post
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?
I don't know, I haven't tested.

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.
Toni Wilen is online now  
Old 05 January 2016, 20:26   #19
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
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?
Mrs Beanbag is offline  
 


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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 13:27.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.14831 seconds with 13 queries