It's been a while, but I haven't been idle. I've made a great amount of progress on Singularity, and I've finally discovered a secret that has eluded me for years!
The Problem
These stories always have to start with a problem. In this case, the problem was a seemingly simple one:
"When the user interacts with Singularity's WebKitGTK viewport, how do I make the app react to it?"
This used to be really easy, back in the days of Webkit 1. However, when Webkit2 changed the API and moved some functionality to it's web extension API, Javascript support followed suit. For a long time, the only solution was to simply create an 'extension' that used some form of IPC to communicate with the main app, but I didn't want to do that in Singularity. Instead, I used a crude hack by encoding messages in URL requests.
A Tentative Solution
Needless to say, this solution is slow and terrible, but I've found a better answer. At some point since my work on Singularity started, WebKit introduced the UserContentManager, which can apply custom CSS and Javascript to web pages. This is a really awesome feature that I plan on using in future projects, but it also provides me with a new tool, a signal for handling certain Javascript calls. According to valadoc.org:
public signal void script_message_received (JavascriptResult js_result)
"This signal is emitted when JavaScript in a web view calls
window.webkit.messageHandlers.name.postMessage()
after registering name using register_script_message_handler"
In other words, it lets you set up a callback that is called whenever a script calls a certain function, sending arbitrary data from the web page to the application displaying it. This is a really powerful feature.
So powerful, in fact, that you can't actually use it in Vala.
What Gives?
As it turns out, Vala's JavascriptResult class has no useful functions or properties. I'm not entirely certain why, given the solution that I'm about to provide.
While WebKitGTK's JavascriptResult does contain the necessary functions, no Vala bindings exist for them. Instead, you need to access them from C and return whatever result your app is expecting. This seems really odd, and I hope I don't have to find out the hard way later on, but for now I'm feeling pretty good about this.
I'll be posting an update with a more thorough rundown of my work on Singularity soon.
Time for my first summer post. I haven't talked about dfgame's improvements since my second three-week project a few months ago.I've been making some decent progress, so it's time for another update blog post. Here are some of the highlights:
Data Structures
One of the biggest things that I miss from C++ is STL, the Standard Template Library. It may not be the fastest or most reliable thing on the planet, but it still provides basic structures for storing data that make my life a tad easier. For better or worse, C has none of that. I could probably seek out a library to provide me with some basic data structures, but I figured it would be good practice to roll my own.
The first one that I built was an arraylist (also known in some parts as a vector). It's a fairly simple structure that more or less serves as a self-resizing array. When I was making my demos for Consol Programming, I noticed that I was making arrays that could grow on their own over and over. Since it's a common need, I decided to just add it to dfgame.
I recently also made a self-balancing binary search tree. Trees don't get a whole lot of love, but they do provide a relatively quick way to find values, so I figured it would be good to have an implementation on hand.
Convenience Features
I noticed a number of code bits that kept getting reused during the creation of the dfgame demo, so I also spent some time putting them together into the main library.
I started off by trying to improve the safety of my code a little, with macro wrappers for malloc, calloc, and free. These add extra error checking and logging as well as automatically zeroing pointers when freeing. I also updated my destructors to zero-out pointers via macros as well.
I also added a camera object that combines a transform matrix with a projection matrix to generate a view-projection matrix as needed. Now, I can just tell the camera to move around instead of doing extra math whenever I want to look around in a game.
Meshes, Shaders, and Fonts
Alright, now it's time for the fun stuff. I've made a lot of progress on adding more graphical capabilities to dfgame in the past few months.
I kicked things off with a revamp of how shader programs were handled. Before, there was just a function that compiled shaders, but now shaders are handled by a struct and some functions that allow binding data and retrieving handles. The result is less boilerplate code as well as the potential for more options later on. For instance, I'm planning on tracking uniforms with a hash table, which should make setting values a tad quicker. While I was at it, I also added support for geometry shaders!
My test geometry shader may have had a bug or two...
One obvious feature that dfgame has been missing for a while was loading/rendering actual meshes. I've thrown together a quick-and-dirty OBJ loader, so this issue has now been resolved. Combined with the new shader setup, I can play around with graphics programming much more easily.
The fixed shader
Lastly, I've added some initial support for font loading/text rendering. For the first time in my life, I've finally managed to get TTF fonts to render properly with FreeType. This will be super useful for making any demos/tutorials in the future. I'm currently in the process of creating actual text objects with word wrapping and some other handy features, which will hopefully be working by next week. If you looked at the above images, you might've noticed the Japanese Hiragana character floating to the right of Suzanne. One of the nicest features of my new system is that it has (basic) Unicode support. For now, text objects are going to stick to ASCII only, but all of the necessary groundwork has been laid out, and at least Unicode can still be used for icons and the like.
Next Up
Once text is figured out, I'm going to go back and fill in some holes. There are a few bugs with audio that need to be fixed, and I need to finish the input implementation. After that, I'm probably going to get the html5 version up to speed, while also continuing work on Halberd. I'm also thinking of adding particles somewhere in-between just for the fun of it!
Let's get the big news out of the way: On May 14th, I graduated from Champlain College with a Bachelor's Degree in Game Programming!
That's right. This blog was started just before the start of my Freshman year, with the goal of documenting my work throughout my studies. Its purpose is now fulfilled, but I have no plans on stopping anytime soon. I'm going to keep posting as long as I can, so don't worry about me disappearing.
Now that I have my degree, I also have to start considering how to divvy up my time for working on projects. I doubt it'll be very long before I'm working 40 hours a week, so I need to come up with a solution that will last beyond my current 'vacation'.
The Plan
Right now, I'm planning to adopt an Agile-like method of working on my projects. Every week, I'll figure out which tasks from various projects to work on, and then try to get them done that week. For now though, that seems like a bit of a leap from my current carefree work-on-whatever schedule, so I'm going to be taking this transition in steps.
For now, I'll be trying to make a list of several projects every week, and focus on one or two every day. This should give me enough content to make at least one post per week. (No promises, though)
It's likely that you'll also see more non-programming content. I've been meaning to do more with art and audio for a while, but school got in the way time and time again. I'm hoping to practice those skills a bit, and maybe that practice will turn into posts once in a while!
It's been a few weeks since my last capstone post, and quite a lot has happened! Last week we finished The Last Light and presented it at the senior show, and it got a pretty great reaction all around. Even better, the game got several Let's Plays after we put it up on itch.io, and the overall reaction seems to be pretty good.
By the way, you can download the game here:
(Sadly, it's Windows only right now. I might see if I can put a Linux build together at some point though)
Now that the dust has settled, I thought it might be a good time to go over some statistics from the project. I got a few requests from fellow team members, and also wanted to do some things myself, so here we go:
(Please keep in mind that these numbers are estimates pulled from hastily-constructed git queries. They should be close to the right number, but may not be perfect)
Total Number of Merge Conflicts
When dealing with teams that have more than a couple of members, it's only natural that at some point, merge conflicts are going to happen. This problem becomes even more common when your project consists mostly of binary files that can't be merged normally. We certainly had our fair share with 122 merge conflicts resolved.
Floor_400x400
For some reason, a random unused asset from the UE4 starter content folder, Floor_400x400.uasset, kept getting marked as changed. My team was curious how many times it got 'updated' in git. Apparently, 60 times. That's about once every other day!
Substance Plugin Kill Counter
Unreal really loves the Substance plugin. If your machine has it installed, Unreal has a habit of quietly slipping it into your project when you're not looking. Then, everyone else on your team gets a little popup saying something along the lines of "This project requires the Substance plugin. Do you want to download it now?"
Naturally, this message is a tad irritating, so we tended to go into the project file and purge the plugin. We did this 34 times, in fact. That number actually seems remarkably low, but I think it's because we didn't always remove the plugin immediately if we were busy, so sometimes it would stick around for a while.
Total Number of Binary Updates
Have you ever an artist to go compile some code? It's not pretty. Although Unreal makes compiles pretty easy, we programmers made a point to include the compiled binaries in git so that our fellow team members could spend less time compiling and more time developing. This happened 96 times.
That's it, but hang on to your seats, boys and girls! It's time for.....
Uncle Huey's Repo Analysis Awards
The "Biggest Git" Award for Total Commits
Let's start with a simple one: Who made the most commits overall? It was a close race, but the winner is: Chris Johnson, with 292 commits Second place is Vincent Loignon, with 288 commits. Simple, right? On to the next category!
The "Man of Mystery" Award for Commits under an Alias
Not everyone keeps to a single name, especially when jumping from computer to computer. This award is for the person who made the most commits under a non-name: Jesse McKinley, with 122 commits listed as 'Dekeche'
Second place is Hugues Ross (me), with 121 commits listed as 'DF458'
Looks like it's another close one. Next!
The "Fashionably Late" Award for Latest First Commit
You know what they say: The early bird is a total loser. This award goes to the person who was the last to start making commits to the repo. Who won? Why, it was: Paul Scardera, who first committed on April 13th
Second place is Kyle Patterson, who began on April 8th
I think it's important to mention that these awards are meant to be fun, and that this isn't any sort of condemnation. Paul and Kyle are both producers, so they only joined in with direct development at the end to help with 11th-hour grunt work. They've been super helpful throughout the project, just not with commits.
And speaking of strange awards...
The "Writing is for Losers" Award for Most Commits Without Changing a Single Line of Text
Git keeps track of how many lines of text were added, removed, or changed in text files. This award goes to the developer who made the most commits while maintaining a perfect 0 in all of those categories. Let's hear it for: Paul Scardera, with 7 commits and 0 lines
Second place is Scott Beecher, with 6 commits and 0 lines
Again, be nice, not everyone's work is represented by commits, yada yada.
Now, time for the final award:
The "Who's That Pokemon" Award for Most Enigmatic Team Member
Among the huddled masses of our Slack channel, there are rumors of a secret developer, spoken of only in hushed tones, working from the shadows. Who are they? Where did they come from? No-one knows for sure. Of course, I'm talking about: Unknown, with 18 commits
Yeah, so someone probably just forgot to enter their name into git before committing. Still, it's good to have fun with these things, that's what the awards are for!
Actually, I just double-checked and apparently it was me all along (with one commit from vince). Whoops!
Project Development Visualization
All this text is pretty boring. Thankfully, I have a solution to that problem. In addition to all of these stats, I also have a visualization of the project's development, starting from February (Fullscreen viewing is recommended):
This video was made with a super-cool tool called gource. Go check it out!
This semester, I posted twice about console programming projects. They were small, carefully scoped projects to help me get a jump-start with DFGame. Now, it's time for the big reveal: My final, 2-month long console programming project. That's right, I
PORTED DFGAME TO HTML5/WEBGL
Yes, all of it.
One of the requirements for Console Programming is to develop at least one project on an unfamiliar platform or with unfamiliar tools. I decided to try my hand at developing a web-based game framework that was fully compatible with DFGame. The project was a big success, and I actually have a playable demo up on my site (based on the demo I produced for my previous project).
You can check it out here. (Note: you need a relatively recent version of a modern web browser such as Firefox or Chrome. IE won't work and Edge/Opera/Safari are untested)
Now, let's talk a little bit more in-depth about the project.
History
When I originally kicked off this project in class, I had much bigger aspirations. My original goal was to port both DFGame and Halberd, then add an HTML5 export option to Halberd's editor. Obviously, that was way out of scope. After a week or two, I decided to scope down to only porting DFGame, and that's what I stuck with throughout the project.
I wasn't sure how much of a demo I'd be able to put together, but I managed to complete the DFGame port quicker than expected and ended up with a couple of spare weeks to work on the demo.
The current demo doesn't have a title screen or audio in it, but is otherwise mostly indistinguishable from the desktop version.
Now, let's talk about the platform in general, and weigh the pros and cons of the platform.
Pros
This setup is mostly cross-platform. I don't have to worry as much about weird edge-cases, at least compared to developing native Windows and Linux versions of my games.
The games that I make with this are more accessible in general. There's no need to download an executable, just load up a link and play.
Since the library draws to an HTML5 canvas, I can pretty much embed DFGame into any web page that I want.
Those are some pretty good benefits. However, there are some pretty big problems with it as well.
Cons
Unlike the C version of DFGame, all IO is required to be asynchronous. This isn't necessarily a bad thing, but it means that I need extra boilerplate to ensure that the right assets are loaded before the game begins.
The actual performance of DFGame is way lower when using the HTML5 version. This is to be expected, of course--You can't really compare raw C to embedded JS, especially not in web browsers with single-threaded renderers, such as Firefox's current release. Chrome currently gets way higher FPS than Firefox, but it still lags if enough is happening on-screen.
The WebGL API is currently outdated, compared to the current OpenGL and OpenGL ES standards. As far as I can tell, WebGL is still locked to the GLSL 1.0 standard, compared to 4.3 in GL and 3.2 in GLES. As a result, I need to rewrite all of my shaders whenever I move something over.
Further Work
Despite the problems with developing HTML5-based games, I'm actually pretty happy with the result. I think it's worth my time to continue developing and using the DFGame port, especially for game jams and other simple prototypes.
The port is currently behind, because I've been recently developing DFGame some more. I'll be posting about some of the new improvements soon. I also want to look into optimizing for WebGL better. I can't get a comparable framerate to the C version, but maybe I can eke out some more performance out of the web.
Lastly, I want to polish the demo some more. If I get it into a good enough shape, I think it could make a good portfolio piece. For now, I'm going to let it sit in a dark and dusty corner of my site until it's properly finished. Hopefully I'll have more time to do that now that my finals are over.
