OpenXcom Forum
Contributions => Programming => Topic started by: Volutar on January 22, 2013, 02:49:42 pm
-
I've been thinking recently on where OXC could go after 1.0, when custom graphics loaders will be added, and 24bit screen mode will be main mode.
We obviously will face THE problem at least of battlescape shading/lighting. UFO:EU have paletted graphics with very "deep" and saturated shades. When it will become 24bit, this shading will become flat.
And I don't know how to overcome this. 24bit oxc will lose this special "night" style.
On screenshot: top line - palette of battlescape; bottom line - flat shaded 24bit lighting.
-
I don't understand it. Can't we show that colors in 24 bpp? Can't 24 bpp basically represent nearly all possible colors?
-
The matter is in SHADING, in lighting falloff gradients, not still representation. There won't be any palette, and color (248,248,248) can be shaded only as gray... but in xcom1 this "hightlight" color corresponding to 4th stripe (warm plastic gradient) and 14th stripe (cold metalic gradient). Engine would have no information on how exactly this color should be "shaded"
-
Yes, that is what I think too. Just convert the indexed palette images to 24 bit images when loading.
Of couse I have no idea how much the current code relies on the indexed stuff for things like lighting.
-
Hmm.. how about calculating the new gradient form the maximum and minimum values? That was my plan all along....
So basically we keep using only the "max and min" for each color group, and we calculate everything in between.
-
The thing is - there's no color groups in 24bit. How will you find what color group is (248,248,248)???
-
By calculating the color range when the palette is loaded?
We should end up with something like in the attachement
-
kkmic, I'm repeating once more: there is no palette in 24mode. Every game sprite will be 24bit even as files. What is the formula of shading, which will "endup" with those gradients you've shown? Considering there's no palette at all. There will be bunch of 24bit sprites. That's all.
-
Every game sprite will be 24bit even as files.
Will it realy? That would mean including converted artwork from the original, wich I think will not be done. Or creating new artwork.
Also the palette currently used is known and could be used for compatible artwork.
-
Whilst the SDL "surface" won't have a palette in 24bpp mode, there's nothing stopping OXC implementing a custom palette and use the lock() and unlock() methods to access a surface and manually replace colours.
This will allow you to retain the palette shifting for lighting, whilst expanding the other possibilities (mixing battlescape, geoscape and basescape items)
-
how about bigger color index? not 255 but 64k colors (it is possible in SDL?)? we could load every palette at once, and have two graphic from xcom1 and xcom2 on one screen.
-
That would mean including converted artwork from the original, wich I think will not be done.
why not? this convertion can be done "on the fly". and then - HD sprites and graphics without palette limitation.
there's nothing stopping OXC implementing a custom palette and use the lock() and unlock() methods to access a surface and manually replace colours.
Of course. No other way to apply lighting in software mode. But how will you shade pixel with 24bit value (248,248,248) which have index 80 and index 224 (yes, two EXACT colors have different shading gradients in terms of palette)??? If you even manage to convert 24bit into 8bit palette (which will greatly cutoff colors), you will get ambiguous values, and that won't let you shade those sprites properly.
This will allow you to retain the palette shifting for lighting
so you're suggesting to keep limited palette graphics? geez...
how about bigger color index? not 255 but 64k colors
1. it's bad idea. 2. it's impossible.
-
It's more a discussion of taste. Ufo tts uses 24bit graphics and "flat" shading. I don't remember anyone complain, I didn't even really notice it.
Example:
https://media.indiedb.com/images/downloads/1/29/28380/tts.JPG
edit: well there are probably better screenshots out there, but I can't access anything here at work. But you get the point. I like to see real examples, not theory. So show the difference between good and bad, and then we make a poll to see how bad bad actually is. And if it is really bad, then we can look for a solution. Now it's like looking for a solution to a problem that is not even proven it's a problem at all.
-
Daiky, yes this is matter of shading "style". And I Believe it would look much better and stylish if it were somehow closer to palette.
-
btw Volutar who will be shading in 24bit? there is SDL function that do it? or it will be do by our side?
If we do it, why dont try made special function that change hue and saturation of pixels?
I think that will be possible to made result similar to original gradient.
Maybe we should use exp function to do it? they can be written to table to speed up.
something like this:
shade(R, G, B, shade)
{
R *= exp(-0.1337*shade);
G *= exp(-0.42*shade);
B *= exp(-0.7*shade)
}
-
When using opengl, you can use shader programs to do the shading.
I tested openxcom with 24bit sprites in a very rough way, and it was painfully slow in software mode, so I assume it needs hardware acceleration anyway.
I know for example in Skyrim there are various mods that change the shader programs that darken textures during sunset,night and dawn to make them more realistic and less flat.
-
Yankes, we cannot do that because of ambiguousnity. You must be reading my point not very carefully.
But how will you shade pixel with 24bit value (248,248,248) which have index 80 and index 224 (yes, two EXACT colors have different shading gradients in terms of palette)??? If you even manage to convert 24bit into 8bit palette (which will greatly cutoff colors), you will get ambiguous values, and that won't let you shade those sprites properly.
-
yup, in my solution this couple of colors will merge, but rest of that gradient will stay maybe close to original (or will not, without test I only guessing :D)
one way to fix this is mark colors, we have 3 bytes with RGB and one byte with "gradient" that is used in my function to get correct shading (this 4th byte will be ignored by SDL).
-
And how will you going to do those sprites with "palette" component???
That's the weirdest idea I ever heard :)
I do have an idea how we can convert old graphics and make new graphics "hued" in oldschool, paletted way. We should lower sprites light alittle, to get slightly off overlighted parts of gradient, so those tints will be there. But when drawing those sprites with light - we'll have not only darken them by particular formulas, but lighten as well (to get back to overlighted part).
Sortly - idea is to darken graphics before converting to 24bit, and light it back when drawing.
-
I've made some tests of my idea.
Top line is palette.
Then "recreated" gradients, with light shift from -8 to -1(second light is taken as "main").
So as you can see, even this techniq won't get close to original, though is better than "flat shading" from first post (which is closest to bottom version).
In second shot I was using slightly different "lighting" method (while "shading" is the same).
Added: If we'll go into hardware (opengl), we can forget about styled shading :(
Found this https://en.wikipedia.org/wiki/Abney_effect
-
The problem, as I understand it is the following:
The paletted image files contain the palette index for only one shade of the colour (colour group).
Right now we shade by moving inside this colour group, which contains the various shades.
Since we have the actual values of each shade for each group, we could plot the curve of shade, component and see if we can find Gamma that gives an approximate curve when used as pow(shade, component Gamma).
Shade and component are normalized to [0,1] (shade was [0,15] and component [0,255]).
I'm guessing that there should be a set of gamma functions that corresponds to these shades or that can approximate them good enough.
EDIT: You mean there are indices that are the same offset in different groups and have the same RGB value? And they are the original colour in the image (the data saved on file)? eg FAKE EXAMPLE to make it clear: Offset 0 in first group (warm wood) and 0 in third group (dark concrete) have the same RGB values and the image data contains a 0 in both cases? Because if that it the case then we have indeed lost information. But if it's not, then we may be able to get a good enough approximation.
-
why not? this convertion can be done "on the fly". and then - HD sprites and graphics without palette limitation.
Short answer: Copyright
There are 2 ways to use the originals artwork.
1. Load it dynamically from the orignal data. I suppose that is what you mean by "on the fly".
2. Have an installer extract all the needed stuff from the original data only once.
The point is you can not distribute any non-original artwork.
And lets not start another discussion about copyright at this point, it is already discussed to death.
so you're suggesting to keep limited palette graphics? geez...
No you misunderstand me. Any converted artwork from the original will use only those indexed colors and as such can be shaded like before. The question is of course what happens once you have new artwork that actually uses new colors?
-
Short answer: Copyright
I deny to discuss any of aspects of this. The real issue is TECHNICAL issue, and the only one. If you want to fall into copyright stuff- there's another topic for this.
I believe it's possible to overcome this 24bit shading, by using GLSL.
-
What's the point of trying to reproduce old palette shading in runtime if they're only gonna work with the old graphics and would just break again with new 24bpp graphics? You'll need to distinguish old and new graphics either way, so might as well just use a fragment shader to simulate palette effects or pre-generate all the lighted versions for old graphics.
Also the old graphics used VGA colors which only went up to (64,64,64), so the gradients probably aren't as crazy as they look converted to (256,256,256).
-
SUpSUper, vga palette is just a pck convertion data, 6bit->8bit won't make any advantage. I'm totally agreed that "palette simulation" should work with ANY graphics, either old and new(added). That's why I've started this topic.. to gather and share ideas on how old palette shading(lighting) gradients could be simulated for non paletted 24/32bit sprites.
There's is a number of "hue ranges" in xcom1 which are getting more saturated when getting darker (more of deep red or blue in middle-bright part). I don't know how to simulate this, except for getting "default" sprites darkened to this middle-bright, oversaturated part, and then either getting sprite darker, or brighter. But when getting sprite brighter from this "middle-bright" we should not just multiply color components (that will lead to results shown in battlescape_palette2.png), but add some values (adding white color for brightening shown in battlescape_palette3.png). Though, it still far from original, since "oversaturated" (bright) parts aren't just "white" - they are cyan, or yellow, or orange...
It's possible to have sort of LUT, for significant bits of color components (for instance - 2 bits of red, 2 bits of green and 2 bits of blue, total 6 bits ->64 "brightening ways") so depending on what hue this color is closer, it will choose "overbright" color for it.. and it will work (I hope) for both old graphics and new will match original palette style. Or at least will be more closer to it.
I'm not very familiar with hardware shading, but I believe it's possible to make this "fragment shader" which will be using this oversaturation and overbright trick fast way. But as fallback it will use flat shading without this palette magic.
-
So you are trying to come up with a universally aplicable algorithm for shading in battlescape?
And the output should look as close to the original game shading as possible?
Well we can discuss a lot of theory, but as long as there is no testbed for the different algorithms we come up with so we can see the result(and performance), we can not realy judge wich algorithm is better.
And to realy test it out someone would have to create real 24bit artwork that uses more than the standart colors.
And does it realy have to look like the original shading?
-
Not exact, but similar, with "oldschool" palette-like appearence, but of course HD and smoother.
I remember UFO:EU as game with special "night" appearence, which was not that nice in TFTD, and absolutely no such thing in Apocalypse. So, yes, I would like to come up with some sort of battlescape lightning algorithm (and why not glsl?), which will give nice result as for old-converted graphics, and for new graphics set as well.
-
If you check out the TFTD Tactical palettes it is even more obvious:
https://www.ufopaedia.org/index.php?title=PALETTES.DAT
..how important the palette colors are. If you would just apply a flat shade, no matter if you are above or under water, you'll loose the underwater effect of the TFTD battlescapes.
-
TFTD palette has blue tint addition for "middle" light levels. And of course it's quite essential for getting particular athmosphere. Some can say it can be done by blue light addition, but that will result in very blue screen, not just a tint.
-
TFTD palette has blue tint addition for "middle" light levels. And of course it's quite essential for getting particular athmosphere. Some can say it can be done by blue light addition, but that will result in very blue screen, not just a tint.
Well unless you tint pixels blue in only certain light levels?
-
You could also do this on a reverse scale
So as your "brightness" decreases from 255 to 0, your blue tint increases
A scale like this should look pretty reasonable
| Light Level | Blue Tint |
| 255 | 0 |
| 220 | 0 |
| 192 | 0 |
| 128 | 0 |
| 96 | 16 |
| 64 | 32 |
| 32 | 48 |
| 16 | 64 |
| 0 | 96 |
-
I would like to point out that UFO:TTS battlescape art is all 24/32bit and was drawn specifically for TTS, not converted from X-COM. TTS art could be used to test how shading algorithms work on 24bit or 32bit art but is not a good comparison of what 6-8bit index based art looks like in a 24bit renderer.
-
darkestaxe, original graphics will do fine for 24bit testing... just convert them on the fly into 24bit (with certain light level), and then use it with 24bit lighting/shading applied.
-
As long as new 24bit textures only ever see normal 24 bit rendering there wouldn't be an execution problem, but two objects may appear to react very differently to lighting if the two objects have different systems for calculating lighting.
I was talking about testing what would be used in both cases to see what happens when both are on the screen at the same time. If you're new tree texture uses full 24bit and the grass is still the original 8bit index texture, then will the two textures look weird next too each-other in different lighting conditions? Another-words if they look fine at first, will they look weird after you drop an electro-flare by the tree?
The other reason I pointed out TTS as being 24bit was a comment by SupSuper that 24bit lighting in TTS looks fine without any special rendering. I didn't think he realized TTS textures were originals drawn in 24bit with Illustrator or PaintShop.
I think I see a problem with converting 8bit to 24 bit at a given light level at the start of a mission: I'm not sure how many different possible light levels a tile can be at on a given mission but even if it's only 32 and a ground texture is only 64x64px that's 4mb per texture tile at 24bit color and 8bit alpha. I'm not sure what the actual texture resolutions are or how many are loaded per battlescape, but I'm estimating well over 200 in my head for a terror site including unit animations. That would be about 800mb, which seems like a lot to me.
-
I don't know what math do you use, but texture of resolution 64x64 with 32bit (RGBA) will be 16kbytes only. Texture atlas with 256 of those will be 8Mbyte only. If you make those pre-rendered for different light levels (there's only 16 of them) - it will be 128Mbytes, not 800. And that would work only for original, paletted graphics. If you try to use same technique with "TTS set" you'll fail, because there's no "colorgroup" info in those sprites.
-
I don't know what math do you use, but texture of resolution 64x64 with 32bit (RGBA) will be 16kbytes only.
Darkestaxe is then talking about 32 versions of the 64x64 for lighting; Though this will still only be 0.5MB (512KB)
-
Having every shaded version in memory at the same time is very expensive because we may have (by definition) 256 different tiles. And 256 different NW and 256 different NE and 256 different center objects. Which adds fast to huge amounts of memory.
Going to 32 bits of colour (RGBA), with premultiplied Alpha, allows us to do tinting and lighting as a simple shader (I think) or alpha blending (I know). We may lose some of the original colours, but we are talking about a visual overhaul anyway. And we get room / possibilities of many more effects, like properly transparent smoke, translucent flames, grayscale-as-fog-of-war and depth bluring at almost no extra cost.
-
pmprog,
1. 64x64x32bit = 16kbytes, 256 of them is 4mbytes.
2. there are only 16 light levels in xcom1, so it would be 64 mbytes. even 32 levels would be only 128mbytes.
karvanit,
why 256 nw and 256 ne? there's only ONE tile set per map. and there's a limit of 256 tiles per map. though it may have animated tiles (but there are only few of them), which _slightly_ increase overall sprites count.
but the thing is - units also need to be "shaded" properly, though they could be flat shaded.
and still, that would work only for 8bit original graphics. still no way of such "oldschool" shading for 32bit "HD" sprites from TTS.
-
pmprog,
1. 64x64x32bit = 16kbytes, 256 of them is 4mbytes.
2. there are only 16 light levels in xcom1, so it would be 64 mbytes. even 32 levels would be only 128mbytes.
I read this (my highlights):
I'm not sure how many different possible light levels a tile can be at on a given mission but even if it's only 32 and a ground texture is only 64x64px that's 4mb per texture tile
I was only talking about a single tile; but it doesn't really matter
-
why 256 nw and 256 ne? there's only ONE tile set per map. and there's a limit of 256 tiles per map. though it may have animated tiles (but there are only few of them), which _slightly_ increase overall sprites count.
but the thing is - units also need to be "shaded" properly, though they could be flat shaded.
and still, that would work only for 8bit original graphics. still no way of such "oldschool" shading for 32bit "HD" sprites from TTS.
Don't we keep the images for NW/NE/floor and central object as separate sprites? If we don't, then it's true that we only have 256 sprites max (for terrain). Although I think the 256 tile limit can be lifted easily enough and become 2^16 (a few typedef changes and a small change when reading from the original data).
-
My math was wrong in two ways. I assumed 32 light levels minimum in a night mission, according to Volutar there's 16. Also I forgot to account for there being multiple bits in a byte, it's 32bit RGBA, not 32byte RGBA which would be an extreme and unnecessary color resolution.
However the x-com map is not a static image, it changes throughout the battlescape turn. If there were a maximum of 256 tiles, like maybe a base mission, it wouldn't matter. (an X-COM base should have 3,600 tiles if a small facility is 10x10) All of this is irrelevent however as it would not make sense to load the pic for the basic hangar floor tile at 16 light levels ~900-1000 times for each and every tile. That would be silly.
But lets suppose we go on a sectiod terror mission in our avenger. We brought at least 1 of each weapon, armor type, and 4 different tanks. Also a male and female soldier are wearing each armor type. Finally the sectiods brought a leader, at least 5 different types of weapons, reapers, etc.
I'm pretty sure we don't need separate sprites for each type of unit holding each type of weapon, however we need at least 6 sprites for each unit type, for each position they would be animated in. (death excluded-everyone faces the same direction to die) We also need sprites for each type of corpse, and the death animations. Next we need sprites for every candy-shelf in the store, door in the apartments, sink in the little houses, roof tiles, etc. Keep in mind many of these things are larger then the tile too. Also there's still all the pavement, grass, dirt, scorched pavement, scorched grass ... I think you can use your imagination at this point.
Basically I find it hard to believe that 256 sprites is even half of it it. Am I off about the 64x64? If so, then that makes a huge difference and would explain how some of this as doable on a 80-286 in 1992.
-
The number of tiles we count is NOT the number of grid positions in the battlescape. It is the different contents that can appear. e.g. All alien UFO floors are the same tile. Right now this is hardcoded at 256 (one byte index), same as in the original game.
-
Ok, I made a test with hybrid solution, when artists gotta make two different shaded 32 sprites for each battlescape sprite - full light, and half-light (It makes light shades being interpolated between these two, and dark shades are going towards "black" by static curve). For vanilla it will simply generate all "intermediate light" sprite pairs, for custom - it should be done manually.
For XCOM-1 it works perfectly. The difference is barely noticeable, so there's no need even to show it.
But for TFTD underwater blue, or deep black is really off. Right now I can't figure how to make it possible with just 2 images.
Obviously there should be "ambient color" parameter, but not only that, because in xcom2 all colors all colors are gaining blue tint, even before going black in deep palette. I hate TFTD colors.
-
vanilla:
(https://volutar.eu5.org/tftd_d3_v.png)
hybrid lighting:
(https://volutar.eu5.org/tftd_d3_h.png)
I need more savegames (night missions from batlescape) from vanilla to make more test shots. If anyone has - would you mind sharing with me (specially crashed plane mission). Thanks.
-
Hello Volutar,
I have quite a lot of saves from my LP.
The spreadsheet with overview, which terrain can be found in which mission/episode/save can be found here:
- https://docs.google.com/spreadsheets/d/1jkgLpvA7Q_x0fMW4T-E74uyNh5MOPIFinIDLrR1H8Ts/edit?usp=sharing
The saves themselves are here:
- link broken
Enjoy!
PS: The Crashed plane mission during the night as you asked are approx. saves #23 #24 and #25
PS2: The LP was about showing everything, so you should see all types of terrains, all types of UFOs and all types of aliens, just find the correct save based on the spreadsheet
-
Holy pixels!
Meridian, thanks!
I hope all this... was made not because I asked :)
-
No, it was already done before...
...but I would gladly do it again, if it helps OpenXcom/OpenTFTD development.
-
Well, results are not too good for TFTD.
Since there are 4 different palettes (terrain, shallow, medium and deep), the "semi-shade" sprites are quite different with different palettes. Sprite with full light is the same, but "shading curves" are too different.
Current algorithm for xcom1 which resembles vanilla by 99%:
- Full light sprite.
- Medium shaded sprite (the 6th grade of shade).
- For shade values 0-6 it takes interpolated result between full light and medium shaded sprites.
- For shade values >6 it takes medium shaded sprite and applying linear shading curve with black clamp (decreasing each of RGB values by some number with each step, red is decreased slowly, so shades are slightly reddish, which is xcom1 visual style).
For TFTD sprites medium shaded sprites are different for each depth. Shading curves also slightly differ (terrain is neutral, and different depths has different slopes with different blue component decreasing speed).
For vanilla 8bit sprites we can generate "medium shaded" versions on battlescape load, and use different shading curves, and result might be not that bad.
But for custom sprites, drawn in 32bits, the artist would need to draw 5 different sprites. Full light, and 4 semi-shaded version for each depth. It's not really nice thing, but currently I can't think of other way, besides giving no fucks on vanilla tftd look and feel and implementing something entierly different.
-
that picture you had above looks fine. this is a remake is not vanilla. as close to vanilla as possible is good enough .
-
This picture above WOULD be achieved only if artists gonna make 5 versions of each TFTD battlescape (shadable) sprite (for custom), or with odrinary 8bit sprites for TFTD palette.
-
vanilla:
(https://volutar.eu5.org/tftd_d3_v.png)
hybrid lighting:
(https://volutar.eu5.org/tftd_d3_h.png)
Hello Volutar,
First and foremost: Thank you for caring about such details!
I believe that it is very important to copy the lighting and shading of vanilla TFTD as close as possible. Why? The outstanding thing about TFTD was its atmosphere. And this atmosphere was created mostly through TFTDs great art direction: the vibrant colors, the gloomy underwater shading/lighting, the “weird colorful darkness” of deep sea missions.
I compared the two images on my Eizo: hybrid lighting looks extremely flat and the gloomy atmosphere of vanilla is lost. It almost seems as if ambient occlusion was turned off in hybrid ;). In particular, the lack of darkening on the floor produces a flat and uninteresting image.
Maybe some people don't care about such graphical differences, but I am glad, that someone who cares is working on OpenXcom.
-
Am I the only one who can't spot a difference between these two pics, no matter how long I look? :)
-
i can spot the difference ..there is more blue hue at the top darkness is different in hybrid is more black and clear. darkness in vanilla is more foggy blue. i personally like vanilla look less. also hybrid light is a bit brighter. i like it more hybrid as it's more clear and contrast is higher between dark light. in vanilla is more flat and goes into generic blue hue . tftd is kinda barfy looking anyway. i'm not a fan. i do like some clors in the palette esp blue/green hues and lots of orange/yellows.
-
Yeah, I can see it now after you've directed me to the right place. But is it really a thing to worry about? Apart from fulfilling a programmer's ambition, which I respect.
-
not really but volutar wants it faithful to original game look. i personally want it playable and looking good. by looking good doesn't have to be the same as original . tftd has 4 palettes so is annoying cause the color curves are different you can't use one formula for everything. but maybe you can.
-
Am I the only one who can't spot a difference between these two pics, no matter how long I look? :)
You have to download and view them in fullscreen. As a fact: only some fully lit objects/tiles are the same; the whole shading of not fully lit areas seems to be different. This will have great impact on the look of deep sea and underwater night missions.
(https://cdn.makeagif.com/media/3-13-2015/n3_0ci.gif)
-
i think special effects like bubbles or bullet projectile wake effect can really make it underwatery..you can even add a slight wavy shader effect if you want for more realism
-
Am I the only one who can't spot a difference between these two pics, no matter how long I look? :)
I can't say I dislike the non-vanilla look. It is more than acceptable. But I can definitely see a huge difference between the vanilla and non-vanilla too.
-
I can't say I dislike the non-vanilla look. It is more than acceptable. But I can definitely see a huge difference between the vanilla and non-vanilla too.
Yeah, I concur. I would certainly enjoy playing in that environment.
-
I'm looking at that gif and I'm with FLIR on this one. That's going to make a huge difference in-game even if it's a subconscious one.
If I understand Volutar correctly then the lame version is after doing the whole conversion thing with 5 versions of each tile sprite, so I'm assuming it's even worse before that. Either way I don't see many moders being able to correctly shade different light levels for ambiance.
Would it be possible to apply lighting to 3 different alpha channels for red green and blue, and then use transparency to apply the gradients differently to different colors?
Maybe someone could make a 8-bit X-COM-color GIMP mod, but I just don't see that working out really well.
-
Employing something like the COLORMAP used in IDEngine1 (https://doomwiki.org/wiki/COLORMAP) for palette entries except with full RGB support for the different light levels of the respective palette entry* would likely be a good solution to this problem.
* - the actual COLORMAP implementation uses palette entries that would visually look like a grayscale image with the pixel brightness indicating the palette entry number. This means we can't do anything we want since ultimately we're dictated by the palette. :^(
So as an example, here's the stock Doom colormap:
(https://dl.dropboxusercontent.com/u/63152810/_DoomCMap.png)
Each pixel in the topmost row represents the raw palette indexes from 0 (leftmost) to 255 (rightmost), with every pixel downwards being a drop in light level.
Do note all the duplicate colors due to the lack of colors to represent the darker shades in the palette.
(https://dl.dropboxusercontent.com/u/63152810/_DoomLazy24CMap.png)
Here's a very quick & dirty "fade to black" approach in 24 bits (not restricted to just the palette entries)
But here's the thing - we can do anything we want in all of those different light levels.
(https://dl.dropboxusercontent.com/u/63152810/_DoomEdited24CMap.png)
(also includes a different blue because the default one sucks)
Which of course also means that we can do some color tinting as we approach the darker shades;
(https://dl.dropboxusercontent.com/u/63152810/_DoomEditedTinted24CMap.png)
And I'm bringing this up because it seems like a way to do what you're looking for, while also providing a funky tool for modding.
-
As much as I love pixelart, using 24bit color to create darker shades, including tinted-blue, but also all sorts of ambient light out of the basic 256 color palette would certainly give awesome effects. So I'm all for it, it doesn't violate the spirit of the original while allowing for so much richer graphics.
-
Employing something like the COLORMAP used in IDEngine1 (https://doomwiki.org/wiki/COLORMAP) for palette entries except with full RGB support for the different light levels of the respective palette entry* would likely be a good solution to this problem.
* - the actual COLORMAP implementation uses palette entries that would visually look like a grayscale image with the pixel brightness indicating the palette entry number. This means we can't do anything we want since ultimately we're dictated by the palette. :^(
And I'm bringing this up because it seems like a way to do what you're looking for, while also providing a funky tool for modding.
X-COM already uses a similar palette method. That's the gradients you see in earlier posts.
The idea is to not have to use the palette. This is analogous to Doom's GL ports allowing 32-bit PNGs, with the same pitfall that in GL renderer you lose the original shading look, since they don't use the colormap at all.
As for my opinion, this is a question that almost every palette based game engine upgrade project reaches at some point (Doom, Quake, Duke 3D, and so on). There simply is no way to perfectly replicate the original shading while taking non-paletted sprites into account. The best you can do is approximate it with shaders or curves or forcing darker shades to certain step intervals.
I think there should simply be a video option for choosing yourself. 8-bit, which uses the vanilla lighting and makes 24/32-bit graphics map to the nearest palette color, or 24/32-bit which allows any color despite a less authentic lighting method. This is what most other projects do.
-
X-COM already uses a similar palette method. That's the gradients you see in earlier posts.
The idea is to not have to use the palette. This is analogous to Doom's GL ports allowing 32-bit PNGs, with the same pitfall that in GL renderer you lose the original shading look, since they don't use the colormap at all.
As for my opinion, this is a question that almost every palette based game engine upgrade project reaches at some point (Doom, Quake, Duke 3D, and so on). There simply is no way to perfectly replicate the original shading while taking non-paletted sprites into account. The best you can do is approximate it with shaders or curves or forcing darker shades to certain step intervals.
I think there should simply be a video option for choosing yourself. 8-bit, which uses the vanilla lighting and makes 24/32-bit graphics map to the nearest palette color, or 24/32-bit which allows any color despite a less authentic lighting method. This is what most other projects do.
I remember when the edge port added 32bit textures, we started using dynamic lights rather than sector lighting. Not sure how dynamic lighting would work in xcom considering you would have to spawn lights on all of the maps.
-
I wasn't referring to the light sources, I meant how the graphics are actually darkened from lighting.
In EDGE, GZDoom, etc. you don't get reds turning into browns and such because it doesn't use the colormap for lighting. The map doesn't get darker further away from the player. The original software lighting shading is lost or only approximated. You can see an example here. (https://fc00.deviantart.net/fs70/i/2012/330/b/1/doom___software_render_vs__open_gl_render_by_shelterscratch-d5m9dxh.png)
The same would happen for OpenXcom in 32-bit. That's the discussion; that allowing non-paletted sprites results in losing the paletted shading method.
If you go back and see the UFO TTS screenshot, you can see that darker tiles look a bit flatter and paler than they would with the 8-bit lighting.
It's not a really big deal, but just like Doom there is a certain charm to it that is lost.
-
I would point out that DOOMs lighting always looked weird because of the way the software renderer handled it. In the comparison Travis linked you can see it, there's odd color bits in various places and dark areas don't look dark so much as discolored.
TFTD is a different case. TFTD doesn't mash up the colors to approximate shading, it uses 8-bit shading to create an underwater effect. DOOMs 8-bit shading artifacts are more like an expertly handled accident compared to TFTDs 8-bit shading feature.
Another way to put it: OpenGL shades DOOM textures correctly where previously they were being shaded incorrectly, though approximated carefully enough to look good. OpenGL shades TFTD incorrectly where previously it was shading exactly as desired and intended.
OR
DOOM actually looks better with an OpenGL renderer, albeit not as nostalgic. TFTD looks wrong in 24 bit and maybe a bit weird, regardless of nostalgia.
-
Doom's palette and colormap are really bad, and it does look better in OpenGL with a certain lighting hack to imitate the software depth fog - the thing that causes things close to the camera to be lightened up.
It would definitely look better paletted with a 24-bit colormap though.
I can imagine rendering the entire scene in fullbright to capture the palette colors into one texture, rendering all the lighting into a separate texture - and then modifying the fullbright texture's colors by matching colors onto the appropriate index of the colormap for the X position and then setting the pixel's Y position on the colormap texture to the brightness on the lighting texture might work.
But that's wishful thinking. :-)
-
if you wanna get rid of palettes go 32 bit. i think is better for effects. you only see 24 bit max but 32 i think makes sfx better . i can't remember why. i think it has to do with having more colors to do math on or something generating better gradients, transparency etc.
probably simplest way to do it atm is to map the 8 bit image to a 32 bit surface just before effects do shading /transp then present to screen so the game would still be 8 bit but will support transparency and nice gradients/shadows/lighting.
-
tollworkout, you're missing the entire point of the thread. Look again at the very post, the two rows of colors in the attached picture :
Top is what XCOM does with a palette,
Bottom is what you'd get if the source image is arbitrary 24bit.
They are different, and the second one is not just "acceptable".
-
tollworkout, you're missing the entire point of the thread. Look again at the very post, the two rows of colors in the attached picture :
Top is what XCOM does with a palette,
Bottom is what you'd get if the source image is arbitrary 24bit.
They are different, and the second one is not just "acceptable".
i read 1st post. i getcha. title confused me a bit. 256 color def looks better :/
-
I made depth shading for AndO3131:
https://github.com/Yankes/OpenXcom/tree/ShaderDraw32bit
This is enough close to TFTD?
Btw I made sandbox where I can do experiments with palettes:
https://jsfiddle.net/hgcufgL7/14/
-
I think it's very good result. Here are screenshots comparing gazer alien. First one is without shading - difference is visible on first glance :).
-
Looks more transparent than tinted.
-
That's what happens when the tint is "blend to this color" rather than any sort of modification of the base color. ;)
It is certainly promising though.
-
In AndO3131 version I made some error making unit more flat that it should be.
I made some screenshoots showing that this isn't simply blend.
I did 3 things, calculate effective shade of pixel based on sum value of colors.
subtract some linear values based on new shade.
finally blend with background color.
This 3 steps allowed me recreate most of behavior of TFTD palette.
You can toy with my implementation here: https://jsfiddle.net/hgcufgL7/14/ and see difference with original colors (upper is calculated, lower is original in each depth line).
-
In AndO3131 version I made some error making unit more flat that it should be.
I made some screenshoots showing that this isn't simply blend.
I did 3 things, calculate effective shade of pixel based on sum value of colors.
subtract some linear values based on new shade.
finally blend with background color.
This 3 steps allowed me recreate most of behavior of TFTD palette.
You can toy with my implementation here: https://jsfiddle.net/hgcufgL7/14/ and see difference with original colors (upper is calculated, lower is original in each depth line).
I have not played TFTD (or UFO for that manner) but that does look positively sexy.