Technical support > Linux

Video problem with 2.2.1 but not 2.1.1

<< < (2/3) > >>

BTAxis:
You seem to think someone just wrote #define 16_BIT 0 or something. It's not that simple. The renderer changes. New features, such as shaders or lighting are implemented. Sometimes that means something else breaks, like rendering in 16-bit color depth. Restoring it may not be as easy as it sounds, and it may not be worth pursuing that goal. So you should consider 32-bit color depth a new system requirement.

rwst:

--- Quote from: BTAxis on June 16, 2008, 02:43:05 pm ---You seem to think someone just wrote #define 16_BIT 0 or something. It's not that simple.
--- End quote ---
While it may not be easy to write a modular renderer, it may be easier to backport
other important changes to 2.1.1, for someone having the opinion that it's worth it.
When I'm fed up with 2.1.1 and still want to play the game, I'll look at this.

ralf

BTAxis:
Note that 2.2.1 is also quite old in terms of features when compared to 2.3. It would be bad if you managed to successfully backport the features to 2.1.1 only to have 2.3.0 make your work obsolete shortly afterwards.

You could look into making 2.3 trunk compatible with 16-bit color depth, though.

rwst:
Never mind! I just have finished compiling trunk and it works fine, just a bit sluggish, but
hey, this is a 1.5GHz Pentium-M that took 24h to create all maps.

Definitely worth it, though.

Thanks to all authors for this game,
rwst

rocketman:
I would just suggest that in the future, for the sanity of the developers, we cut down on sarcasm.  They put in a lot of effort to make the code base more capable.

A 32 bpp color range is a good thing.  :)  Endless backwards compatibility can be a programming nightmare.

Navigation

[0] Message Index

[#] Next page

[*] Previous page