WIP: Proper video scaling, sdl blitting, 32bpp resource support, etc.

[maxrd2]

Have done an experiment with scaling all resources to screen size immediately as they are loaded to improve size and look of the screen graphics.

Here is the progress of the planned changes:

• Base resolution in-game is increased from 640x480 to whatever is setup in json file, screen is setup in 32bpp
• All image resources when loaded are immediately decoded into 32bpp RGBA and scaled/interpolated proportionally to configured resolution
• Bitmap fonts are properly rendered
• Intro, Main menu, Options, Credits screens are scaled and working/looking properly
• Strategic interface screen is scaled and working/looking properly
• Tactical interface screen is scaled and working/looking properly
• Laptop screen is scaled and working/looking properly
• All blitting functions are reworked to use 32bpp
• Ability to dump loaded and scaled resources into png files into some path (so some artist could edit them and make them look better on higher res)
• Ability to override loading of official resources (if png file is found in override path it's loaded instead of official res)
• Add support for freetype fonts.
• Replace all/most blit code with SDL function calls and load resources as SDL textures

Am not sure if SDL 2D allows for z buffers which are used for blits on tactical map.

Anyone has any thoughts on this? Is this something you guys wanted to implement at some point?

[lynxlynxlynx]

Hmm, how will this differ from the scaling SDL2 already provides us? Eg. start in windowed mode and just maximize the window.

Either way, I like the idea of highres file override options.

[maxrd2]

Scaling should be better quality and different parts of screen can be scaled with different ratio.
eg on tactical screen buttons below can be scaled by 1.5 and tiles by 2.0, or what ever looks best

[maxrd2]

This is becoming a big chunk of changes.
Should i separate this in two pull requests, so there will be less stuff to review?

First part of commits upto "Removed useless defines." f8ecb2d is all about rewriting blit code, adding support for 32bpp and making everything looks nice. And it works fine without later commits.

Later ones handle change of coordinates where everything is drawn on screen and how much it's scaled. And they touch code everywhere, but aren't big changes.

Have also separated cosmetic code changes and cleanups from functional changes into different commits.
There are still some minor issues, that i will fixup into existing commits during next days.

BTW have found few buffer overruns in blit code that became serious as buffers grew/changed size.
RestoreBackgroundRects/SaveBackgroundRects() using incorrect pitch values, and as soon as some SDL allocates surface that has width * bytes_per_pixel != pitch, blit functions will start overwriting memory all over the place. Want me to make a patch for that in separate commit? Am not sure if someone reported crashes just on some video cards/drivers.

[lynxlynxlynx]

Yes please!

[lynxlynxlynx]

Hey @maxrd2 is the TODO in the first post still up to date? If so, did you plan to finalize the changes? Besides the laptop&tactical items, most of the remaining look like bonuses that could be done separately, later.

The current conflict is trivial, but these things are best solved by a timely merge into master. :)

[maxrd2]

Yes I plan to finish these, and yes wanted to merge them before completing everything, once all interface changes/fixes are done and game is usable/looks good.
I haven't pushed all the changes I have done yet, as I have run into one bug on Tactical interface (which is mostly completed otherwise) that looks like timing (race condition) issue that was already mentioned/fixed in the past. I wanted to figure that one and fix it properly before proceeding.
Am not sure how close I am to a version that can/should be merged to master.

EDIT: have rebased to current master, will try to get that issues investigated/solved this weekend and get rest of the changes completed ASAP so it can be merged.

[lynxlynxlynx]

Why not just delete them?

[maxrd2]

I kept all obsolete coordinate defines commented out like this... in case something somewhere uses hardcoded 11 or -2 (because there are a lot of places that do that when calculating coordinates) so it's easier to find it. Once I'm done with all the changes will go through commits and remove ugly stuff like this.

[lynxlynxlynx]

Great, thanks! And holy carp, I forgot what a gargantuan effort this was — practically unreviewable. Still, I tried, lightly, though I admit that I didn't check all the files. One benchmark of the completeness of the changeset is how many of your own fixmes remain in the final version.

We're thinking of speeding up the next release, but this is more like something that we'd merge right at the start of a cycle, so little cuts can get patched over. If there are few, we can always make a new release quickly.

[maxrd2]

I have rebased to current master.

It compiles, it runs and it's not looking right.

Some time ago these changes were all looking right and now they're not.
To be sure it's all ok and ready for merge I should restart for the n-th time and recheck all code and changes I did, re-fix the tactical palette and rendering that got broken due to some minor refactoring somewhere.
I should re-test and fix again all the coordinates that were already good in ~1000 places and then I can continue to where I left off the last time to complete last 1%.

During all that I should hope that nothing will change on master that will again undo all the work and time invested.

I'm sorry everyone I just don't have the will to do that in the foreseeable future - if anyone wants to pick up and continue where I left please do.

• tactical rendering menu's actions and bottom panel was rendering fine - there was some change to coordinates on master that borked that - once it's debugged and discovered it should start looking/working ok again

• soldiers having bad colors is due to original paletted sprites have used the palette to change skin/hair/clothing color - since all resources are upscaled and converted to 32bit at load time - i did hack to upscale original resource with changed palette on each character render - due to some changes to palette on master this is borked now, and had to undo the hack as it wasn't compiling

• there are still some UI coordinates on laptop screens that needs to be corrected/multiplied

• coordinates on map editor will need to be fixed too - I planned to just use low/original resolution there for time being

• have thought of step 2 where all of the tactical rendering would be replaced with opengl shaders - tiles and characters would become textures and above hack could be undone then - this would also allow to replace some 2d blits with real 3d objects - eg if wanted characters/tiles could become 3d textured and shaded objects

[lynxlynxlynx]

It was naive to think the codebase would remain the same for 5 years. Thanks for the work either way, it's still salvageable.

[maxrd2]

It was naive to think the codebase would remain the same for 5 years. Thanks for the work either way, it's still salvageable.

5 years would be naive yes. Few months not so much.