OpenGL renderer for hardware acceleration

[thefiddler]

Hi all, new poster / user here.

 

I an effort to make my favorite games a little more compatible with modern / high-resolution systems, I am interested in contributing an OpenGL renderer for GemRB. From a quick glance through the source code, writing a simple GLVideoDriver modeled after SDLVideoDriver should be feasible, if not very efficient. Extracting extra performance is going to take some work and creating an Android-compatible renderer (OpenGL ES) is going to be rather more complicated.

 

For now, I'm trying to setup a development environment I'm happy with. I'm getting some trouble compiling with Xcode (bug report here) so if someone has any ideas on that it would be helpful. Do the developers have a preferred environment?

 

 

Additionally, are there any good resources on how Infinity Engine graphics work? IIRC (and I may be completely wrong here), IE has sprites, animations and backgrounds - are these represented by Sprite2D instances in GemRB? Also, does GemRB use paletted sprites? (that's going to be a little tricky to handle)

 

 

 

What I have in mind is to implement a texture atlas system for sprites to extract some extra performance from the gpu. Without this, and given the 2d-centric approach of IE, I have a feeling that most of the time will be spent binding/unbinding textures in the OpenGL driver and that's never good.

 

Finally, is there some kind of mailing list for more technical questions or should I just ask them here?

 

 

Any other pointers or ideas welcome!

[lynx]

welcome!

 

This forum is ok for nitty-gritty details too, but they're usually resolved on our irc channel (#gemrb on freenode). You are not the first one to think about an opengl renderer, but you seem to have already grasped most of the caveats. The people to talk to are brada (SyntaxError here), fuzzie and wjp. Brad is also the mac maintainer, the rest of us save one are on linux, with likely little IDE overlap. There are not many docs about the graphics system of the originals, save for the reverse-engineered format docs on IESDP (which we implement in various plugins).

[SyntaxError]

there is a supplied xcode project in the apple directory; use that instead of generating one with cmake.

 

IMO the best path for hardware acceleration would be to use SDL2. We have discussed it ad nauseam in IRC and there are design challenges that need to be satisfied before moving forward with any type of hardware acceleration. (Join the channel and I'll tell you all about it).

 

we have a a solution for emulating palettes with textures too.

[thefiddler]

Indeed, the xcode project in the apple directory works fine. For some strange reason I thought that was iOS-only. It might be useful to add a note in the "Compile it yourself" section in the wiki, as that only mentions cmake builds.

 

I'm still having some trouble getting my build to work (fails to find chitin.key and segfaults in freetype2 after the second try). I'm probably missing something obvious, I'll read up some more and try to sort this out tomorrow.

 

I spent some time skimming the code during my train trip to work. Apparently SDLVideoDriver is handling both windowing and rendering? Some sort of split between the two would help keep things saner (same windowing code, different renderer). I think this should be doable within the SDLVideoDriver plugin with no changes to the Video interface.

 

How stable is SDL2 these days? I stopped following its development a while back, does it still retain its '90s-inspired rendering API? (blitting, stretching, rotating) I would like, at the very least, to add the capacity for post-processing shaders - which is why I mentioned plain OpenGL. I have bicubic, lanczos and xBR shaders that should work beautifully with IE-style graphics.

 

8-bit sprites usually map to indirect lookups via a texture+shader or expansion to 32-bits. The optimal approach depends on whether IE uses palette effects/animations, I don't think it does?

 

I'll try to hit you up on #gemrb, timezone differences and free time allowing.

[SyntaxError]

Apparently SDLVideoDriver is handling both windowing and rendering? Some sort of split between the two would help keep things saner (same windowing code, different renderer)

 

no point in this when using SDL. SDL2 has a very simple API rendering that will work fine for what we need. SDL2 is quite stable these days and really a good choice for us since the primary beneficiaries would be iOS/Android and we MUST have support for them in a hardware accelerated way as the software rendering we use now is insufficient for most android devices. Also much of the work for SDL2 rendering I have already done (most is still in my private repo)

 

really shaders are the missing piece, but we need to rewrite some classes such as the sprite class so that it can be abstracted into software and hardware etc. Nothing too complicated just a tedious hassle.

 

please do drop by on IRC.