JULY 10, 2017

I have rebooted the site and gotten so much done in the past couple weeks! Well, "so much" isn't saying much for those who get to code full time, but in what little spare time I have, I've gotten quite a bit done. :3

So, how's XYG going? Well, it's doing pretty well! I've got all essential input done; gonna do gamepad input soon, but I want to try out making an actual game with it for a bit, get a feel for it and see what existing features need to be tweaked and what can be improved before I start adding more stuff. I definitely want to add more!

Bitmap Fonts

A major update I'm working on is getting rid of TTF fonts and using bitmap fonts. Why? Well, let's look at the process it takes to render a piece of text on the screen, and let's assume that once you've rendered this text, you are done with it, and you don't need it again in the next frame. I use this example because if you're going to render the text to an image and reuse it, you can do the same with a bitmap as well. So here we go:

  1. Create surface.
  2. Render text to surface.
  3. Create texture from surface.
  4. Unload surface.
  5. Render texture to target.
  6. Unload texture.

Using a bitmap, you can take an existing sprite and use it as a font, and rendering then works like this:

  1. Clip letter from sprite texture and copy to target.
  2. Increment position for next character.
  3. Return to one until done.

Seems like it's only half as many steps for bitmaps as for TTFs, but what's more is that when you load a TTF in SDL2, you define a size. Why? Because it's turning it into a bitmap! So that means the TTF step 2 is actually three steps, making a total of eight for TTF and three for bitmaps. It's simply self-evident that the bitmap route is the way to go, and what's more, mine will support newlines right out of the box.

So, how will they work? Well, like I said, you take a sprite and turn it into a font. When the font is created, it scans each frame for the min and max X coordinates of the contents, ignoring fully transparent space. Then it stores those values in the form of an offset from the left and the width to move to the next character. When a newline character is encountered while rendering, it simply moves down by the height of the sprite, plus whatever vertical padding is assigned to it.

While thinking of how to handle alignment, I came up with an interesting feature: being able to request the width of a string in pixels. This will be a very useful feature for games that use typing text, allowing them to predict whether or not the next word will overflow and to insert a newline before going to the next word.


Sprites are pretty much perfected at this point. Only problem I'm having is that when scaled, they don't pivot properly, which makes them wander around when rotating. I got it working in the SDL1.2 version, so I just gotta look around and find where I got it to work. Should be a quick fix.


Many thanks to Nuno Silva for the awesome wiki engine, StaticWiki that made this new site possible! The site is now much more mobile friendly and even includes a search function.

I'm going through and moving everything from the reference file into the new wiki, but also doing a better job of organizing and updating what's in it. Also, I'll be including code examples for as many functions as possible, though I think some may possibly work without them. I decided to include the arguments in the title so that they show up in search results. I'll also start copying code examples into the reference file for offline use.

Standard Libs

While working on the games I'm using to help test everything while making the engine, I'm going to work on collecting functions and classes from them that will work in multiple games and create some more libraries so that include() will see more use.

Search results