Jump to content

  • Log In with Google      Sign In   
  • Create Account

melbow

Member Since 16 Feb 2009
Offline Last Active May 18 2014 03:20 AM

Posts I've Made

In Topic: Always use VAO or no?

18 January 2013 - 04:06 AM

OFF TOPIC: And gamedev.net desperately needs to update the mobile site. It has some very annoying design flaws and bugs...

In Topic: Always use VAO or no?

18 January 2013 - 04:03 AM

<blockquote class='ipsBlockquote'data-author="Aks9" data-cid="5022808" data-time="1358498689"><p>
<blockquote class='ipsBlockquote'data-author="melbow" data-cid="5022767" data-time="1358482777"><p>I'm sure there has to be a similar thread somewhere, but I can't find it. I was wondering, is there any reason not to use a VAO? And in the latest version of OpenGL, are all other forms of rendering deprecated?</p></blockquote>
<br />
In core profile VAO is mandatory. But it can be created, selected and forgotten. It is the way I'm using VAO. <span rel='lightbox'><img src='http://public.gamedev.net//public/style_emoticons/default/smile.png' alt='Posted Image' class='bbc_img' /></span><br />
VAO is not always the best way to do things. Try to make several VAOs and select them and compare to changing just one attribute in a single VAO. If you have to change many attributes at once, than just selecting a VAO is better. For a single attribute, or few of them... hm, I wouldn't bet. Also, mixing VAO and NVIDIA bindless is not a good idea.</p></blockquote>

Thank you! That is exactly what I needed to know.

In Topic: Always use VAO or no?

18 January 2013 - 12:17 AM

Thanks Irreversible. I know fixed-function is dead (as it should be), but wasn't sure if there was some scenerio where it might be better to call glVertexAttribPointer and not use a vertex array object.

I'm writing a wrapper for GL ES (for educational as well as practical applications) and was considering forcing the usage of VAOs. I guess I will go ahead with my plan then. Thanks again.

In Topic: Advanced Render Queue API

15 January 2013 - 04:48 PM

So I think I've managed to go full circle from virtual Draw methods to a Render Command Queue back to virtual Draw methods. It just doesn't seem worth it to do all this work just for a unified renderer when you could have a virtual Draw method and call it a day. If renderable objects are managed and batched prior to being made into RenderItems then as far as I can tell, you could just give the batch a Draw method and enqueue the batch.

I guess I don't really see the point of the Commands.

I am at a loss because I want to do this the right way, but I have too little experience with coding rendering APIs to know what that is. And please don't say, "There is no 'right way.'"

Could anybody recommend a book that covers render queues similar to what has been described by Hodgman?

In Topic: Advanced Render Queue API

13 January 2013 - 06:57 AM

Is the reason for storing StateGroups as a header and chunk of States that you make it more cache friendly due to locality?

Also, you say you store StateGroups in Resources. Am I correct in assuming some StateGroups must still be created at runtime, e.g. geometry instance transforms. And therefore RenderItems creation also cannot be done when the game object is initialized, but must be done every frame. Is this correct or am I completely off base?

PARTNERS