Switch to true 24 bit (or 32 bit ) color ?

[Skybuck]

Too much code to compare to see why master is working and the 32 bit surface branch is not working, yaml link errors, stack overflow mention some versions of yaml has link problems, perhaps that's it.

[Skybuck]

2015 openxcom version has problems:

1>MSVCRTD.lib(initializers.obj) : warning LNK4098: defaultlib 'msvcrt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library
1>Ufo.obj : error LNK2001: unresolved external symbol "public: static class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > YAML::detail::node_data::empty_scalar" (?empty_scalar@node_data@detail@YAML@@2V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@A)
1>Vehicle.obj : error LNK2001: unresolved external symbol "public: static class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > YAML::detail::node_data::empty_scalar" (?empty_scalar@node_data@detail@YAML@@2V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@A)
1>Waypoint.obj : error LNK2001: unresolved external symbol "public: static class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > YAML::detail::node_data::empty_scalar" (?empty_scalar@node_data@detail@YAML@@2V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@A)
1>WeightedOptions.obj : error LNK2001: unresolved external symbol "public: static class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > YAML::detail::node_data::empty_scalar" (?empty_scalar@node_data@detail@YAML@@2V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@A)
1>Target.obj : error LNK2001: unresolved external symbol "public: static class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > YAML::detail::node_data::empty_scalar" (?empty_scalar@node_data@detail@YAML@@2V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@A)
1>TerrorSite.obj : error LNK2001: unresolved ext

This sucks hard:

https://stackoverflow.com/questions/3007312/resolving-lnk4098-defaultlib-msvcrt-conflicts-with

Not sure if this is main issue, cannot get yaml working as well ?!

Not including 2015 dependencies in GIT is apperently a major mistake ?!?!?!?

[Skybuck]

Solution found for OpeXcom main/vanilla master branch (also my miniXcom branch can do it, tested on it, which has geoscape, basescape and ufopedia removed for faster compile times ):

(Main problem is zoom.cpp and scalars/SSE/SIMD code and flipWithZoom. Disabling SSE and Disabling flipWithZoom solves the problem for now, but loses some zoom functionality, game can still be run in different resolutions though and zoom options do have some effect on it like original x 2 or full display.)

// 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

[Skybuck]

I was kinda hoping that these changes would be enough. I was hoping the game would automatically create a 32 bit map.cpp. But it doesn't do that.

Trying to set it manually to 32 bit, but modifieing interactive surface, causes arrow->set palette( getpalette something) to crash because the palette is null in map::init.

So same problems as before, but now going through them apperently a step at time, very unfortunately reality.

Screen.cpp has some 'deferredPalette' for setPalette perhaps it can help... perhaps even a generic setPalette with deferred palette could be created to provide a generic solution for these kind of problems.

Or perhaps 5 global variables could be used, where in each the palettes for the game are stored and reference those instead of passing palette pointers around.

Instead each control just has to remember which palette number it should use... However this does not yet account for TFTD and/or mods which might have different palettes...

Futher investigations into how palettes are passed around and loaded initially might be required to shed some more light on this...