Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


OpenGL with WS_POPUP (Win32 API)


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 shinypixel   Members   -  Reputation: 161

Like
0Likes
Like

Posted 05 May 2014 - 02:03 PM

Editing question to be more clear:

 

In short, I'm simply throwing pixels at my windowed screen and watching them populate. Switching from windowed to a maxed WS_POPUP window is causing a blank screen.

 

In long, I have a windowed app. It's using glDrawBuffer(GL_FRONT); to draw pixels about the screen. I don't swap the buffers; rather, I use glFlush(). I also put glClearBuffer() in app_init() so it's called just once. The result is thousands of pixels going on top of each other without the screen being refreshed.

 

To abuse my graphics card even more, I turned my app into fullscreen-window mode. (So, the display wasn't changed internally - just a big popup window). I expect the same pixels to occur.

    if (win->blnFullScreen) {
        dwExStyle = WS_EX_APPWINDOW | WS_EX_WINDOWEDGE;
        dwStyle = WS_POPUP;

    }

Now, nothing shows up. It's just a black screen. I did some research, and it seems like this is an Aero issue. But why is that if I'm just maxing out my window?


Edited by shinypixel, 05 May 2014 - 02:41 PM.


Sponsor:

#2 mhagain   Crossbones+   -  Reputation: 8281

Like
3Likes
Like

Posted 05 May 2014 - 03:27 PM

You don't know what your driver is doing behind the scenes.

 

Under OpenGL a "fullscreen windowed" mode as such doesn't actually exist; OpenGL specifies nothing about this kind of mode and specifies nothing about how it may be handled.

 

So in other words you driver is free to treat it as it wishes, including potentially treating it as a regular fullscreen mode that just happens to be of the same dimensions as your desktop.

 

For this kind of program I certainly wouldn't recommend drawing to the front buffer; as you've found out this doesn't play nice with Aero, and it doesn't play nice with some GPUs even in scenarios where you don't have Aero either.

 

The approach I'd use is to draw to an FBO (which is never cleared, just as you're doing now) and then draw that to the backbuffer in a regular double-buffered context at the end of each frame.


It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#3 shinypixel   Members   -  Reputation: 161

Like
0Likes
Like

Posted 05 May 2014 - 04:16 PM

Thanks for the thoughts, and an FBO sounds ideal. However, I came across this. Sorry about my minimum knowledge of OpenGL so far, but does this mean FBOs are out, or is it just this extension?

 

http://www.opengl.org/wiki/Framebuffer_Object

EXT_Framebuffer_object Warning: This section describes legacy OpenGL APIs that have been removed from core OpenGL 3.1 and above (they are only deprecated in OpenGL 3.0). It is recommended that you not use this functionality in your programs.

The original form of FBOs was this extension. It lacked quite a bit of the above functionality, which later extensions granted. The biggest difference is that it has more hard-coded restrictions on framebuffer completeness. All of the images have to be the same size in the EXT spec, for example. Some of these limitations were hardware-based. So there may be hardware that supports EXT_FBO and not ARB_FBO, even thought they support things like EXT_FBO_blit and other parts of ARB_FBO.

 

--

Edit: Looks like I have GL_ARB_pixel_buffer_object and GL_EXT_framebuffer_object. I assume the latter is the one I need.


Edited by shinypixel, 05 May 2014 - 04:20 PM.


#4 mhagain   Crossbones+   -  Reputation: 8281

Like
1Likes
Like

Posted 05 May 2014 - 04:53 PM

You shouldn't confuse GL_ARB_pixel_buffer_object with the old (and quite horrible) pixel buffers which were used for render-to-texture before FBOs were specified (and which once had the distinction of almost driving John Carmack to switch to D3D).  GL_ARB_pixel_buffer_object is something quite different.

 

If you support GL_EXT_framebuffer_object but not GL_ARB_framebuffer_object a simple driver update might be all you need; otherwise you're very probably on extremely old hardware.  If that's the case then GL_EXT_framebuffer_object is the one you want (but if you ever upgrade be careful not to mix -ARB code with -EXT code or things could get weird on you).

 

An older trick that's compatible all the way down to GL1.1 is to use glCopyTexSubImage instead.  It uses up more bandwidth of course, but that's the tradeoff.  The basic setup for your requirements would look something like:

 

At program startup:

- Create an appropriately sized texture (using a NULL pointer for data).

- Clear the screen to black.

- glCopyTexSubImage to initialize the texture to all-black (the driver should automatically do this with a NULL pointer but some might not).

 

Each frame:

- Draw your appropriately-sized texture as a fullscreen quad.

- Draw your objects.

- glCopyTexSubImage it again.

- SwapBuffers.

 

This way your appropriately-sized texture becomes a running copy of the previous frame's contents which forms a baseline on which to build the current frame.

 

As for the size, it should be at least large enough to cover your screen dimensions, which may be a non-power-of-two.  If you don't have hardware-accelerated non-power-of-two support look at GL_ARB_texture_rectangle which will let you create such a texture but with some limits (which shouldn't matter in your use case).

 

Of course another consideration is that your hardware should support such a texture size, but so long as you can do 2048x2048 you should be OK as that'll cover most resolutions.

 

If that doesn't suit you, you can also do something with the accumulation buffer, which goes down to OpenGL1.0 but may not be hardware-accelerated in some cases.

 

Plenty of options!


It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#5 shinypixel   Members   -  Reputation: 161

Like
0Likes
Like

Posted 05 May 2014 - 05:14 PM

Thanks. I'm still reading through, but I checked and confirmed my card has GL_ARB_framebuffer_object.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS