• 11
• 9
• 11
• 9
• 11
• Similar Content

• By tj8146
I am using immediate mode for OpenGL and I am creating a 2D top down car game. I am trying to configure my game loop in order to get my car-like physics working on a square shape. I have working code but it is not doing as I want it to. I am not sure as to whether it is my game loop that is incorrect or my code for the square is incorrect, or maybe both! Could someone help because I have been trying to work this out for over a day now
I have attached my .cpp file if you wish to run it for yourself..
WinMain code:
/******************* WIN32 FUNCTIONS ***************************/ int WINAPI WinMain( HINSTANCE hInstance, // Instance HINSTANCE hPrevInstance, // Previous Instance LPSTR lpCmdLine, // Command Line Parameters int nCmdShow) // Window Show State { MSG msg; // Windows Message Structure bool done=false; // Bool Variable To Exit Loop Car car; car.x = 220; car.y = 140; car.dx = 0; car.dy = 0; car.ang = 0; AllocConsole(); FILE *stream; freopen_s(&stream, "CONOUT$", "w", stdout); // Create Our OpenGL Window if (!CreateGLWindow("OpenGL Win32 Example",screenWidth,screenHeight)) { return 0; // Quit If Window Was Not Created } while(!done) // Loop That Runs While done=FALSE { if (PeekMessage(&msg,NULL,0,0,PM_REMOVE)) // Is There A Message Waiting? { if (msg.message==WM_QUIT) // Have We Received A Quit Message? { done=true; // If So done=TRUE break; } else // If Not, Deal With Window Messages { TranslateMessage(&msg); // Translate The Message DispatchMessage(&msg); // Dispatch The Message } } else // If There Are No Messages { if(keys[VK_ESCAPE]) done = true; void processKeys(Car& car); //process keyboard while (game_is_running) { loops = 0; while (GetTickCount() > next_game_tick && loops < MAX_FRAMESKIP) { update(car); // update variables next_game_tick += SKIP_TICKS; loops++; } display(car); // Draw The Scene SwapBuffers(hDC); // Swap Buffers (Double Buffering) } } } // Shutdown KillGLWindow(); // Kill The Window return (int)(msg.wParam); // Exit The Program } //WIN32 Processes function - useful for responding to user inputs or other events. LRESULT CALLBACK WndProc( HWND hWnd, // Handle For This Window UINT uMsg, // Message For This Window WPARAM wParam, // Additional Message Information LPARAM lParam) // Additional Message Information { switch (uMsg) // Check For Windows Messages { case WM_CLOSE: // Did We Receive A Close Message? { PostQuitMessage(0); // Send A Quit Message return 0; // Jump Back } break; case WM_SIZE: // Resize The OpenGL Window { reshape(LOWORD(lParam),HIWORD(lParam)); // LoWord=Width, HiWord=Height return 0; // Jump Back } break; case WM_LBUTTONDOWN: { mouse_x = LOWORD(lParam); mouse_y = screenHeight - HIWORD(lParam); LeftPressed = true; } break; case WM_LBUTTONUP: { LeftPressed = false; } break; case WM_MOUSEMOVE: { mouse_x = LOWORD(lParam); mouse_y = screenHeight - HIWORD(lParam); } break; case WM_KEYDOWN: // Is A Key Being Held Down? { keys[wParam] = true; // If So, Mark It As TRUE return 0; // Jump Back } break; case WM_KEYUP: // Has A Key Been Released? { keys[wParam] = false; // If So, Mark It As FALSE return 0; // Jump Back } break; } // Pass All Unhandled Messages To DefWindowProc return DefWindowProc(hWnd,uMsg,wParam,lParam); } C++ and OpenGL code: int mouse_x=0, mouse_y=0; bool LeftPressed = false; int screenWidth=1080, screenHeight=960; bool keys[256]; float radiansFromDegrees(float deg) { return deg * (M_PI / 180.0f); } float degreesFromRadians(float rad) { return rad / (M_PI / 180.0f); } bool game_is_running = true; const int TICKS_PER_SECOND = 50; const int SKIP_TICKS = 1000 / TICKS_PER_SECOND; const int MAX_FRAMESKIP = 10; DWORD next_game_tick = GetTickCount(); int loops; typedef struct { float x, y; float dx, dy; float ang; }Car; //OPENGL FUNCTION PROTOTYPES void display(const Car& car); //called in winmain to draw everything to the screen void reshape(int width, int height); //called when the window is resized void init(); //called in winmain when the program starts. void processKeys(Car& car); //called in winmain to process keyboard input void update(Car& car); //called in winmain to update variables /************* START OF OPENGL FUNCTIONS ****************/ void display(const Car& car) { const float w = 50.0f; const float h = 50.0f; glClear(GL_COLOR_BUFFER_BIT); glLoadIdentity(); glTranslatef(100, 100, 0); glBegin(GL_POLYGON); glVertex2f(car.x, car.y); glVertex2f(car.x + w, car.y); glVertex2f(car.x + w, car.y + h); glVertex2f(car.x, car.y + h); glEnd(); glFlush(); } void reshape(int width, int height) // Resize the OpenGL window { screenWidth = width; screenHeight = height; // to ensure the mouse coordinates match // we will use these values to set the coordinate system glViewport(0, 0, width, height); // Reset the current viewport glMatrixMode(GL_PROJECTION); // select the projection matrix stack glLoadIdentity(); // reset the top of the projection matrix to an identity matrix gluOrtho2D(0, screenWidth, 0, screenHeight); // set the coordinate system for the window glMatrixMode(GL_MODELVIEW); // Select the modelview matrix stack glLoadIdentity(); // Reset the top of the modelview matrix to an identity matrix } void init() { glClearColor(1.0, 1.0, 0.0, 0.0); //sets the clear colour to yellow //glClear(GL_COLOR_BUFFER_BIT) in the display function //will clear the buffer to this colour. } void processKeys(Car& car) { if (keys[VK_UP]) { float cdx = sinf(radiansFromDegrees(car.ang)); float cdy = -cosf(radiansFromDegrees(car.ang)); car.dx += cdx; car.dy += cdy; } if (keys[VK_DOWN]) { float cdx = sinf(radiansFromDegrees(car.ang)); float cdy = -cosf(radiansFromDegrees(car.ang)); car.dx += -cdx; car.dy += -cdy; } if (keys[VK_LEFT]) { car.ang -= 2; } if (keys[VK_RIGHT]) { car.ang += 2; } } void update(Car& car) { car.x += car.dx*next_game_tick; } game.cpp • By tj8146 I am using immediate mode for OpenGL and I am creating a 2D top down car game. I am trying to configure my game loop in order to get my car-like physics working on a square shape. I have working code but it is not doing as I want it to. I am not sure as to whether it is my game loop that is incorrect or my code for the square is incorrect, or maybe both! Could someone help because I have been trying to work this out for over a day now I have attached my .cpp file if you wish to run it for yourself.. This is my C++ and OpenGL code: int mouse_x=0, mouse_y=0; bool LeftPressed = false; int screenWidth=1080, screenHeight=960; bool keys[256]; float radiansFromDegrees(float deg) { return deg * (M_PI / 180.0f); } float degreesFromRadians(float rad) { return rad / (M_PI / 180.0f); } bool game_is_running = true; const int TICKS_PER_SECOND = 50; const int SKIP_TICKS = 1000 / TICKS_PER_SECOND; const int MAX_FRAMESKIP = 10; DWORD next_game_tick = GetTickCount(); int loops; typedef struct { float x, y; float dx, dy; float ang; }Car; //OPENGL FUNCTION PROTOTYPES void display(const Car& car); //called in winmain to draw everything to the screen void reshape(int width, int height); //called when the window is resized void init(); //called in winmain when the program starts. void processKeys(Car& car); //called in winmain to process keyboard input void update(Car& car); //called in winmain to update variables /************* START OF OPENGL FUNCTIONS ****************/ void display(const Car& car) { const float w = 50.0f; const float h = 50.0f; glClear(GL_COLOR_BUFFER_BIT); glLoadIdentity(); glTranslatef(100, 100, 0); glBegin(GL_POLYGON); glVertex2f(car.x, car.y); glVertex2f(car.x + w, car.y); glVertex2f(car.x + w, car.y + h); glVertex2f(car.x, car.y + h); glEnd(); glFlush(); } void reshape(int width, int height) // Resize the OpenGL window { screenWidth = width; screenHeight = height; // to ensure the mouse coordinates match // we will use these values to set the coordinate system glViewport(0, 0, width, height); // Reset the current viewport glMatrixMode(GL_PROJECTION); // select the projection matrix stack glLoadIdentity(); // reset the top of the projection matrix to an identity matrix gluOrtho2D(0, screenWidth, 0, screenHeight); // set the coordinate system for the window glMatrixMode(GL_MODELVIEW); // Select the modelview matrix stack glLoadIdentity(); // Reset the top of the modelview matrix to an identity matrix } void init() { glClearColor(1.0, 1.0, 0.0, 0.0); //sets the clear colour to yellow //glClear(GL_COLOR_BUFFER_BIT) in the display function //will clear the buffer to this colour. } void processKeys(Car& car) { if (keys[VK_UP]) { float cdx = sinf(radiansFromDegrees(car.ang)); float cdy = -cosf(radiansFromDegrees(car.ang)); car.dx += cdx; car.dy += cdy; } if (keys[VK_DOWN]) { float cdx = sinf(radiansFromDegrees(car.ang)); float cdy = -cosf(radiansFromDegrees(car.ang)); car.dx += -cdx; car.dy += -cdy; } if (keys[VK_LEFT]) { car.ang -= 2; } if (keys[VK_RIGHT]) { car.ang += 2; } } void update(Car& car) { car.x += car.dx*next_game_tick; } My WinMain code: /******************* WIN32 FUNCTIONS ***************************/ int WINAPI WinMain( HINSTANCE hInstance, // Instance HINSTANCE hPrevInstance, // Previous Instance LPSTR lpCmdLine, // Command Line Parameters int nCmdShow) // Window Show State { MSG msg; // Windows Message Structure bool done=false; // Bool Variable To Exit Loop Car car; car.x = 220; car.y = 140; car.dx = 0; car.dy = 0; car.ang = 0; AllocConsole(); FILE *stream; freopen_s(&stream, "CONOUT$", "w", stdout); // Create Our OpenGL Window if (!CreateGLWindow("OpenGL Win32 Example",screenWidth,screenHeight)) { return 0; // Quit If Window Was Not Created } while(!done) // Loop That Runs While done=FALSE { if (PeekMessage(&msg,NULL,0,0,PM_REMOVE)) // Is There A Message Waiting? { if (msg.message==WM_QUIT) // Have We Received A Quit Message? { done=true; // If So done=TRUE break; } else // If Not, Deal With Window Messages { TranslateMessage(&msg); // Translate The Message DispatchMessage(&msg); // Dispatch The Message } } else // If There Are No Messages { if(keys[VK_ESCAPE]) done = true; void processKeys(Car& car); //process keyboard while (game_is_running) { loops = 0; while (GetTickCount() > next_game_tick && loops < MAX_FRAMESKIP) { update(car); // update variables next_game_tick += SKIP_TICKS; loops++; } display(car); // Draw The Scene SwapBuffers(hDC); // Swap Buffers (Double Buffering) } } } // Shutdown KillGLWindow(); // Kill The Window return (int)(msg.wParam); // Exit The Program } //WIN32 Processes function - useful for responding to user inputs or other events. LRESULT CALLBACK WndProc( HWND hWnd, // Handle For This Window UINT uMsg, // Message For This Window WPARAM wParam, // Additional Message Information LPARAM lParam) // Additional Message Information { switch (uMsg) // Check For Windows Messages { case WM_CLOSE: // Did We Receive A Close Message? { PostQuitMessage(0); // Send A Quit Message return 0; // Jump Back } break; case WM_SIZE: // Resize The OpenGL Window { reshape(LOWORD(lParam),HIWORD(lParam)); // LoWord=Width, HiWord=Height return 0; // Jump Back } break; case WM_LBUTTONDOWN: { mouse_x = LOWORD(lParam); mouse_y = screenHeight - HIWORD(lParam); LeftPressed = true; } break; case WM_LBUTTONUP: { LeftPressed = false; } break; case WM_MOUSEMOVE: { mouse_x = LOWORD(lParam); mouse_y = screenHeight - HIWORD(lParam); } break; case WM_KEYDOWN: // Is A Key Being Held Down? { keys[wParam] = true; // If So, Mark It As TRUE return 0; // Jump Back } break; case WM_KEYUP: // Has A Key Been Released? { keys[wParam] = false; // If So, Mark It As FALSE return 0; // Jump Back } break; } // Pass All Unhandled Messages To DefWindowProc return DefWindowProc(hWnd,uMsg,wParam,lParam); }
game.cpp
• By lxjk
Hi guys,
There are many ways to do light culling in tile-based shading. I've been playing with this idea for a while, and just want to throw it out there.
Because tile frustums are general small compared to light radius, I tried using cone test to reduce false positives introduced by commonly used sphere-frustum test.
On top of that, I use distance to camera rather than depth for near/far test (aka. sliced by spheres).
This method can be naturally extended to clustered light culling as well.
The following image shows the general ideas

Performance-wise I get around 15% improvement over sphere-frustum test. You can also see how a single light performs as the following: from left to right (1) standard rendering of a point light; then tiles passed the test of (2) sphere-frustum test; (3) cone test; (4) spherical-sliced cone test

I put the details in my blog post (https://lxjk.github.io/2018/03/25/Improve-Tile-based-Light-Culling-with-Spherical-sliced-Cone.html), GLSL source code included!

Eric

• Good evening everyone!

I was wondering if there is something equivalent of  GL_NV_blend_equation_advanced for AMD?
Basically I'm trying to find more compatible version of it.

Thank you!

• Hello guys,

How do I know? Why does wavefront not show for me?
I already checked I have non errors yet.

And my download (mega.nz) should it is original but I tried no success...
- Add blend source and png file here I have tried tried,.....

PS: Why is our community not active? I wait very longer. Stop to lie me!
Thanks !

OpenGL RenderQueue + Multithreading in OpenGL?

This topic is 1138 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

Although this isn't particularly specific to OpenGL, it's in the context of my game engine which currently only deals with OpenGL so...

I was thinking about an approach to the rendering system, similar to how I think Command Buffers in the upcoming APIs are supposed to work.

My game engine has a multithreaded game loop where each thread deals with specific functions (like one for updating physics, another for animations, another for general updates and another for world management, all loops are fixed timestep), now the problem is, being in C# and OpenTK, the rendering is tied to the WinForm Paint function, which sort of bugs me, I'd like to be able to make every thing totally independent. So I came up with the following idea:

Have a Render Queue where a separate Render thread writes its render commands to.

The commands on the render queue (up till swapbuffers) are then executed on every refresh. If the system is having trouble keeping up and a frame is missed, then the commands relevant to it are dropped from the Queue. With this setup I think it should take out a lot of the complexity of dealing with variable rendering time steps while also making it easy to transition to Vulkan and DX12 when they're released.

But just before I go in and start adjusting the API to work like this, I wanted to know if there were any immediately obvious flaws with such a system that I'm overlooking.

Share on other sites

Having a render command buffer (or render queue as you called them) for each thread that potentially submits render commands is the right thing to do.

Maybe I didn't fully understand your command buffer execution but when *exactly* are you going to process the individual command buffers? When the paint funciton is getting called? Where are you going to submit the OpenGL calls? Keep in mind that each OpenGL Context is bound to the thread where the context got created.

You also have to keep rendering order in mind.

Ideally you'd want to have a designated render thread whose only purpose is to process command buffers that have been submitted.

To ensure that the order in which the command buffers is the same order in which the command buffers are getting processed by the render thread you could implement some kind of command buffer dispatcher who receives command buffers to process in a defined order. Once all command buffers from all threads have been dispatched you can kick off the render thread which will immediately start to get the command buffers from the command buffer dispatcher.

To improve performance you could also double buffer the command buffers and the command buffer dispatcher so that you can start adding new render commands while the render thread is still busy processing the render commands that have been submitted in the previous frame.

Edited by FelixK15

Share on other sites

being in C# and OpenTK, the rendering is tied to the WinForm Paint function
Wait what? I'm pretty sure that isn't/shouldn't be necessary. Arent you doing some specific thing? (combining windows widgets with OGL draw surface). Have in mind that thats a library that works on Linux and OSX, so WinForm requirements must be because some specific thing you're doing.

http://www.opentk.com/doc/chapter/0

From that page it seems GameWindow provides a SwapBuffers function.

Share on other sites

One possible problem is that thread-per-subsystem scales rather poorly and may have synchronization/efficiency issues. For example, if "skinning" needs "physics" and "draw" needs "skinning", but "physics" needs "ai", and they all run in a separate thread then they all basically run lockstep, single-threaded (most threads are just waiting for some other thread to produce something they need before they can work, and then there's only one doing something).

On the other hand, having 4 threads compete over, say, two cores is no good. Similarly, running 4 threads on a 6-core machine isn't good.

I prefer pushing tasks (with dependencies) to a thread-per-core-minus-one-atleast-one sized thread pool. This scales really well both upwards and downwards to any number of cores, and things actually happen in parallel, most of the time. Yes, you still have sync points that suck, but you can usually run much of the stuff between them in parallel, and with some thought, you can design your work queues so "useless time" (while a stage is not  ready) can be used to do background tasks.

You most likely have 1-2 moderately busy extra threads running anyway which are out of your control (e.g. audio mixer, GL server), hence having "minus one" on the total number of cores is probably a wise approach (this is a somewhat "unscientific" approach, but works for me).

To keep synchronization low, instead of submitting commands to the render thread's queue (this will require a lot of atomic operations or locking) you most probably want to do something similar as OpenGL is already doing in a very limited way with glDrawElementsIndirect, and what Vulkan will be doing much more elaborately:

Have a thread (any worker thread, or rather any number of them!) build a whole large buffer (or several) of several hundred or so commands, and submit that whole thing to the render queue from where the single thread that owns the GL context submits it with a single API call.

With "dropping commands", you hopefully mean dropping a complete frame worth of commands (I wasn't sure, initially it sounded to me like if e.g. te physics system can't keep up, the respective draws are skipped and only static geometry is rendered, that would be... catastrophic).

Edited by samoth

Share on other sites

Having a render command buffer (or render queue as you called them) for each thread that potentially submits render commands is the right thing to do.

Maybe I didn't fully understand your command buffer execution but when *exactly* are you going to process the individual command buffers? When the paint funciton is getting called? Where are you going to submit the OpenGL calls? Keep in mind that each OpenGL Context is bound to the thread where the context got created.

You also have to keep rendering order in mind.

Ideally you'd want to have a designated render thread whose only purpose is to process command buffers that have been submitted.

To ensure that the order in which the command buffers is the same order in which the command buffers are getting processed by the render thread you could implement some kind of command buffer dispatcher who receives command buffers to process in a defined order. Once all command buffers from all threads have been dispatched you can kick off the render thread which will immediately start to get the command buffers from the command buffer dispatcher.

To improve performance you could also double buffer the command buffers and the command buffer dispatcher so that you can start adding new render commands while the render thread is still busy processing the render commands that have been submitted in the previous frame.

Currently, yes, when the Paint function is called, this is on the thread on which the context was created, so no problems there. Double buffering would be an interesting idea.

Wait what? I'm pretty sure that isn't/shouldn't be necessary. Arent you doing some specific thing? (combining windows widgets with OGL draw surface). Have in mind that thats a library that works on Linux and OSX, so WinForm requirements must be because some specific thing you're doing.

Yes, it isn't necessary, I'm just doing it like that because I don't want to have to rely on the OpenTK GameWindow. The game engine is designed to have the underlying renderer swapped out easily, while still letting the higher level parts handle the window itself, the way this is done is by requiring the renderer to provide a Control object.

One possible problem is that thread-per-subsystem scales rather poorly and may have synchronization/efficiency issues. For example, if "skinning" needs "physics" and "draw" needs "skinning", but "physics" needs "ai", and they all run in a separate thread then they all basically run lockstep, single-threaded (most threads are just waiting for some other thread to produce something they need before they can work, and then there's only one doing something).

On the other hand, having 4 threads compete over, say, two cores is no good. Similarly, running 4 threads on a 6-core machine isn't good.

I prefer pushing tasks (with dependencies) to a thread-per-core-minus-one-atleast-one sized thread pool. This scales really well both upwards and downwards to any number of cores, and things actually happen in parallel, most of the time. Yes, you still have sync points that suck, but you can usually run much of the stuff between them in parallel, and with some thought, you can design your work queues so "useless time" (while a stage is not  ready) can be used to do background tasks.

You most likely have 1-2 moderately busy extra threads running anyway which are out of your control (e.g. audio mixer, GL server), hence having "minus one" on the total number of cores is probably a wise approach (this is a somewhat "unscientific" approach, but works for me).

To keep synchronization low, instead of submitting commands to the render thread's queue (this will require a lot of atomic operations or locking) you most probably want to do something similar as OpenGL is already doing in a very limited way with glDrawElementsIndirect, and what Vulkan will be doing much more elaborately:

Have a thread (any worker thread, or rather any number of them!) build a whole large buffer (or several) of several hundred or so commands, and submit that whole thing to the render queue from where the single thread that owns the GL context submits it with a single API call.

With "dropping commands", you hopefully mean dropping a complete frame worth of commands (I wasn't sure, initially it sounded to me like if e.g. te physics system can't keep up, the respective draws are skipped and only static geometry is rendered, that would be... catastrophic).

The thread pooling setup would be an interesting idea, the thing is that some of the functions aren't heavy enough to require an entire core devoted solely to a thread for it.

I guess I slightly misunderstood how the command buffers are supposed to work in Vulkan, but I see how having each thread maintain its own buffer, and then pushing that to the render queue would reduce synchronization.

Also, yes, by dropping commands, I do plan to drop an entire frame worth of commands, skipping out on physics objects, as you said, would be very bad.

Share on other sites

pushing that to the render queue would reduce synchronization.

A render-queue is for sorting objects for best draw order. It is a high-level construct that is used to reduce state changes.
You are only talking about command buffers. A render-queue is used before a command buffer to sort draw calls and reduce shader swaps, texture swaps, near-to-far, far-to-near, etc.

Anyway, what you describe is mostly a standard multi-threaded-render set-up. There are plenty of resources online regarding this, and it is heavily industry-proven.

If implemented correctly, you really don’t need to worry much about synchronization issues and overhead. You wouldn’t be locking every time you added a command, you would be locking a command buffer once, filling it, unlocking, and signalling that it is read to use.

There is also little to gain by doing this across multiple threads. 1 thread fills and 1 thread eats. At tri-Ace a 3rd thread does pre-render set-up to prepare for rendering, but you don’t need to worry about being that advanced for quite a while.

L. Spiro

Share on other sites

I did mean to talk about Command Buffers, I just suck at terminology :P

I understand that there isn't much to be gained on the OpenGL side, but I think this should help speed up my resource loading since that data will have more time to get loaded before it's needed (then again, since I recently learned how designing the model format so it could be put straight on to the GPU without much parsing would help load times, not sure how much this will matter with that in place as well).

Share on other sites

then again, since I recently learned how designing the model format so it could be put straight on to the GPU without much parsing would help load times, not sure how much this will matter with that in place as well

You still want to be able to load the model on a background thread, and then be able to have the upload to the GPU take place on the main (render) thread.

That might look like a UPLOAD command in your GPU buffer, with a read-only reference to the data it needs to upload. That way you can issue the upload from the background thread, and asynchronously upload the data to the GPU between frames.