View previous topic :: View next topic |
Author |
Message |
Labman
Joined: 05 Nov 2004 Posts: 51 Location: Brisbane, Australia
|
Posted: Fri Oct 09, 2009 3:14 am Post subject: Bad extension support |
|
|
Why say you support VBO but then don't actually support the function use.
When I use the glGenBuffers it just returns 0 which means no buffer. Nice work VIA, you guys are awesome! |
|
Back to top |
|
 |
reckless
Joined: 24 Jan 2008 Posts: 390 Location: inside tha debugger
|
Posted: Fri Oct 09, 2009 4:50 am Post subject: |
|
|
heh funny that you mention it i actually had the same experience a while back with the same function. actually in something as old as phoenix quake.
even the newest compiler on the newest platform os tells me that this function is null and void  |
|
Back to top |
|
 |
Labman
Joined: 05 Nov 2004 Posts: 51 Location: Brisbane, Australia
|
Posted: Tue Oct 13, 2009 4:35 am Post subject: |
|
|
Now its returning a valid buffer id but it segfaults when it tries to render the vbo  |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Tue Oct 13, 2009 9:16 am Post subject: |
|
|
What happens if you use self-chosen ids? _________________ What's a signature? |
|
Back to top |
|
 |
Labman
Joined: 05 Nov 2004 Posts: 51 Location: Brisbane, Australia
|
Posted: Fri Oct 30, 2009 8:27 pm Post subject: |
|
|
Just thought I should say that I was a bit quick to blame S3 here, was some weird stuff caused by the automatic opengl extension loading lib I was using. That and glBufferData and glBufferDataARB are not the same function. One works and one doesn't.
I've got it all working now but I didn't get any speedup from it  |
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 909
|
Posted: Fri Oct 30, 2009 9:04 pm Post subject: |
|
|
Labman wrote: | Just thought I should say that I was a bit quick to blame S3 here, was some weird stuff caused by the automatic opengl extension loading lib I was using. That and glBufferData and glBufferDataARB are not the same function. One works and one doesn't.
I've got it all working now but I didn't get any speedup from it  |
Are you locking and refilling it every frame? That's not good for VBOs, for the same reason as texture uploads during runtime aren't good. What you need is one single big VBO containing all of your static geometry (verts and texcoords don't change), then render each visible surfs from the surfs offset in that. Everything else needs to be done without a VBO. Even with the most optimal strategy (including use of shaders for any texcoord modification you do), a hardware VBO will only give about 10% speedup on Quake owing to the BSP architecture, so it's probably not worth it. Other apps with different architectures may give better or worse results. _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines |
|
Back to top |
|
 |
Labman
Joined: 05 Nov 2004 Posts: 51 Location: Brisbane, Australia
|
Posted: Sat Oct 31, 2009 11:04 pm Post subject: |
|
|
I upload the VBO once at the start of the application, I think that the lack of dedicated graphics memory is more likely the reason for no speed ups however. |
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 909
|
Posted: Sun Nov 01, 2009 12:00 am Post subject: |
|
|
Labman wrote: | I upload the VBO once at the start of the application, I think that the lack of dedicated graphics memory is more likely the reason for no speed ups however. |
Yeah, that would be correct. I've found the same in D3D. It's only really worthwhile on a hardware T&L card, and only really usable if you can modify verts and texcoords using shaders (otherwise you're stuck with totally static and scrolling textures, water warps, and suchlike won't work at all). _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines |
|
Back to top |
|
 |
|