Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 03 Feb 2008
Offline Last Active Yesterday, 12:10 PM

Posts I've Made

In Topic: Where to start (kind of)

26 August 2014 - 08:37 PM

If you just want to learn, then go ahead. Just keep in mind that AI and physics are very complicated subjects. Indie game development does require you to put on many hats, but efficient programmers sidestep all the complicated, hard and (subjectively) unfulfilling tasks. For example by using existing libraries, or by researching things previously done by others to reduce risk, time waste and simply learn faster. Everyone learns new things, all the time, in programming.


It could for example be fun to make your first BMP reader and writer: My advice would be to do research the things you think sound interesting, do the least complicated version of it in tandem with some actual implementation or even a tutorial if one exists.

Being second year at college, I don't know what that means, but it sounds like you are just starting out learning to program. If I were you I would focus on how to be efficient at learning what you set out to do. If I could travel back in time, I would tell that to myself 10 years ago.

In Topic: GL 3.3 glDrawElements VAO issue...AMD bug or my mistake?

20 August 2014 - 02:45 PM


Kind of a silly issue....but that is what i get for trying to cut corners on memory bandwidth, etc.  =P


No need to cut corners there unless you have actual bandwidth issues. I think even then it's suspect, especially since 3-bytes must be aligned to 4 even on modern, because there they just turn into extra instructions.

On modern cards misaligned accesses have minor impact, so packing the data more makes more sense there, I guess.

Very strange that it would just crash though, did you pack the struct so it didn't naturally align to a 4byte boundary? You can only align 1, 2, 4, 8 etc, btw.


While we're talking about performance: The only thing that really matters is that you don't split up your data into several structures. Like position + normals. The GPU will drop in speed exponentially.

See effects of strided access here: http://www.ncsa.illinois.edu/People/kindr/projects/hpca/files/singapore_p3.pdf


As long as the structs are packed, and the data can be read sequentially in memory, you are good.

In Topic: Resources on level editor creation?

20 August 2014 - 09:30 AM

Absolutely what Serapth said. Either Qt, if you really want to. C++ is very nice and all that.

Or, as I would personally recommend, C#. It can't get any easier than that. Making an editor is generally not the fun part, so the fact that it's easy to do can be a huge deal.

In Topic: OpenGL 3.0+ And VAOs

19 August 2014 - 05:57 PM

You don't have to, and in many cases don't want to use UBOs. I think the support is still very shaky, but I actually don't know the specifics. I have limited enviroments to test on.


Here is my VAO implementation:




Just like you said:

generate VAO

bind VAO


note that you don't want to enable attribs here, because you have no VBO bound

an enabled attrib is bound to the VBO you have bound, which means you can in theory have several VBOs with vertex data


generate VBO & IBO

bind VBO

upload data

enable attribs (use offsetof(struct, x))


(potentially bind IBO & upload data)


done. no need to unbind anything.

if you are using a wrapper for VAOs FBOs Textures and Shaders, these wrappers should manage this for you


Note that my implementation isn't 100% perfect. I even spotted grey areas just skimming through it right now, eg. indexes() doesn't do a bind() to make guarantee the IBO bind to work correctly. But it will hopefully give you an idea of how it all works.


When you upload data to a VBO you have a choice between GL_STATIC_DRAW and GL_STREAM_DRAW, the former for when your mesh is static and the latter for when you are re-uploading the data frequently. There are other flags, but afaik the drivers don't care.


So, with all that said, here are some tips:

1. You never really disable an attrib array, as you would just instead use a shader that doesn't utilize the specific attribute.

2. You should avoid unbinding anything, unless you absolutely have to.

3. Don't fall into the immediate mode trap for screenspace shaders, as suddenly glEnable(old_shit) matters, like GL_TEXTURE_2D.

I avoided this trap myself by having a very useful createScreenspace() function in my VAO implementation. :) Laziness > all.


Yes, when you unbind a VAO, you are suddenly back in old/VBO territory with gl*Pointer stuff, I guess. If you are in compatibility mode, like most people are.

In Topic: Advice on Simplifying

19 August 2014 - 11:25 AM

Right, again I wrote it so that you could try to follow what happened easier.


1. We figured out which pokemon the user selected

2. We turned that number into an index into the Pokemon-we-own array

3. We turned that index into a selected Pokemon, which is not a copy (notice no NEW keyword)

Instead it's just a reference, or better yet, just a name for a Pokemon existing somewhere else. It originally came from myPokemon[index].

The object will continue to stay alive/exist as long as the object has existing references.


An example:

Pokemon P1 = myPokemon[index];
Pokemon P2 = P1;
Pokemon P3 = P2;
Pokemon P4 = P3;
Pokemon P5 = P4;

Console.WriteLine(P5.Name + ", I choose you!");

So, now that I have a Pokemon named P5, which is a reference to the Pokemon named P4, which is ... to a Pokemon named P1, which is a reference to myPokemon[index].

They are all one and the same Pokemon.