• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Macin Software

OpenGL
Fast Way To Determine If All Pixels In Opengl Depth Buffer Were Drawn At Least Once?

19 posts in this topic

Hello, I am programming a FPS game and I simply want to make it faster. I tried a lot of things, from which few of them worked. My testing map has 15k vertexes and 26k triangles, and I am using partitioning space by X*Y*Z orthogonal cubes. Thats fine cause it works. Next thing that helped a lot was to order partitions by metric from partition where I am and display them from nearest, which caused OpenGl to not overdraw it so much. Also I use face culling and my own per-triangle frustum clipping, and also overdraw check that makes it sure that same triangle is rendered only once. Also before loading a map, the triangle lists of each partition are ordered by texture to minimalize need of switching glEnd and glBegin, which caused big slowdown. Also, I tried arranging triangles into triangle strips, but they suck arse, and also I tried using VBOs instead glBegin and glEnd, but it didnt helped that much as internet promised. My next, yet undone idea is to compute all this stuff just when the player position and rotation changes, and if not just render it as before without any computations.

 

Anyway, in every tic I count number of triangles being actually drawn. As a testing map I use Hell Gate from Quake III (that one with crazy mouth in a room, if somebody knows that one :D ) loaded from exported .obj file. When I am on the end of map and looking outside (in the mouth), 36 triangles are being drawn, which seems fair to me. However, turning by 180 degrees causes me to look INSIDE the map and my frustum to contain nearly all partitions, and 22k triangles from 26k are displayed. Now I get to my idea - display few partitions, then CHECK IF ALL PIXELS WERE DISPLAYED, if not, display some more partitions, and so on. That could make it really fast, cause it would cut of everything excpet the first room. Problém is that extracting depth buffer and checking all the 1920x1080 of that little guys is so slow that it would be contraproductive (proven by try).

 

So my question is - is there actually a FAST way how to check if all pixels are rendered at least once? (= if the depth value is not 127 anywhere) I did like 3-hours research which didnt found answer. Also, if people here will say "no" it will encourage me in writing my own rasterization (at least I will have totally full control).

0

Share this post


Link to post
Share on other sites

There's a hardware feature called 'occlusion queries', which do exactly what you're looking for -- determine a yes/no answer to whether something was drawn or not. To find out if there's "holes" in the depth buffer, you can draw a quad that's very far away using an occlusion query, and check if the result is "yes - the quad was visible".
 

Now I get to my idea - display few partitions, then CHECK IF ALL PIXELS WERE DISPLAYED, if not, display some more partitions, and so on. That could make it really fast, cause it would cut of everything excpet the first room. Problém is that extracting depth buffer and checking all the 1920x1080 of that little guys is so slow that it would be contraproductive (proven by try).

 A bigger problem is that the CPU and GPU have a very large latency between them. When you call any glDraw function, the driver is actually writing a command packet into a queue (like networking!), and the GPU might not execute that command until, say, 30ms later. This is perfectly fine in most situations, as the CPU and GPU form a pipeline with huge throughput, but long latency.
e.g. a healthy timeline looks like:

CPU: | Frame 1 | Frame 2 | Frame 3 | ...
GPU: | wait    | Frame 1 | Frame 2 | ...

 
If you ever try to read GPU data back to the CPU during a frame -- e.g. you split your frame into two parts (A/B) with a read-back operation in between them, you end up with a timeline like this:

CPU: | Frame1.A | wait      |Copy| Frame1.B | Frame2.A | wait      |Copy| Frame2.B | Frame3.A | ...
GPU: | wait     | Frame 1.A |Copy| wait     | Frame1.B | Frame 2.A |Copy| wait     | Frame2.B | ...

Now, both the CPU and GPU spend roughly half of the time idle, waiting on the other processor.
If you're going to read back GPU data, you need to wait at least one frame before requesting the results, to avoid causing a pipeline bubble :(
That means that reading back GPU data to use in CPU-driven occlusion culling is a dead-end for performance.

Edited by Hodgman
2

Share this post


Link to post
Share on other sites

Writing your own rasterizer isn't really going to solve your problem, since you won't be utilizing your GPU at all (or if you use compute, not as efficiently as you could be). Just leave that stuff to the GPU guys, they know what they're doing. :)

 

Anyway, do you really need such precise culling? I mean, are you absolutely sure you're GPU bound? Going into such detail just to cull a few triangles might not be worth it, and could hurt your performance rather than help if you're actually CPU bound since modern GPUs prefer to eat big chunks of data more than they like to issue a draw call for each individual triangle. If you have bounding box culling on your objects, and frustum culling, then I think that's all you'll really need unless you're writing a big AAA title with a very high scene complexity.

 

Just bear in mind that Quake levels were built for some different hardware constraints, so you should probably break up the obj model you have into small sections to avoid processing the entire mesh in one chunk so that you can leverage those two culling systems a little more.

 

That said, if you really want to have some proper occlusion culling for triangles, you can either check out the Frostbite approach (it's quite complicated iirc), or try implementing a simple Hi-Z culling system using Geometry Shaders (build a simple quad-tree out of your zbuffer and do quad-based culling on each triangle using the geometry shader). The later is simpler to implement and I've had pretty good results with it.

Edited by Styves
1

Share this post


Link to post
Share on other sites

So I tried occlusion culling. Principially it works, but guess what. :D

 

It made it slower. Initially I got framerate 42. When I try to do test of gl_samples count every 20 partitions = 38 fps. Every 10 partitions = 32 fps :(

Making list of displayed triangles in previous frame helped, when I dont move - I get 41, but when I move, it for sure drops on 32.

And yes I think it is worth, cause I see like 5k triangles max. When I have to pass 15k triangles to OpenGl more, it is very noobish performance leak.

Anyway thank you guys.

0

Share this post


Link to post
Share on other sites

"Thousands of triangles" should not be something that alters the framerate so dramatically. A modern game can draw hundreds of thousands of triangles at 1000fps -- which is one of the reasons that VBO's replaced begin/end (same number of gl function calls required for any number of triangles).

 

You need to profile your game to find out where the time is being spent. Set up a class that records the high-frequency timer at two points in time, subtracts the difference, and logs the result, and then put instances of this class in any function that you think might be a performance hog.

It's common to do this with a constructor/destructor:

struct ProfileLogger { ProfileLogger(const char* name) { PushProfileScope(name); } ~ProfileLogger() { PopProfileScope(); } };
#define Profile(name) ProfileLogger _profile_(name);
 
void Test()
{
  Profile("Test");// calls PushProfileScope("Test") here
  DoStuff();
}// calls PopProfileScope("Test") here

From this data you can get a hierarchical breakdown of where all your CPU time is spent per frame. Trying to optimize without this data is just shooting in the dark.

 

From the sounds of it, your game is almost certainly CPU-bound, so you can start here. Later on though, you can use gl timer queries to do the same thing on the GPU side -- wrapping parts of the scene in two timer queries to find out how long it took the GPU to process those commands.

0

Share this post


Link to post
Share on other sites

Displaying is the actual bottleneck, cause I have done this stuff before. What I didnt knew was that on testing computer there was Nvidia set to best antialiasing and texture filtering, so I turned them off and now it runs stably on 60fps without any visible change to worse :)

 

... anyway, if the occlusion culling queries are so slow, what is their point then? Will for example GL_ANY_SAMPLES_PASSED_CONSERVATIVE speed it up? Another idea is lowering viewport resolution when doing queries and then setting it back to normal ...

0

Share this post


Link to post
Share on other sites

The problem with this use of occlusion queries is the pipeline bubble caused by reading back results on the same frame. Even if the query itself is free, this bubble will halve your framerate.

 

Reading back an occlusion query is fine if you wait one frame before requesting the result, as this won't disrupt the pipeline. This is useful for things like lens flares or special effects where you don't care about the data being one frame old, but is dangerous for deciding what parts of the scene to draw :(

Generally they're a pretty useless API feature...

 

In a modern engine though, you can move all your culling and "what to draw" code off the CPU and into a compute shader. You can then issue draw-indirect commands to say "you will be drawing something, but I don't know which triangles, yet. The number and offset will be present in this buffer later (which is filled in by the compute shader).

 

For something like a quake3 level though, you should be able to have a constant draw cost regardless of how many triangles are visible. The level triangle data is static, so put it in a VBO once and never update it again.

0

Share this post


Link to post
Share on other sites

That Hi-Z culling looks promising, I will leave it as a backup idea for optimization. I dont doubt that lighting model will fuck up the framerate significantly when I will do it, so there for sure will be need for any optimizing stuff that works. But since I have already 60fps now and people around me demand mainly the basic functionality ("How its going with a game?" "I made it faster" "And can I play it?" "Not yet"), I must move on networking and multiplayer ASAP.

 

By the way I dont think that constant draw cost is good. I could measure time of the loop and if some time will remain, then do some filler work like pre-loading chunk of next map to second map buffer or something :)

0

Share this post


Link to post
Share on other sites

Since you're using a Quake 3 map, the classic Quake method of solving this was to precompute a potentially visible set (or PVS) using an offline pre-processor, then do checks against that PVS at runtime to determine what should (or should not) be drawn.

 

In (very basic) outline, you divide your map into what I'll call "areas"; these could be nodes/leafs in a BSP tree (which was what Quake used), rooms, cubes in a grid, whatever.  Then for each such area, you use some brute-force method to determine what other areas are potentially visible from it (I believe that the "potentially" part is on account of some coarseness in the algorithm, as well as the fact that this stage ignores frustum culling which is still done at runtime).  Store out the result in some fast and compact data format (Quake used a bitfield array).  Then at runtime you're just looking up those stored results, draw calls, overdraw, etc all go down, the map runs faster, and everbody is happy.

 

The downside is that the pre-processing can take time, needs to be re-run even if you make trivial changes to your map, and needs a custom map format to store the data.  And while we're on the subject of formats, .obj is a horrible, horrible, horrible, horrible, horrible format to use for game maps.  The only reason to use it is if you really love writing text parsers.  The ideal format is where you memory-map a file, read some headers to set up some sizes, then glBufferData the rest.  Simple, quick to load, no faffing about.  And while we're on the subject of glBufferData, if your observation is that VBOs are slower than glBegin/glEnd, then you're using them wrong: probably by writing a glBegin/glEnd-alike wrapper around the VBO API.

0

Share this post


Link to post
Share on other sites

mhagain:

 

You understood me bad - I am loading from .obj just initially after I model some thing in Cinema4D and export it. Then I have a function in my engine that already saves a map in my own format, which saves every number as bytes, plus there is also space partitioning saved in that file. I dont know what exactly you mean with memory-mapping a file, but from name it sounds that it would only work for static arrays of classes, and not for linear linked list of dynamically allocated classes as I have. I like .obj cause its intuitive and readable and there is no reverse engineering about format specification.

 

PVS are really good idea, I like it. I will definitely try it. I am thinking of making special class for that, which is some box area and list of other box areas that are potentially visible. In map editor, the user will choose these manually so there will be no need to make some extra complicated code that determines what is visible from where (even if THIS is exactly the point where occlussion culling would be useful...) and also no need to compile a map like this after every change.

0

Share this post


Link to post
Share on other sites

 

My testing map has 15k vertexes and 26k triangles, and I am using

 

You are looking for optimizations in the wrong place if you are getting such low framerates, with or without any texture filtering. This scene is on my old Radeon 7870 video card from 3 years ago:

 

This is 3,000 plants drawn on top of a terrain with anisotropic texture filtering set to highest, or at least medium. So we are talking about 1 million triangles and plenty of overdraw between the plants. FPS was ... I don't remember around 60 though. You have other issues to sort out depending on how good your hardware is. 30 FPS is bad. 60fps sounds like you may have vsync on so it is capping it at 60. Typically vsync will cap framerates to either 30 or 60, nothing in between. At 56 fps you could be capped down to 30 potentially.

 

http://orig04.deviantart.net/7e28/f/2014/271/0/3/desert2_by_dpadam450-d80w64l.jpg

Edited by dpadam450
0

Share this post


Link to post
Share on other sites

dpadam450:

 

Comp where it was tested is Asus X751L. Has Nvidia GeForce 820M, Intel Core i7-4500U 1.8GHz, 12GB RAM. I think hardware should be enough OK.

And yes I am using vsync, thats why I get 60fps. Previously I heard that 25fps is OK, but truth is that you feel subliminaly that something is wrong. I choose 60fps. The texture of triangles was just 32x32. When I put there some 256x256 texture, framerate is same (so there is so far no need for mipmapping).

 

Your image looks nice, I even see you have some shadows. Perhaps I could make similar benchtest like that and test on it.

I got next idea that I will implement some multithreading (theoretically less then 4x speedup when done correctly). Do you guys use it in your games?

0

Share this post


Link to post
Share on other sites

I choose 60fps. The texture of triangles was just 32x32. When I put there some 256x256 texture, framerate is same (so there is so far no need for mipmapping).

 

Any other good reasons for this ? Actually you might not see any differences, but maybe later, you will notice a performance drop, and you'll spend days (and certainly a lot more) to detect that this is due to the fact that you don't use mipmapping. One big reason for this is that you currently use vsync. So as long as your GPU can afford things, you'll have 60 fps, but once it won't, you won't get 59 fps or so, you'll end up with 30 fps...

Mipmaps is just a factor of few more lines in your code.

Of course, it (almost) double the memory requirement for all your images. But except if you really target to use most of your VRAM for your geometry (and other buffers), I don't see any real good motivations by not using mipmapping.

0

Share this post


Link to post
Share on other sites

Mipmapping is not only a performance thing; it's also affects image quality, and in fact the primary reason why mipmapping was invented in the first place was for quality.

 

https://en.wikipedia.org/wiki/Mipmap

 

 

They are intended to increase rendering speed and reduce aliasing artifacts. .....  Mipmapping was invented by Lance Williams in 1983 and is described in his paper Pyramidal parametrics. From the abstract: "This paper advances a 'pyramidal parametric' prefiltering and sampling geometry which minimizes aliasing effects and assures continuity within and between target images." The "pyramid" can be imagined as the set of mipmaps stacked on top of each other.

 

I suggest that you do some research on aliasing to fully understand the problems that this solves.  Also be aware that to some people, aliasing may be confused with additional detail.

 

Mipmaps don't use almost double the memory - they use one-third extra.  But don't get fooled into thinking that memory usage is a primary arbiter of performance, because it's not.

0

Share this post


Link to post
Share on other sites

Mipmapping is not only a performance thing; it's also affects image quality

 

Right. But one could notice aliasing effects more easily. Aliasing on a textured object could probably means a texture issue (or depth issue, right). But a sudden FPS drop can have many reasons.

 

Mipmaps don't use almost double the memory - they use one-third extra.

 

Right too. I'm still wondering how I could reach such a result...

0

Share this post


Link to post
Share on other sites

How much faster should be VBO compared to glBegin/glEnd?

 

Cause with glBegin/glEnd I got 41fps and with VBO like 43fps in same point. So yes, it IS faster, but honestly I expected more improvement, since its one of main tips people give you on optimization of displaying. The speedup will probably vary depending on type of rendered stuff, but I dont know where it helps most. Another 2 problems (minor problems, I can survive these) is ugly syntax compared to glBegin/End and fact that when you create VBO for some object that changes geometry, the VBO doesnt change with position of vertexes, so you must reupdate positions that are previously copied into the data buffer.

0

Share this post


Link to post
Share on other sites

the VBO doesnt change with position of vertexes, so you must reupdate positions that are previously copied into the data buffer.

 

The best thing, as far as you can do it, is to let the vertex shader do these calculations.

 

How much faster should be VBO compared to glBegin/glEnd?

 

It depends on many things. And this might be related to the fact that you update the VBO each frame with new vertex positions.

 

If you want/can live with GL immediate mode, then why not. But you must be aware that immediate mode is deprecated since GL 3. For example your code won't work on Apple machines, and on mobile devices neither.

0

Share this post


Link to post
Share on other sites

How much faster should be VBO compared to glBegin/glEnd?
 
Cause with glBegin/glEnd I got 41fps and with VBO like 43fps in same point. So yes, it IS faster, but honestly I expected more improvement...


This is the naive expectation.  As Silence correctly observes, if your VBO implementation is just a glBegin/glEnd-like wrapper around the VBO API, or if you're updating data each frame, glBegin/glEnd will often outperform it.  It's common to see bad VBO usage actually perform worse.  An alternative for the dynamic data requirement is to use client-side vertex arrays.

 

It's also the case that your actual bottleneck may be elsewhere.  GPU pipelines are very deep and using a VBO just addresses performance at one very small part of them.  If you're not actually transferring much data to the GPU (and 15k vertices is not much) then using a VBO, even in the best case scnario, isn't going to give you much perf gain, if any.

0

Share this post


Link to post
Share on other sites

Recently I have done the networking and tested it by first deathmatch ever. But the performance on other comps than mine is still one of big problems. I figured out, that when I replace item models with simplified ones, I get OK fps, but thats a wimpy solution.

Also - mipmaps have been implemented. Adjustable LOD bias has no effect on performance, even if set as high (like 9) that textures fade into single color.

It is sow really in glBegin/glEnd when switching textures. Texture sorting helped a bit, but not totally. So I packed all my textures to one big, and before compiling a map i will do just linear fix for texcoords to make their xy ranges in big texture. Trouble is that it will not repeat or wrap anymore, and I need that. Texcoords outside 0..1 will continue in big map through other textures, which is what I dont want. I was looking on Internet for solutions, but there is nothing. My idea is to somehow get into place in memory where texture is stored and manually hack width and height and starting pointer, to make it think that its actually just a region of itself. There will be complication with mipmaps, but thats not the immediate problem. Also textures will have to be stored not in image as I see it, but lineary after rows, so program could read it. I have dilema if I should go for it or no, cause maybe there is function like that - I just looked not enough. Anyone knows a functions that draws only region of texture? I care only about those WITH PRESERVED ABILITY TO WRAP OR REPEAT - the answer TexCoord2f(0.5,0.5) really is not what I am looking for :D

0

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  
Followers 0

  • Similar Content

    • By Toastmastern
      So it's been a while since I took a break from my whole creating a planet in DX11. Last time around I got stuck on fixing a nice LOD.
      A week back or so I got help to find this:
      https://github.com/sp4cerat/Planet-LOD
      In general this is what I'm trying to recreate in DX11, he that made that planet LOD uses OpenGL but that is a minor issue and something I can solve. But I have a question regarding the code
      He gets the position using this row
      vec4d pos = b.var.vec4d["position"]; Which is then used further down when he sends the variable "center" into the drawing function:
      if (pos.len() < 1) pos.norm(); world::draw(vec3d(pos.x, pos.y, pos.z));  
      Inside the draw function this happens:
      draw_recursive(p3[0], p3[1], p3[2], center); Basically the 3 vertices of the triangle and the center of details that he sent as a parameter earlier: vec3d(pos.x, pos.y, pos.z)
      Now onto my real question, he does vec3d edge_center[3] = { (p1 + p2) / 2, (p2 + p3) / 2, (p3 + p1) / 2 }; to get the edge center of each edge, nothing weird there.
      But this is used later on with:
      vec3d d = center + edge_center[i]; edge_test[i] = d.len() > ratio_size; edge_test is then used to evaluate if there should be a triangle drawn or if it should be split up into 3 new triangles instead. Why is it working for him? shouldn't it be like center - edge_center or something like that? Why adding them togheter? I asume here that the center is the center of details for the LOD. the position of the camera if stood on the ground of the planet and not up int he air like it is now.

      Full code can be seen here:
      https://github.com/sp4cerat/Planet-LOD/blob/master/src.simple/Main.cpp
      If anyone would like to take a look and try to help me understand this code I would love this person. I'm running out of ideas on how to solve this in my own head, most likely twisted it one time to many up in my head
      Thanks in advance
      Toastmastern
       
       
    • By fllwr0491
      I googled around but are unable to find source code or details of implementation.
      What keywords should I search for this topic?
      Things I would like to know:
      A. How to ensure that partially covered pixels are rasterized?
         Apparently by expanding each triangle by 1 pixel or so, rasterization problem is almost solved.
         But it will result in an unindexable triangle list without tons of overlaps. Will it incur a large performance penalty?
      B. A-buffer like bitmask needs a read-modiry-write operation.
         How to ensure proper synchronizations in GLSL?
         GLSL seems to only allow int32 atomics on image.
      C. Is there some simple ways to estimate coverage on-the-fly?
         In case I am to draw 2D shapes onto an exisitng target:
         1. A multi-pass whatever-buffer seems overkill.
         2. Multisampling could cost a lot memory though all I need is better coverage.
            Besides, I have to blit twice, if draw target is not multisampled.
       
    • By mapra99
      Hello

      I am working on a recent project and I have been learning how to code in C# using OpenGL libraries for some graphics. I have achieved some quite interesting things using TAO Framework writing in Console Applications, creating a GLUT Window. But my problem now is that I need to incorporate the Graphics in a Windows Form so I can relate the objects that I render with some .NET Controls.

      To deal with this problem, I have seen in some forums that it's better to use OpenTK instead of TAO Framework, so I can use the glControl that OpenTK libraries offer. However, I haven't found complete articles, tutorials or source codes that help using the glControl or that may insert me into de OpenTK functions. Would somebody please share in this forum some links or files where I can find good documentation about this topic? Or may I use another library different of OpenTK?

      Thanks!
    • By Solid_Spy
      Hello, I have been working on SH Irradiance map rendering, and I have been using a GLSL pixel shader to render SH irradiance to 2D irradiance maps for my static objects. I already have it working with 9 3D textures so far for the first 9 SH functions.
      In my GLSL shader, I have to send in 9 SH Coefficient 3D Texures that use RGBA8 as a pixel format. RGB being used for the coefficients for red, green, and blue, and the A for checking if the voxel is in use (for the 3D texture solidification shader to prevent bleeding).
      My problem is, I want to knock this number of textures down to something like 4 or 5. Getting even lower would be a godsend. This is because I eventually plan on adding more SH Coefficient 3D Textures for other parts of the game map (such as inside rooms, as opposed to the outside), to circumvent irradiance probe bleeding between rooms separated by walls. I don't want to reach the 32 texture limit too soon. Also, I figure that it would be a LOT faster.
      Is there a way I could, say, store 2 sets of SH Coefficients for 2 SH functions inside a texture with RGBA16 pixels? If so, how would I extract them from inside GLSL? Let me know if you have any suggestions ^^.
    • By KarimIO
      EDIT: I thought this was restricted to Attribute-Created GL contexts, but it isn't, so I rewrote the post.
      Hey guys, whenever I call SwapBuffers(hDC), I get a crash, and I get a "Too many posts were made to a semaphore." from Windows as I call SwapBuffers. What could be the cause of this?
      Update: No crash occurs if I don't draw, just clear and swap.
      static PIXELFORMATDESCRIPTOR pfd = // pfd Tells Windows How We Want Things To Be { sizeof(PIXELFORMATDESCRIPTOR), // Size Of This Pixel Format Descriptor 1, // Version Number PFD_DRAW_TO_WINDOW | // Format Must Support Window PFD_SUPPORT_OPENGL | // Format Must Support OpenGL PFD_DOUBLEBUFFER, // Must Support Double Buffering PFD_TYPE_RGBA, // Request An RGBA Format 32, // Select Our Color Depth 0, 0, 0, 0, 0, 0, // Color Bits Ignored 0, // No Alpha Buffer 0, // Shift Bit Ignored 0, // No Accumulation Buffer 0, 0, 0, 0, // Accumulation Bits Ignored 24, // 24Bit Z-Buffer (Depth Buffer) 0, // No Stencil Buffer 0, // No Auxiliary Buffer PFD_MAIN_PLANE, // Main Drawing Layer 0, // Reserved 0, 0, 0 // Layer Masks Ignored }; if (!(hDC = GetDC(windowHandle))) return false; unsigned int PixelFormat; if (!(PixelFormat = ChoosePixelFormat(hDC, &pfd))) return false; if (!SetPixelFormat(hDC, PixelFormat, &pfd)) return false; hRC = wglCreateContext(hDC); if (!hRC) { std::cout << "wglCreateContext Failed!\n"; return false; } if (wglMakeCurrent(hDC, hRC) == NULL) { std::cout << "Make Context Current Second Failed!\n"; return false; } ... // OGL Buffer Initialization glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT); glBindVertexArray(vao); glUseProgram(myprogram); glDrawElements(GL_TRIANGLES, indexCount, GL_UNSIGNED_SHORT, (void *)indexStart); SwapBuffers(GetDC(window_handle));  
  • Popular Now