Hi there.

I'm doing a new library for doing all that boring platform specific stuff for creating window, OpenGL context, and handling events. I was dissatisfied with quality of existing libraries (some common issues: feature bloat, broken Alt+Tab, no mouse raw input, no support for OpenGL >= 3.0, etc.), that's why I've decided to make my own.

It has the following goals:
* Do one thing and do it well (UNIX philosophy). Do not try to do anything besides platform-specific part.
* Do not reinvent the wheel whenever possible. Do not reimplement things, where production-quality open source implementation exists. So, I'm not going to include stuff like files, threads, etc, because there are boost and POCO.
* Simple design.

Features:
* Window creation and manipulation.
* OpenGL context creation, including version 3.0 and higher contexts.
* Fullscreen support.
* Event handling.
* Raw mouse input.
* High precision timer.
* Application switch friendly (Alt+Tab support).

License: MIT.

Website: [link]

I'm looking for interested people to help me with Mac OS X port (and other things, see "How to contribute") section.

Quote:Original post by swiftcoder

Quote:There is no support for switching video modes, because game shouldn't do that at all. Video mode configuration should be left to user. If you need to reduce render output size because of performance problems, you should create FBO of smaller size, render to it, and then blit to the actual backbuffer. Games usually use post-processing effects, so that FBO exist anyway.

So you are trying to be better than existing libraries in this area, but you are going to make the same pedantic choice they all make?

Pretty much every commercial game I have ever played allows the user to switch the resolution, and to toggle between fullscreen and windowed mode. Yet to do this with SDL/GLFW/SFML I have to tear down my entire game and load it from scratch.

By your wording it looks like I might have to tear it down and then *manually* change the resolution before reloading from scratch. Not friendly, not friendly at all.

The point is that you shouldn't switch video mode at all. That is also what Mac OS X developer manual for OpenGL suggests, yet no one listens. You SHOULD NOT SWITCH MODE. Render to smaller buffer, then stretch it to full screen.

What if you force quit your app, and the switched video mode is left behind? It also takes some noticeable time to switch the mode, so user experience on Alt+Tab will be far from ideal.

So, don't switch video mode. Really. Just because everyone does that, it doesn't mean YOU should do too.

Looks like an interesting project, but yeah, the 'no video mode switching' might be kind of a tough sell. It's an interesting idea, but I don't know if we're quite to the point yet where you could safely expect a game to be able to accommodate any resolution that the monitor supports (which is basically what not being able to switch modes from within the game would require). The render-to-buffer approach can require some extra work and/or modifying existing architecture, and IINM, there are still some cards out there in the wild that don't support it.

Plus, as has been mentioned, you're fighting a great deal of inertia here; the vast majority of (non-casual, at least) games for desktop platforms allow the user to select the resolution they want to use. Like you said, just because something's done a certain way doesn't always mean it should continue to be done that way, but this is still probably a feature people will expect from a cross-platform windowing and events library.

But, some of the other features sound good. I use SDL for cross-platform C++ stuff, but at times I've considered writing a custom framework *solely* to get complete control of application behavior during alt/cmd-tab switching :| So if your framework handles that correctly on all targeted platforms, that would be a big plus.

And while we're at it, here's a feature request: in Windows, please make it easy to continue to re-render the scene when the window is being dragged! :) Although it seems I'm somewhat alone in caring about this, it really bugs me when dragging a window offscreen and then back on erases part of the window or causes a 'smearing' effect. This really isn't very polished, IMO, and in a native Windows/D3D app it's a problem that's easily fixed. With SDL (1.2.x) on the other hand, the only way to keep rendering when the window is being dragged is by using one of a couple of hacky workarounds. (I'm not sure how SFML behaves in this regard, but I seem to remember that it also 'smears' when you drag the window around.)

The MIT license and being able to statically link easily sounds great. Also, I'd definitely recommend making full OS X support a high priority (which you may already be doing), since (IMO) part of the point of using a portable API of this sort is to be able to target all three of the main PC platforms.

In any case, good luck with the project :)

Just for your information, single image upscaling won't hurt your performance at all. If you are fill rate bound, that is because of heavy pixel shaders. Upscaling is very simple in that regard. And you usually have the off-screen render target already, because most of the modern games use post-processing.

However, considering the inertia, I will accept patches for switching video mode, if someone is interested enough to do it (shouldn't be hard). I'm personally not interested in it, for mentioned reasons.

This resolution switching issue will be killer of your Genesis library IMHO. If developer start to feel limited by your library he/she will abandon it.

I agree with swiftcoder.

Quote:Original post by swiftcoder
Enough of that, however. If you want one, single, truly killer feature, which will be pretty much unique to your library, then implement fullscreen/windowed mode toggling. For some reason, none of the windowing toolkits (apart from Pyglet) implement this, and it really detracts from the professionalism of a game if the player can't switch out to windowed mode to check their email...

It already can. You can build it, and try for yourself (SingleWindow test case). You can Alt+Tab from your application, and you can also press "F" to toggle between fullscreen/windowed.

One of the reasons why I haven't implemented video mode switching, is because it's troublesome with Alt+Tab. In fact, there was a code for it, at least for Unix/X11 platform, but I've failed to find a good place to switch mode back when leaving window. You will receive focus leave event as soon as Alt+Tab is pressed (when application selection window appears), and that is far from good user experience. Also, on Mac OS X, to switch video mode, you should also grab the screen (otherwise it will mess with your desktop), and that mean that you will not have Alt+Tab at all.

If you want your user to have consistent good experience, you should not switch video mode.

Also, as a user, I'd better make graphics settings lower, than switch from the screen's native resolution, because it looks bad.

And why do you think simple bilinear filtering is not enough? I've just tried with a single image of small size, and scaled it to the fullscreen, and it looks fine, not worse than monitor will do.