An interesting way to get more colours on an ST/E...

All 680x0 related coding posts in this section please.

Moderators: exxos, simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

An interesting way to get more colours on an ST/E...

Postby dml » Mon Nov 12, 2012 3:34 pm

I have been making vague noises recently about 'other' ways to display extra colours on an ST(E) without the huge CPU load we get with Spec512/PCS etc. etc. And without the horizontal constraints imposed by rasters. The idea being to do something that would be practical for homebrew games.

So I have been working on an experiment specifically aimed at games and other dynamic graphics. I wasn't happy about releasing much detail until I got a demo kinda working because it's the kind of thing that can slap you pretty hard in the face if it doesn't work. :)

While the demo isn't quite ready for viewing (I mainly have bugs to fix and some testing on real HW - emulators not ideal) I'm not worried about that side of things any more, I have some proof that the idea works - even if it may never be perfect or usable in every scenario.

Anyway that's good enough for me so here we go.... To encourage you to follow the link below here's a puzzle for you. This image is displayed on an STE using a single 16 colour palette. No palette switching, no CPU load. But the perceived color count on the display is... 123 colours?

Image

I have begun to document the method on my site - enough for things to make sense. It is certainly not a magic bullet but for the results it can generate, it is in some ways far easier to work with than some of the other methods available. I'll be posting concrete examples, tools and code before very long - including a scrolling playfield demo (as soon as the glitches are fixed). There's plenty more detail to add but it will have to be incremental as I'm busy most of the time.

http://www.leonik.net/dml/sec_crypto.py

If anyone finds this interesting enough to use in their game (or whatever), let me know and I'll assist. If not, it might still spark a few ideas that somebody else can run with.

FedePede04
Atari Super Hero
Atari Super Hero
Posts: 966
Joined: Fri Feb 04, 2011 12:14 am
Location: Denmark
Contact:

Re: An interesting way to get more colours on an ST/E...

Postby FedePede04 » Mon Nov 12, 2012 4:43 pm

dml wrote:I have begun to document the method on my site - enough for things to make sense. It is certainly not a magic bullet but for the results it can generate, it is in some ways far easier to work with than some of the other methods available. I'll be posting concrete examples, tools and code before very long - including a scrolling playfield demo (as soon as the glitches are fixed). There's plenty more detail to add but it will have to be incremental as I'm busy most of the time.

http://www.leonik.net/dml/sec_crypto.py


your result is looking great,
i don't quite get it, but i will try and re read later( when the house is at sleep), to see if i better understand it. :D
Atari will rule the world, long after man has disappeared

sometime my English is a little weird, Google translate is my best friend :)

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: An interesting way to get more colours on an ST/E...

Postby dml » Mon Nov 12, 2012 5:09 pm

I'll probably need to improve the explanation a few times before it makes complete sense on the first read - I did it in a bit of a hurry and some detail has been compressed.

The general principle is to get each colour in the 16 colour palette doing more than one job - it should mix with not just one other colour (e.g. mixing two greys to get a mid-grey) but with *several* colours - as many as possible - to 'multiply up' the number of useful/intended colours. The cost of doing this is increased distance between each mixing pair - and more visible flicker or grille patterns - which need to be managed in other ways (such as treating luma and chroma significance differently for colours with different population counts - using nonlinear colour perception management... and so on)

The main difficulty is in finding suitable permutations because the space to search for these is really big, measuring the cost of a choice is relatively high for the size of the search and there is more than one solution to each problem (lots of the solutions are really terrible!). But there are some semi-optimal solutions which can give surprising results if they can be found with the search algorithm. And you only need to perform the search once on each set of game graphics - once you have the palette the image is easy to solve.

The rest is just 2-field interlacing and some careful balancing heuristics to get the best results for each image. This is what makes it possible to use with scrolling backgrounds, sprites etc. It still costs a bit more to draw stuff - about 1.5x or 2x the normal cost of drawing graphics because you need to maintain at least 2 buffers for every physically displayed image. The CPU load for displaying though is zero.

It looks much better on real HW than it does under emulation, because the emulators struggle to present a clean VBL refresh. Since it's a perception-based effect, frame dropping and shearing cause the illusion to break temporarily. However on real HW, it's possible to completely isolate 'game framerate' issues from 'display framerate' issues (my demo should show this) and get a stable image all the time even if the game has to slow down for other reasons.

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 660
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: An interesting way to get more colours on an ST/E...

Postby Anima » Mon Nov 12, 2012 5:17 pm

Hello dml,

very interesting stuff.

What I can think of is Galaga 88 for the STE using this technique. :D

How does it fare when you have moving objects especially on full framerate? Does the quality of multi color perception change in this case?

Cheers
Sascha

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: An interesting way to get more colours on an ST/E...

Postby dml » Mon Nov 12, 2012 5:48 pm

Anima wrote:What I can think of is Galaga 88 for the STE using this technique. :D


I was a bit tempted to ask about this earlier - but I wasn't sure if the STE was too low spec for the X68000 emulation in general... I suppose if anyone would know the answer it would be you. :)

Anima wrote:How does it fare when you have moving objects especially on full framerate? Does the quality of multi color perception change in this case?


It definitely can go downhill when things move if nothing extra is done, but I found it is possible to maintain the illusion quite well if you know what the eye is probably doing with each thing on the screen. e.g. for scrolling backgrounds, the eye locks onto the scroll in order to see detail, so the interlace pattern should 'anti scroll' accordingly. Sprites need their own independent 'anti scroll' since they aren't tracking the background. But the solution in most cases is similar to the 'preshifted parallax' stuff people already use in games or demos. It also seems to work at 25 or 50hz although I haven't spent enough time comparing to decide if there are specific problems with one mode or the other.

I have set up a playfield example which does all the buffer management so its just a case of feeding in tiles and sprites and placing them on the screen. The background bit is working but the sprite stuff needs some work for the draw/undraw business.

I tried a few 'anti scroll' compensation methods including direction-sensitive and 'random' interlace patterns for different kinds of scroll (like vertical pattern for vertically moving objects). Tricks like that work very well with it, but obviously complexity can get out of hand if you try to do absolutely everything possible at once.

The first demo will likely use a simple checker interlace pattern plus anti-scroll compensation for anything that moves, as it's fairly easy to do. A specific game project might pick a compensation method that suits it best, possibly with a different pattern for backgrounds and sprites.

The other important trade is image stability vs colour accuracy. By trading off a bit of accuracy in clever ways you can increase image stabilty quite a bit. e.g. background fills with a large surface area - ideally you keep the luma delta small for interlace on those big surface area colours, but smaller things can be much more flexible with interlace mixing.

I'm looking at a few other tricks which seem to help but still figuring out the best ways to control it and get decent results out.

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 660
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: An interesting way to get more colours on an ST/E...

Postby Anima » Mon Nov 12, 2012 8:05 pm

dml wrote:
Anima wrote:What I can think of is Galaga 88 for the STE using this technique. :D


I was a bit tempted to ask about this earlier - but I wasn't sure if the STE was too low spec for the X68000 emulation in general... I suppose if anyone would know the answer it would be you. :)


I am still figuring out which functions are necessary for the gameplay and which can be omitted and/or replaced. IMHO there's a small chance that the STE is capable of running it at least with a 25/30 Hz screen update.

Just looking forward for your demo. ;)

Cheers
Sascha

User avatar
Scarlettkitten
Captain Atari
Captain Atari
Posts: 259
Joined: Thu Mar 19, 2009 11:42 am
Location: Northamptonshire, UK

Re: An interesting way to get more colours on an ST/E...

Postby Scarlettkitten » Mon Nov 12, 2012 8:33 pm

Can't wait to see this technique in action. :D
Music gear
Falcon 030 14MB, Cubase Audio, Soundpool FA8,FDI, MAudio 88 keystation, Roland S750, Yamaha A5000, Roland JV1080, Yamaha MG10, 1040STE, ZX Spectrum 128k.

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: An interesting way to get more colours on an ST/E...

Postby Dio » Mon Nov 12, 2012 9:03 pm

Interesting technique.

Terminology note though - you use the phrase 'deinterlaced' but the ST is incapable of generating an interlaced signal (it can't generate the half-lines required for interlaced operation) - frames out of a constant 313-line system are just 50Hz, 313-line frames. So I think you need to find another word to describe the colour-flipping technique.

Zamuel_a
Atari God
Atari God
Posts: 1221
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: An interesting way to get more colours on an ST/E...

Postby Zamuel_a » Mon Nov 12, 2012 9:18 pm

sounds like this would only work if you have a screen with alot of graphics and higher resolution. If you have a "normal" game you would see alot of flicker since the sprites change colors and the background to. For static images with millions of colors I guess it works, but sounds difficult for other stuff
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: An interesting way to get more colours on an ST/E...

Postby dml » Mon Nov 12, 2012 9:36 pm

Dio wrote:Terminology note though - you use the phrase 'deinterlaced' but the ST is incapable of generating an interlaced signal (it can't generate the half-lines required for interlaced operation) - frames out of a constant 313-line system are just 50Hz, 313-line frames. So I think you need to find another word to describe the colour-flipping technique.


I'm aware the language is a bit ambiguous - a better term could be found. However the 'interlacing' I refer to is not the colour flipping but rather the way the colours are interleaved within one field (checkerboard, random or lines, etc...) in order to allow the colour flipping to work without strobing - to keep the intensity bias equivalent on both fields. Real scanline interlace isn't quite the same thing but the term is near enough for my purpose and lots of other people have been abusing it similarly :)

Maybe 'field interleaving' is better. I'm sure somebody will come up with something.

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: An interesting way to get more colours on an ST/E...

Postby Dio » Mon Nov 12, 2012 10:19 pm

There's no fields in 50Hz either - but frame interleaving seems much more accurate to me :) .

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: An interesting way to get more colours on an ST/E...

Postby dml » Mon Nov 12, 2012 10:19 pm

This is an early test build from about a week ago when I got it displaying a moving image on the STE for the first time. I sent this to a few friends for testing while I worked on improving the system.

Ignore the 'splash screen' - I changed the playfield stuff several times after it started working so it's not doing 8-way scrolling at the moment. Just horizontal.

https://dl.dropbox.com/u/12947585/cryptochrometest1.st

This is mounted for testing here in an emulator but it looks terrible unless you can get a perfect VBL sync (Steem needs borders disabled and 'draw every frame' for a start - but it's not quite enough). I had similar problems with Hatari. I don't recommend it under emulation.

It really is best put on a disk and booted on a real STE, where every VBL arrives on time :)

When the field interlacing/interleaving is stopped you'll just see a strangely dithered 16 colour picture. When display resumes it looks smoothly shaded. This version was made before the luma/chroma management was implemented (and a bunch of other stuff) so newer images look MUCH stranger when the display is 'stopped'. The input image for this test is also a lot less challenging than some of the more recent tests I have done, although my aim all along was to improve ingame graphics - trying to display truecolour photos using this method isn't really necessary.

It probably needs 4mb of ram, I wasn't very lean with memory for 8 way scrolling with multiple double buffers etc.... that will get sorted soon.


I'm just posting this to give an idea of the effect - what to expect. It's already old code. The convertor tool has already been through a few upgrades and improvements, as has the playfield display stuff. Next one will be more interesting looking but it is subject to free hours at the keyboard...

...all for now. See if it works for you. My STE is dead so I'm relying on my Falcon with fiddled VGA signal, and that isn't really an honest test.

Zamuel_a
Atari God
Atari God
Posts: 1221
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: An interesting way to get more colours on an ST/E...

Postby Zamuel_a » Mon Nov 12, 2012 10:45 pm

The demo looks cool, but it's a moving image. What would happen if it's a static one? Like in an RPG game (there the graphics in this demo looks like it came from). If the player stands still you would see the dither I guess and the flicker. They use that technic on many newer TFT monitors (the 16.2M color ones) and I can see the dither flicker on them even that the resolution is so much higher than 320x200 :wink:

How do you calc the color dither in realtime, which you must do if it's a game. Sounds like it would take alot of power.

One game genre I think this could work in are shoot em ups, there you always have a moving background. There is an old thread here about making a shootemup game with an animated background, but the 16 color limit was always a problem. Maybe this technic could be used there, but since the background would be an animation it would still be the old "flicker 2 16 color pictures to get 256 colors" images, so nothing new :wink:
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 660
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: An interesting way to get more colours on an ST/E...

Postby Anima » Mon Nov 12, 2012 10:56 pm

Great. This is exactly what I expected and it looks good.

Cheers
Sascha

User avatar
Omikronman
Atari Super Hero
Atari Super Hero
Posts: 525
Joined: Wed Dec 01, 2004 12:13 am
Location: Germany
Contact:

Re: An interesting way to get more colours on an ST/E...

Postby Omikronman » Tue Nov 13, 2012 7:54 am

It does not work in Hatari 1.6.0. All I see is a black screen with a lot of blue/green moving pixel thrash in a blocky style. :(

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: An interesting way to get more colours on an ST/E...

Postby dml » Tue Nov 13, 2012 10:32 am

Anima wrote:Great. This is exactly what I expected and it looks good.


Thanks! I'll post something a bit more interesting soon. I have some arcade game maps I have been working with so I may pick one of them next time. I'll also make sure the scrolling is more variable and pauses from time to time.

Cheers,

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: An interesting way to get more colours on an ST/E...

Postby dml » Tue Nov 13, 2012 10:43 am

I had a few comments already along the lines of 'just flipping two 16 colour images' - which is absolutely true from a display point of view (that is what makes it cheap after all).

However looking at it this way can miss the point a bit. Without the correct palette, the 'dithering' can't reproduce the colours. The source material isn't even generated with dithering, it is generated as two complementary fields, which are then interleaved with a dither mask. It looks like classic error dithering but that's not how the process works. It is more like a fully automatic version of what game artists / pixel painters do when hand-dithering colours in sprites - and this is an arduous task (I have done it and I know).

Classic error dithering takes place after you generate your palette - compensating for errors in palette matching using another palette index, but this happens blind and it's just luck when a useful dither colour is available to deal with a given pixel error. The method I'm using finds the palette and the complementary pairing at once, so there is no need to dither the errors out. It's all been figured out in the palette beforehand. The result is the interlacing / interleaving mask becomes much less visible when the display starts alternating the fields.

Here's an example, using the image from the demo. The palette choices are generated to complement each other as efficiently as possible BEFORE any dither mask is applied....

complementary field #1:
Image

complementary field #2:
Image

...and the dither mask just interleaves the results to keep the intensity bias equal over time. This system generates the palette with the diffusion already accurately 'baked in' so the display alternation and dither mask 'complete' the solution.

interleaved composite when displayed on STE:
Image

original:
Image

So, yes - it is just flipping two 16-colour images. But you need to generate the right kind of images and that's the hard bit. This is my method :)

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: An interesting way to get more colours on an ST/E...

Postby dml » Tue Nov 13, 2012 10:49 am

Here's another example from an early test (without the luma/chroma compensation and cie space work recently done) - the complementary fields in this one look quite strange when viewed individually... but the final image is a good reproduction of the original.

field #1:
Image

field #2:
Image

STE:
Image

original:
Image

User avatar
Omikronman
Atari Super Hero
Atari Super Hero
Posts: 525
Joined: Wed Dec 01, 2004 12:13 am
Location: Germany
Contact:

Re: An interesting way to get more colours on an ST/E...

Postby Omikronman » Tue Nov 13, 2012 11:03 am

That looks quite interesting. :)

User avatar
alexh
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2630
Joined: Wed Oct 20, 2004 1:52 pm
Location: UK - Oxford
Contact:

Re: An interesting way to get more colours on an ST/E...

Postby alexh » Tue Nov 13, 2012 11:20 am

I wonder if a similar technique was used on the ST/E title screen of Thalion game "Leavin' Teramis".

When run on real hardware you can see an "interlaced" effect where colours are obviously changing each VBL.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: An interesting way to get more colours on an ST/E...

Postby dml » Tue Nov 13, 2012 11:53 am

alexh wrote:I wonder if a similar technique was used on the ST/E title screen of Thalion game "Leavin' Teramis".
When run on real hardware you can see an "interlaced" effect where colours are obviously changing each VBL.


Yeah that's possible. It's likely there are games, demos or single screens from the past that do something like this. It could even be hand-made or a mixture of tools and manual work. The production method in each case is likely quite different. I should probably take a look and see what exists.


I think the Bitmap Brothers' 'GODS' used a combination of reducing saturation and dithering near colours together to make pseudocolours - without the interlacing but some of the other ideas are present.

Having remembered this, I decided to deal with some of the most difficult tests (Pacmania screenshot was one of the tough ones!) by reducing saturation to 75% - pushing more of the target colours into a range which could be simulated by palette colours nearer the range limit (i.e. all pseudocolours are 'between' real colours - and some of the more useful/reusable real colours want to be generated outside of the valid intensity range).

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: An interesting way to get more colours on an ST/E...

Postby dml » Tue Nov 13, 2012 11:57 am

I forgot to explain one other detail - the two fields are deliberately sorted by intensity so each complimentary pair has the low intensity part in one field, and the high intensity in the other field. This ensures that the intensity bias is approximately zero when the fields are combined using the mask. If this isn't done, some parts of the image will flicker, with other parts stable and the overall effect is poor.

Zamuel_a
Atari God
Atari God
Posts: 1221
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: An interesting way to get more colours on an ST/E...

Postby Zamuel_a » Tue Nov 13, 2012 6:08 pm

I don't understand how you will calculate the screens in realtime if you have moving objects so that sprites works.
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

FedePede04
Atari Super Hero
Atari Super Hero
Posts: 966
Joined: Fri Feb 04, 2011 12:14 am
Location: Denmark
Contact:

Re: An interesting way to get more colours on an ST/E...

Postby FedePede04 » Tue Nov 13, 2012 7:02 pm

as i understand it,he has already calculate the gfx when he created it,
so when the game is running he just copy/past the gfx and that should work, because there are already balance in the gfx, even on small objects
Atari will rule the world, long after man has disappeared

sometime my English is a little weird, Google translate is my best friend :)

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: An interesting way to get more colours on an ST/E...

Postby dml » Tue Nov 13, 2012 7:10 pm

Zamuel_a wrote:I don't understand how you will calculate the screens in realtime if you have moving objects so that sprites works.


Everything is precalculated offline, into the 2 component fields ready for drawing. The complexity at runtime is purely in managing the display buffers and ensuring the field for each graphic goes to the correct buffer.

e.g. for a double-buffered drawing scenario, my sample project sets up 4 display objects like this:

Code: Select all

arena
{
    buffers [active,hidden]
    {
       playfields [odd,even]
       {
            display memory
            field-specific background tiles
       }
    }
}


Each 'playfield' is responsible for one display buffer and associated graphic material. The 'odd' playfields are assigned tiles/graphics precalculated for the odd fields only, and the same for 'even' playfields. The display manager then alternates between odd/even display objects for every display refresh, for the ACTIVE buffer. The tile/sprite drawing takes palce to the HIDDEN buffer. When drawing completes, the buffers are swapped by the main program. The display manager is responsible for picking up the new active buffer for the next display refresh. This allows the display manager to maintain the illusion at 50/60Hz, independently of the game framerate - which could be equal or lower.

There is some extra complexity to (optionally) manage 'anti-scroll' for the interlace mask on moving backgrounds and objects but for the simplest case this is just finding the odd/even coordinate remainder and xor with the selected field (for display scrolling), and for individual objects such as sprites, both sets of graphics must be available for use on both fields at any time and must be selected for anti-scroll and redrawn before each buffer rotation.

Overall it is more complex than drawing for a normal game - it is quite similar to the background-preshifting method used for simulated scrolling - but in cost terms it is only a little more expensive than a typical double-buffered system because roughly the same amount of work is taking place (it costs relatively more at 25Hz than 50Hz because drawing needs to be done for both fields ahead of time, but some of this cost can be amortized - I have done this in my demo by drawing tiles to multiple buffers at the same time as they are always in sync).

It is kind of hard to explain all the details involved and I'm probably over complicating it - it will probably be easier to just read the code when I am ready to post it.


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: No registered users and 2 guests