English Amiga Board


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

 
 
Thread Tools
Old 31 October 2012, 22:58   #1
mc6809e
Registered User
 
Join Date: Jan 2012
Location: USA
Posts: 293
Reusing sprites on a line with VHPOSW

Am I correct in assuming I can write to VHPOSW and get multiple copies of sprites on a line?

Looking at HRM it seems that so long as the position registers compare true a sprite will be output.

Developing a copper list to do this might be slightly complicated, though, since I would guess that wait instructions would be useless. Redundant moves or skip instructions would probably be needed to get the positioning right.

Six bitplane settings would be interesting since the the copper can do exactly one write every 16 pixels, which is the width of a sprite. A primitive type of tiling could be done by writing to VHPOSW with positions that match the positions of the sprite that holds the tile data.

A lot might be done in HAM mode, too. With more than 8 sprites on a line, HAM becomes more useful.
mc6809e is offline  
Old 01 November 2012, 00:23   #2
Lonewolf10
AMOS Extensions Developer
Lonewolf10's Avatar
 
Join Date: Jun 2007
Location: near Cambridge, UK
Age: 39
Posts: 1,919
Quote:
Originally Posted by mc6809e View Post
Am I correct in assuming I can write to VHPOSW and get multiple copies of sprites on a line?
erm... it is possible, but I don't see how writing to VHPOSW can be useful other than for resetting the beam to the top-left (when used with VPOSR).

I'm sure I have seen sprites reused on the same line (Turrican 2?) , but you need to write to SPRxPOS to alter a sprites X position to reuse it multiple times on the same horizontal line. So if you wanted the same sprite side by side you would need to use the copper to write to SPRxPOS, then use a copper wait instruction (depending on how close/far you want them both) and then use the copper to alter SPRxPOS again.

Last edited by Lonewolf10; 01 November 2012 at 01:01. Reason: corrected a few typo's
Lonewolf10 is offline  
Old 01 November 2012, 01:13   #3
Coagulus
Gets there in the end...

Coagulus's Avatar
 
Join Date: Sep 2005
Location: Wales
Posts: 624
http://www.codetapper.com/amiga/sprite-tricks/
Coagulus is offline  
Old 01 November 2012, 02:46   #4
mc6809e
Registered User
 
Join Date: Jan 2012
Location: USA
Posts: 293
Quote:
Originally Posted by Lonewolf10 View Post
erm... it is possible, but I don't see how writing to VHPOSW can be useful other than for resetting the beam to the top-left (when used with VPOSR).

I'm sure I have seen sprites reused on the same line (Turrican 2?) , but you need to write to SPRxPOS to alter a sprites X position to reuse it multiple times on the same horizontal line. So if you wanted the same sprite side by side you would need to use the copper to write to SPRxPOS, then use a copper wait instruction (depending on how close/far you want them both) and then use the copper to alter SPRxPOS again.
I'm familiar with this trick, but there are limitations.

One problem is that your position resolution is usually limited to 2 pixels. Using a finer 1 pixel resolution is a problem since writing to the sprite control register disables the sprite and that's where H0 is. Writing to sprite data register A rearms the sprite. This means 3 COPPER moves must be executed to reposition the sprite. And this means the new sprite position must be at least 24 pixels away from the old, assuming a 4 bitplane display.

Even worse, attached sprites at a 1 pixel resolution require 6 COPPER writes. That requires a distance of 48 pixels.

For a 5 or 6 bitplane display the distances are greater.

And the problem that attached sprites have also comes up when moving an object made of multiple sprites. The meagre 16 pixel width of Amiga's sprites is a big limitation and there's a temptation to pair them to make larger, 32 pixel-wide sprites. But pairing sprites this way gives 4 sprites per line. And if you want 16-color sprites, you end up with just 2 32 pixel-wide sprites per line -- a major limitation and probably the biggest reason for not bothering with hardware sprites on the Amiga.

Writing to VHPOSW opens up the possibility of triggering groups of multiple sprites with one write.

A problem, though, and that's all sprites would be affected at once so handling intersecting sprites would be difficult.
mc6809e is offline  
Old 01 November 2012, 05:25   #5
Codetapper
2 contact me: email only!

Codetapper's Avatar
 
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,150
Like Lonewolf has suggested, I would be surprised if that worked at all. Even if you could fake the Amiga into believing it was on a new scanline, it still takes many clock cycles to read the new values in. The Amiga does it in the unseen area on the left hand side of the screen by reading the new sprite data. Nothing is free - if you think you can display a sprite, write to VHPOSW and instantly have new sprite data reloaded, you're in for some serious disappointment!

Are you just wanting to reposition the SAME sprite(s) horizontally, or are you hoping to have more than 8 "real" sprites on a line? Because with your 16 colour example above you just need to do the 2 writes to the POS registers to shift both sprites and not touch the CTL register at all. See Risky Woods for an example of this trick.

Some programmers (Andrew Braybrook and Chris Sorrell for example) would keep track of when a sprite could be used, and fall back to using the blitter if it was going to glitch/vanish. It's quite complex to keep track of, but depending on what you want to do, it might be the best way.
Codetapper is offline  
Old 01 November 2012, 08:51   #6
mc6809e
Registered User
 
Join Date: Jan 2012
Location: USA
Posts: 293
Quote:
Originally Posted by Codetapper View Post
Like Lonewolf has suggested, I would be surprised if that worked at all. Even if you could fake the Amiga into believing it was on a new scanline, it still takes many clock cycles to read the new values in. The Amiga does it in the unseen area on the left hand side of the screen by reading the new sprite data. Nothing is free - if you think you can display a sprite, write to VHPOSW and instantly have new sprite data reloaded, you're in for some serious disappointment!

Are you just wanting to reposition the SAME sprite(s) horizontally, or are you hoping to have more than 8 "real" sprites on a line? Because with your 16 colour example above you just need to do the 2 writes to the POS registers to shift both sprites and not touch the CTL register at all. See Risky Woods for an example of this trick.

I'm thinking VHPOSW might work since the final output of a pixel is determined by Denise and the sprite horizontal comparison logic resides there. One way to activate the comparison logic for a sprite is to change the POS register so that later comparisons with HPOS re-display the sprite data. But I think Denise is comparing sprite POS with VHPOS which is also in Denise I think, so changing VHPOS should also work.

The Risky Woods example only works because of the repetitive pattern in the background. In particular, all re-positioned sprites share the same LSB of their horizontal position so CTL doesn't have to be touched. But what if the re-positioned sprite has a different LSB for its position? CTL has to be touched for that, but then the sprite is disarmed and A dat has to be reloaded to re-arm it.

Risky Woods does about as much as can be done using the COPPER and POS method. Nearly every cycle is consumed by COPPER moves and bit plane DMA.

Now consider this: suppose all 8 (4 attached) of those sprites that makeup the background could be re-positioned at once with a single write to VHPOSW. It would then take just 4 COPPER moves to get the same result as seen in Risky Woods. That leaves free cycles. And those free cycles can be used by the COPPER to reload the data registers of 3 sprites. Or, if the CPU is properly synced with the beam, 5 sprites using a series of MOVE.L into the data registers.
mc6809e is offline  
Old 01 November 2012, 09:58   #7
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,121
Writing to VPOS/VHPOS will mess up display sync (equals refresh rate change, most likely would not work very well with any real physical display) and it won't modify Denise's horizontal counter.

Horizontal strobe register resets (and only resets, can't set any specific value) Denise's horizontal counter but it most likely also resets Paula's horizontal counter (used for dmal timing at least). Weird things may happen with sound and disk DMA..
Toni Wilen is offline  
Old 01 November 2012, 11:18   #8
Codetapper
2 contact me: email only!

Codetapper's Avatar
 
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,150
Also a big warning from Mapping the Amiga:

VHPOSW: This is the write address of the VHPOSR register located at $DFF006. Do not modify the value there or you may corrupt the contents of RAM! It is for diagnostic purposes only.
Codetapper is offline  
Old 02 November 2012, 12:34   #9
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,653
Quote:
Originally Posted by Codetapper View Post
Also a big warning from Mapping the Amiga:

VHPOSW: This is the write address of the VHPOSR register located at $DFF006. Do not modify the value there or you may corrupt the contents of RAM! It is for diagnostic purposes only.

But this is accordingly what Toni says - manipulation with this register You can for example extend or shorten video lines, add more lines etc - together with strobe lines in theory they can destroy whole DMA timing thus chance to corrupt memory (REFRESH cycles)
pandy71 is offline  
Old 03 November 2012, 00:05   #10
mc6809e
Registered User
 
Join Date: Jan 2012
Location: USA
Posts: 293
Quote:
Originally Posted by Toni Wilen View Post
Writing to VPOS/VHPOS will mess up display sync (equals refresh rate change, most likely would not work very well with any real physical display) and it won't modify Denise's horizontal counter.

Horizontal strobe register resets (and only resets, can't set any specific value) Denise's horizontal counter but it most likely also resets Paula's horizontal counter (used for dmal timing at least). Weird things may happen with sound and disk DMA..
Interesting. Thanks.

Looking over the register map summary I now see that VHPOSW is in Agnus while STRHOR is assigned to Denise/Paula.

Schematics also seem to show Agnus generating VSYNC and HSYNC signals directly without Denise. Presumably these signals are based on the contents of VPOS/VHPOS. Advancing VHPOS by writing a value much greater than the current value in VHPOS to VHPOSW probably triggers an early HSYNC.

It may be that VPOS and VHPOS are responsible for Agnus' overall sequencing of DMA slots during a scanline, with the strobe registers strobed by Agnus on certain VPOS and VHPOS values to signal to Denise/Paula that the beginning of a line has begun. Writing small values to VHPOSW might cause Agnus to repeat DMA fetching of sprite data, audio data, etc.

My question would be: does STRHOR actually generate an HSYNC from Agnus or does it just reset Denise/Paula counters?
mc6809e is offline  
Old 07 November 2012, 21:59   #11
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,121
Quote:
Originally Posted by mc6809e View Post
My question would be: does STRHOR actually generate an HSYNC from Agnus or does it just reset Denise/Paula counters?
I am quite sure Agnus ignores strobe signals generated by CPU. They are "write-only".
Toni Wilen 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
Barbarian 2 sprites Maxim project.Sprites 8 11 May 2011 15:51
Pang sprites qtelSparrow project.Sprites 3 12 March 2010 23:10
SuperCars II sprites Lazarus404 project.Sprites 22 21 February 2006 15:44
Where are all the sprites? Gambit37 project.Sprites 8 14 October 2005 15:49
Some sprites Frog project.Sprites 5 06 April 2005 01:35

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 10:20.


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