Arcade / Console --> Amiga conversion discussions

[sandruzzo]

Originally Posted by DanScott

Far from it.... a decent artist and a well chosen 16 colour palette can look beautiful.

I myself have reduced the blocksets and sprites for a Capcom game down to a fixed 16 colour palette. Sure there have to be some compromises somewhere along the way, but the results were really nice!!! A lot better than the "official" conversion of the game (which was a straight ST to Amiga port)

At the end of the day, it's about playability, while still trying to look nice.

G&G is definitely possible at 50fps (maybe not 352 wide, but certainly 320 wide... just losing one sprite that can be actually loaded by the copper anyway), with 16 colours, and would still look really gorgeous.

Do you have some pics about this colors reductions?

[ross]

Originally Posted by sandruzzo

Do you have some pics about this colors reductions?

It's not DanScott related but you can search for AnimaInCorpore's work.

Google for Daimakaimura (Ghouls 'n Ghosts) and Atari..
(EDIT: writing atari gave me a strange tingle )

An universal 16 colors Capcom palette is used and the result are very very good

[DanScott]

Originally Posted by sandruzzo

Do you have some pics about this colors reductions?

No, I don't want to post them in public, thanks

[DanScott]

But here's my current palette. I am still working on some palette tweaks, but for the particular game, it seems to work quite nicely, and gives the artists enough shades to accurately remap the coin-op sprites and background tiles down to 16 colours. As I said, some compromises needed.. there are some sprites/bg tiles that use pink/purple colours, but these look great when remapped to use the blues and reds.



I also have devised another more general purpose palette too, but this would require a lot more work for an artist to remap sprites/tiles

[sandruzzo]

Originally Posted by DanScott

But here's my current palette. I am still working on some palette tweaks, but for the particular game, it seems to work quite nicely, and gives the artists enough shades to accurately remap the coin-op sprites and background tiles down to 16 colours. As I said, some compromises needed.. there are some sprites/bg tiles that use pink/purple colours, but these look great when remapped to use the blues and reds.



I also have devised another more general purpose palette too, but this would require a lot more work for an artist to remap sprites/tiles

I thought you've some Gng Reduce gfx to see how with 16 colors go.

[zero]

It would be even better if you could reduce the backgrounds to 8 colours and the enemies to a different 8 colours, for dual-playfield mode. Then you have sprites with their own palette on top of that, and easy collision detection.

[DanScott]

Originally Posted by zero

It would be even better if you could reduce the backgrounds to 8 colours and the enemies to a different 8 colours, for dual-playfield mode. Then you have sprites with their own palette on top of that, and easy collision detection.

Sprite to playfield collision is pretty useless

Dual playfield does have it's advantages and also it's disadvantages.

On OCS/ECS there is a huge overhead in terms of bitplane DMA usage. This is offset by having to blit less planes for objects (and can clear the area rather than background restore). You could reduce the screen size to help gain more CPU/Blitter time, but a game like GnG needs to stick as close as possible to the original screen resolution / dimensions. Overall though, unless you have a very good artist, you will end up with something that looks pretty bad.

Probably on AGA, dual playfield is the perfect solution (with hardware sprites to build the background parallax layer)

[mcgeezer]

If I was doing i would go for AGA too simply because without the parallax scrolling the game might as well be Ghosts 'n Goblins which had a very good Amiga port.

AGA would do the Arcade proud and would give more time fine tuning the game without having to worry about technical limitations.

[sandruzzo]

On Ocs/Ecs you can have a better Amiga conversion, only by reducing screen size, and I mean A lot better

[DanScott]

highly debatable that reducing screen size makes for a better conversion.

Gameplay is quite often defined around the screen size, and what can be seen from the players position.

As i stated, GnG at full screen size (320x224 perhaps to keep the coinop Y screen size) on Amiga is 100% possible on OCS

[zero]

Originally Posted by DanScott

Sprite to playfield collision is pretty useless

You get pixel perfect collision detection for free. How is that "useless"?

Quite a few games use that technique to avoid having to check collisions with every object on the screen every frame.

[DanScott]

Originally Posted by zero

Quite a few games use that technique to avoid having to check collisions with every object on the screen every frame.

Which ones? It was useless in any of the many commercially released games I wrote.

It only tells you there has been a collision (overlap) of sprite data to other sprite / playfield data.

It doesn't tell you exactly what your sprite collided with. You still have to work out manually what has been collided with.

Checking collisions every frame is not so hard to optimise anyway... generally things are not moving so fast, so a sorted list will not change a great deal from one frame to the next.

[zero]

Originally Posted by DanScott

Which ones?

Leander, for example. I have a feeling Agony did it as well, but I'm not sure.

It only tells you there has been a collision (overlap) of sprite data to other sprite / playfield data.

It doesn't tell you exactly what your sprite collided with. You still have to work out manually what has been collided with.

Think about a game like GnG or Leander. It doesn't matter what you hit, you take the same amount of damage regardless. In GnG you lose your armour or die, that's it. So you don't care what you hit, only that you did hit something.

So now instead of checking player bounding box vs. every enemy on screen, and then doing a pixel-perfect check if they are overlapping, you check one bit.

For the player's weapons you use simpler methods because they won't mind if it's not pixel perfect, but they will care if they die unfairly.

[DanScott]

I have reason to believe that Leander doesn't use pixel perfect collision, based on watching the full playthrough. Would be interesting to see HOW they utilised it, if they did (it sure looks like BB checks to me)

And GnG... there's a lot more that can happen than just taking a hit and losing armour. ie... collision with chests to open them.. collision with pickups to pick then up, non-collision with things like feathers off the vultures, non-collision of walking through a "death" sequence of an enemy, non-collision of enemies that are emerging up through the floor, magician spell that turns you into a duck (or whatever)

[zero]

Leander is pixel perfect using sprite/playfield detection.

[ Show youtube player ]

As I said about GnG, the player probably won't be too upset if the collision detection on power-ups isn't pixel perfect, as long as it goes in their favour.

The non-collision objects are harder. Maybe they could be fudged with sprites instead of being drawn as bitmaps. Hmm.

[Daedalus]

Originally Posted by zero

The non-collision objects are harder. Maybe they could be fudged with sprites instead of being drawn as bitmaps. Hmm.

Non-collision objects can simply be drawn in specific colours that don't trigger the collision detection. Hardware collision detection is bitplane-based, so you can exclude certain bitplanes from the check to provide foreground or background graphics for example.

A simple test to see if a game uses chipset collision detection is to disable it in WinUAE and see if the game still works.

[zero]

Good point about the colour palette stuff. That's the kind of thing that a carefully designed Amiga game could make use of, but which is harder to arrange for an arcade port. Especially with dual playfield giving you only 8 colours for the enemies...

Maybe there is another way. The player sprite is pretty small. You could do pixel perfect collision detection by re-drawing it in a hidden part of the screen along with enemy masks on a single bitplane. Only enemies near the player would need to be rendered, and ones that can't be hit are excluded. The area only needs to be the height of the player sprite.

[AnimaInCorpore]

Originally Posted by Galahad/FLT

I'm sorry, but you're just monumentally wrong.

Ok, this seems to be the final conclusion on your side.

One last question: just tell me how long "good" developers need to create a (or the best) conversion for the Amiga and how would it look like?

[Dunny]

Originally Posted by AnimaInCorpore

Ok, this seems to be the final conclusion on your side.

To be fair, he also explained very concisely and clearly why you were monumentally, totally wrong.

One last question: just tell me how long "good" developers need to create a (or the best) conversion for the Amiga and how would it look like?

How good a programmer is can be very subjective. Many coders with no knowledge beyond Blitz BASIC made games that the ST could not compete with. Hell, a competent AMOS coder could do that. As for how long - how long is a piece of string? You can set a coder on to a task and give him or her an infinite amount of time to get it done and you can bet they will take it too.

Or you can give them restrictions based on publishing dates and get something that's good enough.

It was very rarely down to the coder as to how good an arcade conversion was - nine times out of ten it was due to publisher restraints, and forcing corners to be cut (such as porting from ST to Amiga with all the inadequacies that entails) that caused poor conversions.

[AnimaInCorpore]

Originally Posted by Dunny

To be fair, he also explained very concisely and clearly why you were monumentally, totally wrong.

Yeah, sure: monumentally and totally. It seems that you need these superlatives to have an excuse for not having good arcade ports after 30 years.

Also the "publisher restraints" is the other excuse way back then. There are no restraints now and every "good" coder can show that he's able to deliver. It's even more convenient to develop on modern platforms but there's no real visible progress especially in having better conversions of arcade games.

Anyway, I was asking for help to port Cho Ren Sha 68k to the Amiga platform but there was no support at all. Probably everyone knows that the Amiga (1200) is not able to perform adequately for that certain task.

The only conclusion is that everything about having "good arcade games for the Amiga" is just talking but not doing and that's what I would say is MONUMENTALLY and TOTALLY wrong.