How was it done? (helping understand the coding tricks)

[Shoonay]

Universe.
A simple ECS space adventure with some nice graphics released in 1994, when scanned closely appears to display ~180 colors per screen!

1st pic:

Number of colors: 190

2nd pic:

Number of colors: 171

Some part of the background from
the 2nd pic, without the character
and the space station:

Number of colors: 100

So, how was it done?
Looks nothing like HAM too me...
Multiple screens?

[Amiga1992]

These guys developed a new graphics mode for this game that allowed them to use those many colours.

Exactly how, I dunno.
You can read about this in every WiP done about Universe, there was on in The One Magazine, circa 1994.

[StevenJGore]

It runs at 256 colours on an A500. Looks the same on an A1200. Don't know how it was achieved though. The palette looks limited though, colour gradients aren't as smooth as AGA.

[Shoonay]

Thanks for the info Aki, could you perhaps point me in the right direction of this article concerning Universe's coding tricks?

[Thorham]

Originally Posted by 5h00n4y

So, how was it done?

They probably use the copper to change a bunch of colors on each scanline. It's possible to change the palette of 15 colors in the border, and about 40 more in the screen area, and this can be done for every scanline.

HamLab can do this, too, although it will only change 15 colors in the border.

[yaqube]

I had a look at this game. It uses EHB mode. On every scanline during horizontal blanking some colours from palette entries 1-15 are changed. I saw as few changes as 2 and as many as 10.

[hitchhikr]

Yeah that's what they do, they probably had a tool which analysed 256 colors pictures, reduced them to a lower number of colors (via dithering) and generated the palette variations at the relevant scan lines for the copper. It could be amusing to do such a tool (i guess they needed a part of the palette to remain constant for the sprites and texts).

I don't think there's enough time to change all the palette at every scan line (especially when using 6 bitplanes).

[TCD]

Originally Posted by 5h00n4y

Thanks for the info Aki, could you perhaps point me in the right direction of this article concerning Universe's coding tricks?

I think it's this one Shoonay : http://amr.abime.net/review_14299

[Shoonay]

Thanks guys

[Thorham]

Originally Posted by hitchhikr

I don't think there's enough time to change all the palette at every scan line (especially when using 6 bitplanes).

Check out HamLab demo version. This changes 15 colors per scanline in the border for ham6 (six bpp).

[Amiga1992]

Originally Posted by StevenJGore

It runs at 256 colours on an A500.

No, it doesn't.
The exact number escapes me, but it's not 256, it's a bit less. Probably some of the tech gizmos can calculate it

So, if the colours are changed by the copper, it means they are not all available at any moment anywhere on screen, right? Like Lionheart.

[hitchhikr]

Check out HamLab demo version. This changes 15 colors per scanline in the border for ham6 (six bpp).

15 colors is only half of the available palette registers, the only ones relevant in ham but the mode used here wasn't ham.

I guess such a tool should handle maximum 15 colors / line or so and dither if there's too many present (keeping an history for next lines etc.) then generate the copper colors (or the whole copperlist directly).
So, for a 320x200 picture and considering the copper color registers would be constructed and saved within the file with the bitplanes that would give max. 44000 bytes / file and max. 3000 colors for a whole pic (most probably less) and a hell of a copperlist ;D

[Leffmann]

You can actually manage 16 color changes outside the display, if it makes a difference (at least according to WinUAE cycle exact A500).

Did anyone try doing these tricks using the CPU on the A1200? I'm thinking that with the code in the cache, 32 bit access to the RAM (and to the custom chips?) it should be faster to change colors with the CPU than the copper. By f.ex setting 64 color mode and switching palettes between scanlines using the BPLAM bits in BPLCON4, and thus getting a full scanline worth of time to change colors, you might be able to get 64 unique colors each scanline, or close to there.

[cosmicfrog]

plz some1 do it,

is`t it about time some1 started pushing the original specs of the machine over and beond what was thought possible

[AmigaFriend]

That would be interesting really, to be seen.

[Thorham]

Originally Posted by Leffmann

You can actually manage 16 color changes outside the display, if it makes a difference (at least according to WinUAE cycle exact A500).

That's correct. Hamlab does this (see Aminet)

Originally Posted by Leffmann

Did anyone try doing these tricks using the CPU on the A1200? I'm thinking that with the code in the cache, 32 bit access to the RAM (and to the custom chips?) it should be faster to change colors with the CPU than the copper. By f.ex setting 64 color mode and switching palettes between scanlines using the BPLAM bits in BPLCON4, and thus getting a full scanline worth of time to change colors, you might be able to get 64 unique colors each scanline, or close to there.

Yes, you can change around 64 colors per scanline with the cpu. I coded up something like that over 10 years ago. All you really have to do is set the colors for a scanline on the previous scanline and make sure none of those colors are used on the scanline on which they are changed. This doen't work on non-aga, and Ham8 is much better.

Also, because of timing irregularities, it's very difficult, if not impossible to make something similar work on non-aga as far as I know.

[Shoonay]

Mmmmmm, just imagine some shitty Sierra EGA adventures remade with that trick into AGA...

*drools*

[Thorham]

Originally Posted by 5h00n4y

Mmmmmm, just imagine some shitty Sierra EGA adventures remade with that trick into AGA...

*drools*

Or better yet, imagine how adventure games like Myst would look in glorious Highres Interlace Ham8

[Leffmann]

Originally Posted by Thorham

That's correct. Hamlab does this (see Aminet)
Yes, you can change around 64 colors per scanline with the cpu. I coded up something like that over 10 years ago. All you really have to do is set the colors for a scanline on the previous scanline and make sure none of those colors are used on the scanline on which they are changed. This doen't work on non-aga, and Ham8 is much better.

Also, because of timing irregularities, it's very difficult, if not impossible to make something similar work on non-aga as far as I know.

HAM8 is great and probably sufficient for most pictures, but while it can generate MORE than 64 colors on a single scanline, it can't do 64 SPECIFIC colors, and you usually end up with some color bleeding. Which one is better probably depends on what picture you want to dither. For anything that is not large horizontal gradients, 64 unique colors per scanline will look very good, you could even use 256 colors and replace as many as you have time for on a scanline basis.

You could combine this and HAM8 and get some better results but I don't even want to think of how to work out the dithering algorithm

[jotd]

I saw static pictures of very good quality and a lot of colors on a demo disk a long time ago. The mode was called "dynamic hires".

fiddling with the copper for a demo/picture is one thing, doing it in a game is another. I guess Universe does not allow a lot of player movement, or delimited to a given zone.