Just received my assessment brief for this term in Games Programming; basically we have to make a 2D game using SFML (a c++ library used to support various kinds of inputs and outputs); first thing I looked up: Does SFML support direct OpenGL calls? The answer is yes This is gonna be fun.

Added shooting the entity with blood particles (he also gets redder the longer you shoot him) Found/fixed numerous bugs and issues with the renderer and fixed the memory leaks.

Optimized frustum-aabb test.Added an in-game console that is openable by pressing TAB. You can type and use commands just like you would in your computer's console/terminal (you can also scroll up and down it with the page up/down keys and move through type history with up/down arrow keys)

We're currently at a stage in development for Robot Farm where I'm mostly waiting on everyone to check in with their stuff so we can push out the trailer and I can resume work on the last of what I have to do. In the mean time, I've been writing up a design document for a game idea I had for fun, for down the road when we're trying to decide what to make next. Design docs are always really fun to write up!

For the past couple of days I've been working on getting the HTML/CSS done for my band's website. I relied on Bootstrap a little, but most of it is (unfortunately) written by me. I'm not a front end developer or a designer, so this was pretty hard for me

The content on the site isn't finished (the About page is the main offender), but here it is: astimefades.com

Currently it's just hosted on my github, but the next stage is to add a backend and host it on Linode (or maybe DigitalOcean). I want to give my non-developer friends an easy way to add content to the page, and build out a merch feature (I'm feeling adventurous). The only part that will be new to me on the backend is accepting/handling payments through multiple solutions (PayPal/Stripe/etc...), but I'm hoping it won't be too hard. It'll all be written in that sweet, sweet new ASP.NET Core!

today i learned - tex-coords stored in half-floats is a very bad idea.

If you don't have any wrapping, then normal unsigned normalized shorts could work up to a certain resolution. 16-bits give you decent-ish tex coord precision up to a resolution of 4096x4096 or so. You definitely don't want half floats as they don't have even precision.

EDIT: Hmm, it turns out that unsigned shorts are actually more viable than I first assumed. With 16 bits you get 65536 different values, which for a 4096x4096 texture is a precision of 1/16th texel. However, this really only means that the corner values of your triangles get snapped to the closest representable 16-bit value. This really only gives you a tiny amount of distortion/stretching across the surface of each triangle, as you still have float precision interpolation across the surface of it. I can't think of a realistic situation where this would actually be a real problem.

Going to Beijing, China next week. My dad speaks Chinese and I'd like to learn it, there are many great Android apps for it. But I wanted something where I could gradually add words and it would pick out sentences for me to translate - so I made my own app for it.

The app uses Tatoeba for Chinese and English sentences. The sentences were stored in one big CSV with half a million or so entries (300 mb uncompressed), but I removed all the entries that weren't English or Chinese, so then I only had 90 000 sentences to manage. I also ran a script on those sentences to find the Chinese characters that were most common, and created a separate CSV with each character and the number of times it occurs. You learn the characters that are most frequently used first. I also added Pinyin pronounciation guides using a library called hanyupinyin.

The read screen where you practice sentences features text to speech using Android's super-simple API. The voice is great. The only thing that remains to be done is adding a time-based spaced repetition system where words and sentences are repeated with increasing intervals.

All in a day's work, I'm very happy with how it turned out. Take a look!

Going to Beijing, China next week. My dad speaks Chinese and I'd like to learn it, there are many great Android apps for it. But I wanted something where I could gradually add words and it would pick out sentences for me to translate - so I made my own app for it.

Download apps like QQ, Wechat, and MoMo.

QQ and WeChat because they're how everyone communicates there; MoMo to pick up girls.

Are you implementing your own collision/physics? If so, is there a book or resource that you're using?

Yes im implementing my own collision (and really basic physics). There is no single resource that was helpful but with a lot of googling, you can find information. Ellipsoid collision is surprisingly scarce.

Today I found out that Vulkan is stricter than I thought when it comes to threading. Most Vulkan commands only read objects without modifying them, and those functions are OK to call from any thread at the same time. However, some functions require "external synchronization" of certain arguments, and it turns out that if a single of your concurrent calls requires external synchronization on an argument, ALL uses of that same object needs to be synchronized as well. I didn't know that last part. >__<

In Vulkan, "fences" are used to check if the GPU is done with a certain task. The fence is included in vkQueueSubmit() and is signaled when the submission is completed. You can poll if a fence has been signaled using vkGetFenceStatus(), or block the thread until it becomes signaled using vkWaitForFences(). vkGetFenceStatus() and vkWaitForFences() do not require external synchronization of the fence they operate on, meaning that you can have 20 threads that are both polling the status and awaiting the signaling of a single fence. Now, according to the specification it is technically not wrong to await a fence that has not actually been submitted yet, and I thought this was a great thing! The idea was to for example be able to code something like this:

1 2

sendOffWorkToDedicatedVulkanThread(work, fence); //Will call vkQueueSubmit() on a different thread at some point in the futurevkWaitForFences(fence);

However, vkQueueSubmit() requires external synchronization of the fence you pass in to be signaled. As I learned today, this means that if I want to do vkGetFenceStatus() or vkWaitForFences() calls at the same time I'm submitting the fence I'm querying, I need to synchronize it manually. In the example above, this means wrapping both vkQueueSubmit() (which is called on the dedicated Vulkan thread later) and vkWaitForFences() with a synchronized(fence){}-block.

Some of you may be spotting the paradox. To be able to await a fence, I need to lock it. The fence remains locked until the fence is signaled...... but to be able to submit the task that will signal the fence, I also need to lock the fence! If the task for that fence hasn't been submitted by the Vulkan thread yet, it will never be able to do so because the fence is already locked by the waiting thread! Deadlock!

The solution is really annoying. I need to manually use Java's synchronization to first make sure that the fence has already been submitted before I attempt to query or await a fence. For vkGetFenceStatus(), this can be done with a simple volatile variable and no synchronized() blocks are actually required. However, for vkWaitForFences() I need to first call wait() on the fence until it has been submitted by the Vulkan thread, at which point the Vulkan thread notifies all listeners of the fence so that they can safely call vkWaitForFences() AFTER the Vulkan thread finishes.

And that's a day of concurrent programming horrors.

EDIT: The same thing is sadly true for OpenGL too. OpenGL's equivalent to creating fences is glFenceSync(), which returns a GLsync object that will become signaled once the GPU has finished processing all OpenGL commands before the glFenceSync() call. You can later await a GLsync object using glClientWaitSync(). The (first) above code would look like this:

1 2

sendOffWorkToDedicatedOpenGLThread(work, fence); //Will do OpenGL calls on a different thread at some point in the futureglClientWaitSync(fence);

There's just one problem: We don't have a fence object before the call to glFenceSync() has completed. In other words, we have the exact same issue as above, just for a different reason. glFenceSync() gives us back a new GLsync object when it is called, so we need to wait (using Java's wait()) until the OpenGL thread has completed the glFenceSync() call and received a GLsync object, THEN we can call glClientWaitSync() to await the completion of the GPU commands.

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