Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your help!

We need 7 developers from Canada and 18 more from Australia to help us complete a research survey.

Support our site by taking a quick sponsored survey and win a chance at a $50 Amazon gift card. Click here to get started!


Member Since 13 Sep 2012
Offline Last Active Yesterday, 09:30 PM

#5222169 Multithreaded mesh loading and 0xcc returned from glGenVertexArrays

Posted by TheChubu on 08 April 2015 - 10:40 PM

You could always load the mesh data into main memory from different threads, then hand the pointers to the OpenGL context owner thread and let that one do the GPU uploading.

#5222115 curious case of integer overflow?

Posted by TheChubu on 08 April 2015 - 01:54 PM

If it makes any difference, the code is in Java not c++ 
Yes, it does. In Java all of this is defined, overflow will wrap around, integer variables get auto initialized to 0, you don't have unsinged types (except for 'char' technically, but whatever), and so on.

#5222106 Using named POSIX mutexes?

Posted by TheChubu on 08 April 2015 - 12:29 PM

sometimes when it takes a minute or two for your game to load/start, the user might get impatient and just start clicking away thinking "why won't you start?",
Show a splash screen first that says something along of "Loading the game, please wait.", then init the game.

#5221468 Is it realistic to expect to make money in Unity Asset Store/UE4 Marketplace?

Posted by TheChubu on 05 April 2015 - 07:54 AM

Okay, thank you again, frob. It seems that as a beginner, I have months, or even years of work ahead of me, before I even get the chance to earn some small amounts of money. Not very encouraging
Such is life when you expect to make money in very specialized areas.

#5220872 Trouble with uniform matrices

Posted by TheChubu on 02 April 2015 - 02:34 AM

ByteBuffer matrix_buffer = ByteBuffer.allocateDirect(64).order(ByteOrder.nativeOrder()); //JAVA DIRECT NIO BUFFER, for use with LWJGL




matrix_buffer.asFloatBuffer().put(m).flip(); //Write to buffer and set its capacity


Be careful with what you're doing there. You'll be uploading data to the GPU all the time, you should strive for it to be a garbageless process. There you're creating two new objects each call is made. Moreover, timely deallocation of direct buffers isnt guaranteed, and you're doing a new direct buffer alloc each time.


You can very easily just create one instance of a big enough buffer and pass that all around the renderer, with LWJGL 3 you dont even have to create FloatBuffer view objects since most calls have a version that receives pure ByteBuffers.


EDIT: I misread, you might not be creating a new direct buffer each call. You're still creating a new view each call though, you can (and should) hold onto that reference too instead of re creating it all the time.


Also this line here:


matrix_buffer.asFloatBuffer().put(m).flip(); //Write to buffer and set its capacity


It might not be doing what you think its doing. asFloatBuffer returns a new FloatBuffer object that basically points to the same region of memory as the ByteBuffer (well, address + current position exactly). Thing is, its a whole different object, if you call 'flip' on that view, it wont do anything to the position/limit/etc of the original ByteBuffer. 'ByteBuffer#asFloatBuffer' javadoc explains it in detail.

#5220464 GDC videos?

Posted by TheChubu on 31 March 2015 - 06:21 AM

Actually, all the GDC 2015 free talks are online right now: http://gdcvault.com/free/gdc-15


Too bad Vulkan's has very, very low volume.

#5220169 Unreal Engine 4 and Win 8.1

Posted by TheChubu on 30 March 2015 - 05:52 AM

Epic have to follow US and EU trade laws, as part of that there are 5 (iirc) countries in the world where you can not access the site from or legitimately get the engine to use due to trade being banned with those countries. Cuba is one, Iran is another, NK is a third and I can't recall the others (I think one African nation at least).
Burma is one. Saw them listed in an Intel GPU code sample download, apparently is the home of some pretty extremist Buddhists :D

#5220127 How to map a trapezoid texture area to a rectangle correctly

Posted by TheChubu on 30 March 2015 - 02:32 AM

Um, use the corners of the texture (ie, square area) instead of a trapezoid, then just tilt the quad and let the hardware do the perspective for you.

#5220056 Relationship between Linux and Java/Dalvik, .so vs .jar

Posted by TheChubu on 29 March 2015 - 06:29 PM

assume the Android operating system has some layer built in to allow the two to communicate with each other much like the .NET framework.
Its just the Java VM calling into native code. Pretty sure no exceptional OS feature is needed for that beyond calling a function in a library.


Although as swiftcoder mentioned, Java's particular native interfaces are awful. I have no experience making them, but just for using them you have to forego a couple of things. For example, data has to be marshalled between what the native code sees and what you sent it from JVM run code. Things like endianess, liveness of the pointers, and so on.


Say that you pass an array (effectively, a pointer to an array) to native code. The JVM wont probably be able to guarantee that it wont move the array in a GC pass while the native code is running (remember GC runs in a different thread), that way the native code wont be able to read nor write to it so JVMs will probably just defensively copy anything that you pass to native code. AFAIK there are explicit memory pinning mechanisms exposed in CoreCLR for example, not something you get in JVMs currently though (on the other hand, HotSpot in desktop has a very, very advanced JIT compiler, which is nice).


There are ways to explicitly use a native buffer from inside Java-land, so called "direct" ByteBuffers, aka, wrapper over a pointer returned by a malloc call. They work well, they can be read efficiently by native code, no additional copying required for just passing the data, but they're a pain in the but to use from Java and you will need additional copying from the data in your Java program to the insides of the native buffer/direct ByteBuffer.


Direct ByteBuffers have also a rather convoluted mechanism for being freed that requires a phantom reference to a cleaner object, that frees the memory when it goes out of scope (or so it would like you to think) so there isn't a deterministic (nor garbage free!) way to free unused memory, which can be a big issue, since native/direct buffers have an upper limit in JVMs (meaning you can get an out of memory error just by using too much of that specific kind of memory, regardless of you having actual memory left or not).


As you can see, it gets pretty complex really fast, its simply one of the rough spots in Java and the JVM that became obvious enough when the language got popular.

#5219828 From scratch vs Unity

Posted by TheChubu on 28 March 2015 - 10:13 AM

Why make a game from scratch when you can use unity? Particularly the new Unity 5.

Unity solves the kind of problems I like to solve myself. Say, the architecture of the whole thing. I like to think up how say, the loading systems will construct data that the game systems will consume, the interfaces they will use to communicate, things like that.


Besides, once I come up with these things, I like to use them. For example, I like to use my RenderPass class, see how it fares when the next feature comes up, for the point lights pass I had to refactor a few things, for the bloom pass it turns out that it worked fine as it is. I really enjoy not only to design these things but also to see how they fare when its time to make modifications.


So to me that's my reason for not using it, Unity has no appeal to me, it wont help me to do the things I enjoy to do.


Now in the other hand, if I you are more "results focused", ie, you just want to make a game and don't really care for the rest, or if we're talking about work and not a hobby, I'd say Unity is a great choice. Those do are reasons to use Unity.

#5219802 Books and Tutorial Recommendation

Posted by TheChubu on 28 March 2015 - 07:06 AM

arcsynthesis.org/gltut is down, but the repository is still there:




Download the tutorial 0.3.8 file, it has the PDF with the tutorial/book inside and all the sources. I like how it goes about the theory and the progression.

#5219277 Skeletal animation issues

Posted by TheChubu on 26 March 2015 - 04:50 AM

Well, look at this: 




The wireframe is the actual geometry. I bake the bind pose on the vertices. The garbled polygons and pink pixels (NaNs) is the result of my awesome skeletal animation. Those garbled polygons should resemble the humanoid walking, but It kinda doesn't resembles that... at all.


My understanding is that each joint can be represented with a rotation matrix, and that rotating along the hierarchy of joints, you get the final position.


What I do is to have a two dimensional array Mat3f[][], first index is the joint, second you would index into a specific frame of that joint. The idea is to lerp between the frames, according to the animation timer and current delta, and multiply the resulting interpolated matrix by the parent bone (which it should be already an interpolated matrix of the current frames of the parent joint).


Now pardon my Java but this is my code to compute each joint:
Aaand this is the vertex shader: 
If you need more information just ask.

#5219233 Question about saved games

Posted by TheChubu on 25 March 2015 - 11:11 PM

Exactly and at that point you would be storing your saved data in database.
Even if its not an online game, you could use an embedded database like SQLite to store save game data. It wont be as fast as writing your own custom binary format... but you wont need to write your own custom binary format :3

#5218982 Documentation for PSGL and GNMX

Posted by TheChubu on 25 March 2015 - 12:20 AM

Googling PS3 GCM turns this in the first result:




PSGL is the shading language, not the API.

#5217965 LibGDX Box2D libraries

Posted by TheChubu on 20 March 2015 - 04:10 PM

Yes, just use those two. For Bullet its the same, gdx-bullet.jar and gdx-bullet-natives.jar


The ARM files are probably separate since you wouldn't distribute your application in a .jar for those devices in the first place (need RoboVM for iOS, .apk and DEX for Android), so cant put those in the *-natives.jar.


And the .jar files you've mentioned are just java/jni wrappers on the top of the cross-compiled ( in case of ARM ) libraries. So you need to add .so (dll) file for x86 to support PC.


No, the *-natives.jar contains those. Its designed that way so you don't have to specifically create a directory path to load the native libraries (unlike say, LWJGL), libGDX resolves the path automatically loading them as resources inside the natives jar. You can open them with anything that supports ZIP compression to see whats inside, you'll see the .dll for windows, .so for Linux and .dylib for OSX, x86 and x86_64 versions.