Saturday 4 june to Sunday 5 june 2022: (11 hours and 30 mins spent) Described new Advanced image processing algorithm idea, and investigated gimp and inkscape software and palette support in gimp, experimented with gradients in gimp. Thought about if it's possible to implement real-time interpolation and even extrapolation for OpenXcom, described potential performance problems and potential solutions. Right now main problem is trying to avoid "T" computation for color interpolation. A fast interpolation method was found for shift values, integer based. It's pretty accurate compared to double computations at least by looking at it with the eye... however, it doesn't solve the problem because a division is needed to convert larger palette index to 8 bit palette index, because column width would be 450, number of entries per palette row basically, which unfortunately is not a power of 2.
So there are a number of possibilities that exist as far as I can see:
1. Either do an expensive division per pixel to convert it from 13 bit down to 8 bit and then calculate interpolation in real time, this would allow even higher bits per component in case 48 bit or 64 bit monitors are used where lookup tables would become to large to fit inside L1 cpu cache
2. Use lookup table, though at a shift value of 5, it would be 7200 x 3 = pretty big look up table. A more conservative value of shift = 4 could be used as well... but I want to stick with 5 for now, hopefully it not be too bad. should still fit in L1 cache.
3. Find a different advanced palette size, where colum count is a power of 2 and where the shift value (= multiplier) inside interpolation routine can also remain a power of 2.
4. Concerning point 3, extrapolation slots/entries could be used in 3 to increase the palette size from 7200 to 8192 to create a new power of 2 palette. This would give 31 extrapolation colors... for example 16 on top and 15 on bottom could be possible, or an different distribution... maybe spent more color slots on top of color range, to extrapolate colors towards white, cause they start quite low on the r,g,b spectrum....
Well time flew... investigating this matter, had quite some fun with gimp and a little bit with inkscape... was worth it a little bit, inkscape is cool software definetly try it out if you have not done so and are a graphics artist !
vector graphics software !
11 hour session:
https://www.youtube.com/watch?v=UsKswf7BvBQ(I kinda want to continue (and do something in c/c++ openXcom, some testing) but maybe time for a break, mostly quited because of youtube 12 hour limit and have to go eat)
*Addition*, being not quite statifies, I quickly investigate if map is now 32 bit colors, but unfortunately it is not, and if trying to set it to 32 bit by modifieing interactive surface, the arrow->setPalette( getPalette ) is setting a null pointer and thus game crashes.
So still more work needs to be done, to try and get the game working in 32 bit... would be nice to have a 32 bit map surface...
35 minutes spent, investigating this:
https://www.youtube.com/watch?v=QUzlGdXXTB8