Singularity Update 10

Changelog

-Command-line arguments now use more standard syntax. -Added a menu entry to mark all viewed items as read. -Singularity now asks for confirmation before deleting feeds. -Added settings for how attachments are handled, but they don't do anything yet. -Added an 'about' dialog to display information about singularity.

Well, as you can see I'm back! Unfortunately, this update is mostly full of simple, boring stuff. I wanted some lighter tasks to get myself back intothe groove of things, so I knocked off a few simple features from the v0.2 list. My original goal was to release by the end of the year, but it's hard to tell if that'll happen. Assuming I work my butt off and nothing truly awful happens, I'm probably ok, but you can never know with these things. I'm glad that my estimate was in the right general ballpark though. So far, I'm pretty happy with the progress I've made on the project, although I'll probably stop updating for a long while after 0.2 hits.

300 (Teapots)

Ever wondered what a gang of 300 mobile teapots looks like?

...No?

Well, too bad:

Apparently, 300 teapots

Now, as funny as it would be to just leave this image here without context, I think I should explain what's going on here.

This strange scene is from a class project for my recently completed AI programming course. This was actually the midterm, but I was too busy to share it at the time. With the semster over, though, I can finally write again!

Background

Like any good course on game AI, this one featured a section on pathfinding. Our instructor gave us a basic rundown of Dijkstra's Algorithm and A*, then let us group up and research some more advanced techniques. With Peter off doing who-knows-what, I paired up with Johnathan O'malia, a pretty great coder who I met in the class.

The Project

For our main technique, we looked at using navigation meshes to generate pathfinding graphs from 3D environments. To create the navmesh, we used Recast, a peice of open-source middleware. If you look below, you can see screenshots showing the test mesh with and without the pathfinding graph displayed: Before... ...and after! Now, if you've worked with navigation meshes before you might find the result overcomplicated. You'd be right to think that, as the resulting graph is actually a subdivided version of the original navmesh. We did this so that we could work with a relatively simple node array, rather than pathfinding with the mesh itself. Because of that, we nedded to subdivide the mesh to produce some in-between nodes that would allow us to produce straighter, more direct paths.

The Teapots

As you may know,the teapot model in our project is an old favorite known as the 'Utah Teapot.' If you know what it is, it should be pretty obvious why it was used. However, the fun part comes when you consider the context. The teapots are AI agents that need to path to a specific location, in our case the camera, and so we ended up with the strange situation of being followed by a group of strangely intelligent teapots! The nature of the assignment also lead to a few odd visuals, like these teapot centipedes:   I especially like this image So, uh..... yeah. Teapots! The red lines that you can see in the first image denote the paths calculated by the teapots. Johnathan added some sort of smoothing function to the paths, and I've got to say that the result is quite nice in action! Another thing that you might notice is the rudimentary lighting engine. I wrote that part, and expanded further it in a later project, but that's a topic for later. I'll leave you with an aerial view of the map, with only the paths shown: As you can see, the teapots have just finished their long march to the top

Really Fast Pathfinding, an Assignment

As you probably know at this point, I'm currently a college student majoring in Game Programming. As this semester wraps up, I have to research and explain an AI programming technique here for my final assignment. In this post, I'll be explaining how to use jump points to make a ridiculously fast grid pathfinder.

Note: This tutorial expects that you already understand the basics of the A* pathfinding algorithm. If you don't know it, I recommend looking here. It's the best and easiest resource on the subject that I know of.

 The Problem:

When pathfinding speed can often arise as an issue. A*, the most common pathfinding algorithm, can be fairly slow in numerous cases, especially when dealing with large open spaces. Obviously, this means that games can put A* into it's worst cases on a pretty regular basis. For this reason, a huge number of techniques have sprung up to try and improve A*'s speed when dealing with such areas. I'm going to be talking about one such technique: The Jump-Point Search, or JPS for short.

Turns out, both of these are of equal length.

JPS is based on  the notion of path symmetry, where multiple similar paths have the same length. This mostly occurs when dealing with grids. With A*, hitting a wall or corner often leads to unnecessarily checking a large number of tiles. Thus, the goal is to only check tiles that are important, and ignore the all of the empty space. JPS does just that, by turning small steps into huge leaps.

Introducing JPS

JPS is a surprisingly simple technique that only alters one stage of the process. When the time comes to get the neighors of the last checked node, JPS makes each neighbor 'jump' before adding it. To do this, JPS makes the neighbor move away from the original node until it reaches a turn of some kind. How does it do that? That's the interesting part.

A diagram from the original paper, demonstrating how JPS ignores neighbors. Anything greyed out can easily be reached by the original node, and is ignored.

When 'jumping', JPS acts under the assumption that most of a nodes neighbors can be reached by the original node, and so it ignores them. If a jumping node runs directly into a wall, it returns nothing, since that particular line contains nothing useful.
To find walls, JPS does two things. First, it checks certain neighbors for walls. As you can see in the above diagram, walls can only block out a node's neghbors from the original position if the node is moving orthogonally, and they are perpendicular to its movement, or the node is moving diagonally, and the wall is slightly behind it.

The horizontal and vertical jumps, as illustrated by the original paper. Dashed lines indicate a failed jump.

The second check is only made if a node is moving diagonally. To ensure that a far off but accessible turn isn't missed, the node sends out two more node 'jumps' on its vertical and horizontal movement.
When one of these cases is found, the node stops and is added to the list. Also, if the endpoint is found at any point then that gets added as well. This effectively leaves the list of nodes to check with only potentially important ones, leaving out the filler.

So, Why Care?

There's one simple reason to care about JPS: it's better than regular A*. It's proven to still find the shortest path, it requires no additional preprocessing, and best of all, it's pretty much always faster. The paper mentiona that their worst case had JPS finding paths at around 3 times the speed of A*, and their best had JPS doing so 30x faster. No, the 0 is not a typo. That's immense! I've implemented my own version, and it's still a rather buggy, but still usually outperforms A* by a noticeable margin. In other words, I see no downside to using this in any game that ca, on whatever platform you want. One thing to note is that this only works on on grid-based graphs. If your pathfinding graph is more freeform, then the technique won't be of much use. Of course, at that point you can probably just add your own optimizations anyway.

My Attempt

I've written my own A*/JPS implementation in C++ using Drunkard's Walk-generated random areas and ncurses output. Here's how it looks(Highlighting added after):

Red areas indicate where nodes have been checked/added to the open list. Note that the full path is quite long, so most of it is missing. Rest assured that it's pretty much just like this the whole way.

As you can see, JPS changes things quite a bit. One thing to note is that a JPS path will mostly only have nodes at turns, so you'll have to fill paths in if you plan to snap movement to the grid. I decided not to other in my demo, as I don't really need to do anything more with the path. I've decided not to include my demo here, as it's fully exclusive to Linux, poorly coded, lacks comments entirely, and features a a very draconian vim-like interface that would make most normal people uncomfortable. If you really want it, though, feel free to send me an email or comment, and I'll be happy to make it available on an individual basis, source and all.


Well, that's it. I find JPS a bit difficult to explain, so I hope I've done a decent job of it. I recommend taking a look at the original paper, linked below, if you're confused. It contains psuedocode for the entire jump function, which makes implementation easier. I should warn you now, though, that the language is very academic, so it can be a pain to read. My third reference below has an online demo, so if you just want to see the algorithm run without making your own implementation you should head there.


References:

1. http://www.aaai.org/ocs/index.php/SOCS/SOCS12/paper/viewFile/5396/5212 - This is the original article that describes the JPS technique. A very useful source of information, if you can decipher the academic writing.
2. http://aigamedev.com/open/tutorial/symmetry-in-pathfinding/ - This is where I first encountered JPS. I was researching some things for another project(I'll be posting about that one later), and I ran into this. It looked like a cool technique, so I bookmarked it for later use. This particular resource talks about another technique as well, but doesn't go too in-depth into either.
3. http://zerowidth.com/2013/05/05/jump-point-search-explained.html - Another resource that I used to help me figure out what was going on in the paper. It has some useful diagrams and an interactive demo, making it a really great reference.

Singularity Update 9

Changelog

-Fixed the bug with automatic deletion, and boy was it something! -Added a 'rule' system. It replaces the automatic deletion, but provides the same default function. -Made the settings pane look nicer.

The Rules

The new rule system is working! The way this works, users can set 'rules' based on time and item type. The simplest way to explain these is with a couple of examples:
"After 7 days, delete unread unstarred items"
"After 3 months, mark unread starred items as read"

As you can see, this sort of thing gives the user much more control over what happens to feed items. Eventually, I want to add overrides for specific feeds, multiple rules per type, and more actions. For now, though, it's a nice step up from the old auto-delete feature.

My desktop: Wait, what?!

Hi:

Around Halloween time, I had a "Brilliant" idea to deter people from borrowing my laptop. There is a single key on my keyboard that, when pressed, summons a skeleton as shown above. It was pretty easy to set up with my current desktop, but before we talk about that, I think it's best to give some background about my system.

My current desktop. Click to view it in all of its glory!

I switched to Arch Linux on my laptop last summer, since interesting things happened, and I haven't looked back since. I took this opportunity to learn how to use a tiling window manager, and I fell in love with suckless' dwm. The cool thing is that dwm is very small, and intended to have its code edited instead of using config files. So far, I've built up a wonderful collection of scripts designed to let me have some fun with it.

1. My biggest script handles the information displayed in the upper right-hand corner. Most of it is fairly simple, relying on a ton of basic Linux tools, so I won't bother talking much about it here. If you're interested in any specific part of it, just send me a message or comment here and I'll happily explain. At some point the source will be available, but I'm not quite ready to share it.
2. Remember the Skeleton? Here's how I did it:
1. I drew a grinning skull using Krita, and my drawing tablet. I could've done a better job, but I really liked the sketchy look.
2.  I animated the skull opening and closing its mouth using Blender. I used to know Blender inside-out, but my coding has gotten in the way of using it. This seemed like a great opportunity to get back in the game.
3. I found a bunch of spoooky sounds on Freesound.org.
4. I put the whole thing together in Blender, and added the special effects.
5. I rendered the result to be my exact screen resolution, 1600x900. I still have the files, so on later machines I can remake this.
6. In my dwm config.h file, I added these two lines of code:
   

   static const char *spookycmd[] =
   {"mplayer", 
    "-fs",
    "/home/df458/Videos/SKELETON.mkv",
    NULL };
   // ...Later, inside the keybind array
   {0,
    /*Your key goes here. Mine's a poorly-kept secret ;)*/,
    spawn,
    {.v = spookycmd} },
   

7. As you can see, it's really quite a simple process. This whole mini project took just an afternoon to do!
3.  Now, if you use dwm you might be wondering how I got a pretty little albumart box on my desktop, and a drop shadow for my top bar. In reality this is a bit of a hack--I just use ImageMagick! I've been working on an ImageMagick script that runs when a new song plays, when I start up, and when my background switches. Currently, it's slow, doesn't look great, and isn't finished yet, so I won't be sharing the script. However, expect a small post about it in the future! Just like with my bar script, I'm still willing to discuss the topic in greater detail if you want.

So, what do you think? If you have any suggestions or requests for me to implement and explain, I'd love to hear them!

General Update: Something New

If you've been following this blog, you've probably noticed recently that my posts have dropped off. I've been thinking about this blog and my work, and I'm not very happy. Thus, I'd like to talk about what happens when I fail to make a weekly update post.

There are a few reasons fir this generally:

1. I haven't gotten much work done on anything that week.
2. I forgot.
3. I've been working on some undisclosed project.

All of these happen, but I'd like to look a biut deeper into each. The first one is the rarest, for sure. I usually get something done,  and it's only when I'm super tired and burnt-out that I fail to post. The 2nd one is more common than I'd normally like to admit. I'm a very forgetful person, and frankly This is probably my 3rd or 4th blog at this point. The others survived a few weeks, then were forgotten, so I'm slightly amazed that this one has lasted as long as it has.

Finally, let's talk about the last reason, and my projects.
I have a ton of reasons for which I might not talk about a project:

I might consider it too personal, or odd, at which point I feel like I shouldn't share it publicly. These projects will probably not get talked about in any setting, much less a public blog.
I have smaller 'Toolkit' projects that I make solely to make my life easier. Oftentimes they're the product of a single weekend, and I don't think they'll stick around. Usually, they'll get small occasional updates over a long period of time, and once they've grown it feels too late to discuss them.
I have school work, which seems pretty mundane for obvious reasons. Sometimes, like with Space Douchebag, I post a little bit, but usually I jst stay quiet when I shouldn't.
Lastly, I have prototypes, and lots of them. I come up with all kinds of interesting ideas, but I often worry that they won't go anywhere. Usually, I'm right.

What does this have to do with my moment of introspection? Everything. When I look at my blog, I always regret the fasct that the content on here really freaking boring. In fact, it's mostly just changelogs and massive walls of text, like this post! I've needed to change that for a while, but have had difficulty coming up with a solution. However, I think I have one now. Whether it works or not, only time will tell.

Here it is:

1. I need to drop the weekly updates entirely. Singularity will keep getting them until 0.2, and then that's it.
2. I need to talk less about exactly what I've done, and more about cool stuff I've found while doing it, the things that I'm learning, and how I'm doing things.
3.  I need to talk more about various undisclosed projects.
4. More screenshots, and more videos.

 I'm going to try and put these steps into practice as of today. This is rather experimental, and I'm worried that this will fail horribly, but I still need to try. Hopefully I can keep with this.

Also, an update on Twitter use: If you're wondering why I'm not tweeting at all, it's because I literally cannot log in to Twitter. It simply boots me back to the log in screen when I'm successful, so I'm stuck there. Hopefully that'll get fixed someday!
EDIT: I'm back on Twitter now!


TL;DR: My content sucks, so I'm going to drop my schedule, add more shiny things, talk about more projects, and save the universe. Whoo!

Singularity Update 8

Changelog

-Items should now be marked as read more reliably. -When you aren't subscribed to any feeds, Singularity now displays a 'Welcome Screen' that prompts you to subscribe to some. -Added a Settings pane to set userthe preferences. -Singularity can now periodically check for feed updates. You can disable this/change the interval from the settings pane. -Fixed a serious bug where feeds could end up with the same id.

Settings

Getting settings into Singularity is probably the #1 culprit for why I haven't made any updates during the past few weeks. This particular feature slowed my progress down considerably, mostly because I needed to do a ton of work to even start seeing progress. At this point the settings pane is mostly empty, and it looks awful, but the hard part is over now.

Down the Road

It's been over a month since 0.1 came out, and you might be curious as to when I'm going to release 0.2. For once, I can answer that! My current goal is to finish singularity 0.2 by New Year's Eve, and release it soon after. Last week, I layed out my goals for 0.2 on Singularity's Github page. The list is pretty long so I'm a little bit worried, but I think I can manage. My goal for 0.2 is to take the base I created with 0.1, fix some issues, and then build off of it with some of its more 'essential' missing features, like the aforementioned settings pane. Currently, it looks like 0.3 will try to make the application act nicer on other systems, as a build up for an eventual attempt at getting it provided as a package in one or two distros. We'll see about that, of course, but I'm hopeful.

Singularity Update 7

Changelog

-Added an experimental feature to make feed items fit together nicely. However, it probably won't make it into the release. -Fixed a bug where you couldn't add feeds anymore. -Made a change to the install so that it doesn't require extra work. -Moved the location of the default css and status emblems to /local/share. The default.css file in ~/.local/share/singularity will override it, letting you customize your view a bit.

A Fitting Change

This week, I tried to change the way that items are arranged. Using the css 'flexbox' feature, you can make things fit together in different ways depending on how much room they take up. The result is ok, but pretty underwhelming. Flexbox won't resize content to make it pack more efficiently, so anything containing text will take up a full row. I'll probably need to mess with this a bit more before I include it. The other issue is that the items that get packed into rows aren't all marked as read correctly. This is probably for the same reason that this issue occurs when the view scrolls too rapidly. This issue is starting to become a bit more serious, so fixing it is probably the next thing I'll get to.

The Clearing

Just the other day, old items were cleared for the first time. This was a day I feared slightly, since I wasn't sure how things would go. Considering that, I'm happy to announce that the results of that were mixed, but promising. It looks like any feed that had updated during the one-month period was correctly cleared, and nothing more occurred. Any feed that hadn't was also cleared, but then every item in it was reloaded. This is precisely what I was afraid of, but it looks like the issue might only happen on my end. I added the feeds when the feature was still a bit glitchy, so I think that's what caused the issue. Unfortunately, it's hard to say until next month comes around, and things get cleared again. If the feeds fail twice, I'll have to start testing and fixing things more aggressively. Anyway, this event reminded me that I still need to add a 'clear all' button. Hopefully I'll be getting that in before 0.2.

Let's Make a CLI Game! - 1 - Limits

Previous Part

Next Part

Just like I said in my last post, this is a tutorial series where we'll follow my attempt to make a strategy game designed to run on the command line. I'm going to be doing this in C, so I recommend that you learn the very basics of the language if you decide to follow along on your own. Lastly, while I'm hoping to teach you something, if you think I've made a mistake or need to be informed of something, then by all means email me or leave a comment below.
WARNING: The following tutorial segment is entirely preparatory. There is no code here, only reading. I think this information is important, but if you don't want to read it then just get through the final section, labelled 'Next Steps.' The next installment will be a bit more exciting.


When you start any coding project, it's especially important to know the limitations of your platform. If you don't, you're liable to cause yourself all kinds of problems later down the line. This can be especially true when you work with something as 'different' as your average terminal. Terminals can be quite limiting environments compared to your average graphical window. Let's examine some of these limits:

The first of limiting factor relates to how things are displayed in a terminal interface. Generally, text is added line-by-line to the window, and there's no apparent way to alter this. It is possible to do so, however. Most(all?) terminals provide a set of special escape sequences that allow you to perform various functions, like moving the cursor, changing text color, and so on. You can actually use these yourself if you know what they are, but I seriously wouldn't recommend it. Instead, the best solution is to just use a library for this. For this, I recommend curses. curses is pretty much the go-to library for building TUIs on most systems. It's extremely common on Mac and Linux systems, and there's a port called pdcurses for Windows. It does a few odd things, but it's common and reliable.

Now, after getting around the first problem we come to another: speed. curses, wonderful as it is, is a bit slow compared to modern hardware-accelerated graphics libraries. It doesn't take long to display things, but if you expect to have a gorgeous 60FPS then you are in for a major letdown. This is probably why most command-line games either have very low framerates, and very little to draw. In fact, if you're making a turn-based game you may be better off forgetting FPS altogether. You'll probably want output to be more reactive, only drawing when things change. This means forgoing most animations, but it also makes things much simpler to work with. Not only that, it may also let you use more complex calculations in your game, which is always a plus.

So far, our issues have been fairly simple. However, the next one is a bit harder. Depending on what sort of terminal or terminal emulator is being run, you're likely to run into color-related issues. Most terminals fall under one of these categories regarding color:

1. Black and White - Monochrome terminals aren't as common as they used to be, but they certainly still exist. 
2. 16 colors - As far as I'm aware, most color-supporting terminals have the same general default 16 colors. They are split into two sets, 8 normal and 8 bright. The colors are black, red, green, yellow, blue, magenta, cyan, and white. Generally, this makes the first 16 colors set for a terminal easy to guess.
3. 256 colors - I believe this trend started with xterm, but nowadays this is fairly common, albeit less so than the basic 16.
4. Full 24-bit color support - These are rare, but I've heard they exist. 24-bit color is equivalent to what you can normally draw to a screen(ignoring alpha). I've never tried to code for/use one of these before, so I have no real idea how it works.

As you can see, that's an incredibly wide range. Most games and applications generally seem to target the first two, since they aren't too far apart. However, since I'm building a game I'm going to try to support 256-color terminals as well. Another related difference is palette swapping. While the default colors are fairly predictable, many terminals allow you to change them. If that option is available, then much more can be done. However, just like every other feature it isn't guaranteed. Depending on how many optional graphical features you want to add, the complexity can ramp up significantly. Being a coding masochist, I've chosen most of them, but I'd recommend that a less experienced coder try to stick to simpler configurations. A good easy setup would be to try black+white paired with 16 color support, and maybe add 256 color support later if you feel up to it. Palette swapping can get very messy, but can have a great payoff if you have a solid understanding of it. If you don't believe me, look at these.

The final, most obvious limitation is the medium: In the terminal, everything is text! In fact, it's usually just ASCII. Sometimes other fonts and character sets can be supported, but that's no more reliable than color support is. Depending on what is being represented there are a number of methods for displaying things. If you want to draw something large and potentially elaborate, then ASCII art may be the right choice. However, if you want to draw a lot of smaller things, then you may want to only give them one character each, based on what they are. Players are often represented with an @ sign, a dragon could be an uppercase D, and so on. You aren't restricted to using one form of depiction in a game, but it needs to at least make sense.

Now that we've examined our target platform, we can really start. That'll have to wait until the next installment, though. For now, let me thank you for  reading through all of this. I promise we'll start coding soon! Next follows a short section that I'll be putting at the end of each tutorial segment, where I provide some tasks for you to try and complete before continuing to the next.

Next Steps:

1. Come up with an idea for a game, or adapt one that you already had according to the issues addressed above.
2. Decide what sort of terminal setups you'll be targeting.
3. Get set up. Make sure you have a decent environment for C programming, and curses. Ensure that curses programs compile and run properly. While you're at it, make sure that the terminal that you use matches your target(s). If you have multiple targets, you need to make sure that you can test for all of them.
4. Look over an ASCII table, and think about how to best depict the elements of your game.
5. If you don't already know how, learn to use a version control system. I recommend Git, but plenty of options exist. This isn't required, but if you plan to code any decently large projects then it'll help.

Tutorial: Let's Make a CLI Game!

Next Part

Recently I've been playing XCOM (both of them), and they've left me wanting to make something similar. As far as I can remember, I've never actually made a strategy game, so I think it would be a fun learning experience. That said, my 7DRL attempt has gotten me thinking about the terminal more, and I think such a game would fit perfectly on a platform like this. Thus, I've decided to try and make a strategy game for the command-line. At this point, you may be wondering: "What does this have to do with a tutorial?" and the answer is simple:
I've always wanted to give something back to anyone who reads this blog, so from now on I'll be writing tutorials and posting them up here! Thus will be the first series, but you can expect more in the future. Eventually, I'd like to see this blog become mostly a collection of information and resources for devs, and this is the first step in that direction. As I create this game, I'll be writing up posts explaining what I'm doing, why I'm doing it, and how I'm doing it. I hope you'll stick with me for this experiment, and hopefully the first real post will be up later this week.

Even if you're just curious I encourage you to stick around. You're bound to learn something!


One final note: These tutorials will take considerably more time and effort than my usual posts, so don't expect them to show up as often.

Singularity Update 6

Changelog

-Added basic support for RSS enclosures. -Made some improvements to the feed adding dialog.

Adding Feeds

When I released Singularity last week, you could already add feeds to the program easily enough. However, there were a number of small annoyances concerning this. Originally, I had the dialog hide itself when you did anything with the main application, but I found it to just be an annoyance. Finally, I've gotten around to letting it stick around. Additionally, the url input on the popup was accepting extra lines, resizing the dialog when when it got long urls, and just generally being a pain in the butt. This has been fixed. However, these changes are just temporary. I plan on redesigning some parts of the UI based on my own experience using the program.

Redesign?

Right now, Singularity has most of its screen space taken up by a web view. If you're trying to read some updates, this is great, but any other action renders the area completely useless. Thus, I've decided that most of the UI that was going to be put in dialog boxes is going to go there instead. That way, the space won't be wasted. I haven't tried this setup yet, but I think it'll work much better than what I'm doing right now.

Singularity 0.1 Released!

It's been almost a full month since I started rewriting Singularity, and almost a year and a half since the project was originally announced. This makes Singularity my longest running (regularly updated) project. That's partly why it's such a relief for me to announce the very first public release of the software! All of the project's source code is freely available on Github, under the GNU General Public License.

For those of you who aren't aware of what this is all about, or perhaps have forgotten, here's what this is all about:

Singularity is a simple GTK-based RSS reader. Development was started when Google first announced that Google Reader was being shut down. The project has come a long way since then, with 3 major releases(although this is the first public one), each one featuring a codebase rewrite. The first release, 1.0, was little more than a basic proof of concept. The entire app spanned only two code files, was filled with strange and arcane workarounds to simple problems, and was developed in a very short span of time. Regardless, it did its job(somehow). Afterwards, I felt the need to try and turn Singularity into a halfway decent piece of work. This led to version 1.5, released fairly soon after the 1.0 release. This version was much better than the last, and is the longest-used version so far. However, it wasn't very well designed, had a fairly large number of issues and missing features, and slowly acquired quite a bit of cruft. When I revisited the project this summer, I considered working with the code that I had. However, After spending some time reviewing it I decided it was best to get a fresh start. To that end, I rewrote the whole thing again, and even rolled the version number back to 0.1. That brings us to today. I've used 0.1 for a couple of weeks, even as development continued, and I think I can safely say that it doesn't have any massive issues. There are still bugs, and there's much more to be done, but it's a decent start.

Here's what features are in this version:

• Subscribing to/unsubscribing from feeds, and getting updates.
• Viewing specific feeds, or just reading unread items
• automatic deletion of old items that have been read (This is the only thing that I haven't tested thoroughly. It should work fine, but I'll know in a week or two if it doesn't.)
• Partial RSS, Atom, and RDF support.
• Partial custom themes

The list is pretty short so far, but it's a solid start. The most essential parts are all there, and now it's more about improving quality than just getting the thing to work. At this point, updates will probably be a little infrequent. I've got plenty of other projects in mind, after all. Of course, I'll probably never drop support, since I rely on this app myself. You can rest assured that I'll be keeping this thing in working order for a long time to come.

Fixing things up, part 1

UPDATE: The new games page is up! Go check it out!

Since creating this blog, I've done very little to the content apart from occasionally changing the canned theme. As a result, things have gotten a bit messy around here. Today, since Singularity's new release is done, I've decided to blow out the cobwebs, so to speak, and make the site a little bit nicer.

The first change is coming to the games page. Currently, the game content is poorly formatted, overflowing in some areas, and generally looks like crap. I've redone a portion of the page, and I think I've made some big improvements to the way everything looks. I've added a header to each project, adding a header and some symbolic icons showing the target platforms. I've also messed with the alignment to make sure that noting spills over: The images stay on the left, and the text stays on the right. Overall, even though the changes aren't huge I'm quite happy with the result. Here's a side-by-side comparison of the old and new layouts:

This new change should hit the main site within a day or two.

While I was at it, I also removed a few widgets that I didn't find very useful, and added a custom favicon based on the DFEngine logo. It doesn't seem to have updated yet on my end, but it'll probably be there soon.

I plan to make more changes in the future, but I think I'll leave things at this for now. Hopefully the site will continue to improve as I work on it! If you have any feedback about these changes, or want to make a suggestion, leave your thoughts in the comments below or email me at hugues.ross@gmail.com.

DFEngine Update 7

Changelog:

• Removed Tweens
• Upgraded the collision handling. Scripts can now be called when an object comes into contact with another, maintains contact, or loses contact. This should make some things faster and easier than they were before.
• Rewrote the code for creating PhysicsComponents. It's far more intuitive to create them in scripts now. Also, you now select the shape on creation. Currently the only shapes are Box, Sphere, and Capsule. However, I'll be adding support for custom models shortly.
• Started working on raycast functions. Eventually, this will let you check if the mouse is over a particular object, which will be great for FPS games.
• Moved the model drawing code to its own place(again). The custom drawing functions are back, but now they can draw anything.
• PhysicsComponents now share their angular factor with scripts. In layman's terms, it means that you can now control how objects rotate on each axis.
• Transoformation data is now stored inside the Entity class, not the PhysicsComponent. This means that you can put a GraphicsComponent onto an entity without forcing it to have physics as well. You can also now access rotations as either quaternions or Euler angles, depending on your preferences.

I always love a hefty changelog. The game jam did a lot of good, and it inspired me to work on DFEngine quite a bit. Unfortunately, I had quite a bit of homework, and didn't manage to finish the game I was making, but at least I was still very productive! There are only two downsides to this slew of updates: First, Tweens were removed. It needed to happen soon, since they were always causing tons of issues, but I don't yet have a suitable replacement. That's probably the next thing that I need to do, before anything else. The other downside is that the new PhysicsComponent creation code doesn't let you do as much as the old one. To be fair, I mostly removed the features that won't often get used, and it makes things much simpler. However, I still need to make sure that these features can still be used somewhere. I haven't checked yet, since the change was so recent, but it shouldn't be hard to replace anything that I've removed. Once I have both of those issues cleared up, I'll probably start working on a basic editor. It's one of the things that I've been missing for a while when using this engine, and I think it'll help me get interested in making games again.

Singularity Update 5

Changelog:

• Upgraded to use a newer version of WebKit
• Links now open in your default web browser
• Fixed even more bugs regarding parsing and such
• Items are now marked as read when you see them, not when they are loaded into a view

This is starting to get a bit silly, so I'm releasing Singularity before the end of this week. Already, this version of Singularity greatly exceeds my expectations for a 0.1 release, but general nervousness and an inability to call the version done have held it back. I'm going to figure out licensing, stick it up on Github, and post the link up here. Hopefully, it'll be done in a day or two. At worst, I'll finish before next Monday.

Autumn Game Jam, 24 hours in

Like the last jam, I'm going for something simple. DFEngine works, but it's not at a point where I feel like I can do a ton with it. I think the biggest reason for this is that it take s a while to get things done still. Things are slowly getting better on that front, but it definitely places a big restriction on me when I'm jamming.

Here's my game so far, which I've affectionately named 'ANGRY SUN AAAAAARGHHHH!!' The sun has gotten tired of setting, and now it's taking vengeance on humankind. So far, there's no way to win or lose, just fire big molten rocks at random civilians and rack up points. I might keep it that way.

Autumn Game Jam - Surprise!

Out of a mixture of business and laziness, I've neglected to mention that this weekend is a game jam at all! As always, I'm participating. This means that I plan to delay my update posts until this Sunday, after the jam ends. This will not only give me more time to write them, but it'll also give me a chance to discuss any updates to DFEngine that I make during the jam.

For now, I'm tired so I'll just post the theme: Twilight

Singularity Update 4

Changelog:

• Added support for RDF feeds
• Tested 252 different feeds on Singularity, currently 251 of them are correctly handled.
• Fixed a ton of issues when trying to get/parse feeds in various situations.
• Added icons to the GUI that display the load/update status of each feed.

I really want to release Singularity as it is. I really do. At this point, the old version doesn't even compare to what I have now, and I'm starting to get antsy. However, there still remains one obstacle before I can put out a release. Currently, clicking on links will open the contents in the same view that's being used to display feeds. Obviously, that's a bit of an issue. The old Singularity doesn't have this issue, but it has a bad habit of opening embedded content in a browser window. It's a small annoyance, but with larger feeds it can get quite out of hand. I want to find a better solution before I release this version, since being able to actually open the links that come in is (obviously) a very important part of the software. Once I figure that out, I'll be set to release this version. This time, it's good enough to provide publicly as well. I probably won't post another update on this until the release, but I also expect the release to come next week so it shouldn't make any difference. When that post DOES come, I'll give a general round up of what's there and talk about the future of the project a bit.

Singularity Update 3

Changelog:

• Atom parsing now works about as well as RSS
• Missing data files are now created, and missing configuration files now have their settings replaced with default values.
• Started working on an auto-delete feature, to remove old items

Sorry for the short (and late) post. I'm rather sick, so getting work done is difficult right now. Hopefully I can get back into the swing of things in a few days. That said, Singularity is almost ready for a 0.1 release, similar to what I did with AMAZE. I want to finish the auto-delete feature first, however. Right now, it isn't working too well.

Singularity Update 2

Changelog:

• Created the initial UI
• Feeds now update on startup. Note that there are two differences from the previous version: First, the updates don't freeze the UI anymore. The second major difference is that the feeds should no longer have to update in order, but instead update all at once. This should speed up the update process as well.
• Feed items can keep track of when they were downloaded, so that later I can have them be deleted once they've been around for a while.
• Added buttons to the UI for adding and deleting feeds. This was one of the biggest missing features from the old version, so I'm glad that it all works.
• Deleted feeds aren't fully expunged until the application exits, so that I can easily add an undo function later.
• Started initial work on Atom parsing

These past couple of weeks have been great for Singularity. For some reason or other, I feel really excited about the project and I've been super productive on it. At this rate, I can probably put out a public build by the end of next week. The main thing that I need to do at this point is testing. If I migrate all of my current subscriptions over to the database for the new version of Singularity, it'll probably be a pretty good measure of how well the application works. There are some crashes here and there, but most of the common bugs are gone, and I have the others sorted out somewhat. Now that college has started again, my productivity will probably take a hit, but I'm quite confident that I can finish this soon thanks to my current momentum.

Expect a minor release soon!

Finally, here's a screenshot of the work in progress UI:

Lots of placeholders still, but it's already a bit better than
how the old version looked.