zdoom/qzdoom
0
0
Fork 0
mirror of https://github.com/ZDoom/qzdoom.git synced 2024-12-16 15:31:30 +00:00
Code Issues Projects Releases Packages Wiki Activity
qzdoom/src/gl/data/gl_vertexbuffer.cpp

397 lines
12 KiB
C++
Raw Normal View History

- added GL render as of SVN revision 1600.
2013-06-23 07:49:34 +00:00
/*
** glc_vertexbuffer.cpp
** Vertex buffer handling.
**
**---------------------------------------------------------------------------
** Copyright 2005 Christoph Oelckers
** All rights reserved.
**
** Redistribution and use in source and binary forms, with or without
** modification, are permitted provided that the following conditions
** are met:
**
** 1. Redistributions of source code must retain the above copyright
** notice, this list of conditions and the following disclaimer.
** 2. Redistributions in binary form must reproduce the above copyright
** notice, this list of conditions and the following disclaimer in the
** documentation and/or other materials provided with the distribution.
** 3. The name of the author may not be used to endorse or promote products
** derived from this software without specific prior written permission.
** 4. When not used as part of GZDoom or a GZDoom derivative, this code will be
** covered by the terms of the GNU Lesser General Public License as published
** by the Free Software Foundation; either version 2.1 of the License, or (at
** your option) any later version.
** 5. Full disclosure of the entire project's source code, except for third
** party libraries is mandatory. (NOTE: This clause is non-negotiable!)
**
** THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
** IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
** OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
** IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
** INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
** NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
** DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
** THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
** (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
** THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
**---------------------------------------------------------------------------
**
*/
#include "gl/system/gl_system.h"
#include "doomtype.h"
#include "p_local.h"
- missing #includes in GL code.
2016-02-16 21:01:04 +00:00
#include "r_state.h"
- added GL render as of SVN revision 1600.
2013-06-23 07:49:34 +00:00
#include "m_argv.h"
#include "c_cvars.h"
- moved GLEXT API out of RenderContext struct.
2013-09-03 16:29:39 +00:00
#include "gl/system/gl_interface.h"
- added GL render as of SVN revision 1600.
2013-06-23 07:49:34 +00:00
#include "gl/renderer/gl_renderer.h"
- implement model vertex buffer and draw MD2 models using it instead of using the GLCommands from the model.
2014-06-29 21:24:16 +00:00
#include "gl/shaders/gl_shader.h"
- added GL render as of SVN revision 1600.
2013-06-23 07:49:34 +00:00
#include "gl/data/gl_data.h"
#include "gl/data/gl_vertexbuffer.h"
//==========================================================================
//
// Create / destroy the VBO
//
//==========================================================================
- got rid of VAO's. they have no impact on performance and are a general nuisance if some render paths cannot use them. - cleaned up gl_interface and removed gl.compatibility.
2016-04-26 14:26:34 +00:00
FVertexBuffer::FVertexBuffer(bool wantbuffer)
- added GL render as of SVN revision 1600.
2013-06-23 07:49:34 +00:00
{
- got rid of VAO's. they have no impact on performance and are a general nuisance if some render paths cannot use them. - cleaned up gl_interface and removed gl.compatibility.
2016-04-26 14:26:34 +00:00
vbo_id = 0;
if (wantbuffer) glGenBuffers(1, &vbo_id);
- added GL render as of SVN revision 1600.
2013-06-23 07:49:34 +00:00
}
FVertexBuffer::~FVertexBuffer()
{
if (vbo_id != 0)
{
- moved GLEXT API out of RenderContext struct.
2013-09-03 16:29:39 +00:00
glDeleteBuffers(1, &vbo_id);
- added GL render as of SVN revision 1600.
2013-06-23 07:49:34 +00:00
}
}
//==========================================================================
//
//
//
//==========================================================================
FFlatVertexBuffer::FFlatVertexBuffer()
- got rid of VAO's. they have no impact on performance and are a general nuisance if some render paths cannot use them. - cleaned up gl_interface and removed gl.compatibility.
2016-04-26 14:26:34 +00:00
: FVertexBuffer(!!(gl.flags & RFL_BUFFER_STORAGE))
- added GL render as of SVN revision 1600.
2013-06-23 07:49:34 +00:00
{
- lowered requirements of GL 2.x to OpenGL 3.3. There was one issue preventing the previous 2.0 betas from running under GL 3.x: The lack of persistently mapped buffers. For the dynamic light buffer today's changes take care of that problem. For the vertex buffer there is no good workaround but we can use immediate mode render calls instead which have been reinstated. To handle the current setup, the engine first tries to get a core profile context and checks for presence of GL 4.4 or the GL_ARB_buffer_storage extension. If this fails the context is deleted again and a compatibility context retrieved which is then used for 'old style' rendering which does work on older GL versions. This new version does not support GL 3.2 or lower, meaning that Intel GMA 3000 or lower is not supported. The reason for this is that the engine uses a few GL 3.3 features which are not present in the latest Intel driver. In general the Intel GMA 3000 is far too weak, though, to run the demanding shader of GZDoom 2.x, so this is no real loss. Performance would be far from satisfying. A command line option '-gl3' exists to force the fallback render path. On my Geforce 550Ti there's approx. 10% performance loss on this path.
2014-08-19 13:56:33 +00:00
if (gl.flags & RFL_BUFFER_STORAGE)
{
unsigned int bytesize = BUFFER_SIZE * sizeof(FFlatVertex);
glBindBuffer(GL_ARRAY_BUFFER, vbo_id);
glBufferStorage(GL_ARRAY_BUFFER, bytesize, NULL, GL_MAP_WRITE_BIT | GL_MAP_PERSISTENT_BIT | GL_MAP_COHERENT_BIT);
map = (FFlatVertex*)glMapBufferRange(GL_ARRAY_BUFFER, 0, bytesize, GL_MAP_WRITE_BIT | GL_MAP_PERSISTENT_BIT | GL_MAP_COHERENT_BIT);
}
else
{
- got rid of VAO's. they have no impact on performance and are a general nuisance if some render paths cannot use them. - cleaned up gl_interface and removed gl.compatibility.
2016-04-26 14:26:34 +00:00
// The fallback path uses immediate mode rendering and does not set up an actual vertex buffer
- lowered requirements of GL 2.x to OpenGL 3.3. There was one issue preventing the previous 2.0 betas from running under GL 3.x: The lack of persistently mapped buffers. For the dynamic light buffer today's changes take care of that problem. For the vertex buffer there is no good workaround but we can use immediate mode render calls instead which have been reinstated. To handle the current setup, the engine first tries to get a core profile context and checks for presence of GL 4.4 or the GL_ARB_buffer_storage extension. If this fails the context is deleted again and a compatibility context retrieved which is then used for 'old style' rendering which does work on older GL versions. This new version does not support GL 3.2 or lower, meaning that Intel GMA 3000 or lower is not supported. The reason for this is that the engine uses a few GL 3.3 features which are not present in the latest Intel driver. In general the Intel GMA 3000 is far too weak, though, to run the demanding shader of GZDoom 2.x, so this is no real loss. Performance would be far from satisfying. A command line option '-gl3' exists to force the fallback render path. On my Geforce 550Ti there's approx. 10% performance loss on this path.
2014-08-19 13:56:33 +00:00
vbo_shadowdata.Reserve(BUFFER_SIZE);
map = &vbo_shadowdata[0];
}
- decided to restrict the 2.0 beta to OpenGL 4.x with GL_ARB_buffer_storage extension and removed all code for supporting older versions. Sadly, anything else makes no sense. All the recently made changes live or die, depending on this extension's presence. Without it, there are major performance issues with the buffer uploads. All of the traditional buffer upload methods are without exception horrendously slow, especially in the context of a Doom engine where frequent small updates are required. It could be solved with a complete restructuring of the engine, of course, but that's hardly worth the effort, considering it's only for legacy hardware whose market share will inevitably shrink considerably over the next years. And even then, under the best circumstances I'd still get the same performance as the old immediate mode renderer in GZDoom 1.x and still couldn't implement the additions I'd like to make. So, since I need to keep GZDoom 1.x around anyway for older GL 2.x hardware, it may as well serve for 3.x hardware, too. It's certainly less work than constantly trying to find workarounds for the older hardware's limitations that cost more time than working on future-proofing the engine. This new, trimmed down 4.x renderer runs on a core profile configuration and uses persistently mapped buffers for nearly everything that is getting transferred to the GPU. (The global uniforms are still being used as such but they'll be phased out after the first beta release.
2014-08-01 20:42:39 +00:00
mNumReserved = mIndex = mCurIndex = 0;
- added GL render as of SVN revision 1600.
2013-06-23 07:49:34 +00:00
}
FFlatVertexBuffer::~FFlatVertexBuffer()
{
- lowered requirements of GL 2.x to OpenGL 3.3. There was one issue preventing the previous 2.0 betas from running under GL 3.x: The lack of persistently mapped buffers. For the dynamic light buffer today's changes take care of that problem. For the vertex buffer there is no good workaround but we can use immediate mode render calls instead which have been reinstated. To handle the current setup, the engine first tries to get a core profile context and checks for presence of GL 4.4 or the GL_ARB_buffer_storage extension. If this fails the context is deleted again and a compatibility context retrieved which is then used for 'old style' rendering which does work on older GL versions. This new version does not support GL 3.2 or lower, meaning that Intel GMA 3000 or lower is not supported. The reason for this is that the engine uses a few GL 3.3 features which are not present in the latest Intel driver. In general the Intel GMA 3000 is far too weak, though, to run the demanding shader of GZDoom 2.x, so this is no real loss. Performance would be far from satisfying. A command line option '-gl3' exists to force the fallback render path. On my Geforce 550Ti there's approx. 10% performance loss on this path.
2014-08-19 13:56:33 +00:00
if (gl.flags & RFL_BUFFER_STORAGE)
{
glBindBuffer(GL_ARRAY_BUFFER, vbo_id);
glUnmapBuffer(GL_ARRAY_BUFFER);
glBindBuffer(GL_ARRAY_BUFFER, 0);
}
}
- got rid of VAO's. they have no impact on performance and are a general nuisance if some render paths cannot use them. - cleaned up gl_interface and removed gl.compatibility.
2016-04-26 14:26:34 +00:00
void FFlatVertexBuffer::BindVBO()
{
glBindBuffer(GL_ARRAY_BUFFER, vbo_id);
if (vbo_id != 0) // set this up only if there is an actual buffer.
{
glVertexAttribPointer(VATTR_VERTEX, 3, GL_FLOAT, false, sizeof(FFlatVertex), &VTO->x);
glVertexAttribPointer(VATTR_TEXCOORD, 2, GL_FLOAT, false, sizeof(FFlatVertex), &VTO->u);
glEnableVertexAttribArray(VATTR_VERTEX);
glEnableVertexAttribArray(VATTR_TEXCOORD);
}
else
{
glDisableVertexAttribArray(VATTR_VERTEX);
glDisableVertexAttribArray(VATTR_TEXCOORD);
}
glDisableVertexAttribArray(VATTR_COLOR);
glDisableVertexAttribArray(VATTR_VERTEX2);
}
- lowered requirements of GL 2.x to OpenGL 3.3. There was one issue preventing the previous 2.0 betas from running under GL 3.x: The lack of persistently mapped buffers. For the dynamic light buffer today's changes take care of that problem. For the vertex buffer there is no good workaround but we can use immediate mode render calls instead which have been reinstated. To handle the current setup, the engine first tries to get a core profile context and checks for presence of GL 4.4 or the GL_ARB_buffer_storage extension. If this fails the context is deleted again and a compatibility context retrieved which is then used for 'old style' rendering which does work on older GL versions. This new version does not support GL 3.2 or lower, meaning that Intel GMA 3000 or lower is not supported. The reason for this is that the engine uses a few GL 3.3 features which are not present in the latest Intel driver. In general the Intel GMA 3000 is far too weak, though, to run the demanding shader of GZDoom 2.x, so this is no real loss. Performance would be far from satisfying. A command line option '-gl3' exists to force the fallback render path. On my Geforce 550Ti there's approx. 10% performance loss on this path.
2014-08-19 13:56:33 +00:00
//==========================================================================
//
// immediate mode fallback for drivers without GL_ARB_buffer_storage
//
// No single core method is performant enough to handle this adequately
// so we have to resort to immediate mode instead...
//
//==========================================================================
void FFlatVertexBuffer::ImmRenderBuffer(unsigned int primtype, unsigned int offset, unsigned int count)
{
// this will only get called if we can't acquire a persistently mapped buffer.
#ifndef CORE_PROFILE
glBegin(primtype);
- got rid of VAO's. they have no impact on performance and are a general nuisance if some render paths cannot use them. - cleaned up gl_interface and removed gl.compatibility.
2016-04-26 14:26:34 +00:00
if (gl.glslversion > 0)
- lowered requirements of GL 2.x to OpenGL 3.3. There was one issue preventing the previous 2.0 betas from running under GL 3.x: The lack of persistently mapped buffers. For the dynamic light buffer today's changes take care of that problem. For the vertex buffer there is no good workaround but we can use immediate mode render calls instead which have been reinstated. To handle the current setup, the engine first tries to get a core profile context and checks for presence of GL 4.4 or the GL_ARB_buffer_storage extension. If this fails the context is deleted again and a compatibility context retrieved which is then used for 'old style' rendering which does work on older GL versions. This new version does not support GL 3.2 or lower, meaning that Intel GMA 3000 or lower is not supported. The reason for this is that the engine uses a few GL 3.3 features which are not present in the latest Intel driver. In general the Intel GMA 3000 is far too weak, though, to run the demanding shader of GZDoom 2.x, so this is no real loss. Performance would be far from satisfying. A command line option '-gl3' exists to force the fallback render path. On my Geforce 550Ti there's approx. 10% performance loss on this path.
2014-08-19 13:56:33 +00:00
{
- add shader patching to allow running the engine with GLSL 1.2. - made some initial preparations for the shader-less fallback path.
2016-04-26 13:01:23 +00:00
for (unsigned int i = 0; i < count; i++)
{
glVertexAttrib2fv(VATTR_TEXCOORD, &map[offset + i].u);
glVertexAttrib3fv(VATTR_VERTEX, &map[offset + i].x);
}
}
else // no shader means no vertex attributes, so use the old stuff instead.
{
for (unsigned int i = 0; i < count; i++)
{
glTexCoord2fv(&map[offset + i].u);
glVertex3fv(&map[offset + i].x);
}
- lowered requirements of GL 2.x to OpenGL 3.3. There was one issue preventing the previous 2.0 betas from running under GL 3.x: The lack of persistently mapped buffers. For the dynamic light buffer today's changes take care of that problem. For the vertex buffer there is no good workaround but we can use immediate mode render calls instead which have been reinstated. To handle the current setup, the engine first tries to get a core profile context and checks for presence of GL 4.4 or the GL_ARB_buffer_storage extension. If this fails the context is deleted again and a compatibility context retrieved which is then used for 'old style' rendering which does work on older GL versions. This new version does not support GL 3.2 or lower, meaning that Intel GMA 3000 or lower is not supported. The reason for this is that the engine uses a few GL 3.3 features which are not present in the latest Intel driver. In general the Intel GMA 3000 is far too weak, though, to run the demanding shader of GZDoom 2.x, so this is no real loss. Performance would be far from satisfying. A command line option '-gl3' exists to force the fallback render path. On my Geforce 550Ti there's approx. 10% performance loss on this path.
2014-08-19 13:56:33 +00:00
}
glEnd();
#endif
- added GL render as of SVN revision 1600.
2013-06-23 07:49:34 +00:00
}
//==========================================================================
//
// Initialize a single vertex
//
//==========================================================================
void FFlatVertex::SetFlatVertex(vertex_t *vt, const secplane_t & plane)
{
- floatified vertices and removed the now redundant fx and fy members. This needs an added check for polyobject origins, though, so that such subsectors don't get rendered.
2016-04-03 09:40:14 +00:00
x = vt->fX();
y = vt->fY();
z = plane.ZatPoint(vt);
u = vt->fX()/64.f;
v = -vt->fY()/64.f;
- added GL render as of SVN revision 1600.
2013-06-23 07:49:34 +00:00
}
//==========================================================================
//
// Find a 3D floor
//
//==========================================================================
static F3DFloor *Find3DFloor(sector_t *target, sector_t *model)
{
for(unsigned i=0; i<target->e->XFloor.ffloors.Size(); i++)
{
F3DFloor *ffloor = target->e->XFloor.ffloors[i];
if (ffloor->model == model) return ffloor;
}
return NULL;
}
//==========================================================================
//
// Creates the vertices for one plane in one subsector
//
//==========================================================================
int FFlatVertexBuffer::CreateSubsectorVertices(subsector_t *sub, const secplane_t &plane, int floor)
{
int idx = vbo_shadowdata.Reserve(sub->numlines);
for(unsigned int k=0; k<sub->numlines; k++, idx++)
{
vbo_shadowdata[idx].SetFlatVertex(sub->firstline[k].v1, plane);
if (sub->sector->transdoor && floor) vbo_shadowdata[idx].z -= 1.f;
}
return idx;
}
//==========================================================================
//
// Creates the vertices for one plane in one subsector
//
//==========================================================================
int FFlatVertexBuffer::CreateSectorVertices(sector_t *sec, const secplane_t &plane, int floor)
{
int rt = vbo_shadowdata.Size();
// First calculate the vertices for the sector itself
for(int j=0; j<sec->subsectorcount; j++)
{
subsector_t *sub = sec->subsectors[j];
CreateSubsectorVertices(sub, plane, floor);
}
return rt;
}
//==========================================================================
//
//
//
//==========================================================================
int FFlatVertexBuffer::CreateVertices(int h, sector_t *sec, const secplane_t &plane, int floor)
{
// First calculate the vertices for the sector itself
sec->vboheight[h] = sec->GetPlaneTexZ(h);
sec->vboindex[h] = CreateSectorVertices(sec, plane, floor);
// Next are all sectors using this one as heightsec
TArray<sector_t *> &fakes = sec->e->FakeFloor.Sectors;
for (unsigned g=0; g<fakes.Size(); g++)
{
sector_t *fsec = fakes[g];
fsec->vboindex[2+h] = CreateSectorVertices(fsec, plane, false);
}
// and finally all attached 3D floors
TArray<sector_t *> &xf = sec->e->XFloor.attached;
for (unsigned g=0; g<xf.Size(); g++)
{
sector_t *fsec = xf[g];
F3DFloor *ffloor = Find3DFloor(fsec, sec);
if (ffloor != NULL && ffloor->flags & FF_RENDERPLANES)
{
bool dotop = (ffloor->top.model == sec) && (ffloor->top.isceiling == h);
bool dobottom = (ffloor->bottom.model == sec) && (ffloor->bottom.isceiling == h);
if (dotop || dobottom)
{
if (dotop) ffloor->top.vindex = vbo_shadowdata.Size();
if (dobottom) ffloor->bottom.vindex = vbo_shadowdata.Size();
CreateSectorVertices(fsec, plane, false);
}
}
}
sec->vbocount[h] = vbo_shadowdata.Size() - sec->vboindex[h];
return sec->vboindex[h];
}
//==========================================================================
//
//
//
//==========================================================================
void FFlatVertexBuffer::CreateFlatVBO()
{
for (int h = sector_t::floor; h <= sector_t::ceiling; h++)
{
for(int i=0; i<numsectors;i++)
{
CreateVertices(h, &sectors[i], sectors[i].GetSecPlane(h), h == sector_t::floor);
}
}
// We need to do a final check for Vavoom water and FF_FIX sectors.
// No new vertices are needed here. The planes come from the actual sector
for(int i=0; i<numsectors;i++)
{
for(unsigned j=0;j<sectors[i].e->XFloor.ffloors.Size(); j++)
{
F3DFloor *ff = sectors[i].e->XFloor.ffloors[j];
if (ff->top.model == &sectors[i])
{
ff->top.vindex = sectors[i].vboindex[ff->top.isceiling];
}
if (ff->bottom.model == &sectors[i])
{
ff->bottom.vindex = sectors[i].vboindex[ff->top.isceiling];
}
}
}
}
//==========================================================================
//
//
//
//==========================================================================
void FFlatVertexBuffer::UpdatePlaneVertices(sector_t *sec, int plane)
{
int startvt = sec->vboindex[plane];
int countvt = sec->vbocount[plane];
secplane_t &splane = sec->GetSecPlane(plane);
FFlatVertex *vt = &vbo_shadowdata[startvt];
- rewrote vertex buffer code to require GL_ARB_BUFFER_STORAGE extension. This means it won't work anymore on anything that doesn't support OpenGL 4.0, but I don't think this is a problem. On older NVidia cards performance gains could not be seen and on older AMDs using the vertex buffer was even worse as long as it got mixed with immediate mode rendering.
2014-05-10 19:47:07 +00:00
FFlatVertex *mapvt = &map[startvt];
- fixed: Plane height changes only updated the first buffered vertex for the respective plane.
2014-06-15 08:18:46 +00:00
for(int i=0; i<countvt; i++, vt++, mapvt++)
- added GL render as of SVN revision 1600.
2013-06-23 07:49:34 +00:00
{
vt->z = splane.ZatPoint(vt->x, vt->y);
if (plane == sector_t::floor && sec->transdoor) vt->z -= 1;
- rewrote vertex buffer code to require GL_ARB_BUFFER_STORAGE extension. This means it won't work anymore on anything that doesn't support OpenGL 4.0, but I don't think this is a problem. On older NVidia cards performance gains could not be seen and on older AMDs using the vertex buffer was even worse as long as it got mixed with immediate mode rendering.
2014-05-10 19:47:07 +00:00
mapvt->z = vt->z;
- added GL render as of SVN revision 1600.
2013-06-23 07:49:34 +00:00
}
}
//==========================================================================
//
//
//
//==========================================================================
void FFlatVertexBuffer::CreateVBO()
{
- lowered requirements of GL 2.x to OpenGL 3.3. There was one issue preventing the previous 2.0 betas from running under GL 3.x: The lack of persistently mapped buffers. For the dynamic light buffer today's changes take care of that problem. For the vertex buffer there is no good workaround but we can use immediate mode render calls instead which have been reinstated. To handle the current setup, the engine first tries to get a core profile context and checks for presence of GL 4.4 or the GL_ARB_buffer_storage extension. If this fails the context is deleted again and a compatibility context retrieved which is then used for 'old style' rendering which does work on older GL versions. This new version does not support GL 3.2 or lower, meaning that Intel GMA 3000 or lower is not supported. The reason for this is that the engine uses a few GL 3.3 features which are not present in the latest Intel driver. In general the Intel GMA 3000 is far too weak, though, to run the demanding shader of GZDoom 2.x, so this is no real loss. Performance would be far from satisfying. A command line option '-gl3' exists to force the fallback render path. On my Geforce 550Ti there's approx. 10% performance loss on this path.
2014-08-19 13:56:33 +00:00
if (gl.flags & RFL_BUFFER_STORAGE)
{
vbo_shadowdata.Resize(mNumReserved);
CreateFlatVBO();
mCurIndex = mIndex = vbo_shadowdata.Size();
memcpy(map, &vbo_shadowdata[0], vbo_shadowdata.Size() * sizeof(FFlatVertex));
}
else if (sectors)
{
// set all VBO info to invalid values so that we can save some checks in the rendering code
for(int i=0;i<numsectors;i++)
{
sectors[i].vboindex[3] = sectors[i].vboindex[2] =
sectors[i].vboindex[1] = sectors[i].vboindex[0] = -1;
- made the adjustments.
2016-04-24 11:35:43 +00:00
sectors[i].vboheight[1] = sectors[i].vboheight[0] = FLT_MIN;
- lowered requirements of GL 2.x to OpenGL 3.3. There was one issue preventing the previous 2.0 betas from running under GL 3.x: The lack of persistently mapped buffers. For the dynamic light buffer today's changes take care of that problem. For the vertex buffer there is no good workaround but we can use immediate mode render calls instead which have been reinstated. To handle the current setup, the engine first tries to get a core profile context and checks for presence of GL 4.4 or the GL_ARB_buffer_storage extension. If this fails the context is deleted again and a compatibility context retrieved which is then used for 'old style' rendering which does work on older GL versions. This new version does not support GL 3.2 or lower, meaning that Intel GMA 3000 or lower is not supported. The reason for this is that the engine uses a few GL 3.3 features which are not present in the latest Intel driver. In general the Intel GMA 3000 is far too weak, though, to run the demanding shader of GZDoom 2.x, so this is no real loss. Performance would be far from satisfying. A command line option '-gl3' exists to force the fallback render path. On my Geforce 550Ti there's approx. 10% performance loss on this path.
2014-08-19 13:56:33 +00:00
}
}
- added GL render as of SVN revision 1600.
2013-06-23 07:49:34 +00:00
}
//==========================================================================
//
//
//
//==========================================================================
void FFlatVertexBuffer::CheckPlanes(sector_t *sector)
{
- reenabled the flat vertex buffer for GL 3.x NVidia hardware. On AMD and Intel it'll stay off because past tests have shown that it won't improve performance at all.
2014-07-27 11:46:35 +00:00
if (sector->GetPlaneTexZ(sector_t::ceiling) != sector->vboheight[sector_t::ceiling])
- added GL render as of SVN revision 1600.
2013-06-23 07:49:34 +00:00
{
- reenabled the flat vertex buffer for GL 3.x NVidia hardware. On AMD and Intel it'll stay off because past tests have shown that it won't improve performance at all.
2014-07-27 11:46:35 +00:00
UpdatePlaneVertices(sector, sector_t::ceiling);
sector->vboheight[sector_t::ceiling] = sector->GetPlaneTexZ(sector_t::ceiling);
}
if (sector->GetPlaneTexZ(sector_t::floor) != sector->vboheight[sector_t::floor])
{
UpdatePlaneVertices(sector, sector_t::floor);
sector->vboheight[sector_t::floor] = sector->GetPlaneTexZ(sector_t::floor);
- added GL render as of SVN revision 1600.
2013-06-23 07:49:34 +00:00
}
}
//==========================================================================
//
// checks the validity of all planes attached to this sector
- reenabled the flat vertex buffer for GL 3.x NVidia hardware. On AMD and Intel it'll stay off because past tests have shown that it won't improve performance at all.
2014-07-27 11:46:35 +00:00
// and updates them if possible.
- added GL render as of SVN revision 1600.
2013-06-23 07:49:34 +00:00
//
//==========================================================================
void FFlatVertexBuffer::CheckUpdate(sector_t *sector)
{
- lowered requirements of GL 2.x to OpenGL 3.3. There was one issue preventing the previous 2.0 betas from running under GL 3.x: The lack of persistently mapped buffers. For the dynamic light buffer today's changes take care of that problem. For the vertex buffer there is no good workaround but we can use immediate mode render calls instead which have been reinstated. To handle the current setup, the engine first tries to get a core profile context and checks for presence of GL 4.4 or the GL_ARB_buffer_storage extension. If this fails the context is deleted again and a compatibility context retrieved which is then used for 'old style' rendering which does work on older GL versions. This new version does not support GL 3.2 or lower, meaning that Intel GMA 3000 or lower is not supported. The reason for this is that the engine uses a few GL 3.3 features which are not present in the latest Intel driver. In general the Intel GMA 3000 is far too weak, though, to run the demanding shader of GZDoom 2.x, so this is no real loss. Performance would be far from satisfying. A command line option '-gl3' exists to force the fallback render path. On my Geforce 550Ti there's approx. 10% performance loss on this path.
2014-08-19 13:56:33 +00:00
if (gl.flags & RFL_BUFFER_STORAGE)
{
CheckPlanes(sector);
sector_t *hs = sector->GetHeightSec();
if (hs != NULL) CheckPlanes(hs);
for (unsigned i = 0; i < sector->e->XFloor.ffloors.Size(); i++)
CheckPlanes(sector->e->XFloor.ffloors[i]->model);
}
- added GL render as of SVN revision 1600.
2013-06-23 07:49:34 +00:00
}
Reference in a new issue Copy permalink