For those wondering why we need the functionality to allocate page aligned ByteBuffers: ever since Java 1.4 every ByteBuffer you allocated was page-aligned (typically 4K). Since Java7 this is no longer the case, and there doesn't seem to be any functionality in the Java API to allocate them the old way, except for a commandline parameter, which sets a global flag.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

Create a lightweight API to get familiar with the concept of mapping fields

Closer to the concept of structs (as opposed to struct-pointers)

Most games using this library will use mapped objects as a way to prevent data-copies of VBO data. Game entities by nature are heavily object oriented and therefore are designed to be convenient in use, not necessarily reduced memory footprint. Having 1 game entity holding (mapped) data pointing to 1 area of memory is a likely occurence. The (previous) MappedObject class was way too heavy-weight for this usage, so has been renamed and built on a simplified MappedObject class, that always points to 1 region of memory.

1. Why is the class named Vec3 but the constructor LightVec3? >_>2. Shouldn't the stride variable be contained in Vec3, or is it there to allow you to store multiple interleaved structs in the array (I completely approve of the idea). In that case you also need an offset variable to allow positioning of the second MappedObject into the buffer. Whichever the case is, the byte size should still be retrievable from the Vec3 class and a mapInstances() function without stride should be added.3. What's the performance compared to the old MappedObject implementation?4. Is it possible to have a struct inside a struct like this?

5. This one is a bit unrelated, but I was wondering if you have any suggestions regarding this problem: In my CPU particle engine I had particles which contained both a bunch of data. Some of it was needed for rendering and belonged in a MappedObject (position, color) and some of it did not (velocity, life). I had 12 bytes of needed data and 12 bytes of data that wasn't needed on the GPU. All in all I had to create both a Particle class and a MappedParticle class to split up the data, but everything got a lot more complicated, and it kind of seemed like it defeated the purpose of MappedObjects. This update would simplify a it a bit since I can just pass in an instance from the List gotten by mapInstances() to my (unmapped) Particle class.

2. Shouldn't the stride variable be contained in Vec3, or is it there to allow you to store multiple interleaved structs in the array (I completely approve of the idea). In that case you also need an offset variable to allow positioning of the second MappedObject into the buffer. Whichever the case is, the byte size should still be retrievable from the Vec3 class and a mapInstances() function without stride should be added.

Only .sizeof() is tied to a type. The .stride() is tied to an instance and can be altered at runtime. With the new MappedObject (not the MappedObjectArray) it makes no sense to add a stride, as it won't slide over memory. I could move .sizeof() from MappedObjectArray to MappedObject, and set the stride to sizeof, if the specified stride is zero.

There is no need to provide an offset parameter: the constructor respects the buffer.position(). Even if it wouldn't you could .buffer.slice() it before passing it in the constructor, but I hope support for buffer.position() is enough. (feedback?)

3. What's the performance compared to the old MappedObject implementation?

The bytecode it generates is (supposed to be) a lot friendlier to HotSpot. But really, please enlighten me with some real world particle engine benchmarks. My synthetic benchmarks show it's just as fast in small methods, and 'a bunch' faster in bulky methods, for varying levels of 'a bunch'.

Not yet, but that was because that would mean all kind of wizardry for MappedObject, as it would have to re-calculate the offsets of all (nested) children, every time the position was changed... I can't do it like C/C++ where the nested structs are simply 'burnt in'.

You can see how I solved it in MappedSet: simply generating an set.index(i) method that calls child[n].index(i). You can see the limitations of this approach.

5. This one is a bit unrelated, but I was wondering if you have any suggestions regarding this problem: In my CPU particle engine I had particles which contained both a bunch of data. Some of it was needed for rendering and belonged in a MappedObject (position, color) and some of it did not (velocity, life). I had 12 bytes of needed data and 12 bytes of data that wasn't needed on the GPU. All in all I had to create both a Particle class and a MappedParticle class to split up the data, but everything got a lot more complicated, and it kind of seemed like it defeated the purpose of MappedObjects. This update would simplify a it a bit since I can just pass in an instance from the List gotten by mapInstances() to my (unmapped) Particle class.

Even better: this implementation supports mapped and unmapped fields in the same type.

I don't know if you already have, but could you deploy it to maven central?

Also a little followup question, I tried your lib once, just to check it out and my question is, if because of the needed application "restart" this lib works only on the desktop? Or can it be used as an applet without natives or other security restrictions. What is about android?

Also a little followup question, I tried your lib once, just to check it out and my question is, if because of the needed application "restart" this lib works only on the desktop? Or can it be used as an applet

As specified in the opening post: allows both JIT and AOT bytecode transformation (just add JAR to classpath)

Android does have Unsafe, but doesn't have Unsafe.getFloat(addr) and Unsafe.putFloat(addr, value). Further, FloatBuffer.get(index) and FloatBuffer.put(index, value) are about 50 times (!!) slower than access to a float[]. For Android we probably need an implementation that is backed by a specific primitive array per type, which means 1 type can only have float fields, or only int fields, etc etc.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

Judging from the comments, this is really nice. I'd enjoy to hop in on the cake, but I don't know how, where or when.I can reason that values in structs can now be stored in a single array, with the fields on indexes instead of the objects themselves. Is that accurate? I can't imagine a scenario where this is useful.

How is this better than me, hacking up an array of Object children, and defining the protocol for whatever I need the structs to contain?

Sorry for being ignorant. I'd really like to get more enlightened on this.

How is this better than me, hacking up an array of Object children, and defining the protocol for whatever I need the structs to contain?

Sorry for being ignorant. I'd really like to get more enlightened on this.

it is especially usefull when communicating with OpenGL. When you need to send to OpenGL vertex data it exspects a Bytebuffer, so without this lib you would have to copy all the data you have from your objects to such a buffer. Espsecial usefull if you not only want to push the data once, like for 3d models, but want to operate on it often, like for a particle engine.

My public repository is basically a massive hack: generating a dummy JAR from dummy sourcecode, then replacing the JAR Eclipse generated and I obfuscated, then injecting the required Maven META-INF entries into the JAR, rehashing the *.jar.md5 and *.jar.sha1, then uploading the entire repo to a dir on my webserver.

All that, in a nifty .bat .sh file

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

As the author you just need to state what the license rules are..but you should explicitly state them. So you'd need to state that class files and generated code is BSD or whatever. This opens up a can of worms however. Consider that using a reverse engineering tools of BSD licensed .class files is a "derived works" of the .class files and so logically BSD licensed, so defeating you're purpose. You could add an exception clause, but I'd guess that would be deemed to be unenforceable. I'd suggest that you GPL everything and get the GPL taint and state that other licensing options are available from the original author...if you're willing to deal with the generated emails. You could always drop to a less restrictive license in the future if that becomes too much of a PITA.

NOTE: I'm not a lawyer so take this for what it's worth...which isn't much.

My attempt at thread derailment: Maven is a symptom of everything wrong with software development in the modern age And as an aside: Project Jigsaw - solving a problem nobody has any more, in the most complicated way possible, so that they have failed to deliver what nearly everyone asked for 10 years ago that only took a couple of hours for an amateur to implement. Way to go, software engineers. The same guys probably invented Maven.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org