Feature Request: Convert 16bit to 32bit inside editor

Started by abstauber, Thu 20/11/2014 08:51:44

Previous topic - Next topic

abstauber

I think this has already been discussed, but the search function doesn't reveal it to me. So I'm sorry in advance in case I waste your time ;)

In the mid of development I converted my project from 16bit to 32bit, so there are quite a few 16bit sprites left and the editor identifies them as 16bit sprites. Now unfortunately these sprites aren't rendered on 32bit/alpha GUI surfaces (they simply don't show up), only after I re-import them.
But since I have hundreds of 16bit sprites in my project I would prefer to convert them inside the editor instead of reimporting them.

Something like: "right click -> convert to 32bit" would be really helpful.

Crimson Wizard

#1
My suggestion was to convert all gfx to the game color depth when it loads in the engine, but I'd like to know if there may be reasons not to do that (always).

Actually AGS does this to some bitmaps, just not to all of them.

abstauber

That would most convenient. At least I can't think of any reason why someone would need to mix 16-bit and 32-bit sprites - and after progressing to 32bit it's not possible to import 16bit sprites (and keep them 16bit) anyway.

Crimson Wizard

Just to elaborate: I mean - convert them in the engine (in memory).

Regarding Editor: either add a context menu command for selected sprites, or menu command to convert ALL sprites, or both.

abstauber

The more I think about this, the more I get the feeling we should classify this as a bug.
The normal behaviour should be "converting all sprites to 32bit once you click so in the editor", but for unknown reasons, the editor doesn't convert the existing sprites to 32bit (or only a few bmps?).

So why should this be fixed during runtime? I'd say choosing the colour depth again should trigger the conversion to 32bit.
Btw. choosing 32bit again already leads to the colour depth dialog - it just doesn't do anything ;)

Calin Leafshade

I'm almost of the opinion that they idea of colour depth should be removed entirely from AGS.

Modern systems dont really cope with anything less than 32-bit surfaces. It disables aero and isnt really much faster anyway.

The only possible benefit is to reduce file size which is hardly a concern at this stage surely.

Crimson Wizard

Quote from: Calin Leafshade on Thu 20/11/2014 21:16:28
I'm almost of the opinion that they idea of colour depth should be removed entirely from AGS.

People still making 8-bit games with AGS.

Calin Leafshade

I'd like to know the reasons why they are doing so. There doesnt seem to be any real advantage

Gilbert

A lot of real advantages. Palette effects are the most obvious examples.

I haven't read all of this thread yet, but I vote for converting the graphics by the engine other than by the editor, as colour depth conversion is basically a one-way operation (e.g. when converting an 8-bit image to 16- or 32- bit you lose all palette information, and any decrease in colour depth is a lossy operation). To have the editor do this for you (unless you explicitly tell it to do so) means you are ruining the original assets.

monkey0506

Palette cycling is still a popular reason for using an 8-bit palette, but is there any reason to continue supporting 16-bit color depth? I doubt any modern system will show a noticeable (negative) difference running in 32-bit color mode vs. 16-bit color, and 16-bit mode has obvious drawbacks (as already mentioned).

Snarky

Quote from: Iceboty V7000a on Fri 21/11/2014 02:56:03
A lot of real advantages. Palette effects are the most obvious examples.

Are there any others?

Also, I've found that (1) It's Hard to get 8-bit AGS games to render correctly on a modern system. So in the current state I wouldn't consider AGS a viable platform for making 8-bit games anyway. (The problem, I should think, is that DirectDraw and Direct3D rely on Windows and the graphics card to support 256-color mode correctly "out of the box", and that's just not the case in many modern systems. To work reliably, the graphics subsystem would need an emulator to render 8-bit palette effects in 32-bit color.) And (2) this is almost never a problem in practice, because aside from Scavenger, is anyone actually making 8-bit AGS games?

So I'm in favor of ditching 8-bit support completely.

abstauber

QuoteAre there any others?
Sure - educational reasons :) You can learn to keep your color-count low, while still producing great art.
I started out 8bit because of it. Then of course I had to upgrade to 16bit because of OS issues and not being able to port it to different systems anytime soon. 16bit on the other hand seems to be useless - it isn't even faster than 32bit, which was the main argument in the early 2000s. Now my project runs with 32bit and is totally fine :)

So how about this:
8-bit: Keep it and convert to 32bit during runtime
16-bit: any reasons why to keep it? If so - convert to 32bit during runtime.
32-bit: Let the editor do proper conversion of existing sprites. still convert 16-bit sprites to 32-bit during runtime.

I think this would also make 8bit graphics more attractive again, since palette effects are still cool and fun to try.

Crimson Wizard

#12
Quote from: abstauber on Fri 21/11/2014 10:38:46
So how about this:
8-bit: Keep it and convert to 32bit during runtime
<...>
I think this would also make 8bit graphics more attractive again, since palette effects are still cool and fun to try.
You do realize that all palette effects wont work if you convert graphics to 32bit?

There's yet another solution, suggested by JJS: combined software-hardware renderer which first draws 8-bit gfx on a virtual screen, then moves result to 32-bit texture and puts that on real screen.

abstauber

Quote from: Crimson Wizard on Fri 21/11/2014 10:40:18
Quote from: abstauber on Fri 21/11/2014 10:38:46
So how about this:
8-bit: Keep it and convert to 32bit during runtime
<...>
I think this would also make 8bit graphics more attractive again, since palette effects are still cool and fun to try.
You do realize that all palette effects wont work if you convert graphics to 32bit?
I was just dreaming...
Quote from: Crimson Wizard on Fri 21/11/2014 10:40:18
There's yet another solution, suggested by JJS: combined software-hardware renderer which first draws 8-bit gfx on a virtual screen, then moves result to 32-bit texture and puts that on real screen.
But this sounds like it would do the trick. Also it sounds like lots of work  :P

Crimson Wizard

Quote from: abstauber on Fri 21/11/2014 10:51:50
But this sounds like it would do the trick. Also it sounds like lots of work  :P
Idk, maybe not that lots. We have software and hardware renderers coded, a combined one may use parts of both.

BTW, found in issue tracker: http://www.adventuregamestudio.co.uk/forums/index.php?issue=325.0

Snarky

It wouldn't necessarily have to be a software renderer. You can pretty easily emulate palette swapping in a pixel shader, and Allegro lets you write shaders. But I know the graphics rendering of AGS is a mess and uses an Allegro version that is old (and modified?), so I understand it could be difficult.

Quote from: abstauber on Fri 21/11/2014 10:38:46
QuoteAre there any others?
Sure - educational reasons :) You can learn to keep your color-count low, while still producing great art.

If you're not using palette effects, you can simply create your graphics in 8-bit but import them and have the game run in 32-bit. You don't need AGS support for that.

Crimson Wizard

#16
Quote from: Snarky on Fri 21/11/2014 11:34:31
It wouldn't necessarily have to be a software renderer. You can pretty easily emulate palette swapping in a pixel shader, and Allegro lets you write shaders. But I know the graphics rendering of AGS is a mess and uses an Allegro version that is old (and modified?), so I understand it could be difficult.
This is Allegro 5, totally incompatible with A4 we are using.

In general renderer solution should be far easier to do, although may be not optimal by runtime speed.

SMF spam blocked by CleanTalk