aliens

Author Topic: Bigger Palette idea.  (Read 334 times)

Online Skybuck

  • Colonel
  • ****
  • Posts: 167
    • View Profile
Bigger Palette idea.
« on: May 12, 2022, 05:52:10 pm »
The idea is to increase the number of entries for the palette per row.

Currently the palette has 16 entries.

This could be increased to 16x2, 16x3, 16x4, 16x5, 16x6, 16x8, 16x9, 16x10, 16x11, 16x12, 16x13, 16x14, 16x15, 16x16 for a maximum of 256 colors per row, even more might be possible for 48 bit displays and such but I don't have one and most probably don't.

The idea is then to take a color from the original palette, and the next one and put entries in between and then interpolate the entries so for example:
16x3 seems interesting, 48 colors per row:

NewC[0] := OldC[0];
NewC[3] := OldC[1];
NewC[7] := OldC[2];
NewC[11] := OldC[3];
and so forth.

Then have some algorithm interpolate the colors to fill in C[1], C[2].

Are even better 16x4 and so forth.

Here is a link to a youtube video to show this idea a little bit:

https://www.youtube.com/watch?v=4tlHXbOGy6o

This will keep the palette much more to it's original make up, but this still allows the palette to be scaled up, to take adventage of true colors, more shades possible, while staying within the original intend of the palette/colors.

This will/should then avoid any color shifting if this is not done... if using true color directly I can imagine that this will disturb the shading that is in the game, it seems to work in a certain way... it's palette is basically a sort of shader I think... therefore sticking with it but scaling it up, should give some good/better results, then translating colors directly to 24 bit and then trying to shade in between true colors, instead shade in between color values/indexes inside this palette may and should give better results ! Definetly worth a try ! ;)
« Last Edit: May 12, 2022, 05:53:52 pm by Skybuck »

Offline Yankes

  • Commander
  • *****
  • Posts: 2677
    • View Profile
Re: Bigger Palette idea.
« Reply #1 on: May 12, 2022, 07:17:17 pm »
8bit palette is fundamental part of OXC engine, changing this would require rewriting most of code that is responsible for graphic not mention that lack of support form SDL for bigger palettes.

In theory you can make palette bigger, but then only sense have 16bit value as other wise you will waste bits.
Using bigger palette is pointless as it will have same size as RGB value.

another problem is that you can't have arbitrary "column" size, it need be fixed other wise all bliting code will be two time slower because it will require to read some memory to check current size. This will be waste of CPU time for very marginal grains, adding new bit in palette in theory can double numbers of colors, in your case adding new bit only barely add new colors values as they are very similar to existing one, probably after 2 bits you would need painting program to be able recognize two different colors in this "extended" palette.

Offline Finnik

  • Colonel
  • ****
  • Posts: 383
  • Finnik#0257
    • View Profile
Re: Bigger Palette idea.
« Reply #2 on: May 12, 2022, 10:05:20 pm »
I'd rather suggest changing SDL to 2ed version, rather than that...

Online Skybuck

  • Colonel
  • ****
  • Posts: 167
    • View Profile
Re: Bigger Palette idea.
« Reply #3 on: May 13, 2022, 09:17:24 am »
8bit palette is fundamental part of OXC engine, changing this would require rewriting most of code that is responsible for graphic not mention that lack of support form SDL for bigger palettes.

1. I am thinking of by-passing SDL completely, but calling into a DLL written in Delphi and then simply passing around variables and maybe pointers to memory. Perhaps these pointers cannot be read, but I know there is some way to make the DLL part of the Game and in that case the DLL can access memory.For example if the game loads the DLL then I believe the DLL will be mapped into memory and thus should be able to access any part of the game's memory. This DLL could then use OpenGL to render graphics or any other library.

In theory you can make palette bigger, but then only sense have 16bit value as other wise you will waste bits.
Using bigger palette is pointless as it will have same size as RGB value.

The idea is to pre-compute the palette to indeed make it bigger. I don't see how it would be pointless.

Palettes are simply indexes into RGB values.

another problem is that you can't have arbitrary "column" size, it need be fixed other wise all bliting code will be two time slower because it will require to read some memory to

I don't care about the blitting code, it is more a nuisance/hinder and it sits in the way of doing special vga/color effects. I also discover the rendering is quite fast on todays CPUs even with setpixel and getpixel. Blitting might have been nice/fast in ms-dos days, but it seems to be of little use in 2022.

check current size. This will be waste of CPU time for very marginal grains, adding new bit in palette in theory can double numbers of colors, in your case adding new bit only barely add new colors values as they are very similar to existing one, probably after 2 bits you would need painting program to be able recognize two different colors in this "extended" palette.

The current 8 bit palette causes visible "banding", where the transition from one shade of color to the next is clearly visible by "circle like patterns" known as banding. So here there is a clear oppertunity to make the banding less severe.

For an initial try of this idea the performance is somewhat irrelevant, first the idea should be tried to see if it makes x-com look good and better.

However the performance won't be so bad because the following code/formulas can be used:

To compute the "base" color of a sprite pixel:

1. First acquire the color (=palette index) with getPixel.

2. Then divide the index by 16 to compute in which row it ends up. This is the same as masking the palette index with "and 240" which is much faster than div 16.

3. Then since the dark colors start on the opposite side of this row "add 15", to make the base index start on the other side/dark side, near zero rgb.

4. Then to shade anything subtract the shade value which should lie between 0 and 15 from this base index.

And here one can see how limited 16 colors really is. Maybe the C64 even had more colors lol.

To show any kind of texture, the texture also needs to lie with these 16 colors. To compute the texture index "and 15" maybe then div 4 to scale it "down", to generate a texture index/color of a range of only 0..3 which is very limited. That would lead 12 shade colors for the texture, again very limited. (In code below this is not down and shade simply subtracted from texture color to "shade/subtract" it down and if it goes below zero, cap it, which needs an "expensive < 0 branch".

Because of these very serious limitations, I am convinced that more should be possible with a bigger palette. Extra colors could also be added to make it go fully to dark/blackness at the end of each row. Or even better, invert the palette so that each row starts at zero color rgb values for a more intuitive palette. This would also make the computations easier, add 15 then don't have to be done, and subtracting the shade value would just be an add.

So currently the code per pixel is, it's also safer to simple use signed integers in case anything goes below zero.

Real code example, the sun code can be ignored, but I post it anyway in case anybody wants to use it or wants to try and optimize it ! ;)

                  // some rough estimate
                  MaxDistanceToSun = sqrt( (50*16) * (50*16) * 2 + (4*24) * (4*24) ) / 3; // pre-computed estimate

                  SunShade = (DistanceToSun / MaxDistanceToSun) * 15; // slow div

                  // cap it
                  if (SunShade < 0) SunShade = 0;
                  if (SunShade > 15) SunShade = 15;

//                  int ShadowShade = 15 - SunShade;
                  int ShadowShade = SunShade;

// Important parts start here:
                     int BaseColor = (PixelColor & 240) + 15;
                     int TextureColor = 15 - (PixelColor & 15); // isolate "texture information"

                     int ShadeColor = TextureColor - ShadowShade;

                     if (ShadeColor < 0) ShadeColor = 0;

                     Uint8 FinalColor = BaseColor - ShadeColor;

                     surface->setPixel( ScreenPixelX, ScreenPixelY, FinalColor );


The texture color has to be inverted, since the base color is moved to +15, so now 15 - textureColor to revert that.

Let's see if that make sense:

Let's say original texture color is 246:

Base Color = 246 and 240 =  240 + 15 = 255
Texture Color = 15 - (246 and 15 =6) = 15 - 6 = 9

FinalColor =  255 - 9 = 246

So now the final color is back at 246 so the computations above are correct.

Online Skybuck

  • Colonel
  • ****
  • Posts: 167
    • View Profile
Re: Bigger Palette idea.
« Reply #4 on: May 13, 2022, 09:19:54 am »
I'd rather suggest changing SDL to 2ed version, rather than that...

SDL version 2 doesn't even work on my system ! HAHA.

That signals to me it has compatibility problems, since this laptop is plain intel/vanilla core i5 processor, and SDL 2 was badly tested.

Here is further prove of this, very recent:

https://discourse.libsdl.org/t/sdl-opengl-context-glitchy-window-with-integrated-graphics/35369/2

Most likely SDL version 2 depends on opengl hardware rendering, which for old games is a bad idea... not everybody in the world installs a gpu driver, and when gpu fails all that is left is integrated graphics... thus fallback to software rendering is much preferred for old games, at least as a bottom/base/minimum.

Very disappointing to see that SDL version 2 cannot function properly on integrated graphics or broken/none-gpu systems out of the box. Perhaps there is some setting that can be tweaked.

However so far I am impressed with opengl software rendering mode it seems to be quite faster, much faster than when trying to do the same with delphi vcl/canvas or other technique to access vga/integrate graphics hardware. I suspect somehow opengl software driver of Microsoft is by-passing a lot of stuff to make it a lot quicker.
« Last Edit: May 13, 2022, 09:26:24 am by Skybuck »

Offline Yankes

  • Commander
  • *****
  • Posts: 2677
    • View Profile
Re: Bigger Palette idea.
« Reply #5 on: May 13, 2022, 08:31:41 pm »
1. I am thinking of by-passing SDL completely, but calling into a DLL written in Delphi and then simply passing around variables and maybe pointers to memory. Perhaps these pointers cannot be read, but I know there is some way to make the DLL part of the Game and in that case the DLL can access memory.For example if the game loads the DLL then I believe the DLL will be mapped into memory and thus should be able to access any part of the game's memory. This DLL could then use OpenGL to render graphics or any other library.

Do you aware that OXC is open sorcie project and all changes you can make in this dll you can make in OXC itself?
Do you consider any other operating system than Windows? or system that do not supports any code linkage on run time?

Beside even if you skip SDL then how you handle system API that support only 8bit palettes or RGB colors? Where you fit 9bit palette?
Most of SDL limitation is because what most hardware support.
This mean you need manually convert this "big" palette to RGB before sending it to anywhere.


The idea is to pre-compute the palette to indeed make it bigger. I don't see how it would be pointless.

Palettes are simply indexes into RGB values.

You probably do not understand what you try to do. If you add new indexes to existing palette that are interpolation of old colors then you effective add only "decimal" parts to colors.
e.g.

If I add new bite to palette and interpreter it as new "color", then number of row will double, and each new one can behave in unique way.
This is same if to number 99. add 9 on front and get 999.

Now you want only expand number of elements in row, and each new value depend strictly on old ones.
This is same if you to number 99. add 9 on end, like 99.9

Now problem is that human eye can only see differences (I mean in abstract way) bigger than 0.2, this is why JPG or PNG can compress files 10 or more times because they throw away all .999 that take lot of space in file but do not affect much our perception.

This is way your approach is useless as do work opposite that PNG do.


I don't care about the blitting code, it is more a nuisance/hinder and it sits in the way of doing special vga/color effects. I also discover the rendering is quite fast on todays CPUs even with setpixel and getpixel. Blitting might have been nice/fast in ms-dos days, but it seems to be of little use in 2022.

Do you care about OXC anyway? Current blitting code is fundamental part of OXC feel. Beside, current OXC blitting can in theory use vector instructions and this is order of magnitude faster than `getPixel`.


The current 8 bit palette causes visible "banding", where the transition from one shade of color to the next is clearly visible by "circle like patterns" known as banding. So here there is a clear oppertunity to make the banding less severe.


Problems like this was already solved long time ago in OXC, do you notice any banding on globe?

For an initial try of this idea the performance is somewhat irrelevant, first the idea should be tried to see if it makes x-com look good and better.

However the performance won't be so bad because the following code/formulas can be used:


OXC right now have performance problems on big resolution and big maps, and you want make it worse?
This is game not slideshow.


Because of these very serious limitations, I am convinced that more should be possible with a bigger palette. Extra colors could also be added to make it go fully to dark/blackness at the end of each row. Or even better, invert the palette so that each row starts at zero color rgb values for a more intuitive palette. This would also make the computations easier, add 15 then don't have to be done, and subtracting the shade value would just be an add.
I think you confuse yourself when trying understating curter blitting logic and even make result it look worse, you will have always check if offset do not overflow, this mean you can't avoid it, and adding "dark" on any end of this will not help with this.

Current code (OXCE version) handle this very simply:
Code: [Select]
const Uint8 newShade = src + shade;
if ((newShade ^ src) & 0xF0)
// so dark it would flip over to another color - make it black instead
dest = 0x0F;
else
dest = newShade;
By some compilers this even can get some vectorization. one `if` handle overflow of shade and add nice black pixel when it too dark.

Offline Solarius Scorch

  • Global Moderator
  • Commander
  • *****
  • Posts: 10459
  • WE MUST DISSENT
    • View Profile
    • Nocturmal Productions modding studio website
    • Email
Re: Bigger Palette idea.
« Reply #6 on: May 13, 2022, 08:45:23 pm »
OK, let me be that guy:

Why?

I've been modding OpenXCom for 8 years and never felt the need to do anything about the palette.

Offline Finnik

  • Colonel
  • ****
  • Posts: 383
  • Finnik#0257
    • View Profile
Re: Bigger Palette idea.
« Reply #7 on: May 14, 2022, 01:17:19 am »
Same here. People wanting more palette just cant draw pixel art. I'm not an artist myself, but I have a lot of communications with professional pixel artists, working on FtA. None of them complain palette limitations, considering we have CPAL system.

Online Skybuck

  • Colonel
  • ****
  • Posts: 167
    • View Profile
Re: Bigger Palette idea.
« Reply #8 on: May 14, 2022, 01:58:50 am »
VGA is easy to implement on top of RGB/true color/24 bit or 32 bit.

The VGA basically uses a palette of 3x256 bytes, but I don't care how many bytes it uses, in my head VGA is simply a lookup table of 256 entries and each entry is such high resolution color.

So basically:

struct TColor
{
   Uint8 r;
   Uint8 g;
   Uint8 b;
};

struct TVGAPalette
{
  TColor Entry[256];
};

Now to translate 8 bit indexes to 24 bit colors is very easy using a "lookup" table. Which looks up the index, fetches the RGB and puts the RGB onto the screen.

SpriteColor = GetPixel( X,Y );

TrueColor = VGAPallette[SpriteColor];

So your biggest question was: "Where to store the palette", the answer is, lol, simply in main RAM, where else lol... ok in the vga days it was stored in graphics card somewhere,sometimes, however even in those days, plenty of software stored the copies of the palette in RAM as well, to swap palettes when needed, even the real x-com might be doing this.

Anyway the real trick is converting the sprite 8 bit index, to some other index, perhaps 9, 10, 11, 12 bit, the bitness isn't that important, as long as it will fit in a 16 or 32 bit integer. CPUs seems to like 32 bit integers.

My suggestion is to multiply the 8 bit index times 4, which is the same as shifting it by 2. Perhaps something more might be nice too, the next step would be x8.

16x4 = 64 shades
16x8 = 128 shades
16x16 = 256 shades

The next step would be multiplieing by 16, which would be 2,4,8,16, shl 4.

More shades than 256 probably not necessary since true color only has 256 shades of red, then again I am not so sure if even 256 shades is enough, because it does seem to go from red to blue and such across the row... so perhaps even more shades might be required to fully shade it uniquely... this is an interesting test to check with a piece of code.

I consider this laptop quite old, it's from 2010, bought by mother/half sister in 2012... it runs this game fine on 1600x900, so what resolution runs slow according to you and on what hardware ?

I would like to use Delphi to continue some experimentation with OpenXCom it couls save me some time if I don't have to re-write lots of code to C/C++ plus it can use some Delphi specific language features which C/C++ are lacking which I find a very serious ommission in that language.

Especially Delphi properties is a big ommission in C/C++.

This is a very good point I am making. In Delphi I could write certain features/special effects much easier than in C/C++... At least so I believe for now ! ;)

For prototyping new ideas. Delphi is the way to go for me... not c/c++ shudder ;) Though recently I did have some fun with C/C++ but it's biggest feature "inlined variables" is now also available in Delphi, so language-wise Delphi is right on the heals of C/C++ when it comes to usefull features.

Granted the structures/classes in c/c++ are much more advanced and feel more complete than Delphi that's true. I like how c structures are basically as powerfull as classes, with references behind them. In delphi all classes are references which slows down code unfortunately, that's one performance aspect of Delphi I don't like.

I don't care about any other operating system, perhaps in future, for now consider my work, prototype stuff. Why would I try to prototype for some exotic hardware ? It's already difficult enough to get it working on PC.

Besides X-Com for me came out on PC... I didn't know about anything else... I doubt there were many ports at the time... but apperently there were some... playstation later apperently... for me there is only one true x-com... the ms-dos x-com the way it was ment to be played and now openxcom which continues it's legacy/graphics/files, perhaps not entirely gameplay but you guys sure trying and maybe even making it a bit more interesting with mods and weapons, that's cool.

Perhaps I try points or lines or quads in OpenGL, perhaps textures, if that blinks in software mode with v-sync, or is too slow, then maybe I abort this idea... or maybe sdl has some 24 bit mode ?

Delphi also has some 24 bit mode/canvas which could come in use...

It might be possible to just have the game render as usual, take the picture and covert it to a higher palette, perhaps then fill in special effects like better shading.

However if it's all done at once, perhaps the result might be a bit better or it might be required, then again depends on pipeline basically.

At least if the existing shade is disabled, then the existing graphics could be considered a 'bare bones' graphics painting and then later shading applied, could be an interesting technique to keep the original speed of the game, and then build the rest on top of it.

In case algorithms need to know about layers/depths and so forth a mask instead could be build which records that information per layer/z depth and so forth, it's not a bad idea, though it can get tricky at times with the sprites being slightly off vs voxels, maybe that problem be solved, not yet sure what exact cause of problem is, could be the ray traversing algorithm for now.

Not decimals parts, full unique colors, there is plenty of "room" between the existing colors.

It's not useless, I have programmed vga when I was 15 to know what I am doing, and also in true color. The only thing that truely matters is if the display can actually render true colors/24 bit. Very few monitors apperently can... they are something like 160.000 colors in reality, it should still be better than just 8 bit color palette though.

The blitting and vector code will make it difficult for less c/c++/asm experienced programmers to get involved with that section of code, so I highly recommend that you create alternative code paths that use "simple" code to do the "rendering"/"pixel processing" so that new pixel processing ideas can be tried out. It was for me the most difficult part to figure out, eventually more or less gave up on trying to understand the insanely abstract blitting code and simply replaced it with a simple getpixel/setpixel, that was way more effective to get me started than the insanely abstract blitting code, calling weird shade functions etc.

Globe does look kinda crap to me... on one hand it's all nice and everything, looks kinda like original, however the original was more "blocky and pointy" probably had less vertices. The shading on the globe... it's meh... at best... probably also caused by low palette quality. I find the globe the most boring part so far. Maybe some "bump mapping" could be added to it, to make it look a bit more interesting or some slightly changes in verteces heights on the globe... like mountains sticking out a little bit.

There are plenty of rows that don't fully end in darkness/blackness... extending those rows to go to full blackness seems interesting to me, it will surely make the map shade to dark better I think. If you believe otherwise than I respect your oppinion but to me it also seems like you come across like a noob, but maybe you know something that I don't :)

The only thing that worries me about the palette of x-com a little bit is that some colors/rows might drop off exponentially, but that is why I suggest interpolating those color ranges in between to keep some of that exponentiality and also the shading from yellow to red for example on row 1, or yellow to pink row 9.

If you don't not interpolate the palette, then this could be why your 24 bit color try/source code/branch might have failed ?!? and easy mistake/oversight to make. I would still be interested to look at your 24 bit color branch ? I thought you mentioned you tried ? How did you implement the 24 bit colors and how you work around SDL limits.

But the way, good thing I mention this.

Even with 8 bit colors, there might be a different way to simulate 24 bit true colors.

A different default palette could be chosen which choose colors best picked, 256 out of 16 million. Then dithering can be applied to "translate" the x-com ufo palette into dithered palette colors, very interesting idea if all else fails.

And this is where the power of bigger palettes and dithering comes in, especially on large monitors and smaller graphics this could be a pretty neat solution, since the pixels become very small, they start blending in the eyes of the viewer... so dithering can simulate the appearance of true color.

I notice banding when I tried my shading code, maybe check one of my videos, one of the recent ones, very noticeable, nothing I can do about that, except maybe dithering or using a bigger/better palette and true colors.

Not sure if your blitting code does anything special. I think it does, but perhaps not per pixel, except maybe shaders... it does seem to do bitmap overlap/intersection/clipping like this to not go outside of the screen, with mods and all kinds of other things, that makes it hard to understand.

SetPixel is easier to use/understand for now.

As far as the flipping around the other pixel colors, that can be avoided if the ranges stay within 0 to 15.... if ranges are carefully chosen then masking off is not necessary.

However with such few shades available choosing a base range of 0..4 and then a shade range on top of that from 5 to 15 gives limited ammounts of shading, might as well "shift it down all the way to zero" and even below zero... that is the disadventage of having so few shades... it kinda forces me to subtract and go below zero and thus branching or masking necessary to mask that off... also not convinced yet that masking off can handle negative cases but maybe would have to check two complements... but here it gets weird... you talk about porting code... are you sure your mask of will on systems with 1 complement ? :)

JPG uses dithering and other filty techniques to throw away information, not a suited topic for game clearity.

PNG on the other hand seems to be lossless format, but is more about run length encoding, don't see how this is relevant to screen quality of this game.
You mention compression, that is a completely different topic. What the eye can see is also debateable and can vary from human to human.

I know what I can see, I can see clear oppertunities to the colors/shades in this game, that is almost for sure ! =D

Don't get me wrong the game already looks pretty cool on hi-resolution, but I am sure on low resolution it can also look better and even on both.

Not trying to do that properly would be a very big missed oppertunity to make the game look better on todays hardware and monitors !

No need to maintain the spreading of 16. What matters is the spreading across the entire range, basically the idea of the original programmers/artists.... using more spread should make their idea come to life even more, if I am wrong then I would apologize for wasted time, but it's definetly worth a shot.

It's maybe same as games moving from CGA to EGA(?) or VGA... makes the game look better. Now those steps were huge, going from 8 bit vga to 24 bit will be more subtle but still somewhat noticeable, more pleasing tot he eye, that is why I am enthousiatic about it... it will be less severe then going from CGA to VGA... but more beautifull than VGA, most hopefully ! and people will be like: Why the fuck does OpenXCom look so good ? They might still believe it's in VGA mode, while in reality it's "secretly" using magic palette sauce to make it look better LOL.

Get it looking good first, then worry about performance... and start optimizing and re-coding, that is my suggestion for now, yes it requires more effect/time/energy, but at least getting some results quickly to see if it's worth doing "right"/"quick"/"optimized" is better, if it turns out it looks like shit then abort, if it looks great then proceed and try and get it working in real-time or find approx solutions that can appromixate it.

Online Skybuck

  • Colonel
  • ****
  • Posts: 167
    • View Profile
Re: Bigger Palette idea.
« Reply #9 on: May 14, 2022, 02:02:42 am »
Same here. People wanting more palette just cant draw pixel art. I'm not an artist myself, but I have a lot of communications with professional pixel artists, working on FtA. None of them complain palette limitations, considering we have CPAL system.

While you are artist, I am programmer, you have luxery of picking colors, that is all fine and all and I am sure you will do great job making it look great, but for a shading algorithm that is hard to do to pick just the right color. It has to spread the colors among a palette... the colors go from light to dark... and vice versa, if there is not enough subtle in this stepping process it will lead to banding... now I am not necessarily against banding... it gives it a nice retro/8 bit look and feel, but this is windows I am on... and it feels out of place on a 24 bit true color palette.

Besides I want to see what OpenXcom can do if it's using true color and better shading, there might even be some "glow" oppertunities in it... things that vga programmers could only dream of back in the vga days.

Basically OpenXcom plus the tech of nowadays could be "best of both worlds"... nice original palette colors picked, but enhanced with interpolation and more spread/range.

Artists can still pick the original palette and make 8 bit color images if they want, the software can interpolate it and make it look a bit better, or shade it and do it more granual...

Online Skybuck

  • Colonel
  • ****
  • Posts: 167
    • View Profile
Re: Bigger Palette idea.
« Reply #10 on: May 14, 2022, 02:05:49 am »
What is also cool is this can be configured and the algorithms made adeptive:

Want to keep the original 8 bit look and feel fine !

Want to try x2, x4, x8, x16 ! Fine that can be done as well !

So this can give best of both worlds... everybody happen, try out different things and see how it looks. Gotta give it a chance first ! =D

SDL does seem to support more than just 8 bits per pixel, 16, 24 and 32 is also mentioned at bottom of page:

https://www.libsdl.org/release/SDL-1.2.15/docs/html/video.html
« Last Edit: May 14, 2022, 02:20:20 am by Skybuck »

Offline Yankes

  • Commander
  • *****
  • Posts: 2677
    • View Profile
Re: Bigger Palette idea.
« Reply #11 on: May 14, 2022, 12:45:53 pm »
If you ignoring suggestion to make this useful for any one else then I do not see point in continue discussing this any more.

Online Skybuck

  • Colonel
  • ****
  • Posts: 167
    • View Profile
Re: Bigger Palette idea.
« Reply #12 on: May 14, 2022, 02:54:01 pm »
If you ignoring suggestion to make this useful for any one else then I do not see point in continue discussing this any more.

It can be implemented with SDL... see link above, so it can be usefull for others/cross platform.

Online Skybuck

  • Colonel
  • ****
  • Posts: 167
    • View Profile
Re: Bigger Palette idea.
« Reply #13 on: May 15, 2022, 01:16:20 am »
I wrote a special application in Delphi to analyze/inspect OpenXcom palette and extend/grow/scale it to a more advanced palette (so that each row has more shades available) with linear and cubic interpolation. The cubic interpolation needs a little bit more work, for begin and end sections, the end section might also be slighty buggy maybe ?! ;)

https://www.youtube.com/watch?v=myqxefLcoOo

Offline Finnik

  • Colonel
  • ****
  • Posts: 383
  • Finnik#0257
    • View Profile
Re: Bigger Palette idea.
« Reply #14 on: May 15, 2022, 12:47:56 pm »
Can you highlight it? It's 7 hours video!