Jibble

There is a new version of the forums ready for testing. Please post here if you're willing to help test! We could also use the help of coders!

Author Topic: Issues with 8bit palettes  (Read 4618 times)

Issues with 8bit palettes
« on: 10 Apr 2018, 14:55 »
Hi,

I was experimenting with 8bit 256 color graphics as of lately and have run into a few issues.

First, palette importing. When importing from bmp file it all goes well, but when importing from a pal file, the palette rgb values have some weird offsets, appearing much higher than 255, and throwing an error in AGS.
I'm using ProMotion app for palette export, it may be that the problem is on its end.


Next is the palette cycling. I admit I've never used it in AGS before, but this kind of behavior is really odd... For example, when using CyclePalette(0,15) function, I understand the palette indices from 0 to 15 should *all* shift one color value every tick, right?
In my case, only the index 0 shifts until it reaches 16 then wraps. Indices 1-15 remain static.
Example:

If I use anything but 0 as function parameter, ie. CyclePalette(1,255), nothing happens. ???
I'm on AGS 3.4.2 alpha1, but I remember similar thing happening few versions ago too. Tested so far on two machines, one desktop with nvidia gpu and one Intel Atom tablet. Both running Win10.

And finally, since 256-color graphics are only supported in software rendering mode, does it make sense to use it at all? I vaguely remember reading about people having issues with software renderer, and not having a fallback option doesn't seem like a great idea. In any case, 8bit graphics is only relevant for palette manipulation, everything else works the same in 32bit mode anyway. But palette manipulation IS a great feature to have. :-D

------

EDIT/SOLVED: If you're one of those forum searching people from the future (Hi people from the future! Did you come here in a flying car?) the full explanation is in the post #16.
« Last Edit: 14 Apr 2018, 17:08 by doimus »

Gilbert

  • Local Moderator
  • * KILL* * KILL * * KILL *
    • Lifetime Achievement Award Winner
Re: Issues with 8bit palettes
« Reply #1 on: 10 Apr 2018, 15:36 »
I'm not sure whether this is the problem, but colours with lower indices (at least #0-15) are supposed to be "reserved", so you may not be able to do whatever you want to them. For dynamic palette entries, it's advised to have them taking higher indices(which also in general is better for organisation, so you can have all the fixed colours taking the lower indiced slots).

Also check that you're not using the Direct3D or OpenGL drivers in the game's set-up, as last time I tried they didn;t even support 8-bit modes.

There are some information in the wiki, though they're written some time ago I think they're still mostly relevant. (There're some problems displaying images in the wiki ATM and I'll report this.)

Re: Issues with 8bit palettes
« Reply #2 on: 10 Apr 2018, 15:53 »
Best person to ask about 8-bit games is Scavenger, he makes only them afaik :).

And finally, since 256-color graphics are only supported in software rendering mode, does it make sense to use it at all? I vaguely remember reading about people having issues with software renderer, and not having a fallback option doesn't seem like a great idea. In any case, 8bit graphics is only relevant for palette manipulation, everything else works the same in 32bit mode anyway. But palette manipulation IS a great feature to have. :-D

Neither Direct3D nor OpenGL support paletted mode natively (because both are working with textures rather than bitmaps). The solution that was once suggested is to create a mixed mode where the in-game gfx manipulation would be performed in 8-bit software mode, but the final output made through one of the "advanced" renderers (converting final 8-bit room image on fly). However, no one has got to make such mode yet.

Since AGS 3.4.1 both hardware renderers actually run 8-bit games, converting all sprites to 32-bit, but support is only formal, because some graphic aspects may be lost and dynamic palette cycling does not work either.
« Last Edit: 10 Apr 2018, 15:56 by Crimson Wizard »

Gilbert

  • Local Moderator
  • * KILL* * KILL * * KILL *
    • Lifetime Achievement Award Winner
Re: Issues with 8bit palettes
« Reply #3 on: 10 Apr 2018, 16:02 »
Best person to ask about 8-bit games is Scavenger, he makes only them afaik :).
Me also, apparently, and that's why I wrote those wiki pages.

Re: Issues with 8bit palettes
« Reply #4 on: 10 Apr 2018, 16:12 »
Best person to ask about 8-bit games is Scavenger, he makes only them afaik :).
Me also, apparently, and that's why I wrote those wiki pages.

Oops! :tongue:

Re: Issues with 8bit palettes
« Reply #5 on: 10 Apr 2018, 16:51 »
I'm not sure whether this is the problem, but colours with lower indices (at least #0-15) are supposed to be "reserved", so you may not be able to do whatever you want to them. For dynamic palette entries, it's advised to have them taking higher indices(which also in general is better for organisation, so you can have all the fixed colours taking the lower indiced slots).


I have re-checked it with setting color id's to "room", and nothing changes. For some super-weird reason, only the first slot in the palette is ever shifted.

Same happens with SetPalRGB:

SetPalRGB(0, 42,42,42) works.
SetPalRGB(1, 42,42,42) and subsequent slots, don't. :-\

Neither Direct3D nor OpenGL support paletted mode natively (because both are working with textures rather than bitmaps). The solution that was once suggested is to create a mixed mode where the in-game gfx manipulation would be performed in 8-bit software mode, but the final output made through one of the "advanced" renderers (converting final 8-bit room image on fly). However, no one has got to make such mode yet.

Since AGS 3.4.1 both hardware renderers actually run 8-bit games, converting all sprites to 32-bit, but support is only formal, because some graphic aspects may be lost and dynamic palette cycling does not work either.

So AGS uses native Windows software rendering? GDI? Or is it Allegro's?
I remember dabbling in SDL and Pygame a while ago and it had 8bit surfaces you could draw onto and then manipulate as needed, including drawing to 32bit textures.

Anyhow, lot's of cycling effects can be "imitated" by brute forcing it as animated objects, but actual shifting/cycling is more performance-friendly and can be really breathtaking when used skillfully, like these images by Mark Ferrari - not a single animation frame there, only static images.
« Last Edit: 10 Apr 2018, 16:54 by doimus »

Gilbert

  • Local Moderator
  • * KILL* * KILL * * KILL *
    • Lifetime Achievement Award Winner
Re: Issues with 8bit palettes
« Reply #6 on: 10 Apr 2018, 17:09 »
Hmmm. Are you sure the game is a 8-bit game? Importing 8-bit assets into a 16/32 bit game will never work as intended.

Re: Issues with 8bit palettes
« Reply #7 on: 10 Apr 2018, 17:15 »
Hmmm. Are you sure the game is a 8-bit game? Importing 8-bit assets into a 16/32 bit game will never work as intended.

I thought of this too and created an empty game, switched from 32 to 8 bit, imported one room background, added cycling function in repeatedly-execute-always and that's it.
Perhaps the problem is in this defaulting to 32bit at creation?
« Last Edit: 10 Apr 2018, 17:26 by doimus »

Re: Issues with 8bit palettes
« Reply #8 on: 10 Apr 2018, 17:55 »
Dumb question, could you move the window around desktop and see if the changes will appear after that?
Actually, do you see any objects moving in your game when you run in software mode?
For example, my system does not update window contents in 8-bit and 16-bit games (either gfx driver or Windows problem), this is why I have to use a virtual machine with Windows XP to test or play them :(.


So AGS uses native Windows software rendering? GDI? Or is it Allegro's?
It uses Allegro, which in turn uses system-dependent software rendering.
I remember dabbling in SDL and Pygame a while ago and it had 8bit surfaces you could draw onto and then manipulate as needed, including drawing to 32bit textures.
Yes, that's the point of the mixed rendering. The only problem with AGS is an algorithm, because right now its graphic subsystem is optimized to immediately convert all gfx to 32-bit on load, which makes them incompatible with palette changes.
« Last Edit: 10 Apr 2018, 18:06 by Crimson Wizard »

Gilbert

  • Local Moderator
  • * KILL* * KILL * * KILL *
    • Lifetime Achievement Award Winner
Re: Issues with 8bit palettes
« Reply #9 on: 11 Apr 2018, 02:46 »
Don't know about the current versions, but I remember JJS's old Android version of the engine did support 8-bit mode and palette changes without any problem. Maybe that could help with OpenGL? I don't know how it's done though, maybe it's just plain software by constructing a frame buffer every frame and then just displays it.

Scavenger

  • Cavefish
  • In Four Glorious Colours!
    • I can help with animation
    • I can help with backgrounds
    • I can help with characters
    • I can help with scripting
    • Scavenger worked on one or more games that won an AGS Award!
    •  
    • Scavenger worked on one or more games that was nominated for an AGS Award!
Re: Issues with 8bit palettes
« Reply #10 on: 11 Apr 2018, 13:22 »
Dumb question, could you move the window around desktop and see if the changes will appear after that?
Actually, do you see any objects moving in your game when you run in software mode?
For example, my system does not update window contents in 8-bit and 16-bit games (either gfx driver or Windows problem), this is why I have to use a virtual machine with Windows XP to test or play them :(.

Wait, I've had that problem before, a long time ago, even on Windows 2000. A computer, freshly installed and without proper stuff, would not update the graphics screen unless it was moved around. There was SOMETHING I did to fix that. I may have installed a version of DirectX, or something... I wish I knew.

Gilbert

  • Local Moderator
  • * KILL* * KILL * * KILL *
    • Lifetime Achievement Award Winner
Re: Issues with 8bit palettes
« Reply #11 on: 11 Apr 2018, 18:20 »
Ah yeah, try updating DirectX9 also.
As DirectX version 10 onwards are not a replacement of DirectX9, recent versions of Windows (starting from WIN Vista I think) actually contain both the newest version of DX and DX9, and will fall back to using DX9 if an app needs it.
However, M$ always ships a really old version of DX9 with their Windows installation and it's never updated automatically anymore(probably intentional, considering it's M$). By hunting down an updated version of DX9.0c and install it manually in your system some of these problems may be solved.

Danvzare

  • The Man with No Name
    • I can help with AGS tutoring
    • I can help with proof reading
    • I can help with scripting
    • I can help with voice acting
    • Danvzare worked on one or more games that was nominated for an AGS Award!
Re: Issues with 8bit palettes
« Reply #12 on: 12 Apr 2018, 13:53 »
Ah yeah, try updating DirectX9 also.
As DirectX version 10 onwards are not a replacement of DirectX9, recent versions of Windows (starting from WIN Vista I think) actually contain both the newest version of DX and DX9, and will fall back to using DX9 if an app needs it.
However, M$ always ships a really old version of DX9 with their Windows installation and it's never updated automatically anymore(probably intentional, considering it's M$). By hunting down an updated version of DX9.0c and install it manually in your system some of these problems may be solved.
Yeah, I think they did that to get more people to use Windows Vista, since they made sure DirextX10 didn't work on Windows XP.
I think they might have done it again with another DirectX on Windows 8 and/or Windows 10.
If I'm wrong though, please correct me. I'm going based on vague memories here. :-D

Re: Issues with 8bit palettes
« Reply #13 on: 13 Apr 2018, 10:58 »
Ok, I think I solved the palette cycling issue, somewhat...

It works if starting from an empty game template, using 8bit mode from the start, importing room backgrounds as 8bt images (with "remap palette" option in Preferences unchecked).
In this case, it will cycle (in software mode) even when raising color depth to 32 bit and using 32bit sprites for mouse cursor.
Then I experimented a bit, throwing in various sprites at various depths, with and without alphachannels and using all possible rendering modes. I got a few crashes and some graphics were drawn corrupted.

In the other situation, when starting from the default template (which has 32bit sprites), then lowering depth and re-importing room images at 8bit, it seems it remains in 32bit mode no matter what, as it still draws original 32bit sprites in full color, regardless of the palette and doesn't cycle even in software mode. Nothing is drawn corrupted and there were no crashes.
« Last Edit: 13 Apr 2018, 11:03 by doimus »

Re: Issues with 8bit palettes
« Reply #14 on: 13 Apr 2018, 16:07 »
In the other situation, when starting from the default template (which has 32bit sprites), then lowering depth and re-importing room images at 8bit, it seems it remains in 32bit mode no matter what, as it still draws original 32bit sprites in full color, regardless of the palette and doesn't cycle even in software mode. Nothing is drawn corrupted and there were no crashes.

When you say "it seems it remains in 32bit mode", have you pressed Ctrl + V in game to check the actual display mode?

First of all, AGS Editor does not automatically convert sprites when you change game's color depth, they retain original color depth.
I cannot tell without investigation if and how 32-bit sprites are converted to 8-bit at runtime, and which palette they will use.
One thing to note, these sprites were originally 8-bit, and therefore have very limited colors on them. For that reason they may look alike in all color modes.

Does 8-bit room background changes when you cycle palette? And if you import 8-bit sprites to such game, will they cycle?
« Last Edit: 13 Apr 2018, 16:30 by Crimson Wizard »

Re: Issues with 8bit palettes
« Reply #15 on: 13 Apr 2018, 17:38 »
In the other situation, when starting from the default template (which has 32bit sprites), then lowering depth and re-importing room images at 8bit, it seems it remains in 32bit mode no matter what, as it still draws original 32bit sprites in full color, regardless of the palette and doesn't cycle even in software mode. Nothing is drawn corrupted and there were no crashes.

When you say "it seems it remains in 32bit mode", have you pressed Ctrl + V in game to check the actual display mode?


Thank you for reminding me of the obvious. Of course I didn't use the debug screen! That'd be too easy wouldn't it! :-D :X
And yes! It was stuck in Hardware rendering, 32bit mode!

And I think I can finally fully reproduce it!

What settings have the priority when running the game with F5 from AGS? The editor saves it's settings in _Debug folder. I deleted everything from the Compiled folder.
But the game still ran on settings from the previous winsetup.exe in the compiled folder?!
As soon as game is recompiled, ran through winsetup, it will remain in whatever mode was set there. No matter what was set in the editor.

Even if I set the game to 8bit, software, and then compile and run it - it will still run at settings from previous compile (32bit, or whatever). It's only when run through winsetup that it truly changes the rendering mode.
« Last Edit: 13 Apr 2018, 17:50 by doimus »

Re: Issues with 8bit palettes
« Reply #16 on: 13 Apr 2018, 17:50 »
As soon as game is recompiled, ran through winsetup, it will remain in whatever mode was set there. No matter what was set in the editor.

The thing is that changing driver in the editor only changes default option, but does not change current user settings. And since AGS 3.3.5 the actual current config is saved in user documents (same place where your savedgames are stored).
You need to do "File -> Build EXE" then "File -> Run setup program" - and then edit config in winsetup.
(Or delete config in %USERPROFILE%/Saved Games/Your game's name/ folder)

EDIT: the config edited in winsetup has a priority. The one you set in the editor is called "default config", it is only applied when there is no user config yet.

EDIT2: although game's color depth is not part of config. It's just that hardware driver runs in 32-bit mode.
« Last Edit: 13 Apr 2018, 17:57 by Crimson Wizard »

Re: Issues with 8bit palettes
« Reply #17 on: 14 Apr 2018, 17:03 »
Ahh, it's all much clearer now, thanks for the explanation! Thumbs up!

Re: Issues with 8bit palettes
« Reply #18 on: 20 Apr 2018, 13:47 »
I remember dabbling in SDL and Pygame a while ago and it had 8bit surfaces you could draw onto and then manipulate as needed, including drawing to 32bit textures.

A bit offtopic.
I was curious about whether SDL2 supports 8-bit software drawing out of the box, and it seems it does (contrary to e.g. Allegro 5 where only option is to emulate palette tricks using shaders):
https://stackoverflow.com/questions/30599636/8-bit-surfaces-in-sdl-2
https://wiki.libsdl.org/SDL_CreateRGBSurface
https://wiki.libsdl.org/SDL_SetPaletteColors

Seem to be as said above: you work with bitmap in software mode (this simply means copying pixel values in memory), then the final result is copied onto 32-bit texture, going through necessary conversion.
« Last Edit: 20 Apr 2018, 13:50 by Crimson Wizard »

Re: Issues with 8bit palettes
« Reply #19 on: 17 May 2022, 21:30 »
Hi, my game is 32 bit game but when importing the sprites I imported all with remap palette I think. Is it always marked with a tick under "import alpha"? I'm not sure if it was unchecked before and if I checked it then. Is there any impact to import with remape palette if the game is 32 bit game?
Truly, truly, I say to you, blessed are those who play adventure games, for theirs is the kingdom of heaven.