Akradion Update 1

Changelog:

• Mostly integrated Bullet into the engine
• Added creation script callbacks for entities

Bullet Physics:

Here's some big news. While I was working on this project, I finally decided to add some proper physics into DFEngine. It's taken me quite some time, and I still haven't worked out all of the kinks, but I have an actual physics engine handling things now! That's pretty sweet! Along with other benefits, this will most likely faster and more accurate collisions, something that's been missing for quite some time. Unfortunately, this means that I don't have anything new on the game side of things. Maybe next time!


As for the callbacks, that's important but not too interesting. Basically, I can now call a script when I make an object. It's nothing new, but it helps.

DFEngine Update 3

Sorry for the late post! This one took a while to write up.

Changelog:

• Finished Lua integration
• Added some basic collision checking
• Added a special component to hold user-defined data.
• Made a basic prototype for a new game (!!!)

Lua:

This was a bit of a pain to figure out, but lua scripts can now be attached to entities. Instead of running my stupid little scripting thing from AMAZE, entities now have access to a fully featured scripting language. In fact, all of an entity's data gets exposed to the lua scripts, so you can mess with pretty much anything as you please now. Global game functions are also accessible, so you can now do crazy things like entities that can add components to themselves when certain conditions are met. I can't wait to explore the new possibilities that this will open up for me.

Collisions:

Currently, collision checking is very basic. The engine can only handle basic AABB collisions at the moment, making it even worse than what AMAZE had. I'll improve this eventually, but for the moment it'll do. Since it's been a while since I've posted anything particularly technical, I think I'll explain AABB collisions here: 

AABB stands for Axis-Aligned Bounding Box. In other words, an AABB is a rectangle that surrounds something without rotating. In order to check if two AABBs intersect, you just need two diagonally opposite corners from each, generally the position of the top-left corner, the width, and the height. From there, you only need to make four checks. If they are all true, then the two AABBs overlap. Otherwise, they do not. Here's some pseudocode describing these checks:

Rectangle1.x + Rectangle1.width >= Rectangle2.x

Rectangle2.x + Rectangle2.width >= Rectangle1.x

Rectangle1.y + Rectangle1.height >= Rectangle2.y

Rectangle2.y + Rectangle2.height >= Rectangle1.y

The first two checks ensure that the left/right sides of the rectangles touch. The other two do the same for the top/bottom sides. This is easily the quickest and easiest way to check for collisions, and often an AABB check is enough. It's generally quite inaccurate, however, to use a rectangle to describe most objects. For more complex shapes, more precise calculations are needed. I'll describe the methods of checking other shapes as I add them to the engine.

The New Game:

So, you're all probably curious what this new game is! First though, I'd like to explain how I came to my decision to make it. After AMAZE was done, I felt that one of the biggest issues I'd run into in terms of DFEngine's development was the size of the game. DFEngine's code was supposed to be updated regularly, but because my first project ended up being too big I ran into some issues. This became especially true once I started working on the game's levels. At that point, an update could force me to redo tons of work, and I started dreading engine updates. Thus, I want my first game with this new engine to be short and easy to make. With that in mind, my first game will be..... Akradion! This will be a simple breakout-style game, and I'm not putting any upper or lower limit on the number of levels. In the end, Akradion will probably end up being more of a minigame, with around 5-10 levels. To see if I could actually make this game, I threw together simple prototype yesterday. It was extremely basic, and it had a few bugs, but the fact that it took me so little time makes me very happy. If I'm lucky, I might even be able to finish the game in a month! I'm not making any promises there, though. (By the way, the name Akradion is actually an anagram of Arkanoid)

DFEngine Update 2

Changelog:

• Added Text Rendering, using FreeType
• Reworked some of the structure, primarily with components
• Added some initial Lua scripting features
• Made some minor changes that should speed things up down the line

Text Rendering:

So, the font stuff's done. Now that I'm using the FreeType library to load fonts, the visual quality of the text has improved dramatically. Instead of the previous sprite fonts(which I may add support for at some point, but not now) which had to be drawn and generally looked pretty bad, I can now use any font that you'd otherwise see used in most applications. These fonts have several massive advantages: First, they're scalable. Once one's been made, I can set it to be used at any size. Second, they are properly aligned. Most sprite font systems don't account well for the sizes and shapes of letters, and the resulting text looks blocky and strange. It's also difficult to deal with letters of different heights, especially those that need to be placed lower than others. FreeType gives you all the information needed to align your letters nicely. Lastly, it's much simpler to read these fonts in and keep track of them. Even if I decide to make my own font files, they'll be made using information gotten from FreeType. I can edit the base font normally, and I won't need to keep track of anything else.

To be honest, the actual process of getting FreeType into a program is pretty boring. The library handles most of the really interesting things behind the scenes. That said, I should leave a word of warning: Most of the tutorials I found for using FreeType with OpenGL were outdated and/or useless. If you want to use the library, you're better off looking through the documentation to get an understanding of how it works, then using that as reference. There's a nice tutorial there to help walk you through the basics of setting up and using FreeType in your application, which is what I used.

Lua:

If you've seen how AMAZE operates under the hood, you'll very quickly find that the scripting is very rudimentary. I'd originally considered using lua, but I eventually decided not to until later. Of course, I never expected things to go as they did, and the scripting stayed as it was. Finally, I can fix that. In order to do so, I had to rearrange quite a bit of code, mostly dealing with components. Components belonging to one entity are now held together in an entity class, and systems hold less power. Now, most of the 'meat' of an entities behavior will be defined in lua scripts that the entity can call. Systems will handle more complex things, such as collisions, timers, and other processes that require knowledge of the game's 'big picture.' Anyway, one of the biggest upsides to using lua will be that the syntax of scripts can be much more complex, and more information can be obtained in these scripts. It'll also make the engine code simpler and cleaner. Overall, it means that I can do fancier things than before, and with it'll be easier too! Of course, lua integration is still ongoing, so for the moment I can't do much more than spawn a couple of basic test objects when the game starts. I did, however, make a nice little FPS counter using lua. I'll probably end up using lua scripts to handle some more basic things like setting up the UI, but I haven't decided for certain yet.

DFEngine Update 1

Note: From now on, I think I'm going to try and add more code examples to these updates. Not only will these help add more interesting content to my update posts, they may come in handy for any aspiring programmers out there. For now, code is marked with green text. I'll try and see if I can come up with a better solution soon.

Changelog:

• Started working on a UI toolkit
• Added a window class that can hold UI components
• Added a viewport class that can act as an in-game view
• Made UI widget positions/sizes be based on their containers
• Made UI widgets dictate whether or not to fill their containers when extra space is available
• Added a basic tweening engine
• Started rewriting the Entity Component System code
• Got basic keyboard/mouse input working

Oh boy, guys! Here comes the new engine! And this time, I've actually made sure to back up my codebase so I don't lose everything again!

Viewports:

One exciting new feature I've added to the engine is the ability to have multiple views! This will let me do quite a few nice things, such as adding minimaps and split-screen multiplayer. Surprisingly, adding viewports with opengl was much easier than expected. All you have to do is call glViewport to specify the position/size of the view, run some transformations based on the view's position, rotation, and scale, then redraw the scene. Here's an example:

glClear(GL_DEPTH_BUFFER_BIT); //Setup the viewport for drawing

glViewport (view x position, view y position - view y size, view x size, view y size);
glLoadIdentity();

glOrtho(0, 1, 1, 0, -1, 1);

glPushMatrix(); //Apply view transforms

glTranslatef(ingame camera x position, ingame camera y position, ingame camera z position);

glRotatef(ingame camera x-axis rotation, 1, 0, 0);

glRotatef(ingame camera y-axis rotation, 0, 1, 0);

glRotatef(ingame camera z-axis rotation, 0, 0, 1);

glScalef(ingame camera x scale, ingame camera y scale, ingame camera z scale);

glPopMatrix();

As you can see, it's quite simple. I'm sure there are better ways to handle the rotation, but I don't know it right now.

(Note that I'm still working with old opengl code, as my graphics drivers are pretty terrible. Thus, this might not be the correct solution for opengl 3+.)

I also gave it beautifully smooth zoom feature, which brings me to...

Tweening:

While I was at it, I also decided to experiment with tweening. I believe the term originated with animation, and referred to adding frames in between keyframes. In games, it refers to taking some numerical amount, like the position or color of an object, and changing it smoothly over a certain length of time rather than just setting it to its new value. It took quite some time to make, but I think it'll really help make my games look better. Unfortunately, the effect can't really be shown with just a screenshot, so I may have to try and make some progress videos.

Component System:

This is pretty similar what I had in the last version of this engine, and it's a bit boring, so I'll spare you the details. That said, one new thing I added was a better way of handling the retrieval of data from objects. I'm still not happy with it, but it works. Lastly, pretty much any data that an object's components are hanging on to can be tweened now.

Finally, I've started working on a new (and much improved) font system, but it's still far from finished. More on that next week, hopefully.

Delete Everything 2: Electric Boogaloo

It's been more than a year since the last time this happened, so let's give it another go!
AHAHAHAHAHAHAHAHAHAhahahahahahahahaha....

So I started working on the new version of DFEngine this week, and then I lost all of it. I also lost most of my other files in the process. Singularity and my other game/code projects seem to be safe, thankfully, but I'm still shocked at how much is gone. I've also simultaneously fallen ill, which just serves to make matters worse. Of course, this means that the super cool update post will have to wait at least a week, a prospect that makes me pretty sad.

Well, time to get working!