View Single Post
Old 01 November 2013, 02:59   #13
Going nowhere

Galahad/FLT's Avatar
Join Date: Oct 2001
Location: United Kingdom
Age: 43
Posts: 6,229
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  
Page generated in 0.05596 seconds with 9 queries