Got a bit obsessed with drawing vehicles for my zombie game, the road seems a bit blocked this morning:
https://dl.dropboxusercontent.com/u/1668516/shots/blockedroad.png
Cheers,
Kev
Quick, make a highway chase scene with zombies!
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.
Played a bit with some fractals
made a cake!
Areā¦ are you sure the cake isnāt a lie? :persecutioncomplex:
Wow! Tons of work done recently.
Added entities:
Entity-player collision (Vertical cylinder)
Entity-world collision (Ellipsoid)
Entity-ray collision (Ellipsoid)
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)
Made it so that only bilinear filtered textures are drawn with 256 colors, dithered and nearest-neighbor are true color.
Fixed up sphere mapping issue. added legacy opengl primitives like POINT, LINES, LINE_STRIP, LINE_LOOP, TRIANGLE_FAN, TRIANGLE_STRIP, QUAD_STRIP (no polygon :p)
Started working on more functional stuff like hit boxes and blocking zones. Need to doodle up a house and a wall shortly.
https://dl.dropboxusercontent.com/u/1668516/shots/walkers-hits.png
Cheers,
Kev
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!
I decided to add multi lingual support for my website powered by Jekyll, and it is extremely easy with the front matter. From now on, Iām going to post in Telugu and Hindi along with English.
https://goharsha.com/blog/multi-lingual-support/
Look at the language-selector in the top right!
This week I finally finished the BennyBox Game Engine tutorial. It is a tutorial about what is and how to develop a 3D Game Engine in 60 episodes.
Iām including more stuff and creating basic GameComponents (e.g. skybox, gui) to facilitate the game creation.
Hopefully, next week I can post something related to this little project.
nono, a cake, not a pie.
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!
aah ā¦ ushorts, good idea. thanks for the heads up.
Download apps like QQ, Wechat, and MoMo.
QQ and WeChat because theyāre how everyone communicates there; MoMo to pick up girls.
[quote]Added entities:
Entity-player collision (Vertical cylinder)
Entity-world collision (Ellipsoid)
Entity-ray collision (Ellipsoid)
[/quote]
Are you implementing your own collision/physics? If so, is there a book or resource that youāre using?
Are you implementing your own collision/physics? If so, is there a book or resource that youāre using?
[/quote]
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:
sendOffWorkToDedicatedVulkanThread(work, fence); //Will call vkQueueSubmit() on a different thread at some point in the future
vkWaitForFences(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.
sendOffWorkToDedicatedVulkanThread(work, fence); //Will call vkQueueSubmit() in a synchronized(fence){}-block later
synchronized(fence){
vkWaitForFences(fence);
}
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:
sendOffWorkToDedicatedOpenGLThread(work, fence); //Will do OpenGL calls on a different thread at some point in the future
glClientWaitSync(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.