English Amiga Board


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 30 October 2013, 05:03   #1
ImmortalA1000
Registered User
 
Join Date: Feb 2009
Location: london/england
Posts: 347
Need some help about specs of OCS Sprites please

After googling for a bit I couldn't find any detailed info about Amiga sprites.

e.g.

I don't know if there are or aren't any sprite expansion facilities in hardware
I don't know if sprite colours are taken from regular screen palette colours 1-32

It's just all confusing and all I know is you have 8 16 pixel wide 3 colour sprites which can be multiplexed each to death within one scanline of end of previous screen draw position of bottom of sprite. But I knew that bit before I searched.
ImmortalA1000 is offline  
AdSense AdSense  
Old 30 October 2013, 06:22   #2
Codetapper
2 contact me: email only!

Codetapper's Avatar
 
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,135
1. There are no sprite expansion facilities in hardware.
2. Yes, sprites 0 and 1 use colours 17-19, sprites 2-3 use colours 21-23, sprites 4-5 use colours 25-27 and sprites 6-7 use colours 29-31. The remaining "gaps" are transparent, unless you attach each odd and even sprite together, in which case you get 15 colours. Also if you do horizontal scrolling in hardware, you lose sprites (highest first) if your screen is at least 320 pixels wide and you start displaying it in the "normal" position.

Have a look at the sprite tricks section on codetapper.com as there are loads of examples and explanations on there. Also google the Rom Kernal Manuals and read the sprite section.

Games like Risky Woods and Jim Power do horizontal multiplexing tricks aswell.
Codetapper is offline  
Old 30 October 2013, 13:59   #3
ImmortalA1000
Registered User
 
Join Date: Feb 2009
Location: london/england
Posts: 347
Cheers buddy, doesn't look like I can use them in my game I wanted to convert though. Luckily it is such a simple game despite being on the SNES I can even squeeze it onto the Atari ST....maybe lol

The Amiga sprites are quite odd, they are actually less feature rich than the 8 bit computers where they had independent palettes and never got wiped from the screen when scrolling. Was there some time constraint that made Jay do it totally different to the VCS and 8 bit Atari computers?

I've read some of your excellent site about how Agony and SotB etc were done not too long ago I remember there was a 2 or 3 page feature in an Amiga Magazine by Dave Jones about how he programmed Menace too but can't remember which one.
ImmortalA1000 is offline  
Old 30 October 2013, 14:18   #4
Codetapper
2 contact me: email only!

Codetapper's Avatar
 
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,135
In some ways they are less feature rich, but in other ways they are infinitely better. The fact you don't have to do any special tricks to display sprites down the screen in different locations is very powerful. That's the reason SWIV has so many bullets (all sprites) on the screen. On the C64, you have to do horrendous timing hacks to multiplex sprites vertically.

It would have been nice if the sprites had their own palette, were wider, stretchable etc but we're stuck with what Jay came up with! With imagination, you can do some cool tricks however, especially re-using sprites horizontally!

On each scanline of the display, the Amiga hardware has to read the sprite data for each of the 8 sprites as well as doing the same for audio. With faster memory accesses they could have done more, but perhaps that bottleneck was too difficult to overcome back in 1984?

The Menace article by Dave Jones started in Amiga Format issue 7 on page 63.
Codetapper is offline  
Old 30 October 2013, 16:53   #5
sokolovic
Registered User

sokolovic's Avatar
 
Join Date: Aug 2013
Location: Marseille / France
Posts: 119
This codetapper's site is really really interesting, althought I can't understand nearly anything. Seems that the Amiga was much more limitated than his consoles counterpart, however, some games were clearly masterpieces of coding on Amiga...

Maybe because there were coded with the Amiga in mind ? When you seen how ugly is Chuck Rock 2 on CD32 in comparison of the Megadrive version, it's a bit of pity, especially when you remember the technical specs comparisons in Amiga magazines at that time (which lead to one of my question : was the MegaCD actually much more powerful than the CD32 ? )

The part with the interviews is wonderful.
You should maybe try to have an interview of Peter Thierolf, main coder of Mr Nutz and Turrican III (his e-mail : p.thierolf@keengames.com )
sokolovic is offline  
Old 30 October 2013, 21:17   #6
mc6809e
Registered User
 
Join Date: Jan 2012
Location: USA
Posts: 281
Quote:
Originally Posted by ImmortalA1000 View Post
The Amiga sprites are quite odd, they are actually less feature rich than the 8 bit computers where they had independent palettes and never got wiped from the screen when scrolling.
Sprites get wiped from the screen when scrolling? What makes you believe that? Maybe you mean bobs.

And the shared palette really isn't that bad, is it? The shared palette only happens with 5 bitplanes. I'd rather have 32 colors where 12 are shared with sprites than have just 16 colors and 12 sprite colors.

The primary problem with Amiga hardware sprites are their size.

EDIT: I understand now. You meant losing one hardware sprite when smooth scrolling a screen that's 320px wide. Okay. But tt's still possible to load the sprite in manual mode using the CPU or copper.

Last edited by mc6809e; 30 October 2013 at 21:25.
mc6809e is offline  
Old 30 October 2013, 21:22   #7
mc6809e
Registered User
 
Join Date: Jan 2012
Location: USA
Posts: 281
Quote:
Originally Posted by Codetapper View Post
Have a look at the sprite tricks section on codetapper.com as there are loads of examples and explanations on there. Also google the Rom Kernal Manuals and read the sprite section.
This caught my eye: "Saint Dragon uses a sprite multiplexing technique devised by Ronald Pieket Weeserik and implemented by John Croudy. "

Uh, I'm pretty sure that the sprite multiplexing technique is mentioned in the Amiga HRM.
mc6809e is offline  
Old 30 October 2013, 21:51   #8
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Saint Dragon actually does sprite multiplexing in the Commodore recommended way (i.e. putting another control word at the end of each sprite data). Although there are details in any practical implementation of it that I'm sure someone can take the credit for.
Mrs Beanbag is offline  
Old 31 October 2013, 15:43   #9
ImmortalA1000
Registered User
 
Join Date: Feb 2009
Location: london/england
Posts: 347
Quote:
Originally Posted by Codetapper View Post
In some ways they are less feature rich, but in other ways they are infinitely better. The fact you don't have to do any special tricks to display sprites down the screen in different locations is very powerful. That's the reason SWIV has so many bullets (all sprites) on the screen. On the C64, you have to do horrendous timing hacks to multiplex sprites vertically.

It would have been nice if the sprites had their own palette, were wider, stretchable etc but we're stuck with what Jay came up with! With imagination, you can do some cool tricks however, especially re-using sprites horizontally!

On each scanline of the display, the Amiga hardware has to read the sprite data for each of the 8 sprites as well as doing the same for audio. With faster memory accesses they could have done more, but perhaps that bottleneck was too difficult to overcome back in 1984?

The Menace article by Dave Jones started in Amiga Format issue 7 on page 63.
But on the 2600 and Atari 400/800 they had independent palettes and also MSX, Memotech, Coleco ADAM, 464PLUS, C64, TI99/4A they all use independent palettes. I really can't think of a 70s machine, let alone 80s, that didn't have an independent palette, very unusual. Combined with the fundamental issue of disappearing sprites during pixel scroll it seems to me it was an unfinished abandoned element for the other graphical tricks to up the ante.

It's not a negative thing to me as such, for me the copper,blitter, 'any sound possible' sound hardware idea it is to me more versatile and ultimately more powerful than even the X68000 copy SF2 type hardware to make a system that couldn't do Lotus II NTSC from Amiga looking at their Chase HQ and the excellent F1 clone called Overtake.

Any way there isn't too much chipset bandwidth required for the game I was thinking of coding up to brush up on coding so I will use EHB mode inversely so there will be enough colours and the highlight effect I need.

It probably is more apparent as I am doing some nice F1 cars on the C64 for a project. As you say it might be a case of swings and roundabouts because 75% of the surface of the VIC-II silicon relates to having that advanced sprites system. The Amiga just happens to have them but it isn't the heart of the graphics system like a C64 I guess, maybe it's a freebie like HAM mode and that's how I should view it.
ImmortalA1000 is offline  
Old 31 October 2013, 17:01   #10
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Atari 2600 et al didn't even have a frame buffer, let alone hardware sprites. The CPU had to draw everything on the screen on each scanline as the vertical beam position reached it, much like the work the Amiga's copper has to do.

Other examples such as the relatively advanced Mattel Intellivision, the CPU had no access to graphics RAM or hardware registers outside of vertical blank. Also usually on machines of that era, if there was any static background graphics capability, it was "character based" displays with up to 256 8x8 characters in only two colours, which is much lower bandwidth. The later 16 bit consoles also used a variant of this technique but with more characters and more available colour combinations, which is very good for scrolling tilemap based games and perhaps how they managed so many hardware sprites. But the Amiga uses bitplanes which can be anywhere in Chip RAM and have to be read into the display hardware to be displayed on the screen.

C64 had only 16 colours anyway so what does "independent palettes" even mean in this case? They used the same colours you could use for the background graphics. On the Amiga if you are only using a 16 colour screen, your sprites use a different set of 16 colours. How independent do you want it?

Also I really want to clarify this. On the Amiga horizontal scrolling isn't what causes sprites to disappear. Setting the horizontal display fetch 16 pixels earlier (further left) disables the last sprite because the bitplane data has to be read during the time it would otherwise have read that sprite's data. You can do scrolling without doing that but not if you want the screen to go right to the left-hand edge. You will note that Turrican, for instance, doesn't go all the way to the edge, so I guess they wanted to use all 8 sprites.
Mrs Beanbag is offline  
Old 31 October 2013, 20:44   #11
Codetapper
2 contact me: email only!

Codetapper's Avatar
 
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,135
Quote:
Originally Posted by Mrs Beanbag View Post
Also I really want to clarify this. On the Amiga horizontal scrolling isn't what causes sprites to disappear. Setting the horizontal display fetch 16 pixels earlier (further left) disables the last sprite because the bitplane data has to be read during the time it would otherwise have read that sprite's data. You can do scrolling without doing that but not if you want the screen to go right to the left-hand edge.
This only applies if you are using automatic mode sprites. If you manually load sprite 7's data with the copper at the left edge of the screen, you can still have all 8 sprites no problem.
Codetapper is offline  
Old 01 November 2013, 03:21   #12
ImmortalA1000
Registered User
 
Join Date: Feb 2009
Location: london/england
Posts: 347
Quote:
Originally Posted by Mrs Beanbag View Post
Atari 2600 et al didn't even have a frame buffer, let alone hardware sprites. The CPU had to draw everything on the screen on each scanline as the vertical beam position reached it, much like the work the Amiga's copper has to do.

Other examples such as the relatively advanced Mattel Intellivision, the CPU had no access to graphics RAM or hardware registers outside of vertical blank. Also usually on machines of that era, if there was any static background graphics capability, it was "character based" displays with up to 256 8x8 characters in only two colours, which is much lower bandwidth. The later 16 bit consoles also used a variant of this technique but with more characters and more available colour combinations, which is very good for scrolling tilemap based games and perhaps how they managed so many hardware sprites. But the Amiga uses bitplanes which can be anywhere in Chip RAM and have to be read into the display hardware to be displayed on the screen.

C64 had only 16 colours anyway so what does "independent palettes" even mean in this case? They used the same colours you could use for the background graphics. On the Amiga if you are only using a 16 colour screen, your sprites use a different set of 16 colours. How independent do you want it?

Also I really want to clarify this. On the Amiga horizontal scrolling isn't what causes sprites to disappear. Setting the horizontal display fetch 16 pixels earlier (further left) disables the last sprite because the bitplane data has to be read during the time it would otherwise have read that sprite's data. You can do scrolling without doing that but not if you want the screen to go right to the left-hand edge. You will note that Turrican, for instance, doesn't go all the way to the edge, so I guess they wanted to use all 8 sprites.
Whereas the TI99/4A from the 70s does indeed have 16x16 pixel sprites with individual colour registers which pre-dates the Intellivision by 2 years. And the 1981 VIC-II chip may have only 16 colours but for the Amiga, as befits a machine 4 years younger than a C64 I don't expect the sprites to be thinner and not even have their own palette, however you paint it it IS a backward step for the sprite system on the Amiga. If the sprites can only take their colours from the background screen memory underneath then what is the point of having a 32 colour palette if you have to use half of them for the 8 three colour sprites, and if you then multiplex them using the GELs system of Kickstart again what is the point if multiplexing the sprite colour registers changes the colours on the background image, which again is not a problem on something like multiplexing sprites on a C64 (something so simple to do it took me just a few hours to do it in machine code on my second day of 6502 coding).

It is a very awkwardly implemented sprite system which most machines in the history of computing did not use and for a very good reason IMO.

The fact you only have 16 colours on the C64 is neither here nor there, because the multicolour screens have only 3 universal colours and one user selectable colour per 4x8 pixel charblock like most early 80s micros and so having an extra 2 colours universally and 1 per sprite means your sprites are designed independently of the background with their own registers which can then be changed when multiplexing them including their colours. This therefore means you double the effective number of colours on screen.

That was the whole point of sprites, that they are an independant hardware generated layer. If you can only put sprites on the screen that use the regular screen background colour registers then why would you use them and not BOBs? Amiga sprites have 50% of the limitations of Atari ST/Amstrad CPC software sprites therfore IMO because whilst the hardware is taking care of making sure they are refreshed on the screen without affecting the screen beneath you you still have to use a single palette for all (and then are not able to have say 6 colour cycling animation as the sprites using those colour registers would also get their colours cycled so no easy colour cycling water effects on a Twin Cobra/Ghost Pilots rip-off etc).

Again though like I said it doesn't really matter because I was just seeking clarification and the copper and blitter is the key to getting my game looking as close as possible to the SNES original game anyway and there are only really two huge animated characters on screen at a time (plus animated backgrounds). I will just use EHB colours in the opposite way intended so you can 'see through' your player and still hit the enemy. I just found it odd that Amiga sprites work in such an unusual way given it's such a graphical powerhouse

PS I did the longplay for SWIV on the C64 and apart from being technically very impressive for a conversion of an Amiga game I would also not have felt too sad if I didn't own an Amiga like my friends and had to play the C64 version instead. This is down to the sophistication of the C64 sprite hardware, and why it is the only 8-bit version worth playing and better than the ST version of the game IMO.
ImmortalA1000 is offline  
Old 01 November 2013, 03:59   #13
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 44
Posts: 6,604
Quote:
Originally Posted by ImmortalA1000 View Post
Whereas the TI99/4A from the 70s does indeed have 16x16 pixel sprites with individual colour registers which pre-dates the Intellivision by 2 years. And the 1981 VIC-II chip may have only 16 colours but for the Amiga, as befits a machine 4 years younger than a C64 I don't expect the sprites to be thinner and not even have their own palette, however you paint it it IS a backward step for the sprite system on the Amiga. If the sprites can only take their colours from the background screen memory underneath then what is the point of having a 32 colour palette if you have to use half of them for the 8 three colour sprites, and if you then multiplex them using the GELs system of Kickstart again what is the point if multiplexing the sprite colour registers changes the colours on the background image, which again is not a problem on something like multiplexing sprites on a C64 (something so simple to do it took me just a few hours to do it in machine code on my second day of 6502 coding).

It is a very awkwardly implemented sprite system which most machines in the history of computing did not use and for a very good reason IMO.

The fact you only have 16 colours on the C64 is neither here nor there, because the multicolour screens have only 3 universal colours and one user selectable colour per 4x8 pixel charblock like most early 80s micros and so having an extra 2 colours universally and 1 per sprite means your sprites are designed independently of the background with their own registers which can then be changed when multiplexing them including their colours. This therefore means you double the effective number of colours on screen.

That was the whole point of sprites, that they are an independant hardware generated layer. If you can only put sprites on the screen that use the regular screen background colour registers then why would you use them and not BOBs? Amiga sprites have 50% of the limitations of Atari ST/Amstrad CPC software sprites therfore IMO because whilst the hardware is taking care of making sure they are refreshed on the screen without affecting the screen beneath you you still have to use a single palette for all (and then are not able to have say 6 colour cycling animation as the sprites using those colour registers would also get their colours cycled so no easy colour cycling water effects on a Twin Cobra/Ghost Pilots rip-off etc).

Again though like I said it doesn't really matter because I was just seeking clarification and the copper and blitter is the key to getting my game looking as close as possible to the SNES original game anyway and there are only really two huge animated characters on screen at a time (plus animated backgrounds). I will just use EHB colours in the opposite way intended so you can 'see through' your player and still hit the enemy. I just found it odd that Amiga sprites work in such an unusual way given it's such a graphical powerhouse

PS I did the longplay for SWIV on the C64 and apart from being technically very impressive for a conversion of an Amiga game I would also not have felt too sad if I didn't own an Amiga like my friends and had to play the C64 version instead. This is down to the sophistication of the C64 sprite hardware, and why it is the only 8-bit version worth playing and better than the ST version of the game IMO.
You're right and wrong. Yes its a limitation that it has to share the colour pallete, but the fact is, the Amiga has 4096 colours, it instantly has more colours to pick from than older 8bit systems.

With copper reloading of bitplane data, its possible to have enough variation that the sprites don't appear to be sharing the same colours in any case.

In some areas the Amiga sprites are weak, in other areas with judicious programming, the Amiga sprite system in conjunction with the copper chip is all kinds of awesome.
Galahad/FLT is offline  
Old 01 November 2013, 06:18   #14
Codetapper
2 contact me: email only!

Codetapper's Avatar
 
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,135
I agree with Galahad. It comes down to the talent and imagination of the programmer.

If you asked an absolute muppet like Dr John Prince/Tiertex, he'd probably say the Amiga sprites are useless. (Assuming he even knew they existed since I don't think any of his games used them).

Yet ask a decent programmer like Ron Pieket who wrote SWIV and said "We got a lot of mileage out of those 8 sprite channels". All player bullets, most enemy bullets and some explosions were all done by reusing those 8 sprites.

As for your Twin Cobra example, if you really wanted water animation you could easily reserve colours 29-31 as 3 shades of blue, multiplex sprites 6 and 7 over the entire screen and have a much better animation than basic colour cycling could ever achieve. It all comes down to creativity!
Codetapper is offline  
Old 01 November 2013, 07:59   #15
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 274
Quote:
Originally Posted by ImmortalA1000 View Post
because the multicolour screens have only 3 universal colours and one user selectable colour per 4x8 pixel charblock
The multicolor bitmap mode has 1 universal color and 3 selectable colors per characterblock.
britelite is offline  
Old 01 November 2013, 14:02   #16
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by ImmortalA1000 View Post
Whereas the TI99/4A from the 70s does indeed have 16x16 pixel sprites with individual colour registers which pre-dates the Intellivision by 2 years.
But it is similar in that the background is divided into indexed blocks. It is not a full bitmap like the Amiga, therefore uses far less memory bandwidth. The Amiga's graphics system with its full bitmaps allows any image to displayed without block limitations, which is what ALLOWS the use of bobs at all, not to mention 3D vector graphics &c.

Quote:
If the sprites can only take their colours from the background screen memory underneath
They don't. That doesn't even make any sense. They take them from the palette registers.

Quote:
It is a very awkwardly implemented sprite system which most machines in the history of computing did not use and for a very good reason IMO.
Well Amiga sprites do have their shortcomings of course, and even the C64 sprite system can do things the Amiga can't but there are also very good reasons to prefer full bitmaps and sacrifice sprite functionality. On those old machines the hardware sprite limitations really were limitations. On the Amiga you have a choice of techniques to use, and there is no hard limit on the amount of moving action you can implement.

Quote:
The fact you only have 16 colours on the C64 is neither here nor there, because the multicolour screens have only 3 universal colours and one user selectable colour per 4x8 pixel charblock like most early 80s micros and so having an extra 2 colours universally and 1 per sprite means your sprites are designed independently of the background with their own registers which can then be changed when multiplexing them including their colours. This therefore means you double the effective number of colours on screen.
But there is nothing there that the Amiga couldn't replicate exactly! At least mention something the C64 could do that the Amiga can't, like that you can scale them up by a factor of 2 in each direction. Or that the C64 can use monochrome sprites at 24 pixels wide.

The C64 can't even do colour palette cycling! So how can you say the Amiga sprites are more limiting than the C64 because they introduces some limitations on colour cycling, when the C64 and other machines can't even do it at all?

Quote:
That was the whole point of sprites, that they are an independant hardware generated layer. If you can only put sprites on the screen that use the regular screen background colour registers then why would you use them and not BOBs?
Well as someone who has written a game that uses sprites, I'll tell you.

Sprites are an independent hardware generated layer. Unlike bobs that have to be copied into the screen buffer, they don't have any time overhead in terms of drawing, and you don't have to worry about replacing the background graphics when you move them. And if you are only using a 16 colour background screen (or you use Dual Playfield mode - another thing the old consoles couldn't do), they use a completely separate palette.

There are not "background colour registers". There are only 32 colour registers that the background may or may not happen to use. The sprites use colours 17-31 even if they are not used by the screen. If you are using a 16 colour screen or even a HAM screen, the upper half of the 32 colour palette is not used by the screen, only by the sprites.
Mrs Beanbag is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
X-Specs 3D software? AmigaOneFan Amiga scene 13 16 January 2017 08:55
ClassicWB specs list fc.studio project.ClassicWB 1 21 March 2009 13:23
T-Zero - what specs? Nostromo support.Games 16 30 January 2009 06:43
A1500 purchase: specs and what to do....? skote Hardware mods 30 07 June 2008 14:39
New WinUAE specs.. Mclane support.WinUAE 2 13 August 2002 02:16

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 01:40.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.31464 seconds with 11 queries