So it’s a question of how much vertex data your pushing around? If it is, how much more can I push? And should I care if all I’m doing is making small games with under 50k polygons?
First, we have the same idea about the struct-API.
Second, I see LWJGL as a binding to OpenGL/input.
So LWJGL will not benefit from structs, only the engines written around the wrappers, that do particle-engines for example, will benefit from structs.
I’m going to look for my Struct-classes, and see what the performance is. Last time I checked it was 50% of field-access… :
IIRC The last particle engine I made used a interleaved array and had a lot of put statements, probably would have been better with structs…
IMHO the speed issue is secondary - I have a tendancy to be lazy and just duplicate the structures (so I’ll have a bunch of objects which are the actual state, and these get pushed into a buffer as needed for rendering/io). The alternative of trying to keep the structures themselves in buffers ends up with clunky, awkward and error prone code which requires lots of superflours typing. And of course I’ve wasted a fair chunk of memory by having this duplication.
But of course I’m only doing low-poly 2d work. Even my most over the top particle systems don’t top 512 particles.
I do the same thing, I store all my particles in an array of Vertex and put them in a buffer every frame. I think structs would help me out here, but only if I needed a lot more particles. I’d have to do the same thing for animated models, so structs might help there too… Btw why is your particle system size a power of two? Is this really necessary?
It’s probably not really nessesary, bit of a C/C++ hangover there.
I’m also a fan of powers of two 
I’ve bit the bullet, and started a blogger account. Will dig out the missing 2nd half of this (only a couple of paras IIRC) or just rewrite it, and post asap. Possibly in the next half hour, if I dont get distracted ;).
lets see if I get this right.
so you want to pull non-jvm memory into the jvm. from a within-the-jvm-perspective(the developers perspective/the OO kinda thing/the code) there is only Non-jvm memory since you don’t handle jvm-memory from inside the jvm (and,as noted, you never should) so it’s save to reguard and refer to non-jvm from within-the-jvm simply as memory since thats the only type of memory known inside the jvm. perhaps I should grant you some whitespaces to let that sink in.
ok Now we could declare a class Memory to create an abstract representation of memory. Now we don’t want to dance with the whole memory just parts. hmm what to name those parts? Wenn figuring out a name a good name it useally helps to ask youself what you do with the object we read and write a to part or subsection/subcollection of the memory. Hmm read write isn’t that input an output? now the obivous question that comes from this is how do we call a subsection of memory that we use for input and output: oi offcourse a buffer.
now the ppl paying attention will note how we already have that in NIO. and since we can obtain already buffers we don’t need to write new code. (so we can trash that Memory class)
for the actual problem/issue the separate primitives that you can get from the buffer and are pritty meanless and simply don’t fit in our OO world. We don’t want do deal with indexes as an developer we deal with Ordered and unordered Elements/Objects, choosing ordered or unorded depending on if the order has added value. things like memory adress or the index on top of that existing buffer(because of the buffer already abstracting away memory adresses) are meaningless. We want objects that hold a few elements resp variables resp fields that abstractly represent something like a Coordinate Vertex Population or what not. We want the object and we want it to be in the memory.
from the memory perspective there are no objects there is an index(memory adress) and a value. So in order to get what we want we must Map the value and multiplex it to an Object. multiplex? you might think well yeah we strip the index/indentifier infavor for a posision or hierarchy overviewed by the as the position seperates them/ makes them indentifiable from eachother(instead of the index).
In a nutshell what we want is a mapping of a collection of a group of values where we want that group to be astractly represented as an Object in our code.
now as someone already correcly noted this creates a lot of Objects. Objects that only hold a couple of state’s which seem to perfectly lent themselfs to apply the flyweight pattern to.
ok guys if that didn’t make any sense it could be any of the following reasons:
- I didn’t get it, so it’s incorrect.
- I was sleepy so I made mistakes which lead to inconsistency and what not
- my formulation sucks
etc
I’m gonna reread it in the morning and edit it, good night.