Interesting note about initializing OpenGL

[leeor_net]

I've been running and testing and developing OutpostHD on several different computers lately and have noticed a couple of interesting things.

First, OutpostHD will have low requirements. Generally speaking, integrated GPU's (except Intel) will work fine and even on older hardware it runs great (I have a laptop from 2006 that runs it very well).

More interestingly though, I've noticed a pattern with startup times for the under the hood code that powers NAS2D. The longest time is spent initializing OpenGL and the GPU. On some older hardware you can watch as each individual phase is called made and output is generated for it including setting up an OpenGL device context, calling the various parameters to set up OpenGL into the proper rendering state and grabbing driver information. I never would have expected initializing OpenGL would take as long as it does.

[Arklon]

I have to ask, why use OpenGL? Obviously you'd probably want to use some cross-platform API, but what does hardware accelerated graphics do for a remake of a game with simple 2D graphics? Do you plan on making use of shaders or something? I noticed that NAS2D already has SDL as a dependency, but it looks like you're only using it for keyboard input. Why not just use that for the graphics? Especially if you're having issues with Intel iGPUs, which is the vast majority of the iGPU market.

[Hooman]

I'm not too surprised that initializing a graphics library takes a bit of time, but I'm curious what your actual numbers are. How much detail can you get on where the time is spent? There will be issues such as the number of system calls causing not entirely speedy context switches, talking to hardware, and of course initializing a frame buffer, which on modern 1080p displays has over 2 million pixels. Double that if you're using double buffering. Thankfully graphics hardware can handle the frame buffer part. There's also implications for how all this interacts with the windowing system of the OS. Of course I'm still expecting all of this to be sub-second.

Arklon, you bring up an interesting question. Of course, according to the SDL website, SDL uses OpenGL, so it'd still be using OpenGL:

Simple DirectMedia Layer is a cross-platform development library designed to provide low level access to audio, keyboard, mouse, joystick, and graphics hardware via OpenGL and Direct3D.

It might reduce the source code dependencies if the project relied only on SDL, and not OpenGL directly. The difference though is likely just whether or not you have OpenGL development headers installed, since the library might still be needed, (except on Windows where DirectX is an option).

[leeor_net]

I have to ask, why use OpenGL? ... <snip> ... I noticed that NAS2D already has SDL as a dependency, but it looks like you're only using it for keyboard input. Why not just use that for the graphics?

Originally NAS2D offered both a Software and a Hardware renderer... but as time went on we wanted to make use of shaders, something the software side simply couldn't keep up with. So we dumped it and focused on the OpenGL Renderer.

Do you plan on making use of shaders or something?

Yes. There is rudimentary support for GLSL shaders but it doesn't do much at all. I haven't had time to develop this side of the renderer.

Obviously you'd probably want to use some cross-platform API,

There were plans at some point for a DirectX renderer... something the user can basically switch between but that's in the future of NAS2D's development. But... seems like it's not really that necessary.

... but what does hardware accelerated graphics do for a remake of a game with simple 2D graphics?

Nothing. NAS2D wasn't developed for Outpost -- it was developed as a 2D game development framework with the intentions of a high performance 2D rendering engine. By taking advantage of modern GPU's you can provide visual effects that are either impossible or improbable with a software blitter. The GPU/Shader side of NAS2D isn't developed yet but it works very effectively for basic 2D games. Also, OpenGL make it very, very fast to render scenes without having to worry about dirty rectangles and all that jazz though modern computers would probably be able to blit 2D graphics with ease without dirty rects (LoM's original performance was very good with the software engine).

Why not just use that for the graphics? Especially if you're having issues with Intel iGPUs, which is the vast majority of the iGPU market.

Answered above but generally speaking I used SDL to do more than simply input. It also handles setting up an OpenGL context and window management, something that would make renderer code difficult to set up on many different platforms without writing platform dependent code -- SDL takes care of all of that so I don't have to.

As for Intel GPU's, I dunno. I have yet to find any that support an OpenGL 3.0 context and with what the NAS2D renderer does it kind of requires that especially if we want to support shaders. Now, it's entirely possible to offer options to allow for running on these kinds of GPU's and just ignore shaders and other calls that would break in non openGL 3.0 contexts but that's future development of NAS2D -- right now it runs on a majority of machines that offer anything other than an Intel GPU which is basically any computer that's 5+ years old and not less than $450 new.

On the other hand, if I find I have a significant portion of users that have Intel GPU's, it would encourage me to develop support for them.

It might reduce the source code dependencies...

Eh, not quite. It's about setting up rendering contexts on different window managers for different platforms. E.g., if I wanted to port NAS2D to, say, the PlayStation 2, I could with very little effort (would just need to add support for the filesystem) but SDL handles all the rest for me.

but I'm curious what your actual numbers are. How much detail can you get on where the time is spent?

I haven't thought to instrument this to actually see. I could use geDebugger to tell me that, really. Actually that program helped me cut my OpenGL calls in NAS2D by about 70% when we first put it together (the original OpenGL Renderer was very slow in the beginning. It's not bleeding edge now but it's definitely much, much more efficient).