[SOLVED] 8-Bits Palette possibilities/limitations?

[Deist]

Well I'm really taking the step now into actually building my first adventure.
I have already some basic yet precise ideas for the game I want to do. I'm going for a true retro feeling (first person view, /a la/ "Death Gate" or "Shannara") which suits my tastes best, so naturally I'm tempted to select the 256 colour-based option (not interested in most of the features made available by no palette as of now).

Although, as a true noobie with AGS and after reading the manual looking for the answers, I'm still a bit confused and doubtful about one or 2 things regarding the limitations or 256 colours palette, so I'm resorting to bother you, wise experimented users of the forum, to help me make up my mind about it once and for all. So here is:

- I've read that some transparency/fading effects are still available in 8-bits, yet in the manual many fonctions -- for instance the "Transparency property (GUI)" -- explicitly state that "Transparency only works in 16-bit and 32-bit colour games." Does it mean that (to keep the same exemple) it is impossible to fade out a GUI in 8-bits?

- Is cross-fading directly between pictures possible? (ie. Instead of fading an image to black then fading in the next one, I'd like to fade directly from one picture to another). Of course that's only a small detail (I'm sorta picky I'm afraid), but just wondering anyway...


That's it for my wonderings as of now.
Thank you all in advance!

[Gilbert]

- I've read that some transparency/fading effects are still available in 8-bits, yet in the manual many fonctions, for instance the "Transparency property (GUI)", explicitly state that "Transparency only works in 16-bit and 32-bit colour games." Does it mean that (to keep the same exemple) it is impossible to fade out a GUI in 8-bits?

Well I think for safety and to avoid problems, you better assume all of these are impossible (and about the GUI part I'm sure that it's impossible). Some of the effects may work to some extend if the palette is static (and there's no extensive test to guarantee anything) and doing such will just cause chaos if the palette is dynamic (like you use palette cycling, etc.).

- Is cross-fading directly between pictures possible? (ie. Instead of fading to black a image and then fading in the next one, fading directly from one picture to the other)

Impossible.

[Khris]

About the cross-fading, one could fake the effect by a pixel-wise fading (like 256col games do), but that's probably slow and not easy to code.

Except for color-cycling and saving HD space, I can't think of any reason to create an actual 256 col game; it's very easy to create a 16bit game that looks like one though.

[Scavenger]

I used 8-bit in my game, and I used a plugin to get really grainy 2bit transparency. It's rather crude, but it works for simple transparencies. I suppose you could trick the player into thinking the GUIs are fading with it.

For the crossfading, if you REALLY need it, create the crossfade in another program (a movie editing program, or something), make sure both images have the same palette, convert it all in Smacker, export as a FLC/bmp sequence and use that.

[Deist]

Thank you all very much for your answers and insights!!
I think I'll be able to move forward now thanks to your suggestions...

Well I think for safety and to avoid problems, you better assume all of these are impossible (and about the GUI part I'm sure that it's impossible). Some of the effects may work to some extend if the palette is static (and there's no extensive test to guarantee anything) and doing such will just cause chaos if the palette is dynamic (like you use palette cycling, etc.).

Yeah I could very much imagine what a mess it would be to try fading while colour cycling, and I always meant to do it with static palette (then again, even with a palette cycling background, would that be any difficult when triggering the fade out event to stop the cycling effect (thus getting back to static palette) before proceeding with the actual fading job on the background picture?).

Anyway, I hear what you say about fading effect being quite untested and not guaranteed at all in 8-bit mode.
I've been misled into thinking it was well implemented and supported because of one sentence in the introduction tutorial (http://www.adventuregamestudio.co.uk/acintro1.htm), coz that one says: "The advantage of a palette is that the game size will be smaller, and the game will run up to twice as fast as using hi-colour. Neat fading and colour cycling effects are also possible." If that is in fact not really the case (or at least not officially supported), shouldn't that part be edited out?

I used 8-bit in my game, and I used a plugin to get really grainy 2bit transparency. It's rather crude, but it works for simple transparencies. I suppose you could trick the player into thinking the GUIs are fading with it.

(Interesting... Looked for it a bit in the plugins section, to no avail. Is that plugin still available somewhere?)

For the crossfading, if you REALLY need it, create the crossfade in another program (a movie editing program, or something), make sure both images have the same palette, convert it all in Smacker, export as a FLC/bmp sequence and use that.

Never used that before, I'm afraid. Do you mean Smacker like in RAD Game Tools' Bink or Smacker?

About the cross-fading, one could fake the effect by a pixel-wise fading (like 256col games do), but that's probably slow and not easy to code.

Pixel-wise fading? Ouch, you are expecting too much from my humble noobie brain... :
Do you actually mean, like, coding the fading from original colour to destination colour for EACH pixel? :o That can't be, so guess I'm just not understanding it right...
Anyway, since you pointed out it's a slow and complicated method, I only understand it's not for me (not before some years of practice anyway!)

Except for color-cycling and saving HD space, I can't think of any reason to create an actual 256 col game; it's very easy to create a 16bit game that looks like one though.

Well, I instinctively went for 8-bit first for a bunch of reasons. First the obvious one is I don't intend to use more than 256 colors (at once on screen, that is) nor any of the more complex effects features (except fading) that 16 or 32 bit allow, like overlay, alpha channel and so on... I used to be a graphic artist in the demoscene in the golden years of the Amiga, so I intend to create most of my graphics the old way, using GraFX2 -- a pure 8-bit bitmap soft a la Deluxe Paint (magnifying tool and careful pixel-handdrawing, that's right! ^^). It's only natural for me to produce graphics that way and I still enjoy their old-fashioned touch.

Also, I was interested about the assets put forward for choosing palette based, namely: ensuring that every PC can run it (and with much  faster performances too) regardless of its hardware, and much smaller size (right, I know everybody now has broadband and huge HD, but I still don't consider that to be an excuse to completely disregard the size issue altogether. Like, to distribute a 50-100 Mb or more (without voice-pack!) old-fashioned LucasArts type adv game, when Monkey Island for instance weighted like 4 Mb or so, is ridiculous, and it doesn't matter that people CAN afford it in terms of download bandwith and HD space, it still IS ridiculous IMHO!).

That said, I guess the easiest way for me to compromise between a 256 colours game look and some nice fading effects, will be effectively to create a 16-bit game and convert all my graphics when done to 16-bit. And in case I fancy some colour-cycling effect somewhere, I suppose it shouldn't be too hard to achieve it via a workaround like an animation or sth, right?

[Khris]

Sure, that's possible. I know exactly what you mean btw, I'm an amateur pixel artist and love restricting myself to e.g. 16 or even less colors or creating NES-style mockups.

By pixel-wise fading I meant an effect that was used in early Sierra games; afaik they tiled the screen into 4x4 squares or so, then changed e.g. the top-left pixel of every tile to the new background, then a second one, etc.
Castle of Dr. Brain uses this excessively, I think.

[Wonkyth]

That wouldn't even be that hard to code, and you could get several effects simply by starting on different squares.
Also, there'd be nearly no need to worry about speed!

[Pumaman]

I've been misled into thinking it was well implemented and supported because of one sentence in the introduction tutorial (http://www.adventuregamestudio.co.uk/acintro1.htm), coz that one says: "The advantage of a palette is that the game size will be smaller, and the game will run up to twice as fast as using hi-colour. Neat fading and colour cycling effects are also possible." If that is in fact not really the case (or at least not officially supported), shouldn't that part be edited out?

Hmm good point, that page was originally written a long time ago. I will re-word it to reflect the fact that 256-colour games are now not recommended.

[Deist]

By pixel-wise fading I meant an effect that was used in early Sierra games; afaik they tiled the screen into 4x4 squares or so, then changed e.g. the top-left pixel of every tile to the new background, then a second one, etc.
Castle of Dr. Brain uses this excessively, I think.

Mmmh, played that so long ago, can't remember... I'll prolly try it again to check then, but I got it alright about the effect from what you explained here anyway. Not a bad way to fake a fading effect, maybe.

That wouldn't even be that hard to code, and you could get several effects simply by starting on different squares.
Also, there'd be nearly no need to worry about speed!

I believe you, but your comment prolly doesn't apply to me, since I'm not much of a coder to begin with, and a total beginner with AGS scripting... But indeed the effect is interesting and, I figure, could produce a range of somewhat varied visuals, similar to cross-fading yet worth it in their own right too.

Hmm good point, that page was originally written a long time ago. I will re-word it to reflect the fact that 256-colour games are now not recommended.

Glad my request helped spot any improvement for the AGS website -- if only this very tiny bit.


I think I'll consider myself satisfied now with your help and suggestions, thanks again!
Tagging the thread "SOLVED" then.

[Gilbert]

Actually there is a tutorial in the wiki demonstrating how to use 8-bit graphics and it is not an easy task for the general public if you want to use it to the full extend.
The problem is, that tutorial is incomplete (part 3 hasn't been written yet) and it's for an old version of AGS. There are lots of changes in the engine since then that you cannot follow these tutorials directly to get things done (especially part 2, which involves scripting). I just don't have the time to complete and update them at the moment.

[Snarky]

If you can do palette cycling, wouldn't you be able to do fading just by palette manipulation? (Cross fading is another, much more complicated, matter.)

[Gilbert]

Since he's talking about fading with GUI/objects/characters, there's no easy way around that, especially if these entities are put against a background. Furthermore, there are a lot of dependencies in the colour slots used, i.e. you must assign the colours carefully or else, it'll affect other stuff when you're just changing the colour of one certain entity.

[Snarky]

Well, what I'm saying is that in 8-bit color, you can do a fade to black just by gradually making each color in the palette darker. It shouldn't matter what's on-screen; whether it's GUIs, objects or characters, they'll all fade out along with the background. (Though if you want to make it so e.g. the cursor doesn't disappear in the fade, you can reserve some color slots for that element and not include them as you adjust the palette.)

A fade is easy since all colors are treated equally. Selective palette cycling effects (water, flickering flames, pulsing glow, day/night cycles, etc.) do require some care in how to set up and use the palette.

[Gilbert]

Fade to black is extremely easy and to begin with, Adventure Creator already supported fade-in and fade-out during room changes in 8-bit mode (the engine didn't even support 16/32 modes back at the time), and the FadeIn() and FadeOut() functions supported 8-bit right from the beginning.

The problem is, obviously, this thread is about those various effects, not specifically on this single effect, which would in general be hard for most people and require much planning and care in setting up the game and the graphics.

That's why I don't encourage other people to use 8-bit modes as this will only get oneself into troubles (the fact that nearly all 'modern' 'powerful' graphics applications suck in editing 8-but images natively is another main reason), even though I personally don't use 16 and 32 bit modes. Nowadays, it's worth using 8-bit palette modes only if you can really manage them and take advantage of them; otherwise it's much easier to work on graphics under 16/32-bit direct colour modes plus everyone can do easy-to-implement special effects such as lightings and transparencies.