Jump to content

  • Log In with Google      Sign In   
  • Create Account


StasB

Member Since 10 Jul 2008
Offline Last Active Feb 20 2013 08:00 PM

Posts I've Made

In Topic: Projecting Textures

10 October 2012 - 11:47 AM

I didn't know texture coordinates had Z and W components. I think I get it now. I guess I should do some more reading about how OpenGL works. Thanks, guys.

In Topic: Projecting Textures

10 October 2012 - 10:12 AM

I don't understand.
Getting the texture coordinate for a world vertex involves a division by the distance from the projector's near plane. That's a non-linear function. =S

In Topic: Wrapping OpenGL Calls

09 March 2012 - 10:23 AM

If you're going for a higher level graphics engine you should not think about how to wrap OpenGL. Instead you should think about how you'd like to make the calls to render something and then fill that in by using OpenGL. You might need a few iterations of adjusting requirements due to api specific limitations but you'll end up with a system that's easy to use, which is one of the most important things for anything high level.

To answer your question, my glBindBuffer calls are checked in the implementation of the Renderer class just by comparing ints like suggested by the poster above. I'm not doing this in the state manager because i've defined that to be managing render states like cullmode, blend mode, alpha testing etc etc. I gues you could do that in the state manager aswell, it doesnt really matter.

On a side note, maybe managing glBindBuffer calls isn't your biggest problem if you're worried about redundant state changes performance loss. Other state changes like shader and texture binds will probably be a lot more expensive and your buffer count will be very low when you've implemented batching.


What's wrong with an intermediate layer to ease up the task of writing a higher-level engine? I have no intentions of writing a big general-purpose graphics engine. If I wanted one, there are many available. I write small apps with widely varying requirements that don't usually fit a standard engine architecture and I find myself writing over and over again heaps of OGL code to handle low-level tasks like setting up and rendering FBOs, VBOs etc.

In Topic: Wrapping OpenGL Calls

09 March 2012 - 09:54 AM

well, while wrapping the whole api is possible, in my opinion its rather pointless. You might want to write a state manager as suggested, but I think that you shouldn't wrap everything, but rather certain functionality (mesh loading, texture loading, shader loading etc.) which enables you to use OGL without making a single error, because the wrapper class takes care of it.

for ex. you could say that the current buffer stored would be:
struct buffer_state
{
GLuint buffer;
GLenum target;
} current_buffer_state;

and you could implement a function that checks if the current buffer bound is the one you pass to it, and in that case it wouldn't call the OGL function:
void my_bind_buffer(GLenum target, GLuint buffer)
{
if(current_buffer_state.buffer != buffer || current_buffer_state.target != target) //check the current state
{
if(glIsBuffer(buffer)) //check if it is really a buffer
{
glBindBuffer(target, buffer);
}
}
}

or something like this...
you might want to check out pixellight for a whole api wrap example.

when your app starts up you could just simply query the current gl state with glGet* to initialize your states


Basically, here's my problem:
I need to write my own versions of the OGL state-setter functions I care for that check for redundant state changes. Some of those functions take a parameter that specifies which state to change, like glBindBuffer. Ideally, if I write a glBindBuffer wrapper, it better act like the original, accept a target parameter and handle it correctly. How do I do that without manually writing special code for every type of target?

In Topic: Wrapping OpenGL Calls

09 March 2012 - 08:30 AM

Yes it's possible, it's called object orientation. You create classes with specific responsibilities. This will add a very tiny mini overhead but it's more than worth it. The trick is to pull your classes to an as high as possible level of abstraction without creating overly complex class responsibilities. For example, who sais you're using VBOs, maybe you've just got some vertex data that needs to be rendered however the implementation sees fit.

To counter the state changes you might end up with a state manager which only changes state if it is required.


I thought it was clear from my OP that object orientation is what I'm trying to achieve. I'm just worried about the performance penalties from redundant state changes.
I just want a thin and convenient layer on top of plain OpenGL to ease up the task of writing a higher-level graphics engine. I thought about making a state manager, but I'm not sure how to go about it. How would you go about wrapping "void glBindBuffer( GLenum target, GLuint buffer)", for example?

PARTNERS