Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 20 Mar 2012
Offline Last Active Sep 20 2016 12:54 AM

Posts I've Made

In Topic: glAddSwapHintRectWIN

14 September 2016 - 06:59 AM

You can use different windows, one for rendering, one or 2 for the interface. You'll then be able to easy choose which window to swap the buffer for.

I initially had a look at this, but I had problems such as having the GUI draw over the 3d window (dropdown menus that obscure it etc).


Why targeting OpenGL 1 ? I have doubts that nowadays we can still find GC that can do GL 1 but no GL 2 or 3... I mean GL 2 came at the early 2000. This was 16 years ago... And you won't be forced to use shaders or to remove deprecated GL features.

Hehe I will update it if I get around to it (I would probably need it for normal and specular maps). I have an OpenGL ES 2.0 version of the GUI for Android, but just wanted something easy to get going that runs anywhere to start with for the paint app. And display lists and wireframe are nice and easy.


To my opinion it  might be more effective for a GC to swap the full buffer than a portion for several reasons: memory alignment in the buffer, having to maintain the other buffers aligned too. This implies extra work for something that should be as easy as setting the address of a buffer to another value...

Yup this is true. I may have been assuming it was doing an extra copy somewhere for windowed rather than full screen, but that might well not be true. I guess it is a black box to me how this is implemented, and OpenGL has to work well with lots of different implementations under the hood.


As a final thought, and the one you might prefer, what you can do is: don't clear your color buffer, and display a black rectangle for the GUI portion that had changed, then redraw on top of it. Then swap your buffer. Since you don't clear the buffer, you don't have to redraw your model each time... You'll have to play with the depth test to make it work well.

I did end up with a situation like this by accident when things went wrong lol. It is a little more complex though because the app might be using single, double triple buffering etc, and if you try to force it to a single buffer, it would impede getting nice fluid graphics. So you have to make sure that not only your back buffer is filled with the right background, but the last 2 or 3.

In Topic: glAddSwapHintRectWIN

14 September 2016 - 05:49 AM

It is for my little 3d paint app:



I am already using glScissor, and viewports, but they do not solve the problem of having to draw the whole frame, when swaphint does not work (and as I have no way of querying this, I am forced to draw the whole screen every time :( ).


After a bit of assessment, the problem is not hugely severe except causing lag with high poly models in the user interface, so I may just live with it. :rolleyes:


I am also already copying the 3d view to a texture in some modes to accelerate things, so could potentially use the same functionality and save the 3d view to a texture when I stop rotating the view, and then render the 3d view as a quad when doing small GUI rect updates.


This is still a convoluted way of doing things, and limiting the swap area would seem much more sensible. But perhaps there are hidden hardware reasons why this is not possible in some cases (tiled rendering or somesuch). A way of querying OpenGL whether the extension is active in the context would seem to be far more sensible than the current hint system, imo.


In Topic: glAddSwapHintRectWIN

14 September 2016 - 03:29 AM

I would usually agree on the WGL extensions, but this is for a windows only app, and was quite easy to put in.


I'm getting the impression that maybe the problem is that while opengl has a means of showing whether the extension is available (wglGetProcAddress and glGetString), it doesn't seem to have a way of letting you know whether the extension is working in your particular hardware configuration. :blink: I had a glimmer of hope as I found in the docs that in the PixelFormatDescriptor there were 2 new flags for glAddSwapHintRectWin, PFD_SWAP_COPY and PFD_SWAP_EXCHANGE. However when I checked them PFD_SWAP_EXCHANGE was set for both my machine where it was working, and the test machine where it wasn't, so it didn't provide a means of distinguishing whether the extension was 'active'.




The problem I'm facing is I'm combining a complex 3d model (say 300,000 polys) and a GUI user interface. I don't want to have to render the model, every time I change a tiny element in the user interface (say a cursor blinking on and off!). As it is, without the swaphint, because of double / triple buffering, I'm needing to do this because it is forcing me to update the whole frame. Unless I render the model to another surface then copy this to the main one. Which might be difficult as I'm trying to use OpenGL 1 lol.  :D


I've now had to change my app code to by default update the whole frame each time, and then offer the 'proper' implementation of just updating subrects via a command line option. Which seems to be ridiculous. :wacko: If there is a better way of doing this I'd love to hear it!  :)

In Topic: What are some ways to efficiently and quickly code a spreading object?

12 September 2016 - 12:01 PM

Ok gradually teasing more information.. is this for a game? Or is it precalculated?


If it is for a game.. is it something you want to change on every frame, like water simulation? With games usually what you would ask is, how many cells can I get away with for a fast calculation, and then design the game around that. Not the other way around. And consider how are you going to get this to the GPU, if you are doing this per frame, and its a big texture (again, not enough background info), or if it is not per pixel, why calculate stuff that is off screen?


These 'griddy things' come up time and time again in game and graphics programming (so much so I have templates in my template library to do the monkey work). I think the official name might be 'continuous cellular automaton', maybe you can do some googling for optimizations.





If you want to iterate a large field you might be able to do something like do a bit at a time each frame. Or use a more complex iteration over a number of frames, then just use simple interpolation to get per frame positions. There are also versions which don't fit to a grid, continuous spatial automata:



I also saw a guy use OpenCL or something on the GPU to speed stuff like this up with impressive results.


Personally I've never managed to get stuff like this running *that* fast, so I'll be as interested as you in any super methods. :) There might be some tricks to store the grid in a cache friendly manner or use SSE. With 'game of life' cellular automatons you could use a simple look up table to look up the result depending on the contents of neighbouring cells, a small LUT might be an option if your rules are complex.

In Topic: Pet Rescue Team - Android game

12 September 2016 - 12:59 AM

Maybe you can make an option to play the villain. :)