Amiga.org
Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started by: evil_nerd on April 29, 2004, 10:40:14 AM
-
Hello,
I am wondering how much colors a Amiga 500 can display. I have read 16, 32, 64, 4096, but I don't understand. There's a pallat of 4096 colors isn't it? Depending on the mode you can have 16, 32 or 64 colors. But in most Amiga games I see much more colors, very nice indeed, but how do they do that? Is there some trick or something? It wouldn't be logic if the Amiga is limited to 64 colors, because a MSX2 (a few years earlier) could display 512 colors!!! So, can anybody explain this???
-
I gave you an answer on The Amiga Forums: http://www.amigaforums.org/forums/viewtopic.php?t=1404
Bye,
Thomas
-
Yes but its always nice to ask it on a forum where are more people around :lol: :-P :-D :laughing: ;-)
But what I ask is is there a trick or something? The games that I've seen have more than 32 colors (some are on the PC VGA (256 colors))
-
Thomas's reply was bang on. If a bit technical :)
The amiga A500 hardware could display 16 or 32 colours in game. The copper could be used to change colours per line for all those lovely fades you see in amiga games :) It also had a 4096 HAM mode (mainly for static imagery- Art programs, adventure games, loading screens etc). You could also have different colour/resolution screens dragged up for menu bars etc. I used have a ham hires mod player that looked like a stereo- it used to sit at the bottom of a 16 clour lo-res workbench :)
The the A500+ and A600 EHB mode was added allowing 64 colours (darker versions of the first 32 colours)
This is all in hardware: coders produced their own code for introducing more colours: Lion heart had hundreds of colours on screen, as did Universe (256 from 4096) rumour has it they picked certain ham colours that caused no fringing, and just diplayed them.
-EDIT- Iv'e just realised mine sounds technical as well, guess there is no easy way to explain it :(
-
@Khephren
The the A500+ and A600 EHB mode was added allowing 64 colours (darker versions of the first 32 colours)
All A500 models had EHB.
Only very early A1000 models didn't have it (or was it some early Amiga prototypes, can't remember).
-
Thomas's reply was bang on. If a bit technical :)
The amiga A500 hardware could display 16 or 32 colours in game. The copper could be used to change colours per line for all those lovely fades you see in amiga games :)
so you can change the pallet per line of pixels or something?
It also had a 4096 HAM mode (mainly for static imagery- Art programs, adventure games, loading screens etc). You could also have different colour/resolution screens dragged up for menu bars etc. I used have a ham hires mod player that looked like a stereo- it used to sit at the bottom of a 16 clour lo-res workbench :)
The the A500+ and A600 EHB mode was added allowing 64 colours (darker versions of the first 32 colours)
This is all in hardware: coders produced their own code for introducing more colours: Lion heart had hundreds of colours on screen, as did Universe (256 from 4096) rumour has it they picked certain ham colours that caused no fringing, and just diplayed them.
fringing? whats that? Whats HAM? 16 or 32 color?
-
so you can change the pallet per line of pixels or something?
Yes. Actually, you can even change the palette in the middle of a line if you like, all without the main CPU having to do the work.
fringing? whats that? Whats HAM? 16 or 32 color?
HAM is a special display mode.
Normally, the colours on the Amiga display are stored in standard bitplanes. See here (http://en.wikipedia.org/wiki/Planar) for a good description of planar graphics.
HAM is a different way of interpreting the bitplane data, such that some pixels depend on the colour of the pixel to the left of them. If you change that pixel, all the pixels to the right that use this encoding change to the wrong colour, which is known as "fringing". Theres a good description of HAM here (http://encyclopedia.thefreedictionary.com/HAM).
Edit: Although I'm pretty sure that article is wrong in one respect. I think HAM uses all 6 bitplanes, and uses 2 of those bitplanes to mean "Indexed colour", "Modify Red", "Modify Green" and "Modify Blue"
-
HAM is 4096 color. 16 colors can be choosen directly and the others need three pixels to be set (one for changing red, one for changing green and one to change blue).
And yes, theoretically the Copper is able to change the colors every line. But every copper instruction needs as much time as the graphics needs to display four pixels. Changing all 32 color registers needs more time than the horizontal sync signal (the time the beam needs from the right end of one row to return to the outer left in order to start the next row). But it is easily possible to create a color fade from the top to the bottom of the screen with only one color register. For example for creating a sunset sky and the corresponding horizon and ground as a background. No graphics data is needed for this apart from the Copper's command list. The foreground can be painted using the remaining 31 colors (or 4096 colors in HAM).
Bye,
Thomas
-
Ok, its a little bit more clear for me now :) Although I have to study HAM a few times more before I understand it :-o
-
offtopic:
I see there are more nerdy ppl in here, guess what I did last night ?
*code*
start:
move.l #cop,$dff080
move.l #1,$dff088
eternal_loop:
jmp eternal_loop
cop:
dc.w ...
[more..
..of..
..it]
dc.w $ffff,$fffe
*/code*
WHat do you think, the worst ever intro or what ? :-D :lol:
-
GreatLor wrote:
WHat do you think, the worst ever intro or what ? :-D :lol:
Errm.. I think your startup code needs a little work :) Maybe this link (http://www.amiga.org/forums/showthread.php?t=6803) will be of use to you? ;-)
-
Startup code is ok, but I don't like the exit code. Usually you want to return to the assembler without reboot after the test.
Something like
mouseloop:
btst #6,$bfe001
beq.s mouseloop
;
; restore system copper list here
rts
is much more convenient.
Bye,
Thomas
-
Defender, whats this startup-code ?
oh, I DID some 2 one-screen demos back in 92-93, one of them used used huge fonts in a scroll, fonts that I drew myself in deluxe paint III I think it was, anyway I did both the graphic (phont) and the code pretty nice, that was fun, and also I drew a picture which I then coded a wave-effect to it (a pretty amateur one, nevertheless), but somehow I wasnt very fond of that OS stuff one had to code, so I just copied a routine to take care of things :-P , thats pretty much what I did back then, oh I also tried horizontal starscrollers, but failed, cos I didnt know how to work with float-numbers in SEKA, well that was a little story from my amiga life, I hope you enjoyed me babbling nonsense stuff ! :-)
-
*sniff*
Man, sometimes I actually regret getting a graphics card. Getting into harware banging was fun, but alas I sold my soul for RTG :-(
-
I know thomas, just didnt have time/energy to look in my VERY old mags hehe ! hey thomas, have you done any Intros or soomething ?
-
Well, some school friends of mine were members of a scene group. Alpha Flight, IIRC. They [d]provided me with cracked games and[/d] encouraged me to start coding intros and demos. I think I finished two or three works which were really published, but I never advanved as far as the "real" demo coders. If memory servers correctly just before end of school (must be 1989 or '90) we joined a group called Catwalk. But then I lost contact to the people and to the scene shortly after that.
One of my friends coded a translator which created 68k assembler code from Rob Hubbard C64 songs, just around the time when (or shortly before) PlaySID was developed.
Bye,
Thomas
-
ok I wanna give it a try! Using C, I wanna make some graphics :D But whats a good tutorial (never programmed on an Amiga before, is it much different from x86?
-
I you mean asm all I can say is that it is HELL alot more elegant syntax in the 680x0 family, I had a look at x86 asm syntax, I didnt exactly fall in love with it (actually was almost throwing up), do you know x86 evil_nerd ? I dont understand how ppl can code x86 cpu's, hell even in C it's a HELLISH SLAVISH amount of code just to use the damn API's for gods sake ! :-(
-
The basic Amiga 500 had a color palette of 32 basic colors. I'm not sure at what revision they also added Extra HalfBrite mode, but you couldn't modify the halfbrite colors directly since there were only 32 color registers, but you could basically have images with 64 colors total. There could be a maximum of 6 bitplanes.
Then you had HAM6 mode, in which 2 bits of each pixel's value determines the code of what to do (ie hold, modify red, modify green or modify blue), and 4 bits to determine the amount to modify that component. It could only modify one component at a time per pixel so took about 3 pixel to fully transition to a new color, although it did allow you to select from a base color palette of 16 colors when you told it to `hold`... ie use a real color.
The color palette itself had a 12-bit color resolution, ie 4096 maximum different shades. Some clever people invented something called Dynamic Ham making use of the Amiga's copperlists to modify the palette on give lines of the screen or at given intervals, allowing the literal pixels (from the palette of 16) to be used more often using modified colors... but if I recall, the copper could only modify one color register per 4 (or was it 8?) low-resolution pixels horizontally, so only so many changes could be performed in a given amount of space. Either way, this could be used to optimize an image and display using more individual colors and therefore less of the `modify` operations.
It was the inability of a modify operation to change more than one component at a time, requiring 3 pixels to completely transition, that led to the effect they called `Ham Fringing`, ie a color `bleed` where modify operations were used that didn't get close enough to the color you wanted for a given pixel. Good software would be able to change 24-bit images into a Ham image with a specially selected color palette to make best use of the 16 color registers so that there was the least fringing and best color representation.
There was also something called Sliced Ham which was basically dynamic ham but there were only a set number of palettes per image, divided into slices down the screen, rather than the constantly modifying copperlist of Dynamic HAm.
Also you can't really say that there were only 32 (or 64) real colors because you could also apply the copperlist to change color registers at any point in the display (although only one change per unit of (4 or 8?) pixels). ... With clever and diligent use this allowed several different slices of the display to be given different color palettes, so in a game like Shadow of the Beast you could have your 8-color clouds with their own palette, then some mountains with their own palette, then some horizon-ground stuff, then some foreground, and also the strip with the fence at the bottom of the screen, etc, and I'm sure the same effect was used for the other 8 colors of the foreground playfield (since it was a dual-playfield game with two separate bitmaps of 3 bitplanes each).
And that's another thing, dual playfields would split the 6 available bitplanes into two sets of 3, each with their own palette of 8 colors, and could be scrolled independently of each other... Bits (pixels) in one set of bitplanes would not be affected by bits in the other playfield, thus giving the impression that there were two layers (or playfields)... or in other words, the bits from the lower 3 bitplanes were overwritten with bits from the higher bitplanes rather than being combined with them, on-the-fly as the copper render the display. So in this mode, some software had only 16 base colors to work with. .. but of course they could do some copperlist magic to change color register contents across each line and down the screen... hense a cool colorful looking game like Shadow of the Beast I think was quoted as having at least a few hundred simultaneous colors onscreen.
So with judicious use of the copperlists and the dual playfields and careful design of whatever the particular software or game is, it was possible to actually output a lot more colors, and I know some games probably had way more than the basic 256 colors that PC's were starting to come out with their VGA displays. I don't think there were many Ham-based games, but there were some. "Universe" springs to mind. The only issue with Ham was that, since the color changes occured as the copper rendered the display to the output device (monitor/tv), it would modify the color based on what the color was immediately to the left. So you had to be careful to use one of those literal colors from the color registers down the left and right edges of moving images (blitter objects - bobs), so that there wouldn't be unsightly fringing or incorrect colors. That was quite a challenge to achieve, and could be noticed in all Ham paint packages that moved brushes around. As a result, Ham was kind of slow but it was pretty at the time.
Also there were hardware sprites which, even if the display was only using, say, 8 colors, would render the hardware sprites in colors from higher up in the palette, so there could be more colors used than the number of actual bitplanes in the bitmap data. With some judicious use of copperlist color changes and careful switching on and off of sprites as their data was rendered by the hardware on the fly down the screen, `virtual sprites` could be drawn each with their own color palette. I don't exactly remeber if sprites were 8 or 16 colors, tho, just that they were only up to 16 pixels wide and there were 8 of them (one of which was the mouse pointer in the o/s).
So basically overall it's hard to exactly say how many colors the A500 had. It was capable of 4096 colors - a 12-bit color palette, potentially simultaneously, but it would depend largely on clever design techniques and special copperlist palette changes to make full use of all of the colors at once. Even though there were only 32 modifyable color registers, and 32 halfbrite registers (in later revisions only I think), there were allowed to be up to 6 bitplanes... which could be used in various clever ways, either in split playfields or Ham modes or whatever. I am sure that some games I saw made very clever use of color changes to make the screen very colorful and I'm sure I've read some game companes reporting that their games had over 1000 colors on screen at a time in some cases.
The separated bitplane model - ie Planar graphics rather than Chunky, was cool.. even though proving eventually less efficient for certain kinds of graphics manipulation on a per-pixel basis.
Ahhhhhhhhhhhhhhhh.... those were the days. I'm surprised I remember all this! But of course I do, cus I really loved my Amiga 500!! *kissy*
Paul
-
evil_nerd wrote:
ok I wanna give it a try! Using C, I wanna make some graphics :D But whats a good tutorial (never programmed on an Amiga before, is it much different from x86?
Before you start coding for the Amiga you have to learn about the structure of AmigaOS and its coding rules. #include will not work on the Amiga.
A big big recommendation is to buy the Amiga Developer CD. It is not too expensive, especially in its older versions which all cover the 1.3 NDK (Native Developer Kit).
It also covers the RKRMs (ROM Kernel Reference Manuals) which are essential readings.
Bye,
Thomas
-
No, I understand that #include will not work :-) But before I buy the CD, are there good sites on this topic?
-
The only website I know that has any decent example source is the Aminet (http://aminet.net/dev/c/index.html). There are also C compilers on there too. (DICE C should work on Kickstart 1.3 but if you have Kickstart 2.0 or newer and a lot of memory VBCC produces better code.)
-
Every Amiga 500 ever built had 64 color mode.
This is why games like Dungeon Master were so dam
depressungly disappointing with its puny 16 colors.
Dungeon Master was ported from Atari ST which only
allowed lame 16 color games.
The 64 color EHB mode was introduced in 1985 with
the A1000. Some A1000s came with the 64 color chip
while others did not. I know because I was there.
The most colors I ever personally programmed in any
AmigaOS game for the A500 was about 80. (Chaos WWII)
The most colors I ever personally programmed in any
AmigaOS game for the A1200 was about 6000. (Total Chaos)
-
But before I buy the CD
Why ??? It is essential. And it is cheap. And it has a C/C++ compiler with GUI on it (which requires Amiga OS 3.x though, and a CD-ROM drive of course).
However you might have a look at the programming part of http://www.amigau.com/
Bye,
Thomas
-
@ChaosLord
"...The most colors I ever personally programmed in any
AmigaOS game for the A1200 was about 6000. (Total Chaos)..."
Interestig. Never tried it. Was that with HAM8 or using the Copper to change the pallete on the fly?
-
"...The most colors I ever personally programmed in any
AmigaOS game for the A1200 was about 6000. (Total Chaos)..."
Interestig. Never tried it. Was that with HAM8 or using the Copper to change the pallete on the fly?
yes :-D
HAM8 for 6000 colors + 16 more colors at bottom of
screen using AmigaOS Copper.
HAM8 can easily do 256000 colors I just never displayed
any artwork that actually used more than 6000 or so.
-
What about those pictures that were in hires lace, but with 16 independent colors per scanline (IIRC)? What was the name of that mode? It's been so long since I've seen one that I've forgotten. Does WinUAE fully support those? I'd love to convert some of them over to truecolor images. The ones I used to have were quite brilliant, and I believe they used the full overscan too, but I could be wrong.
-
Hey I've got interested somewhat in coding the amiga in assembler again, during the past days I've been sick at home and reading a two-page article about coding the dos an assembler from a mag called "hemdator-nytt" (swedish mag) from 1990 (tears).
Now, I want to use the DOS in asm and I'm looking for pages containging files, giving all the info of the OS-libraries, the offsets to their routines and the in/out parameters, please post any links you have.
Thanx in advance !
-
LocalH wrote:
...but with 16 independent colors per scanline (IIRC)? What was the name of that mode?
That was SHAM (sliced HAM) or something wasn't it? I remember there was a HAM8 derived version that could get so close to 24-bit you'd struggle to tell the difference.
There was also a strange 15-bit emulation that used the old HAM6 laced mode. Each pixel was split into two (vertically) where the least significant bits of the 15-bit data were split between the upper and lower pixels.
So, suppose you wanted to show the lowest level of grey possible in 15-bits, the upper pixel would have 12-bit RGB values of 1 1 1 and the lower pixel would have 12-bit RGB balues of 0 0 0. This pattern of upper/lower was inverted every pixel to produce a regular dither pattern to improve the effect.
The eye thus saw one larger pixel as an average of the two colours and you got the effect of an extra bit of precision for each channel.
It was pretty simple, but effective :-)
The downside was you couldn't show images that were taller than the lowres mode because effectively the onscreen image was doubled.
-
Interesting stuff about the SHAM and the vertically split ... ie two vertical pixels representing a color, thing... although obviously that would suffer a resolution penalty.
Another technique for a slightly flickery display just came to mind ... I don't know if anyone ever tried this but it would give the illusion of billions of colours....
I don't know exactly how fast screen/palette switching is on graphics cards these days .. I seem to remembering it was more difficult to synchronize such things with the vertical blanking cycle on gfx cards than it was on the old OCS/ECS/AGA chipsets. .. but anyway...
What if you had two versions of an image. One image has color precision rounded down to the nearest available colors, and the other has the color precision rounded up. Then you flip between the two images at 50/60fps so that each image is displayed for 1 frame.
The colors in the one image would seem to combine with the colors in the other image to produce a hybrid color?
For example, taking it to an extreme, black pixels in one image would combine with white pixels in the other to produce a grey?
Of course you wouldn't have to use only black and white. You'd use as many colors in each image as possible. If there was scrolling, both frames would scroll together... even if there is a 50fps refresh this produces the effect of it being a 25fps refresh.
It halves the refresh rate, but the illusion of a third color is produced for every pixel based on the combination of the two colors to the eye. Even if you only had 12-bit color in each image, surely this would give you an illusion of 24-bit color.. if not a lot more? I don't know what the exact formula would be.
I don't even know if the illusion would work but it would sure work BETTER if the refresh rate was high enough ... eg a 100hz refresh would produce a screen at 50hz with flips between screens being one flip per cycle. It would give you a 50hz screen with a whole lotta colors?
I haven't tried it, like I said, to see if the illusion actually holds up and if the flip is fast enough to make the effect, but hey... this just came to me and I don't have an Amiga. Maybe someone can try it and let us know if it works.
Imagine how many colours you could potentially have if you used the 18-bit color palette of AGA and flipped between two slightly differently colored versions of the same image? .... all those hybrid colors.. .36bit color?
-
Also the colors in each image would only be SLIGHTLY different from each other probably, greatly reducing a flicker effect, since flicker is caused by contrast?
-
Somebody could test using two 12-bit images whose `combined color` produces the correct 24-bit color. .. and compare it alongside the original 24-bit image, see if the colors look the same?
-
@pwest
Sorry dude, it doesn't quite work that way. If you add 2 x-bit numbers, the maximum result is an x+1 bit number. You get a 2*x bit number when multiplying, not adding.
So, if you think of your RGB 444 values, adding two together (like the vertical split system) gives you 555, since you are adding each 4-bit channel.
This is exactly what the fake 15-bit mode depended on, it did the rounding up and down for each laced pixel comprising one "normal" pixel.
-
All A500 models had EHB.
Only very early A1000 models didn't have it (or was it some early Amiga prototypes, can't remember).
:smack:
I don't think so. My A2000 originally did not have the Denise chip that enabled half-bright mode. I purchased it and added it in later. So I surmise that A1000s did not have them originally either, nor A500s produced about the same time as my A2000. (Were A1000s still produced after The A500 and A2000 came out?)
-
@aardvark
That's quite interesting, considering OCS Denise does EHB.
Perhaps some old stock of pre-OCS chips were used on some machines?
-
@ LocalH
You are probably talking about a program such as BROADCAST TITLER 2.0........................it allowed 320 colors on screen at once................16 per line?
it also had the SupeHiresMode (1440x480) or something like that. And on ECS 4 colors per line on the SuperHiresMode..............now when I say per line........I mean for each line of text you wrote....and it could smoothly change colors.
I still cant believe it every time I run it on my A600.it looks quite nice.
this program is still awesome today...........I love it..........its probably the best Character Generator on the Amiga (Besides the ToasterCG or Montage)............not even SCALA can match it in terms of the quality of the characters.
Also wanted to add that Brilliance 2.0 had the ability to paint on HAM without showing fringing like most other paint packages.
Also have a game called OverLander(Trainer).its a car game kinda like RoadBlaster or MadMax.........where when the game starts to load.it display an apparently more colors than HAM image with no fringing of a the Overlander Logo with a red car at the bottom............this is the highest quality HAM image I have ever seen on any OCS/ECS Amiga
I still cant figure how they did it and why no one else used this technique
Oh, and as far as I know........WinUAE cant run Broadcast Titler 2.0
-
Whoa, lots of dots there … use … … an ellipsis!
…
nice, eh?
Yeah, it was possible to achieve a lot of nice effects by programming the graphics chip in the Amiga, a lot of people never bothered to learn it that well though because the default stuff was so good.
Btw, I never thought much of EHB mode on the Amiga. I think that it would have been much better to use the 6th plane as an inverse plane. I.e., black → white, red → cyan. Would have allowed for a lot of extra colours in games instead of just darkening games (although useful for shadows, e.g., in Settlers).
-
@Karlos
Well excuuuuuuuuuuuuuwze me!
Well then it *at least* doubles the number of colors.
If I have a 16 color palette on one screen and a 16 color palette on the other, and I flip the two images quickly, I'm not just going to see 16 extra colors.
Each individual color in one screen is going to combine with each individual color on the other screen. Surely it's more something like the number of colors are squared. We're talking about how many unique combinations. I know there is some formula for that like something to do with N^2 or something cosmic.
Anyway, numbers aside, I still think it would produce more colors than normal and not require chunkier pixels or extra rows being wasted. It can be full resolution.
Somebody try it?
-
I thought EHB was standard on the A500, at least on my revision.
-
@pwest:
Many C64 graphic "modes" use this method to ge decent looking images.
If you kept the palette constant, and switched between two screens you'd get a possible 136 'colours' on screen (I worked this out previously on an Amstrad CPC forum, heh). A lot of these would be too flickery to use though, so you'd get more like 60 usable colours. As a picture also has colour gradients in the palette already the options reduce even further.
Changing palettes between screens wouldn't work either. If you want white in a picture, you've got to have white in both palettes. Same with black, and any other colour!
-
@Kephren:
Lionheart was one hell of a game graphically.
Considering that it was OCS and ran great on an A500 ... and from what I could see ran in two playfields, both 8 colours, the fact that there must have been hundreds of colours on screen at the same time due to clever copper manipulation ... whoa. And then it had that 3D backdrop (like the floor in SNES Streetfighter 2) of marshes on the first level.
Dammit, I must play that game again. Pretty damned difficult though.
-
pwest wrote:
@Karlos
Well excuuuuuuuuuuuuuwze me!
Easy matey - I wasn't flaming you or anything :-D Blimey!
I actually see what you're driving at with the idea but see the other posts before this one to see what would possibly happen.
I think the actual number of colours would be some permutation rather than a simple double or the square. I mean if you think about it, some combinations will be equivalent - eg if screen 1 had solid blue and screen 2 solid red, you'd get the same magenta as you would if screen 1 was red and screen 2 blue.
-
Shouldn't be to hard to try. Just use the copper to alternate between two screens. Or even use different images for an interlaced screen.
-
Lionheart was one hell of a game graphically.
Considering that it was OCS and ran great on an A500 ... and from what I could see ran in two playfields, both 8 colours,
In two-playfield mode the one in the front only shows 7 colors, because one is transparent and makes the back-playfield show through.