- Joined
- Feb 17, 2012
- Messages
- 1,552
- Reaction score
- 2,604
Today I took some time for another iteration of the part of the code that has already been iterated over most of any other part: The cube mesh graphics.
The reason is, that I discovered the graphics to lag (sometimes more then 1 sec, which is unacceptable) with big view distances (25+) after zooming in and out of visibility for a couple of times. So I dug in the code and found out, that I was using a not optimal method of putting my cube meshes onto the graphics card memory.
Technical:
I was using glBufferData to change a VBO content, which is equivalent with an allocaion + memcpy, when I only need to allocate the buffer once and then fill it over and over again with the changed data. The function I'm using now is glBufferSubData, which does exactly that.
Though this did increase the graphics performance by a big deal, when loading in segments, it didn't solve the initial problem of the lag. So I researched and found out, that glBufferSubData can be slow with bigger chunks data. I have two portions of data to send to the graphics card: A small one, and a rather big one 768kb, and profiling that part of the code has shown that the lag exactly occurs when copying the big portion. So for this, I switched out glBufferSubData with a call to glMapBuffer, which as I read is much faster with chunks over 32kb.
This finally solved the problem.
Thanks for playing StarMade
- schema
The reason is, that I discovered the graphics to lag (sometimes more then 1 sec, which is unacceptable) with big view distances (25+) after zooming in and out of visibility for a couple of times. So I dug in the code and found out, that I was using a not optimal method of putting my cube meshes onto the graphics card memory.
Technical:
I was using glBufferData to change a VBO content, which is equivalent with an allocaion + memcpy, when I only need to allocate the buffer once and then fill it over and over again with the changed data. The function I'm using now is glBufferSubData, which does exactly that.
Though this did increase the graphics performance by a big deal, when loading in segments, it didn't solve the initial problem of the lag. So I researched and found out, that glBufferSubData can be slow with bigger chunks data. I have two portions of data to send to the graphics card: A small one, and a rather big one 768kb, and profiling that part of the code has shown that the lag exactly occurs when copying the big portion. So for this, I switched out glBufferSubData with a call to glMapBuffer, which as I read is much faster with chunks over 32kb.
This finally solved the problem.
Thanks for playing StarMade
- schema