Author Topic: NEW PLAN: MINI X-COM  (Read 3993 times)

Offline Skybuck

  • Colonel
  • ****
  • Posts: 223
    • View Profile
NEW PLAN: MINI X-COM
« on: May 23, 2022, 07:08:01 pm »
Monday 23 may 2022:

*** Last update: Sunday 5 june 2022 ***
*** Latest miniXcom branch: ***
https://github.com/SkybuckFlying/OpenXcom/tree/miniXcomV2


AFTER THINKING ABOUT ALL THE PROBLEMS THAT I ENCOUNTERED WITH VISUAL STUDIO 2019 AND X-COM I HAVE COME TO THE FOLLOWING NEW PLAN:

MINI X-COM !!!!!!!!!!!!!!!

ALL THAT GARBAGE I DON'T NEED GOING TO BE RIPPED OUT OF IT:

1. GEOSCAPE
2. UFOPEDIA
3. BASESCAPE (not to be confused with BATTLEscape)

AND OTHER CRAP.

IT'S GOING TO BE FOCUSED ON BATTLESCAPE ONLY, SO THAT I CAN WORK ON MY SHADING/LIGHT CASTING BETTER.

AND ONCE THAT IS DONE IT CAN BE RE-INTEGRATED INTO THE BIGGER OPEN-XCOM.

SUCCESS, geoscape, basescape and ufopaedia deleted and game/battlescape still working ! =D

This means 18% of the source code is "cut" away, thus lowering compile time.

github branch
https://github.com/SkybuckFlying/OpenXcom/tree/miniXcom

video:
https://www.youtube.com/watch?v=tqd2vUYe5-Y
« Last Edit: June 05, 2022, 05:28:57 pm by Skybuck »

Offline Skybuck

  • Colonel
  • ****
  • Posts: 223
    • View Profile
Re: NEW PLAN: MINI X-COM
« Reply #1 on: May 25, 2022, 11:55:07 am »
Wednesday 25 may 2022 spent 12 hours trying to reduce miniXcom further, restructured some files. Discovered many stupid things with visual studio and somewhat c/c++, very bad language, very bad development tools, enormous waste of time. Highly recommend re-write project in Delphi like original X-Com was made in Borland Pascal, but you guess probably won't do that.

Anyway next few days, I might try again to get compile time further done..
« Last Edit: June 05, 2022, 05:25:24 pm by Skybuck »

Offline Skybuck

  • Colonel
  • ****
  • Posts: 223
    • View Profile
Re: NEW PLAN: MINI X-COM
« Reply #2 on: May 30, 2022, 05:41:17 am »
Monday 30 may 2022, spent roughly 4 hours or so, trying out a surface modification for true color support. Access violations. Better to leave openxcom's surface the way it is and perhaps convert to SDL surface where needed. Somewhat confusing that there are two surfaces classes, one openxcom wrapper vs sdl surface.
« Last Edit: June 05, 2022, 05:25:00 pm by Skybuck »

Offline Skybuck

  • Colonel
  • ****
  • Posts: 223
    • View Profile
Re: NEW PLAN: MINI X-COM
« Reply #3 on: May 30, 2022, 09:44:11 pm »
Monday 30 may 2022, spent another 5 hours trying to get 32 bit mode working, shame that it's such a pain in the ass. This is where SDL completely fails as far as I am concerned, it should make it easy, instead it makes it incredibly hard. Though the code base is huge but still...

Branch with most succcess was here: https://github.com/SkybuckFlying/OpenXcom/tree/TryCustomBlit 

This code base/situation give me a slight headache ! haha ! VGA in it's day was super simple, this SDL turns it into a nightmare. Though some cropping code to blame possibly as well... hmmm.... Also running into strange visual studio compiler issues from time to time, it fails to recompile files properly from time to time, very low quality development environement in many ways. The replace all in files functionality is nice though.
« Last Edit: June 05, 2022, 05:24:52 pm by Skybuck »

Offline Skybuck

  • Colonel
  • ****
  • Posts: 223
    • View Profile
Re: NEW PLAN: MINI X-COM
« Reply #4 on: June 03, 2022, 03:49:31 am »
Friday 3 june 2022: (6 hours spent) Modified OpenXcom Palette Analyzer to load palettes directly from original UFO/game folder, also implemented 6 bit to 8 bit converted. Discovered and fixed a bug where R,B,G was being used instead of R,G,B. Wrote a x-com screen loader + background palette loader (+ xcom palette loader). Investigated ideas how to make OpenXcom work with 32 bit screen and/or surfaces. Hypothesized that SSE code was the problem and the cause of bugs/crashes and wrong rendering. Decided to investigate further and disabled SSE in zoom.cpp. This fixes part of the problem. Even the default/sse-less code seems buggy. Disabling zoom code can make the game work well in 32 bit, if bpp set to 32 bit.
In screen.cpp this code would need to be disabled. (Then I ran into an audio chip/driver bug/hang so cannot test the game further right now, but I tested enough to know that most likely the game can run in 32 bit true color. I should still investigate further now (after reboot) or tomorrow, to see if pixelformat is indeed 32 and if gradients render nicely the ultimately test ! ;)):

// change surface to 32 bit in screen.cpp:
Code: [Select]
void Screen::resetDisplay(bool resetVideo)
{
...
...
...
// _surface = new Surface(_baseWidth, _baseHeight, 0, 0, Screen::use32bitScaler() ? 32 : 8); // only HQX/XBRZ needs 32bpp for this surface; the OpenGL class has its own 32bpp buffer
_surface = new Surface(_baseWidth, _baseHeight, 0, 0, 32); // only HQX/XBRZ needs 32bpp for this surface; the OpenGL class has its own 32bpp buffer
...
...
...
}



// zoom.cpp: disable this code:
Code: [Select]
bool Zoom::haveSSE2()
{
...
...
...
// return (CPUInfo[3] & 0x04000000) ? true : false;
return false;
}

// screen.cpp: disable this code:
Code: [Select]
// if (getWidth() != _baseWidth || getHeight() != _baseHeight || useOpenGL())
// {
// Zoom::flipWithZoom(_surface->getSurface(), _screen, _topBlackBand, _bottomBlackBand, _leftBlackBand, _rightBlackBand, &glOutput);
// }
// else

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

This is kinda cool, it was ment to be, galactic interference: =D

https://www.theguardian.com/science/2022/jun/02/rare-sight-for-amateur-astronomers-as-five-planets-align
« Last Edit: June 05, 2022, 05:24:39 pm by Skybuck »

Offline Skybuck

  • Colonel
  • ****
  • Posts: 223
    • View Profile
Re: NEW PLAN: MINI X-COM
« Reply #5 on: June 05, 2022, 03:00:52 am »
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
« Last Edit: June 05, 2022, 05:24:26 pm by Skybuck »

Offline Skybuck

  • Colonel
  • ****
  • Posts: 223
    • View Profile
Re: NEW PLAN: MINI X-COM
« Reply #6 on: June 05, 2022, 05:23:19 pm »
Sunday 5 june 2022 (1 hour 37 mins spent)  jokingly called it 'C++ Appreciation day' but it really is C++ destruction day ! =D
0. Move ufo folder/game files to "C:\Users\new\Documents\OpenXcom", so copy to source code/bin folder is no longer necessary. DONE. SUCCESS.
1. Remove scalars. DONE. SUCCESS. (menu options and some "useScalars32bit" or something code could also still be removed)
2. Remove Flc/Flv player. (This should get rid of the microprose logo which is no longer relevant as far as I am concerned :P*) DONE. SUCCESS.
3. Remove PNG. DONE. SUCCESS. (Additional code for saving voxels, screenshot, F11/F12, etc, could also be removed ).

(All removes commited on seperate branches based of miniXcom)
(All removes integrated into miniXcomV2)
https://github.com/SkybuckFlying/OpenXcom/tree/miniXcomV2

--- ^ This was the easy part ^ ---
https://www.youtube.com/watch?v=TUkicXpyRFo

Perhaps later today, I do some more work on miniXcom... with the more tricky bits...