ceti331
-
Content Count
60 -
Joined
-
Last visited
Posts posted by ceti331
-
-
serious question.
I gather the C64 palette involved some compromises r.e. shared/flipped UV values
Does anyone think an improved 'universal 16color palette' would have been possible with benefit of hindsight (looking back at CPC464 & ST/Amiga games I guess..)
the only glaring change i'd make is to tweak the slightly sickly bright yellow
copying the palette from chaos-engine would probably not be universal enough IMO, excellent as it was.
-
Ok,
which has better colors:-
Jupiter Ace or ZX81
-
Now, imagine a C64 with that graphics.
And we're still talking 16 on screen colours.
And the A8 can't do them either, so once more this is a totally moot point and absolutely irrelevant even to your latest tangent away from the actual thread topic.
That's what a big pallette can do for 16 on screen colours. And that was my point.
Now, imagine a C64 with a palette of 128 or 256 colours to choose from.
With the same abilitys as now.
I agree a larger palette would have enhanced what the C64 can do.
but it was very capable where it was.. it was a good compromise.
A large palette would have ment more onchip registers, more going on in its video hardware
Might sound a bit silly
but as pete pointed out - Dan Malones' chaos-engine palette is very similar to taking the C64 palette and desaturating it. Maybe one could just do that with the TV -
Have i?
Then check the whole game.
It's nothing even like on C64.
hehe
yes that has the 3 least representative ingame screenshots, all very empty try this:-
-
Here's the ST version in 320x200
Not much dithering used to create new shades?
You've gone out of your way to pick the least dithered image, this has dithering all over the place.. even for flat shades (cliff tops)
broken image link taken from..
http://free-game-downloads.mosw.com/abandonware/amiga/games_c/chaos_engine.html
look at the image of the level exit
even more in the next metalic level
-
No dithering in there then? I see lots. About the only solid colours in there is the top of the trees and the floor.
Some levels even used dithering for the floor.
Agree dithering was a vital technique, IMO.
It allowed you to tradeoff detail vs color depth obviously... the eye is more drawn to edges, information is not equally scattered across the screen.
Gods' used it well to get a 3rd 'major shading range'.. the blue tinted grey, the orange/brown, and something midway between them.
Even many arcade machines with huge numbers of onscreen colors used dithering (e.g. In The Hunt etc)
-
To create a smooth detailed look like in Bitmap brothers games, use real shades. The resolution is too low to be dithered. You will loose all detail.
Bitmap often used about three different spreads and some well thoughtout single colours.
Yes this is why i liked the BB games. More real detail due to all the shades. Didn't matter that most of the objects were the same colours.
BB games did resort to dithering on larger elements.. Xenon's 3rd boss, etc etc.
Other more 'colourfull' games had to dither more.
i think on many TV's the 320 pixels wide tended to blur ordered dither together very well
-
(Rare case was BBC micro which could display more onscreen colors than it had in its palette!)
Yeah, but those bad boys FLASHED on and off!!
yeah I do recall setting the flashing rate as fast as possible
I would be curious to hook up a BBC micro to an LCD monitor with a really poor refresh rate to blur them together!
-
If you look at Bitmaps games, they use quite different palettes. But they use them very effective, and they had to because 16 on screen colours to work with, isn't much if you are about to create smooth shaded graphics.
Many games change palette often, like many driving games for exemple and creates night stages, sunset stages, different environments etc and makes good use of ST's 512 colour palette.
BB games (Dan Malone drawn stuff anyway) used a more C64 palette though, a reasonable shade (say 6-8 greys) with some very different colours and interleaved those using the greys to make other coloured shades. That's how things are done on the C64, You've got 4 greys in total including black and white, you add to those the blues or reds or greens etc and you dither them/interleave them (as the BB games do) to get the perception of more colour.
yup that was probably the best.. i'd describe his palette has halfway between C64 and the other BB games.
-
If you look at Bitmaps games, they use quite different palettes. But they use them very effective, and they had to because 16 on screen colours to work with, isn't much if you are about to create smooth shaded graphics.
Many games change palette often, like many driving games for exemple and creates night stages, sunset stages, different environments etc and makes good use of ST's 512 colour palette.
most bitmap games were 'greys' + 'yellow-orange-brown' (+ fewsome incidental colors). they looked great.
the key thing was lots of shades of single colors (as you correctly identify) to get lots of detail in the objects.
Some atari ST games even used the C64 palette
(or something similar)I'm not saying a bigger palette isn't good... just that on most computers the limitation you most feel is "not enough onscreen".
(Rare case was BBC micro which could display more onscreen colors than it had in its palette!)
-
Yes it helps because you can switch palette many times in the same game to give it more variation. Then you can create much finer spreads using a big palette.
One way to look at it. for each machine ask what you'd do to improve it.
I dont mind samey colorschemes between different games.. machines always tended to have a distinctive best way of using them. The bitmap brothers games had similar palettes... but IMO looked quite a bit better than rivals.
Amstrad CPC464 vs commodore 64... the Amstrad has bigger palette, but I think I'd still go for the C64's hardware fast sprites & scrolling over the Amstrad
-
Dithering isn't a good method to use because you will destroy all detail and half the resolution using that method. And it's very limited anyway.
Having large areas of single color also means 'resolution lost'
Generally in computer graphics you'd choose less res for more color depth
Dithering was always a highly effective technique on 8,16 bit computers.
even the 32bit PSX benefited from dithering
-
Only when you have a big palette to choose from.
Snes for exemple had 256 on screen colours AND a palette of over 32.000 colours to choose from.
clearly for a certain number onscreen, a bigger palette doesn't help
CPC464 xenon looks quite good to me, only 27 color palette but 16 onscreen being very effective.
an attempt at A8 xenon (see my mockup earlier) is clearly lacking onscreen colours.
-
Amstrad CPC. [Runs like buggery away from the CPC fanboys =-]
not bad at all
-
Dithering is always last way out when the machine simply don't have enough colours.
Just wrong. The ST/Amiga have enough colours - but they still use Dithering to overcome limits of mostly 16colors visible at once. (even amiga needs dithering on its 3color sprites or 7color playfields)
It is not about the Palette. it is about the bitmap/tiles/sprites
Even if the C64 had more colors it would still use dithering due to sprites & tiles being 3 colors.
-
So, what classic computer battle do we start up next?
have we got a consensus here yet, by ALL parties ?
-
If you put together shades instead it will look much more clean. Like in many games for ST. If you plan to use different colours, ...
...
The point isn't to put 16 on screen colours in the game all the time. The point is to be able to switch between lots of different colours to bring variation to your game.
agree 100% that many shades of fewer colours look best ( and yes I am a fan of the 2 ramp style seen in Paradroid or the bitmap brothers games)
the diagram earlier from "way of the pixel" shows why the C64 palette is an effective compromise
Really these 8bit machines can only display 3 shades of something at the same time in object detail.
The C64's palette & sprites/attributes allows for a lot of different ramps this way, allowing player/enemies & different background elements (e.g. walls vs backdrop) to be seperated.
Some 'hue rotation' approximating colours is necessary for C64 these ramps, sure.. but thats not a problem.
in real life, its very rare to see pure shades of a single colour... brighter areas would be lit by lightsources (e.g. yellow sun); darker areas would be lit by reflected ambient light (e.g. blue sky, earthtones in landscape)
So for cartoony game graphics, its fine to just have slightly different hues for the highlight & mid-tones.. & white is usually used for highlights.
From what i've seen on the A8 with its 5 color backgrounds, you need to make exactly the same compromise if you want a background with distinctly coloured elements.
You can use black, white, and a generic 'dark' color as the main 3 colours.. then have 2 distinct 'mid-tones' .. giving you 2 distinct ramps, only one of which can be shades of a single color.
Most likely you'd make the dark shade a different hue halfway between the hue of the two mid-tones you wanted,or you could have 3 pure shades and one different colour ramp thats futher off.
-
It feels like an uncomplete platform game.
Why?
You will have to focus on a few things and max them out because you can't have the rest to make the game complete. Exactly like they did in Mayhem in Monsterland. Crownland is a much more complete experience because they aimed the game for what's possible for an 8bit computer. Else it would have been recived the same review.
...
To mimic more powerful hardware isn't always a good thing to do, because you will have to sacrifice a lot of things. I would rather have seen a more complete game with less max outs in just certain areas.
Both look good attempts to create a unique machine specific experience inspired by something on better hardware. As such they're both interesting.
personally i was more a fan of the sci-fi type games, hence subdued palettes even mostly greys are just fine. More movement as was possible on the C64 wins for me. =More gameplay possibilities.
I agree 100% with what was said above - the fixed palette but more choice in where colors are, and how many different coloured blocks can move - was a highly effective compromise, and the C64 deserved its popularity.
Shame about the C64's not-quite bright yellow. That was an odd colour. But on wikipedia they state they needed to re-use YUV values, some colours are just complements or something, forced by what they could fit on the chip.
-
I give up
Quitter!
keep going till we reach a consensus
its an important issue.
-
lol deja vu. Is it the fact that Doctor Who is on and I've somehow been sucked into the time vortex ....
To make it REALLY easy, ignore anyone posting about rainbows, it's just for a laugh and there's no need for something like that to kick of another days pointless arguing.
Random diversion-
Seeing Dr Who and Rainbows in the same post instantly reminded me of the RAINBOW dalek re-design with their "Clear" colours..grrrr.
Maybe I should do a mockup of a 8bit doctor who game with DLI shaded daleks
-
Have a search for quantizator. Myself and a few other people have written converters that do 4 different colours per scanline and I'm just about to finish one that adds support for PMGs and mid-scanline register changing to get even more colours. Most of the examples are probably in the quantizator thread (sorry can't remember the coder off hand).
Pete
thats quite impressive, interesting stuff.
r.e Quantizator, to really throw the cat amongst the pigeons we should get some side by side pictures of C64 &per-line A8 paletizer
Regarding mid-line register changing - how intensive was this.. is it possible to horizontally re-use sprites?
-
Greetings, interesting app.
Q1How involved is the ditering here - Does it do ordered dither aware of the colour aproximations & hence additional error in the scanlines above/below
Q2 Has anyone tried a general converter using 4th tile colour. (even just one using 1 palette for the whole screen... i.e. trying to pick the most effective color for the 4th.
-
Has anyone got any stills of A8 representations of converted photographs/modern bitmaps, at 160x192 resolution
maybe generated by seperately palettizing each scanline ..something like that.
-
Yup, a discussion like this is quite insane. We are arguing about computers almost 30 years old. Like someone said, it's no good. We'll better put it on ice. Good luck with your game programming.
no. we'll keep going for another few decades until we've reached a consensus
only kidding
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Atari ST vs. Amiga
in Atari ST/TT/Falcon Computers
Posted · Edited by ceti331
Did ST's have concept of Fast(CPU-only) ram .. i.e. the 68000 could run fullspeed in fastram (or running ROM routines) while bitplane+blitter used ALL cycles in chipram
Amigas had more memory intensive video modes (68000+4 bitplanes = full CPU speed, but 5,6bitplanes started to steal cpu cycles i think; intensive copper use i.e. changing background color continously across scanline could also do that)
also how did the ST blitter behave, surely it would also have to do cycle stealing
Maybe i'm missing a detail here: Why was the amiga at 7.14mhz and the ST at 8mhz, if so rigorously tied to video scanout both clocks would be identical in 320pixels x 4bpp