opengl

[Daiky]

This is not really a suggestion, as I'm already working on it (in my own sandbox not in the official openxcom repository): people that are on IRC already know all of this, they are already totally bored with my rambling.
But I just wanted the forums opinion or comments too, regarding the implementation of it.

So the idea is to keep support for SDL, Pallettes, 8bit graphics, software blitting, 320x200 - the oldskool stuff.
But on top of that have the option for OpenGL, truecolor graphics, hardware blitting and higher resolutions.

Apart from the differences in intialisation, support for both opengl/sdl is done by abstracting the Surface class and creating two new implementations: SDLSurface and OGLSurface. The second one will load the surfaces as textures into video memory: blitting (and shading) surfaces will be done in video memory. (when it makes sense, because video memory has its limits)
New blitting functions, text & simple geometry rendering functions will have to be written in openGL versions.

I got the basic lines and pieces of code for the most part. I must give credit to the FIFE engine for it, as I take a lot of inspiration from there.
For testing I'm currently using UFO:TTS's graphics (which I converted to PNG, because I wanted to make sure SDL could handle that format also).

On the geoscape part we got another fun new toy to play with: drawing teh globe in opengl. In theory it would dramatically simplify the globe code (also the shading of the day/night cycle, which could be done simply by adding a rotating light to the scene), while dramatically increase the fps.
However I did not try anything on that front yet... it's just theory and ideas.

[Volutar]

Making oxc opengl-driven is definitely very good idea. I was thinking about rendering sprites as emposters long time ago. Lighting/shade could look much smoother. There is only one difficulty with rendering sprites via opengl - unshadable palette parts, like Alien entertainmebt, or ellerium modules, which are illuminated, but only partly. They should be "splitted" by two layers - shadable and not shadable with colorfiltering on "loading" stage. So it's not that hard.
Oldschoolish look could be achieved with nearest neighbour texture filter.
I really will be looking forward for updates in this direction.
Opengl is really easy to use, and on some point project might be switched into real 3d.

Cheers!

[luke83]

Sounds good to me , well the parts my non programmer brain can understand

[Yankes]

i think best solution will be separate game form graphic, something like client-server approach.
this will allow to add new graphic engines without changing game logic.
we could ended with couple different "games":
a) classic graphic
b) opengl enhanced
c) full 3d
d) 2d with z-buffer*

* every graphic in battlescape will get height map (stored as simple image), and when you blit two surfaces, pixel will be drawn only then his height is bigger than height of current one.
this will allow to draw solder inside tall grass not on top of it.

[Daiky]

That sounds a bit too advanced to me... Any examples of opensource projects that did what you described Yankes?

[Yankes]

That sounds a bit too advanced to me... Any examples of opensource projects that did what you described Yankes?

openXcom in future?
i probably like too much advanced things :>

[michal]

Well, i guess something like Model - View - Controller could be used for that.

Anyway i think it is overkill to have different views. Instead there could be:

- OpenXcom 1.0 - SDL
- OpenXcom 2.0 - Opengl 2d
- OpenXcom 3.0 - Opengl 3d

[Volutar]

I'd vote for opengl with both my hands. Actually I was aiming myself for replicating ufo defence code (including original AI) but with opengl graphics. Firstly - with billboards, simulating classic graphics (orthographic projection). And then - full 3d.

[sir_nacnud]

This is not really a suggestion, as I'm already working on it (in my own sandbox not in the official openxcom repository): people that are on IRC already know all of this, they are already totally bored with my rambling.
But I just wanted the forums opinion or comments too, regarding the implementation of it.

So the idea is to keep support for SDL, Pallettes, 8bit graphics, software blitting, 320x200 - the oldskool stuff.
But on top of that have the option for OpenGL, truecolor graphics, hardware blitting and higher resolutions.

Apart from the differences in intialisation, support for both opengl/sdl is done by abstracting the Surface class and creating two new implementations: SDLSurface and OGLSurface. The second one will load the surfaces as textures into video memory: blitting (and shading) surfaces will be done in video memory. (when it makes sense, because video memory has its limits)
New blitting functions, text & simple geometry rendering functions will have to be written in openGL versions.

I got the basic lines and pieces of code for the most part. I must give credit to the FIFE engine for it, as I take a lot of inspiration from there.
For testing I'm currently using UFO:TTS's graphics (which I converted to PNG, because I wanted to make sure SDL could handle that format also).

On the geoscape part we got another fun new toy to play with: drawing teh globe in opengl. In theory it would dramatically simplify the globe code (also the shading of the day/night cycle, which could be done simply by adding a rotating light to the scene), while dramatically increase the fps.
However I did not try anything on that front yet... it's just theory and ideas.

How are you going to handle palette rendering under OpenGL?  Building up a bunch of smaller buffers via software rendering, then uploading them as textures will be slow for higher resolutions.

When I was thinking about how to use OpenGL as a rendering backend, I found a couple of articles about talking about how to implement palette rendering.  The thought was you would have two textures, one that is 8 bit containing a color index for each texel, and the other of higher bit depth, containing your color values.  You then write a pixel shader that did the look up of the color index for the current texel in the color value texture.  I never did get around to implementing it, so I don't know how it would perform.

[SupSuper]

I am definitely a supporter of an OpenGL graphics backend, the only reason I've used SDL graphics is because it's incredibly easy and simulates 8bpp graphics well (if slow), and I don't know how to do the same in OpenGL. There must be a way though, every emulator does it.

I agree with michal that in the end it would probably be best to have everything rendered in OpenGL (once it has no disadvantages over SDL rendering), both retro and modern. Supporting various graphics APIs would become a maintenance nightmare.

NOTE: In this context I'm referring just to the "SDL graphics backend", not the whole SDL library. Obviously we'd still use SDL but with OpenGL graphics on top.

[Volutar]

How are you going to handle palette rendering under OpenGL?  Building up a bunch of smaller buffers via software rendering, then uploading them as textures will be slow for higher resolutions.

Graphics bitdepth converting could be done on-the-fly during resource loading. Paletted/not paletted actually doesn't matter.
Actually UFO1/2 doesn't have any of palette "scrolling" effects. DogFight stage done with simple re-drawing, battlescape "alien entertainment" tiles or any other animated things - same. Game palette is absolutely stable. Moreover, having opengl lighting on our side will heavily accelerate rendering, especially during "night" missions. I believe Daiky started this suggest topic after realizing UGLINESS of sdl cached tiles approach for number of shades (fight for fps). OpenGL would made it much nicer.
Basically, rendering could be done in "orthographic" view, with pixel-accurate rendering (with or without scaling), and would look as much as the original XCOM.

[michal]

How are you going to handle palette rendering under OpenGL?  Building up a bunch of smaller buffers via software rendering, then uploading them as textures will be slow for higher resolutions.

Graphics bitdepth converting could be done on-the-fly during resource loading. Paletted/not paletted actually doesn't matter.

Exactly - that's how Ufo: TTS works. But it uses converted images, OpenXcom could just use palletes during image loading.

Also, going from 8bpp to (for example) 32bpp will allow gfx packs (if someone implement that in future) with much better quality. For example such pictures could be used for ufopaedia (taken from https://ufotts.ninex.info/forum/index.php?topic=1101.0):

[Daiky]

I agree with michal that in the end it would probably be best to have everything rendered in OpenGL (once it has no disadvantages over SDL rendering), both retro and modern. Supporting various graphics APIs would become a maintenance nightmare.

Shouldn't there be a backup option if your system does not support OpenGL (properly)?

Also if switching entirely to OpenGL is the way to go, there is no reason to first waste time on implementing a system that can support both and then throwing all that code away to go back to a system that only supports one of them...

[michal]

I think it would be post to support both. But i can live with only opengl support. I've seen many 2d games, which requires opengl. For example https://blog.naev.org/

On the othere side, openxcom can also be played on amigas for example - i'm not sure how they handle opengl.

[Volutar]

Amigas?? which amigas?

Support for all kind of platforms will cause many limitations.