Sign in to follow this  
Mad Fish

Genesis - library for cross-platform window and OpenGL context management.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Mad Fish
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.
And if I am fillrate-limited, rather than saving fillrate by rendering at a lower resolution, I am *wasting* bandwidth on the necessary filtering to upscale a 25% render target. The monitor has dedicated support for upscaling images, which is free (at least from an application standpoint).
Quote:
So, don't switch video mode. Really. Just because everyone does that, it doesn't mean YOU should do too.
Who are you to dictate how I write my application? When one chooses to violate Apple's HIG, one generally does it for a reason.

Now, this particular point I couldn't care less about in the long run - I will do it the way that works for me, and if your library doesn't do things my way, I won't use your library. But I think you should think carefully about the mentality behind developing a library that arbitrarily excludes functionality...

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Mad Fish
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.
No, its not - I experimented with this heavily back when Apple introduced that recommendation.

*Naive* up-scaling is cheap and trivial, but it also looks like hell. To achieve the same degree of filtering that the monitor supports out-of-the-box for low resolutions, requires a fairly complex multiple-tap filter in several stages.

Now, admittedly GPU power has increased significantly since then, so it probably doesn't have as much performance impact as it used to, but particularly for indies targeting a wide range of low-end hardware, this cost may be unacceptable.

***

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...

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by jyk
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.)


There is no easy way to do this in case of event polling main loop (in contrast to callback main loop). That is because when user moves or resizes window, it blocks and passes WM_PAINT messages directly to MsgProc. Why would you need it, anyway?

Share this post


Link to post
Share on other sites
Quote:
There is no easy way to do this in case of event polling main loop (in contrast to callback main loop).
I'm not entirely sure that's true. I've managed to do it with SDL using a couple of different methods. Now, both involved callbacks in one form or another, so I won't argue with you there, but I don't see why it couldn't be incorporated into an API with a polling-based event system.
Quote:
That is because when user moves or resizes window, it blocks and passes WM_PAINT messages directly to MsgProc. Why would you need it, anyway?
Are you asking why you'd want to draw in response to WM_PAINT messages?

Anyway, yes, I know why it happens :) That's not the issue. The issue as that SDL doesn't provide an easy way to respond to the WM_PAINT messages when they arrive.

As you already know, when a window drag commences, Windows blocks and passes WM_PAINT messages back to the handler periodically as needed. Your standard D3D-based application (for example) will render in response to those WM_PAINT messages.

If you don't render in response to those messages, then if you drag the window offscreen and then back onscreen again, the area that was offscreen remains blank until the window drag is completed (or, in some cases you get a 'smearing' effect instead). If you *do* render in response to those messages, that doesn't happen; the image remains intact regardless of where you move the window. (This is true in Windows XP, at least.) It's the later behavior that's preferred, IMO, and is what I'd like to see supported in a Windowing API.

If you're just asking why I care that dragging the window around corrupts the view, then the answer is basically that it's a matter of aesthetics and polish. Apparently not many share that view though, because every time I've brought it up anywhere, I've gotten a response more or less like yours :/

Share this post


Link to post
Share on other sites
Quote:
Original post by jyk
If you're just asking why I care that dragging the window around corrupts the view, then the answer is basically that it's a matter of aesthetics and polish. Apparently not many share that view though, because every time I've brought it up anywhere, I've gotten a response more or less like yours :/

Just stopping by to voice my support, I would definitely appreciate such functionality. I agree that it's mostly a matter of aesthetics and polish. Exposing the user to some glitchy graphics junk when he is moving the window just isn't pleasant and makes the application feel less robust.

Share this post


Link to post
Share on other sites
Quote:
Original post by jyk
If you're just asking why I care that dragging the window around corrupts the view, then the answer is basically that it's a matter of aesthetics and polish. Apparently not many share that view though, because every time I've brought it up anywhere, I've gotten a response more or less like yours :/


Well, it will not happen at all when using composited desktop (Aero on Windows Vista and Windows 7). And that is what most users will use in the near future.

I also want to keep API clean. If I'm using event polling main loop (which is more convenient, and also does not introduce troubles with callbacks into C++ methods), I will prefer to stick to it, and not introduce any "special" behavior to fix Windows API problem. We can all say thanks to Microsoft for that. Why would they make a PeekMessage function and still deliver some messages directly by a callback? Makes no sense to me.

And games usually run fullscreen, so this is not an issue. Windowed mode is useful for development and that single flaw is not so important.

So, to summarize: I also like aesthetics and polish, but this one just not worth the burden. :)

Share this post


Link to post
Share on other sites
Quote:
Original post by AndyPandyV2
I'd be nice if it doesn't tie you to using OpenGL, alot of the current cross platform windowing solutions seem to force OpenGL upon you.


What's the point of supporting DirectX in cross-platform library when DirectX is not cross-platform?

Share this post


Link to post
Share on other sites
Quote:
Original post by Mad Fish
And games usually run fullscreen, so this is not an issue. Windowed mode is useful for development and that single flaw is not so important.
Tad pedantic today, are we? [smile]

My monitor is large enough that I run very few games fullscreen - usually playing while waiting for something to complete, so I need to keep an eye on it in the background, or while IM'ing, etc.
Quote:
What's the point of supporting DirectX in cross-platform library when DirectX is not cross-platform?
Because many cross-platform games/engines support both OpenGL and DirectX, and having to use a different windowing+input library just for DirectX is a complete pain.

I have a feeling that this is one of the larger reasons why no existing cross-platform windowing toolkit has made big inroads into commercial game development.

Share this post


Link to post
Share on other sites
Quote:
Original post by swiftcoder
Because many cross-platform games/engines support both OpenGL and DirectX, and having to use a different windowing+input library just for DirectX is a complete pain.


Well, you have a valid point, and I will accept patches on this if someone is interested to do that.

I am personally not interested however, because I'm not going to support both APIs in my project. OpenGL runs fine on Windows, and is performance- and feature-wise on par with DirectX. So, what is the reason for using DirectX for cross-platform project? I see none.

DirectX is only needed when targeting Xbox, and probably in that case PC windowing library will not suite at all (I'm not sure about this, because I've never programmed for Xbox).

Share this post


Link to post
Share on other sites
Quote:
Well, it will not happen at all when using composited desktop (Aero on Windows Vista and Windows 7). And that is what most users will use in the near future.
Yes, and I look forward to the day when we don't have to worry about XP any more :) But, I don't know that we're quite there yet.
Quote:
And games usually run fullscreen, so this is not an issue. Windowed mode is useful for development and that single flaw is not so important.
Well, you seem to be making a lot of assumptions about what the end user will or will not want to do. From what I read online I get the impression that quite a lot of folks play games in windowed mode, although I may be wrong about that.
Quote:
So, to summarize: I also like aesthetics and polish, but this one just not worth the burden. :)
Obviously others who have implemented similar frameworks have felt the same way, so I guess you're in good company :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Mad Fish
OpenGL runs fine on Windows, and is performance- and feature-wise on par with DirectX. So, what is the reason for using DirectX for cross-platform project?
DirectX generally supports newer hardware features, has more stable drivers, and said drivers are installed automatically. It also has a much less fragmented API and specification (and I say this as primarily an OpenGL user).

It probably doesn't make sense for an indie title to support both, but commercial games often decide to.

Share this post


Link to post
Share on other sites
Quote:
Original post by jyk
Well, you seem to be making a lot of assumptions about what the end user will or will not want to do. From what I read online I get the impression that quite a lot of folks play games in windowed mode, although I may be wrong about that.


OK, maybe I'm wrong about "always fullscreen games", but I'm not dropping windowed mode support for the user. :) It will work of course if the user wants it that way.

But I've rarely seen someone playing anything non-casual in windowed mode, that is the reason for my assumptions.

Share this post


Link to post
Share on other sites
Quote:
OpenGL runs fine on Windows, and is performance- and feature-wise on par with DirectX. So, what is the reason for using DirectX for cross-platform project? I see none.
I think one possible reason is that DirectX/Direct3D might be better supported on some Windows installations than others.

We had a big thread on this a while back. IIRC, some people said that OpenGL will always run fine out of the box on any PC, while some reported having seen cases where OpenGL drivers weren't included in the installation or had been stripped out. I don't have enough experience with varied Windows installations to confirm any of this myself, but I do think that for a casual user, a dialog box that pops up talking about 'OpenGL drivers' is likely to be a deal-breaker. Whether this matters or not is of course project-dependent, but I think for more casual games at least, it could be a consideration.

Share this post


Link to post
Share on other sites
Quote:
Original post by Mad Fish
that is the reason for my assumptions.
As I think I may have mentioned in passing, assumptions are a very bad thing in a library that aims to be widely used. You attract users by allowing them to do what *they* want [smile]

You mention the unix philosophy as a guiding principle, but in creating a library to perform windowing + input + context creation + timing, you are already well outside of the 'do one thing' mentality.

Share this post


Link to post
Share on other sites
Quote:
Original post by swiftcoder
DirectX generally supports newer hardware features, has more stable drivers, and said drivers are installed automatically. It also has a much less fragmented API and specification (and I say this as primarily an OpenGL user).


OpenGL supports new features immediately through extensions. Official specification including all new features is usually released some time after. So I think the first point is not valid at all.

I can't say anything about drivers stability, but to this point, I have not encountered any troubles yet (btw, using NVIDIA, maybe this is not the case with ATI).

Automatic drivers installation - this is valid point, but not entirely valid. :) It's always a good idea to suggest user to install latest official drivers for their video card, because there will be less bugs and better performance. And that is what some prominent PC DirectX titles are doing, noticeably StarCraft 2. So I don't think this matters. Users should (I would even say MUST) install full official drivers for their hardware.

About fragmented API - not really, look at OpenGL 3.x or 4.x specs - they are not fragmented at all. You will encounter fragmentation only if you're using a low version core profile + lots of extensions (I acknowledge though, that this is what most OpenGL developers do). DirectX 9 is also not quite nice, so what's the deal? :) And DirectX >= 10 and OpenGL >= 3.1 are pretty much the same thing.

Share this post


Link to post
Share on other sites
Quote:
Original post by swiftcoder
You mention the unix philosophy as a guiding principle, but in creating a library to perform windowing + input + context creation + timing, you are already well outside of the 'do one thing' mentality.


Actually it does exactly one thing - cross-platform layer to windowing system.
The one thing that is doubtful is timing, but it was so inconvenient to make test case programs without it, so I've decided to let it be there.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this