Hello!

Over the past month I have been working on revamping the rendering system to being something that's actually usable, mainly making it easy to add new shaders and modify them over time, eventually without having to restart the game for a shader modification. My previous approach was the "OpenGL 2.x" style of using GetUniformLocation() to upload data. This ends up requiring a lot of specialized code for each shader you load. Newer OpenGL versions offer some shader reflection which might have made this less painful, but I think I've been able to transcend most of that by uploading all of the discrete uniforms as a block for each shader. I've accomplished this by defining a struct/UBO for each shader, in a file which gets compiled as both C++ and GLSL. Here's a bit of that file.

[code] //shader_uniforms.h

#ifdef CPP #define layout(a,b) #define mat4 matrix4 #define vec2 v2 #define vec3 v3 #define vec4 v4 #define uniform struct #endif

#define YAM_TEXTURE0_LOCATION

Long time no post! My excuse is that I've been busy preparing to move to Seattle for the summer! I have had some time to work on this project this month. Mainly, adding some basic Wwise integration, and adding support for FBOs (Frame Buffer Objects) through the graphics abstraction API.

The Going Ham demo was my audio partners first time trying FMOD. He has decided he prefers Wwise, which he has used for other projects. Integrating it was much more difficult than FMOD, but seems to have a lot more flexibility if I ever need to do really high-end audio programming. Either way, I should go with whatever makes him most comfortable.

The FBO support is exciting because it opens the door for cleaning up some of the viewport code and for a whole host of visual effects, particularly post-processing, reflections, and lighting. Right now the way the scene draw order is Editor UI, Game view, Scene view. By using FBOs I can pass the final game view texture to the UI system, which will draw

Hey guys,

It's been a little while, but I've been very busy with the engine project. My friend and I were able to complete our 7DRL game mentioned in the last blog post, with the working title "Going Ham". You can find a download for the demo here.

I'm pretty happy with how it came out. The general consensus I've gathered is that its difficult, but fun. Best of all, no one has reported any technical mishaps!

Since my last post I've added two new "engine" features, being SDF text rendering, and stack trace dumps when the app crashes. I'm using a library for the SDF generation, which can be found here. The stack trace dumps are being generated through the Win32 API, using StackWalk64. The documentation on using this is pretty bad, so if anyone wants to add similar functionality to their app, I'd recommend check

This past week I started development on my 7DRL project. So this is my progress from Saturday to today (Monday).

(gif is pretty choppy, it actually runs very smoothly, check the video below!)

I was surprised that I didn't really have to make any major changes to my existing engine code. I've found a handful of bugs now that I'm actually battle-testing these systems, and have another user. There's a few things that popped out at me that I'll want to change when this is done, but all in all this is going smoother than I thought it would!

The development for this is happening at a separate repository, so I can have all of the media checked in. You can find my usual video-log here.

Last week I overhauled the rotation tool so it would be actually usable. This meant writing a real UI for it and adding multiple axis constraints to the rotation. It's working pretty well in my opinion! Now I just need a scaling tool to complete the basic transformations tool suite.

Full video demo/explanation here

Hello!

I have two weeks of backlogged videos so I'm going to be posting them now. In this episode I went over a new profiler I wrote to replace what I was previously using, iprof. I did this because I wanted a profiler that could cross the DLL boundary easily (covering platform, game, and rendering code), and could save a single frame easily so I could profile start times. It was easier to write a new simple profiler than to try to get a full understanding of iprof.

There were a few interesting takeaways off the bat when I got this working.

A. Zeroing 250mb of memory one byte at a time is pretty slow (duh). This took about 2 seconds off my start time B. It takes Windows a full second to choose a pixel format, no way around this except serializing the result it seems. C. Doing any downstream calls costs from OpenGL, anything glGet*, costs about 11-12 milliseconds on the first call, because of thread syn