Pixelation

General => Challenges & Activities => Commercial Critique => Topic started by: goat on March 28, 2006, 12:05:13 am

Title: Commercial Critique: The Chaos Engine
Post by: goat on March 28, 2006, 12:05:13 am
(http://i38.photobucket.com/albums/e106/masonbond/crit_chaos/title.gif)

For those new to commercial critiques, this is an activity where the community selects something, usually a game, containing interesting examples of pixel art.  We then discuss the pixel art as a group, analyzing and dissecting techniques that work for the art, and techniques that don't, in order to learn and grow and all that warm fuzzy stuff.

This time around we'll be critiquing The Chaos Engine, by The Bitmap Brothers.  To give a little background, The Bitmap Brothers played a huge part in bringing the Amiga platform to the front lines of popular gaming in the late 80s and early 90s, due in no small part to their freaking awesome graphics and immense levels of pixeling talent.  The Chaos Engine was selected by popular demand because it exemplifies some of the pixeling techniques that make their graphics great by today's standards while still working within the limitations of the Amiga's Original Chip Set (in case you wondered what all that OCS stuff people have been babbling about stands for)

Finding screenshots for critique:

- Screenshots of the OCS version (the original version, often preferred due to more subdued colors, particularly on sprites) are available here (http://hol.abime.net/2985/screenshot) and here (http://www.lemonamiga.com/?game_id=1848), among other places. 

- The DOS version of the game is available for download here (http://takegame.com/arcade/htm/chaos.htm).

- Those of you who prefer to kick it oldschool can download the Amiga OCS rom here (http://www.amiga.hu/amigos/ancientoys/c.html).  You'll need an Amiga emulator and an lzx-capable file decompressor.

Remember, kids: hotlinking images is a terrible thing to do.  If I still had hosting I'd put them all up on it for linking, but such is life.

We obviously have a lot to learn from these guys, and their art.  I can't wait to hear what grabs you about these graphics, and why, as well as dissecting some of these awesome techniques with you so that we can learn, move up, and move on as pixel pushers.



I'll throw my hat into the ring first.  One of the first things most people mention when giving this game its rightful praise is the color selection.  The artists managed to keep colors down while retaining a very high level of quality and fidelity in the art; in fact, many of their color optimization techniques became cornerstones of their style, or at least contributed to the atmosphere of the games. 

(http://i38.photobucket.com/albums/e106/masonbond/crit_chaos/splash_colorcast.gif)

Here's an early cutscene grab that I scribbled on.  This shot is an excellent example of one of a popular technique for color reduction.  As you can see, even though the general tone of the image is definitely a yellow-green, there are a few different things going on here colorwise; the grey of the dino's skin and top of the plateau, the brown on the ground, the pink of the gums and tongue, the skin tones and clothing on the wee people.  However, this image only contains 32 colors.

If you look at the colors I smudged out near the bottom of the image you can see that the palette cointains one big pale greenscale with a few mini-gradients of grey, brown, and pink to make up the rest of the colors.  By dithering colors from the greenscale into these other color palettes, especially within the transitional shades from light to dark (since the highlight and core shadow colors are the most important in showing the color of the light and the object it's hitting), they not only kept the total color count down to 32, but also gave the image a green, moody ambient color cast appropriate for a cutscene.  Near the top I blew up one of the little worker guys to examine how a full compliment of shirt shades was derived from two blues mixed with colors from the main greenscale.

Now for some actual gameplay graphics:
(http://i38.photobucket.com/albums/e106/masonbond/crit_chaos/ChaosEngine1_s13.png)(http://i38.photobucket.com/albums/e106/masonbond/crit_chaos/ChaosEngine1_s9.png)

These two shots show a practice popular with The Bitmap Brothers, their many imitators, and Amiga era pixelists in general, namely taking what we know and love about hue rotation and turning it on its head.  Most pixel artists (at least, most around this board) think of a hue rotation or a hue shift in terms of moving hue either up or down across the hue slider as a color becomes darker or lighter.  In these shots the hues seem to bounce back and forth, to different degrees on different objects.  First, let's look at some metal stuff from the first shot:

(http://i38.photobucket.com/albums/e106/masonbond/crit_chaos/4x_1.gif)(http://i38.photobucket.com/albums/e106/masonbond/crit_chaos/4x_2.gif)

Most of us learn early on that banding light and dark values next to each other is the key to creating believable metal textures in pixels.  The artists take it a little further here in that they're banding hues along with values.  A piece of metal that goes from light, to dark, to light again could also go from blue, to green, to blue again.  To look at the relationship between hue and value in these objects, my geeky ass made a graph:

(http://i38.photobucket.com/albums/e106/masonbond/crit_chaos/hue_lum_1.gif)

As the colors go from dark to light, the hue jumps around, making larger leaps towards the middle range.  As predicted, the colors on the metal go from light/greenish to darker/bluish and back to light/greenish, but wait! There's all kinds of reds in there! Right smack in those middle transitional shades as well as at the very darkest end, the hue jumps to the deep reds and the desaturated oranges (browns) you find in the ground.  Not only does this create intermediate shading without adding more colors onto the palette, but it gives the impression that the metal is catching and reflecting the ground colors.

(http://i38.photobucket.com/albums/e106/masonbond/crit_chaos/4x_3.gif)(http://i38.photobucket.com/albums/e106/masonbond/crit_chaos/hue_lum_2.gif)
Here's a grab of some ground tiles from the same level.  We see a few runs of similar hues with different values, like a few dark greens we saw in the metal, middle browns for the bulk of the ground, etc.  We also see the hue jumping back up to green and even into the blues towards the brighter end.  We see greens and blues in the upper ranges of the metal too, apparently the artists are indicating the color of the lightsource as best as they can without wasting extra colors. Same deal with some cave wall tiles grabbed from the first level:

(http://i38.photobucket.com/albums/e106/masonbond/crit_chaos/4x_4.gif)(http://i38.photobucket.com/albums/e106/masonbond/crit_chaos/hue_lum_3.gif) different palette, same principle.  Accentuating the blueness of the natural daylight gives the whole scene a cooler ("subdued" as Ptoing or someone put it) appearance.

I have more to say, but I'll shut up and give you guys a turn, and give myself a chance to prepare a little more.
Title: Re: Commercial Critique: The Chaos Engine
Post by: Helm on March 28, 2006, 01:58:35 am
Excellent points, supergoat.

Another useful point to be made about bitmap INGAME graphics is that they hardly ever miss an apportunity to pronounce dents and general volumetric shifts on objects, with contrasting highlights. For the longest time when I was starting out with pixel art, since I came from a comic art background where we usually shade from pure white light ( white paper ) to pure dark ( full ink ) I was having trouble convincingly suggesting volumes in pixel art. I did everything right, in theory. The stuff I drew were lightsourced, the colours were ok, the shapes registered well in general. After going back to studying Speedball II and Cadaver and the like, I realized what I was doing wrong, or rather, not doing much of: I was working from a middle shade, towards darkness, and that was it. If there were brighter spots, they were on large areas, where a lot of direct light would hit. I practically had no idea of the power of highlight, especially of the sharp type. A sharp highlight is that which might go two or even more steps up from the body of colour it's highlighting, on colour ramp, and which usually is extra accented by darker pixels than the body of colour around it too.

Let's say I was trying to draw some cracks on a dented metal wall, right? (zoom in on these)

(http://www.locustleaves.com/bitmap1.png)

This would be the old helm. Technically, this is not wrong. There's variations of lightness, there's the information that cracks are there, but it looks dull and lifeless. Studying bitmap brothers I understood that anywhere where's an edge, there's highlight! Obivously this has a lot to do with what type of material you're trying to shade, but in pixel art, especially game art, clarity is important, so this effect should be overstressed a bit.


(http://www.locustleaves.com/bitmap2.png)

Likeso. For every contour, an edge highlight. But this isn't all I learnt by the bitmap brothers. I also learnt the importance of pushing the contrast far more than you would in other media, to travel the complete range from pure black to pure white. Now, they don't do this as much as I do (my usage has evolved for other reasons to be even more harsh) but the theory's there, and it's more to do with the needs of game art than it's to do with realistic representation of reality. Again, this is about clarity and how fast the eye can proccess information and detail. Where there's EDGE, which in gameplay can possibly mean unreachable area and the like, you need to give the brain the tools to work out what it's looking at fast. So more sharpening and contrast is good.

Another thing that the brothers taught me was the importance of the traditional 75%, 50% and 25% ordered dithers as means to suggest texture and inter-shade buffering. Now my examples use 16 shades of gray which is insanely rich for this sort of stuff, but if I were to use say, 5 shades between black and white, by doing bodies of ordered dither, I would be able to fake and convey both rougher terrain, and more importantly, an extra 5 lightness levels between my original 6, and if I used 25% and 75% patterns, 24 different lightness levels between pure black and pure white, using only 5 colour slots. This is a great strength to have, and the brothers put it to use constantly.

(http://www.locustleaves.com/bitmap3.png)
Title: Re: Commercial Critique: The Chaos Engine
Post by: AdamTierney on March 28, 2006, 06:57:47 am
Based on the screenshots, I think the examples exhibit an amazing artistry in terms of pixel management, color palettes and lighting. But I find their form a little weaker. The 3/4 perspective is a little bleh and I think the components in the shots work better individually than as a whole. Dissected and removed, each piece is quite lovely. Placed together, I see somewhat of a mishmash of light sources, perspectives, too much repetition and too little flow between each component. I'm assuming factors like tile count and other limitations may have limited the realization of what they would have liked to create, but even that considered I see a lot of stylistic and design choices I would have made differently.

- Adam
Title: Re: Commercial Critique: The Chaos Engine
Post by: ptoing on March 28, 2006, 11:37:12 am
Nice stuff so far from you guys, I will write up something at some point and it will be long with screenshots and lots of disecting, but atm i am superbusy and then i am away in holland for 3 days over the weekend. But I am already running the "Chaos Engine CC" in my subconscious mind :D

Edit: I just downloaded all those screenshots from HOL and did some closer investigation on the palettes and i have to say i am baffled.

The ingamegfx actually only have 16 colours as 16 colours are fixed on the statusbar. The colours of the statbar are NEVER used on the actual gamearea. The different worlds have different 16 colourpalettes and they are brilliant examples of 2 hue ramps with interspersed greys (not full greys tho) and some more saturated colours in each hue (mostly one per hue).

16 fix colours for the statbar
16 colours for the actual game area (changing per world)

I will elaborate on this some more, but prolly not today, but when i do i will provide screenshots.

Oh another thing. The OCS of the Amiga 500 can only handle 32 colours at once (without doing trickery) and those 32 colours are chosen from a 12bit colourpool meaning each RGB value has 4 bits, which leads up to 4096 colours to choose from which is less than it sounds. Also i am quite sure that these colours are unstretched bits, meaning there is no full white as the bits for each value are 0-F which would translate to 00-F0 on PC.
WinUAE uses those colours and I am quite sure this holds true on a real machine, it has been a time since i last seen an Amiga in action so i am not 100% sure about this last detail.
Title: Re: Commercial Critique: The Chaos Engine
Post by: Helm on March 28, 2006, 03:23:37 pm
This explains why on this game the elements don't go from pure black to pure white. Interesting. Are you sure it's not a stretching error in the screenshotting, ptoing?

Adam: I agree that as a game this could be designed better. My biggest issue is the flat-coloured ground tileage. I never enjoy that in top-down games, unless the ground IS so perfect and unblemished. For example Speedball is fine with large patches of flat colour ( although there aren't many ) but when the characters in Chaos Engine are over what seems to be mud and dirty ground, an one-colour tiled floor makes little sense.

If you look at Cadaver

http://www.mobygames.com/images/shots/original/963771351-00.gif

http://www.mobygames.com/images/shots/original/963771775-00.gif

http://www.mobygames.com/images/shots/original/963771393-00.gif

( same art-guy if I remember correctly)

they handle this much better there.


Still, gameplay is king, and for all the design stuff we could discuss in Chaos Engine, the actual gameplay, especially in 2-player is amazing. So the choices are somewhat justified. You could put more detail in it, or do it iso, or whatever else, but would it play as well?
Title: Re: Commercial Critique: The Chaos Engine
Post by: ptoing on March 28, 2006, 03:47:03 pm
You mean the F0 thing? I am about 90% sure the amiga OCS which has only 12bit colour is unstretched. The atari st is 9bit unstretched no pure white there. Also as I said WinUAE uses those unstretched colours and i am sure the guy who coded that made his homework.

About the "bleak" ground tiles. In cadaver you dont have many enemies and the game is more on puzzlesolving and finding stuff, whereas in CE you are blasting away all the time and they have only 16 colours for EVERYTHING - sprites and backgrounds. So this is IMO a valid designchoice as it enhances visibiliy immensly if you think about it. Dan Malone sure as hell knew what he was doing and all the choices made in the gfxdesign department are counterchecked to make sense with the gameplay department. I am very sure about this.
Title: Re: Commercial Critique: The Chaos Engine
Post by: goat on March 28, 2006, 04:11:50 pm
I can confirm that, the closest you can get to white is something like 94%.  Still, that's about as high as I would go in representative art.

The perfectly smooth or 50% dither ground thing seems to be a stylistic choice as they don't spare any texture at all on the walls and objects, as Helm covered before with an example.  While playing the DOS version a little I too was unimpressed by the wonkiness of the perspective, ESPECIALLY in the animations.  One could argue that they make it perfectly flat so that the player knows where they can walk, but I still think it can be pulled off.

They also use a good degree of flatness in the trees in the first world, even though they have more than enough colors in the palette to make leaves.  I'll post this shot again so you can see what I mean:
(http://i38.photobucket.com/albums/e106/masonbond/crit_chaos/ChaosEngine1_s9.png)
The flatness in the middle of the trees and the symbolic notation of the leaf outlines (rather than a leaf texture with a litle more depth) give the trees an almost cartoony look that directly clashes with the detailed, slick, moody style of the cave, ground tiles, and even the tree trunk.  You can also see how the 3/4 perspective gets a little crappy on the sprite walk frames, which is especially glaring since I think 3/4 perspective in game art is second nature to just about all of us.

EDIT!$_($: about the HUD having its own 16 color palette, the only reason I could think of for that is so that you could do some kind of palette animation on the game world without it affecting the HUD colors.  I just can't think of any situation in the game where that happens.

As a card-carrying tileset whore I'm doing some hefty dissections of the tiling.  I haven't found anything really innovative or noteworthy in how they gridded or stored the tiles yet (except the way they reuse tiles in that cave wall is kinda neat), but once I do, I'll be all over it in a future update ;p
Title: Re: Commercial Critique: The Chaos Engine
Post by: Mr.Modem on March 28, 2006, 04:49:58 pm
Most of the tiles and sprites can be found here:

http://ipdb.ath.cx/_pubtest/tagl/viewallgfx.asp?title=chaosengine
http://eab.abime.net/showthread.php?t=22404&highlight=chaos+engine

They were ripped by some guys from the English Amiga Board a wonderful Amiga forum. They have this project going on with the goal to rip sprites and tiles from every Amiga game made.

I can confirm that Amiga had 12bit unstretched colours. And WinUAE shows them correctly. There are probably very few people in the world that know more about the Amiga hardware than Toni Wilen, the author of WinUAE (not the original UAE).

I have no critique to share right now. I think you have covered everything that a newbie as myself would ever think of. Better to just sit down and enjoy your discussion. Have anyone been able to same some of the commercial critiques threads from old Pixelation? I wasn't around at the time, but it would be really fun and useful to be able to read them.
Title: Re: Commercial Critique: The Chaos Engine
Post by: AlexHW on March 28, 2006, 07:23:47 pm
Greys can be considered a magic color because they work with any other color so to speak. You can tint it slightly blue or green or whatever and convey an object that is blue or green. If you do the opposite and tint a blue slightly grey in a spot, it can help convey the grey as being a complimentary color to the blue or whatever color you choose. I remember a tutorial about this on some site, but i can't find it.
With this you can see how in a situation where you must use a restricted palette, useing greys as a means for values and a few color tints can be combined to convey a range of colors in objects.

As for the flatness. I can understand why they did it since I do the same thing at times. There could be multiple reasons for it, for example, one could be connected with tile restrictions. For instance if you have only a certain amount of tiles to use, perhaps you wouldn't want to use too many on the floor in order to create a detailed and seamless texture, and instead focuse on keeping it solid and only use unique tiles for details(like the rocks in that screenshot, or the craters).
Another reason could be connected with the compositional side of the art(which is what is mostly my reason for doing it), for example you wouldn't want everything all details and busy, expecially in a scenerio where you are constantly moveing and alot of things are happening. You instead want to balance things out and have in essence positive and negative areas of focus where the eye can be directed and also things can be identified.
Title: Re: Commercial Critique: The Chaos Engine
Post by: AdamTierney on March 28, 2006, 07:29:10 pm
Still, gameplay is king, and for all the design stuff we could discuss in Chaos Engine, the actual gameplay, especially in 2-player is amazing. So the choices are somewhat justified. You could put more detail in it, or do it iso, or whatever else, but would it play as well?

Absolutely, and I've definitely seen games that go so far in detail that they end up obscuring the playfield, and negatively impacting the gameplay. In that regard, the game probably plays like a dream. It just struck me as odd that the pixelling itself is so expertly done, but the layouts and general design felt a little more stilted.

- Adam
Title: Re: Commercial Critique: The Chaos Engine
Post by: Ryumaru on March 29, 2006, 07:43:48 am
im more of the one that studies the the critiques made but id like to say that the almost over "sculpted" look in th tiles made from the highlights lends itself well to other things in pixelart and i think some people are too timid to go for such a look.
Title: Re: Commercial Critique: The Chaos Engine
Post by: crab2selout.png on March 29, 2006, 08:51:14 pm
I notice that there is a pattern to how they use a 50/50 dither on the floors. It seems like they never place 50/50 dither floor tiles on the same floor level as flat color tiles. It's difficult to be sure as I haven't played this game, but I've only seen one instance where this wasn't true

(http://img138.imageshack.us/img138/825/chaosengine1s113up.png)
-higher rocks are dithered, while lower level the palyer is on isn't
(http://img138.imageshack.us/img138/7848/chaosengine1s214nv.png)
-water here has a 50/50 dither
(http://img138.imageshack.us/img138/9071/chaosengine1s246wn.png)
-the main floor level is dithered here, while on the right you can see a lower floor level that is flat shaded

(http://i38.photobucket.com/albums/e106/masonbond/crit_chaos/ChaosEngine1_s9.png)(http://i38.photobucket.com/albums/e106/masonbond/crit_chaos/ChaosEngine1_s13.png)
-two more examples

(http://img145.imageshack.us/img145/1122/chaosengine1s239tl.png)
-the outlier

Provided I'm not wrong about this, it's a pretty interesting way to make the brain see a difference between separate height levels.
Title: Re: Commercial Critique: The Chaos Engine
Post by: goat on March 29, 2006, 10:20:42 pm
good food for thought.  rock on.
Title: Re: Commercial Critique: The Chaos Engine
Post by: Darien on April 03, 2006, 09:38:37 pm
Perhaps the mostly flat ground tiles were chosen because the sprites shadows are non-transparent.  In the game as it is, if you walk over some rocks your shadow looks very fake because it completely covers up the ground that was once detailed.  The shadows look best against the flat ground. 

I'm glad that I got to see this game... the "hue bouncing" really astounds me.  I definately have to try to incorporate it into my stuff.
Title: Re: Commercial Critique: The Chaos Engine
Post by: initial_reality on April 04, 2006, 12:33:32 pm
My guess is, they use flat color tiles or dithered tiles because they're faster to draw than textured tiles. For flat tiles, pixels are just set to a given color, whereas for textured tiles, we have to copy all the 256 pixels from RAM to video memory, wich takes longer. And this really matters for a scroller. At least, it's how it used to work in DOS. Seems to be same in the C64. Note that the trees may use flat tiles too.

Despite the speed issue, the game's rather slow in my computer (AMD 1.1)! Is it because the XP is emulating the DOS mode ? Other than that, excellent game (behind Gods off course).
Title: Re: Commercial Critique: The Chaos Engine
Post by: Mr.Modem on April 04, 2006, 02:48:50 pm
I don't think you're right initial_reality. Commodore Amiga (the computer it was initially developed for) was powerful enough to scroll tiles like this. Since Amiga had a hardware scroll these kind of stuff didn't take any cpu time. I doubt it would be faster to render flat areas. Please correct me if I'm wrong though. I reccomend you to use an Amiga emulator to play this game if you're experiencing slowdowns with the dos version. You could also thry the snes or megadrive versions. And Chaos Engine is much better than Gods (imo).
Title: Re: Commercial Critique: The Chaos Engine
Post by: goat on April 04, 2006, 04:23:02 pm
Confirming the hardware scrolling, Amiga's OCS/ECS was head and shoulders above other chipsets of its time for video performance
Title: Re: Commercial Critique: The Chaos Engine
Post by: Mr.Modem on April 04, 2006, 05:11:09 pm
And even poor Atari ST (don't get me wrong, I love Atari ST but the hardware really sucked) could handle this game! It had almost no graphics hardware at all. No blitter, no hardware scroll. Again, feel free to correct me.
Title: Re: Commercial Critique: The Chaos Engine
Post by: Helm on April 04, 2006, 08:41:16 pm
No you are correct. But he does have a point in that if shadows overlapped with a lot of detail it would look strange. The shadows aren't of course, semi-transparent because you had to do a lot of wizardry to get tints and active transparencies in the Amiga, and it either took AGA chipset or master coder, or both. Look at Lionheart.
Title: Re: Commercial Critique: The Chaos Engine
Post by: Ryumaru on May 01, 2006, 10:22:51 pm
somewhat off topic, but does anybody know of some sites with graphics from other bb games?
ive looked at there site, but all teh screenshots are jpeg
id like to look at more of there graphics and do some disecting of my own.
Title: Re: Commercial Critique: The Chaos Engine
Post by: Mr.Modem on May 02, 2006, 06:45:10 am
The biggest screenshot archive for Commodore Amiga is Hall of Light: http://hol.abime.net/ You should be able to find all Bitmap Brother games there.
Title: Re: Commercial Critique: The Chaos Engine
Post by: saimo on November 18, 2006, 01:02:38 am
It's definetely late to resurrect this discussion, but maybe the most tech-minded of you will appreciate this ;-)

No you are correct. But he does have a point in that if shadows overlapped with a lot of detail it would look strange. The shadows aren't of course, semi-transparent because you had to do a lot of wizardry to get tints and active transparencies in the Amiga, and it either took AGA chipset or master coder, or both.
Actually in TCE adding real transparencies would have been extremely easy. As some of you have noted, the in-game area (entirely separated from the status bar) has only 16 colors, which means that the BB only used 4 bitplanes. On OCS/ECS 5 planes were perfectly possible, so it would have been just a matter of adding one more plane, setting the palette so that the colors 16-31 were the darker versions of colors 0-15 and blitting the shadow masks on the 5th bitplane. Indeed, almost the same could have been possible even if the game used 5 planes, as OCS/ECS handled also 6 bitplanes: the only restriction, in that case, is that the colors 32-63 were forced to reflect the colors 0-31 with halved brightness (hence, the EHB = Extra Half Brite mode). So, now you'd be probably and rightfully wondering why the BB did not do go for such a simple solution: well, I guess that the problem was that just activating the 5th bitplane would steal more DMA time, making everything (occasionally) slower.

Quote
Look at Lionheart.
Uhm... are you thinking of the water in the first levels? If so, in that case the trick is much different: at a certain Y of the screen the Copper (a very simple 3-instruction coprocessor that had access to the chipset) was instructed to change the palette on the fly - that's basically the same mechanism that allowed to have so many hues for the sky (despite the background had only 8 colors) and the line-by-line parallax. This means that the same effect could not have been used to achieve shadows.


Besides this, somewhere in the thread somebody wonders about full whites/grays... well, I've always been coding for AGA so I don't really know, but, anyway, the AGA chipset for compatibility automatically copies what gets written in the upper 12 bits of color registers to the lower 12 bits, so I'd say that 0xFFF on OCS/ECS equals 0xFFFFFF on AGA (and not 0xF0F0F0).

One final thing: I don't think that the flat tiles were used for performance reasons, because that would have made the tile engine much more complicated for a very little gain; moreover, the gain would not have been constant as it would have depended on the graphics shown, meaning that in certain occasions the engine would have performed faster than in others, which certainly is not as desireable as a steady refresh rate (which, from what I've seen, is what TCE has). I agree with those that say that the flat colors and dithering were chosen to give a better idea of the different levels.

Congratulations to everybody for the nice analysis carried out here!

saimo
Title: Re: Commercial Critique: The Chaos Engine
Post by: Ai on November 18, 2006, 02:17:35 am
the shadow masks on the 5th bitplane. Indeed, almost the same could have been possible even if the game used 5 planes, as OCS/ECS handled also 6 bitplanes: the only restriction, in that case, is that the colors 32-63 were forced to reflect the colors 0-31 with halved brightness (hence, the EHB = Extra Half Brite mode). So, now you'd be probably and rightfully wondering why the BB did not do go for such a simple solution: well, I guess that the problem was that just activating the 5th bitplane would steal more DMA time, making everything (occasionally) slower.
Uhm... are you thinking of the water in the first levels? If so, in that case the trick is much different: at a certain Y of the screen the Copper (a very simple 3-instruction coprocessor that had access to the chipset) was instructed to change the palette on the fly - that's basically the same mechanism that allowed to have so many hues for the sky (despite the background had only 8 colors) and the line-by-line parallax. This means that the same effect could not have been used to achieve shadows.
.. And if there was a duplicate color that could appear the same as another color or darker, depending on what raster effect was active where? That would allow you to define 'where the shadow would fall if it was dark enough' and make it visible on a particular range of scanlines. It would mean the scrolling would need to be vertical to do a proper transition, but it's certainly possible.


Quote
Besides this, somewhere in the thread somebody wonders about full whites/grays... well, I've always been coding for AGA so I don't really know, but, anyway, the AGA chipset for compatibility automatically copies what gets written in the upper 12 bits of color registers to the lower 12 bits, so I'd say that 0xFFF on OCS/ECS equals 0xFFFFFF on AGA (and not 0xF0F0F0).
Quote
The question was how it was displayed, though -- which could easily be different from how it was emulated. Probably whatever was simple and good enough looking was done in both the case of AGA-emulation and non-AGA.
Title: Re: Commercial Critique: The Chaos Engine
Post by: saimo on November 18, 2006, 03:18:13 am
.. And if there was a duplicate color that could appear the same as another color or darker, depending on what raster effect was active where? That would allow you to define 'where the shadow would fall if it was dark enough' and make it visible on a particular range of scanlines. It would mean the scrolling would need to be vertical to do a proper transition, but it's certainly possible.
Uhm... could you elaborate, please? I'm not sure I get what you mean.
The "duplicate colors" idea implies the existence of the extra bitplane mentioned above, but I can't follow you when you talk about "raster effect": if it's not about blitting the shadows (simplest method), but it's about Copper, how could it be done pixel-perfect horizontally-wise given the limitations of horizontal timings (not to mention that it would be much more complicated and time consuming than blitting a 1-plane shadow mask)?

Quote
The question was how it was displayed, though -- which could easily be different from how it was emulated. Probably whatever was simple and good enough looking was done in both the case of AGA-emulation and non-AGA.
True, what should be checked is the actual output of the HW. Though I don't have the equipment to do it (not even an OCS/ESC machine, indeed) nor any specific technical documentation, so the best I can come up with is assuming that AGA compatibility was as close to the original output as possible.

saimo
Title: Re: Commercial Critique: The Chaos Engine
Post by: Ai on November 21, 2006, 11:02:54 pm
Uhm... could you elaborate, please? I'm not sure I get what you mean.
you have two identical colors in the palette. one is used to draw a shadow, so you can toggle having a shadow on that tile row via raster effects (changing that palette entry)


Quote
The "duplicate colors" idea implies the existence of the extra bitplane mentioned above, but I can't follow you when you talk about "raster effect": if it's not about blitting the shadows (simplest method), but it's about Copper, how could it be done pixel-perfect horizontally-wise given the limitations of horizontal timings (not to mention that it would be much more complicated and time consuming than blitting a 1-plane shadow mask)?
Well, I find that difficult to believe. The only thing tricky about a raster effect is getting it to run fast enough and timed right.Perhaps the raster timing is lees flexible on Amiga; I remember  games (Switchblade, Stryker and the crypts of Trogan) on the amstrad CPC, a mere 8bit machine running at 4mhz, that changed the entire palette once per scanliine.
Title: Re: Commercial Critique: The Chaos Engine
Post by: saimo on November 22, 2006, 01:37:55 am
you have two identical colors in the palette. one is used to draw a shadow, so you can toggle having a shadow on that tile row via raster effects (changing that palette entry)
OK. So, I had got it right.

Quote
Well, I find that difficult to believe. The only thing tricky about a raster effect is getting it to run fast enough and timed right.Perhaps the raster timing is lees flexible on Amiga;
Indeed, there are timings issues.
For example, with a LORES screen (that is, ~15 kHz horizontal and 50 Hz vertical), while the Copper writes a value to a color register, the beam roughly draws four pixels, meaning that the Copper cannot be pixel-perfect, horizontally-wise. Moreover, the kind of trick you have in mind requires the CPU intervention which, as fast as the CPU can be, still is deadly affected by the slow CHIP RAM access bottleneck (this also means that even if the effect was applied directly by the CPU - i.e., without Copper at all - still the timings would be just as tight). In a nutshell: simply impossible, if what one is after is creating perfect shadows at any arbitrary horizontal position. And, anyway, asking the Blitter to blit just a single plane (without even having to read any data: just a pure write) not only gives perfect results, but also requires much much simpler code.

Quote
I remember  games (Switchblade, Stryker and the crypts of Trogan) on the amstrad CPC, a mere 8bit machine running at 4mhz, that changed the entire palette once per scanliine.
Indeed, on the Amiga, whether the Copper manages to change the whole palette depends on its size (more colors = more writes), its type (f.ex. a 24-bit palette requires more than the double of writes with respect to a 12-bit one) and the graphical needs (f.ex., if colors are freely used, the Copper should do the operation only during the horizontal blanking... which is definitely very short for this kind of operations).

saimo
Title: Re: Commercial Critique: The Chaos Engine
Post by: Ai on November 22, 2006, 05:24:49 am
And, anyway, asking the Blitter to blit just a single plane (without even having to read any data: just a pure write) not only gives perfect results, but also requires much much simpler code.
.. It's a different effect. If at all possible, in such a situation I would want to make use of as many of the 16 extra colors as i can, rather than using them for a fixed-color transparency effect.
Title: Re: Commercial Critique: The Chaos Engine
Post by: saimo on November 22, 2006, 02:17:45 pm
.. It's a different effect.
Technically, yes. As for the results... at this point, I wonder (again) if whether we're talking about the same thing ???

Quote
If at all possible, in such a situation I would want to make use of as many of the 16 extra colors as i can, rather than using them for a fixed-color transparency effect.
Well, yes, of course that's a matter of choices... solid (like the BB did in TCE) or dithered shadows and more colors to play with, or "proper" shadows and half the colors. IMHO when the pixeller is a master, colors can be sacrificed for the added beauty of the effects that can be achieved - well, better shadows are definitely not a major gain, but double playfields/parallaxes/etc. can be ;)

saimo
Title: Re: Commercial Critique: The Chaos Engine
Post by: EyeCraft on November 24, 2006, 07:38:37 am
Far out, you guys are giving me a headache  ;), but its extremely interesting. All hail necro posting  :D
Title: Re: Commercial Critique: The Chaos Engine
Post by: Blick on November 24, 2006, 10:55:08 am
Holy crap, it's like having two Neota/AIs and I'm comprehending only half their discussion! It's pretty interesting to see that a game would have to do so many tricks, just to squeeze in transparencies (I think that's what they were talking about).

I feel sorry for the poor bastards that had to brainstorm the process by which they'd create a game with such constraints. It was after the time when games were relatively simple and before the time games were relatively simple to make.
Title: Re: Commercial Critique: The Chaos Engine
Post by: Ai on November 24, 2006, 11:51:19 am
Holy crap, it's like having two Neota/AIs and I'm comprehending only half their discussion! It's pretty interesting to see that a game would have to do so many tricks, just to squeeze in transparencies (I think that's what they were talking about).

I feel sorry for the poor bastards that had to brainstorm the process by which they'd create a game with such constraints. It was after the time when games were relatively simple and before the time games were relatively simple to make.

Saimo was talking about a single-color transparency (choosing a single color, and then being able to mix that in a fixed proportion with any of the normal 16 colors)

What I was talking about was using a single palette index exclusively for drawing shadows, so that shadows can be enabled/disabled on any particular set of scanlines.
(roughly. You may not be able to get it accurate to 1 scanline.. but accurate to 4 would be okay)

With what saimo is talking about, you'd be able to blit a shadow mask onto the 5th bitplane, and that would be all that is needed to make an object cast a shadow.

With what I'm talking about, you'd be able to vary the depth of the shadows across the Y axis.

Title: Re: Commercial Critique: The Chaos Engine
Post by: saimo on November 24, 2006, 12:00:16 pm
It's pretty interesting to see that a game would have to do so many tricks, just to squeeze in transparencies (I think that's what they were talking about).

I feel sorry for the poor bastards that had to brainstorm the process by which they'd create a game with such constraints. It was after the time when games were relatively simple and before the time games were relatively simple to make.
Don't be: it was tough, but also very creative and stimulating. Nowadays there are other problems... but I prefer the oldskool ones ;)
BTW: actually on low-power platforms there are still those kind of challenges...

saimo
Title: Re: Commercial Critique: The Chaos Engine
Post by: saimo on November 24, 2006, 12:40:53 pm
AI, I hope you don't mind if I de-interleave your post ;)

Saimo was talking about a single-color transparency (choosing a single color, and then being able to mix that in a fixed proportion with any of the normal 16 colors)

With what saimo is talking about, you'd be able to blit a shadow mask onto the 5th bitplane, and that would be all that is needed to make an object cast a shadow.
100% correct.
Note to others: this method can be used to do more than just projecting shadows (f.ex. lighting and glass effects).

Quote
What I was talking about was using a single palette index exclusively for drawing shadows, so that shadows can be enabled/disabled on any particular set of scanlines.
(roughly. You may not be able to get it accurate to 1 scanline.. but accurate to 4 would be okay)

With what I'm talking about, you'd be able to vary the depth of the shadows across the Y axis.
If the figure "4" comes from the "4" I mentioned myself, please note that I was talking about horizontal constraits. The vertical ones are a lot easier to deal with, so your method could be easily mixed with mine in order to have horizontally pixel-perfect shadows with varying depth across the Y axis.

saimo