Working with Vulkan

So, work on Fluxions 4.0 has begun. I started out by digging into Kristian Høgsberg Kristensens’ vkCube source code. I think he did a good job laying out all the essential pieces. Vulkan like OpenGL is a C library at heart. Instead of many state calls, you need to fill in data structures with all the important information. Unfortunately, the anonymous initializer lists that C uses are not compatible with C++, so instead I used that as an opportunity to go into the vulkan_core.h header file and see what these structs do.

One key piece of information is that you need to set all the non-essential parameters of every struct to zero or you likely will cause a crash. One method is to call memset to set the entire struct to 0, which I did initially, but I think the better way is to simply initialize all the members directly. And I won’t feel that I’m adding unnecessary calls to It helps with the learning process and since the whole process of programming with Vulkan is a bit verbose anyways, not a big deal. Another option that I considered was to encapsulate every Vulkan struct as a C++ class. But there is a substantial work cost involved given the vast number of different structures in the Vulkan library.

To initialize the Vulkan library, I use SDL 2.0 to create the window, initialize OS-dependent extensions, and create a surface to render to. Ultimately, this initialization takes about 500 lines of code. I need to add the ability to create a depth-stencil buffer in addition to the color buffer, but I do not think this will take too much effort. The functionality for initialization is going to located in the VulkanContext class. The main idea is to have code that looks like:

bool MyApp::init() {
  if (!context.init())
    return false;
}

void MyApp::render() {
  context.beginFrame();
  // render objects
  context.presentFrame();
}

The next concept to finalize is the render config. The render config is a thing I started in my WebGL LibXOR game engine. The idea matches the idea of the graphics pipeline in Vulkan. Of course, I was inspired by early talks about the architectures of Mantle, Direct3D, and Vulkan in hopes that I would be ready for it when I was ready to begin work with Vulkan. This has turned out to be a good strategy. While not finished, I hope to make the following code idea to be viable:

void MyApp::render() {
  context.beginFrame()
  if (config.use()) {
    config.setLights(lights)
    config.setMaterial(material)
    config.useTransformation(transformation)
    config.useTextures(textures)
    config.draw(geometry)
    config.restore()
  }
  context.endFrame()
}

Before I go down that road, I need to identify the material, geometry, and scene graph methodologies I want to use. The first is to use the Alias/Wavefront OBJ/MTL format which is great for static geometry. The second is to investigate the Autodesk (Filmbox) FBX format which supports animation. The third is to investigate Alembic which is an animation format for preserving animation. Lastly, I have taken a look at glTF which has a nice subset of features including animation. It may be worth my time to simply develop tools to convert these into a simpler system useful for direct upload in GPU buffers. I have played around with extending the Alias/Wavefront text file format and had good results in the past. I may keep that work and see what FBX or glTF ideas might be useful.

This last point is important because when you want to focus on physically-based rendering, you do not want to get too bogged down into a complex animation system. I do want to be able to tell animated stories with my graphics engine. But I have to balance it with the needs of the other components to my graphics engine.

So, the next work I need to do is to encapsulate the following ideas in Vulkan. How do I upload a texture map, create separate uniform buffer objects, and separate interleaved vertex array objects? Currently, I am working on abstracting the VkMemory and VkBuffer objects to make this process easier. Ultimately, I am working towards a smallish demo on using the new Ray Tracing features. Until then, Adios!

Fluxions Engine 3.0: The History of a Research Graphics Engine

The first graphics engine I wrote was in the late 1990s which I originally named KA3D — short for Kick-Ass 3D. But, I couldn’t commit to this name because it had a slight hint of profanity which I am generally uncomfortable with. So I changed it to Fluxions after the Method of Fluxions which Isaac Newton invented. The name was cool and it had the allure of mystery. I found an old version of my website, though mostly non-working, which was cached in October 1999.

https://web.archive.org/web/19991007002444/http://skyscraper.fortunecity.com/altavista/565/

The first engine was short-lived and it was completely software-based using scan-line rendering and blended lightmaps and color look-up tables. It was written for MS-DOS using the DJGPP port of GNU C++ compilers. Then I discovered the Allegro library.

Fluxions / KA3D 1.0 for MS-DOS

The Allegro engine was a game engine that was fairly easy to get into. It had graphical user interfaces and extensions for 3D graphics. I was also getting into Linux at the time and I was first learning about the Mesa library for rendering with OpenGL. And then I was lucky to get a hold of Riva TNT2 card which had OpenGL graphics drivers to use at school.

So I began writing the second version of Fluxions using OpenGL 1.1. I used this for a game I was working on called Outpost Wars. I remember there was an online contest for 3D demos, so I submitted the following demo. You could walk around this strange sculpture featuring rotating rings kinda like the ones from Superman.

Fluxions 2.0: GL Land demo

I followed the extension scene around OpenGL until at least version 1.5. This was especially useful for doing bump mapping and other related techniques. I started working on an outer space network game with some friends from work. Unfortunately, we were not able to complete it, but I still look fondly back on that work. I was very pleased with some graphical user interface work I programmed and utilizing bump mapping and lightmapping. But programmable shaders were becoming interesting and so it was time for the longest-running Fluxions 3.0 graphics engine.

Fluxions 2.0 — The unpublished BattleLine game

When I began working on programmable graphics, the 3D engine has taken a number of turns before it gets to its final form. But basically, it served as the basis of my Master’s and Ph.D. research. My first trip to SIGGRAPH in 2012 really brought me up to speed on many of the latest and greatest pushes into physically based rendering. You can see some of the improvements in the remaining two images.

Fluxions 3.0 earlier results

So, I think it’s probably time that I put Fluxions 3.0 to bed. It needs a few last remaining touches, but the next version will switch to the Vulkan graphics library and make use of real-time path tracing. I will work on moving some of my earlier research work on local dynamic radiance maps, spherical harmonic lights, and scalable SH harmonics. Farewell Fluxions 3.0, and good tidings to the new Fluxions 4.0 engine.

Fluxions 3.0 later results

FreeBSD Part 4

Today, I am getting my development environment all set up. I wanted to use VS Code, but it wasn’t in the pkg system for 12.1. So I tried to use the ports system, however, the 49GB slice I have for my /usr folder was filling up — fast. OK, so instead I decided to see if I could update where I’m getting the software. So I changed from release_0 to latest inside my /usr/local/etc/pkg/repos/FreeBSD.conf. This file does not exist initially, so you have to create it. Afterward, I type in the following and I’m able to install newer software!

FreeBSD: {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest"
}

FreeBSD Part 3: Boot Loading

So one of my laptops is a ThinkPad Yoga that I use Windows 10, Fedora, and FreeBSD. The adventure was figuring out how to get FreeBSD to boot. I am using GRUB2 from my Fedora installation to chainload the bootloader. To do that, I had to add the following entry to the /etc/grub.d/40_custom file.

menuentry "FreeBSD" {
    insmod part_gpt
    insmod fat
    set root=(hd0,gpt8)
    chainloader /efi/boot/bootx64.efi
}

After that I ran grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg to update my current GRUB2 configuration. And the result was that it worked! I have an entry to boot into FreeBSD now. This took several hours to figure out. I am posting to help some other soul in my situation. Now on to install Gnome Desktop, Chromium, and Xorg.

Pushdown Automata

A pushdown automaton (PDA) is a state machine with a stack. They can either be deterministic or nondeterministic. Mathematically, they are weird to look at. It is better to be deterministic rather than nondeterministic because you control what your application will do even if you do not know the exact order of user input. They can be used to handle numerous game development tasks like handling the game loop.

The formal definition is that a PDA is a 7-tuple M = ( Q, \Sigma, \Gamma, \delta, q_0, Z, F ). This is behavior and data wrapped into one. Let’s make this usable. Q is the set of states you can be in. It needs to be finite. Then you have an input alphabet \Sigma which essentially is player input. Next we have the stack alphabet \Gamma which are the items we can put on the stack.

For convenience sake, we are going to use ALLCAPS for symbols on the stack, CamelCase for states, and quoted characters (such as “Escape” or “q”) for input.

The function \delta defines which state we can transition to given the current top of the stack. This is the transition relation. For example, if INIT is currently the top item on the stack, we shouldn’t move around in states that are reserved for GAMEWON. This kind of formalism helps our PDA to be deterministic. More specifically, the transition relation requires five pieces of information (p, a, A, q, \alpha) which we will discuss shortly.

The Z is the initial stack symbol that the stack is initialized to when started. And F is the set of accepting states. For instance, perhaps we only want to transition when a key is pressed down, but not when a key is released. Often a double circle is used to mark these states.

Let’s return to the transition relation \delta which contains (p, a, A, q, \alpha). This means that we are allowed to transition from state p to state q when the input a is received and while A is the topmost stack symbol, pop the topmost stack symbol and replace it with \alpha.

If we were using a regular state machine, then we might have the player in the GamePlaying state and when the user inputs “Escape” (to pause the game), we might transition to the GamePaused state and wait until “Escape” is pressed again before transitioning back to the GamePlaying state. This is trivial, but if we then decide to add a settings menu that is accessible from the pause menu or from the game, this is going to cause a mess of if-else statements because the way to code this is:

// Init code
int gameState = GamePlaying;

// Game loop
if (gameState == GamePlaying) {
  if (keys[ESCAPE]) {
    keys[ESCAPE] = 0;
    gameState = GamePaused;
    return;
  }
  if (keys[F2]) {
    keys[F2] = 0;
    gameState = GameSettingsMenu;
    return;
  }
}
else if (gameState == GamePaused) {
  if (keys[ESCAPE]) {
    keys[ESCAPE] = 0;
    gameState = GamePlaying;
    return;
  }  
  if (keys[F2]) {
    keys[F2] = 0;
    gameState = GameSettingsMenu;
    return;
  }
}
else if (gameState == GameSettingsMenu) {
  if (keys[ESCAPE]) {
    keys[ESCAPE] = 0;
    gameState = GamePlaying; // What about pause?
    return;
}

So the problem is very clear, we have no way to remember where we currently are. We have to either duplicate the Settings menu as GamePlayingSettingsMenu and GamePausedSettingsMenu or we have to keep track of extra state. With the PDA, we can remember where we are by pushing/popping the current state. Consider the following code:

// Init code
vector<int> gameModes;
gameModes.push(GamePlaying)

// Game loop
if (gameModes.back() == GamePlaying) {
  if (keys[ESCAPE]) {
    keys[ESCAPE] = 0;
    gameModes.push_back(GamePaused);
    return;
  }
}
else if (gameModes.back() == GamePaused) {
  if (keys[ESCAPE]) {
    keys[ESCAPE] = 0;
    gameModes.pop_back();
    return;
  }
  if (keys[F2]) {
    keys[F2] = 0;
    gameModes.push_back(GameSettings);
    return;
  }
}
else if (gameModes.back() == GameSettings) {
  if (keys[ESCAPE]) {
    keys[ESCAPE] = 0;
    // now we go back to where we were
    gameModes.pop_back();
  }
}

This new PDA behavior is far easier to maintain than the previous if-else statement process. The previous Finite State Automaton (FSA) previously had no method of remembering where we were. Hence, if you pressed “ESCAPE” in the settings menu, you would go back to the game even if the game was previously paused. You would have to have a non-deterministic algorithm otherwise. The PDA makes this process deterministic, which we previously mentioned is the ideal case–you always know what your application will do.

So, one modification I like to use is to couple the stack with a main symbol, a secondary symbol, and a pop time. The main symbol is used to control the main logic of the game, the secondary symbol is used as a PDA. I can then pop the main symbol and all the PDA used for the secondary state will go away. The pop time is used to automatically pop a symbol off the stack after a certain period of time. The following pseudocode is then possible:

struct GameState {
  std::string gamemodule;
  std::string alt;
  double popTime;
}
vector<GameState> gameStates;

void init() {
  gameStates.push({"MAINMENU", "", 0});           // When play game is pressed, these next
                                                  // items are popped at 1 second intervals
  gameStates.push({"SHOWCOUNTDOWN", "THREE", currentTime + 1});
  gameStates.push({"SHOWCOUNTDOWN", "TWO", currentTime + 2});
  gameStates.push({"SHOWCOUNTDOWN", "ONE", currentTime + 3});
  gameStates.push({"SHOWCOUNTDOWN", "GO!", currentTime + 4});
  gameStates.push({"MAINGAME", "", 0});
}

void gameloop() {
  if (gameStates.empty()) return;
  GameState &top = gameStates.back();
  if (currentTime > top.popTime) {
    gameStates.pop();
    return;
  }
  if (top.gamemodule == "MAINMENU") {
    // if PlayButton pressed
    gameStates.pop_back();
    return;
  }
  if (top.gamemodule == "SHOWCOUNTDOWN") {
    // do nothing, display() will draw "ONE", "TWO", "THREE", or "GO!"
    return;
  }
  if (top.gamemodule == "MAINGAME") {
    // handle in game logic
    return;
  }
}

void display() {
  // Approach here could iterate through gameStates and render items back to front
}

Stock Market Game

From the book “Announcing Computer Games for Business, School and Home” by J. Victor Nahigian and William S. Hodges, this post is about two interesting games: Star Trek and Stock Market. There are many good games in this book, but I’ve chosen these two because they are interesting to me today. In the past, I have written these two programs out on the Commodore VIC-20. They are simplifications on previous games, but when you have very limited memory (5KB and 16KB), you have to cut features.

Stock (Market)

The object of this game is to make more money than the opponent (computer). The mechanism for this game is rolling two dice representing shares “A” and “B”. The first die allows you to buy “B” shares and the second allows you to buy “A” shares. The amount of shares is the value on each die. Selling works the same way. There is a 5% brokerage fee on each transaction. At this point, I’m wondering how much the brokerage earns?

The second mechanism is adjusting the price of the stock. This appears completely made up. You can use your turn to raise the price of a stock “A” by “B” dollars or lowering a “B” stock by “A” dollars.

Overall the program is about 2 pages of BASIC code. So the challenge would be to convert it to C++ or use JavaScript and my LibXOR library. I would rather experiment with C++ for the core mechanic and then convert it later if it still remains interesting.

Star Trek

This program is also two pages of BASIC code, but it feels more dense than STOCK. This game reminds me of an RPG or Pokemon battle. You have the U.S.S. Enterprise and a Klingon ship each facing a different angle. You have to figure out the appropriate angle to fire at the opposing ship. You are given the option to fire phasers, fire photon torpedos, print a status report, change movement, or self destruct.

I’m reading the source code and this game is more involved to describe than the STOCK game, so I will delay that until I have experimented with writing this game out. I am thinking this could be fun to expand by allowing several ships, real-time flight, or several star systems. For now, I will also try my hand at doing this in C++.

Gamedev This Year

Furtual Rabbit was my first game in a year. It was revealing how out of practice I had gotten. It might be time to start doing more One Hour Game Jams. On the other hand, I got a lot of experience with computer graphics and simulation techniques which was my main focus during the academic year.

So what will I focus on this coming year? On the top of the backlog is getting some graphics research written up and sent to journals. Next up is improving my LibXOR library for #GameDev so that I can prepare for a 7DRL. And one last goal for good measure is creating a real-time ray tracer to go with my Unicornfish network rendering concept. For this blog post, I will talk about the latter two in a bit more detail.

The 7 Day Roguelike Challenge (7DRL.com) happens in early March. Roguelikes are inspired by the game Rogue. They often feature some combination of turn-based gameplay, grid-based environments, permadeath, and procedurally generated levels. What would mine look like? Topologically speaking, I want a procedurally generated overworld and fairly shallow levels with keyed off areas. I have some concepts in my head how they might play out, but I need to work on some prototypes first.

And finally, graphics wise I want to experiment with Realtime Ray Tracing and to that extent, I want to integrate it with my network rendering API Unicornfish. This means that I need to start decoupling it from the Fluxions Library. There is a lot of work to be done in that department, so I will need to spend some time charting out how the library works. There are a lot of TODOs on the current backlog, so this coming year will be quite busy, but perhaps I can drive two publications out of all that work.

Furtual Rabbit Ludum Dare 44

The Ludum Dare 44 theme is “Your life is currency.” So I created a capitalist virtual pet game called Furtual Rabbit: A Defurred Income Game. The goal of the game is to raise an Angora Rabbit. You have to feed, water, brush, and clean to keep the quality of the rabbit fur high so that you can groom it and sell it. Not all rabbits live forever and poorly maintained ones die even faster.

Link: https://ldjam.com/events/ludum-dare/44/furtual-rabbit-a-defurred-income-game

HTML5: https://microwerx.github.io/ldjam44/

The BSDs and System V

NetBSD, OpenBSD, and FreeBSD. They are all fun. They are different than Linux. I am of course talking about the kernel rather than the GNU software that is typically available on all of them. The BSDs have a vintage feel about them. I like it.

I wish that it was easier to try System V or SVR4 rather. Because instead of the Berkeley line, it is from the AT&T line which was the basis for IRIX, the version of UNIX on SGI systems. I still have a fondness for the MIPS10000 Octane MXE workstation I had many years ago.

The only way to try System V nowadays is to use an OpenSolaris derived system. But I have to admit that I hated Sun systems when I was younger for no good reason. I think it was because the 3D graphics sucked and I do graphics! So, it left a sour taste. Though there is a Sun variant called Tribblex that looks like it could be interesting to try in a virtual machine.

Of course, the BSDs still feel like the best out feel out there. I want to set one up with a nice X11 desktop like MWM. And it would be nice if IBM and HP would release AIX and HP/UX as free software. And maybe SGI will release their source code for their X based desktop and life would be grand.

UNIX could become more available to the common folk. I was watching some classic Computer Chronicles about UNIX. In 1985, it was still crusty and untrustworthy. In 1989, their last chance to prove UNIX was worth using, all they could talk about was how you could use a menu and how there machines cost $5000. Lol.

FreeBSD Part 2

So I tried FreeBSD in VirtualBox. Step 2 was to try and install it on my Thinkpad. Unfortunately, I am having boot issues. Perhaps it was too many operating systems. I deleted everything but Windows 10 and then reinstalled Fedora 29. I may try again on my Intel NUC that I am currently using PopOS with. In the mean time, the Raspberry Pi 3 is getting a go at it. The wifi does not work, so it is tethered to my router so I can install X11. I used the image from the FreeBSD website. When I get everything installed, we’ll see how the experience is.