This is Bananattack.

Tag: C++


Posted by Overkill on May 15, 2010 at 7:30 pm under Uncategorized

So in my previous, almost stream of consciousness post, I had briefly mentioned about updating Verge. One of those features in particular is the replacement of DirectDraw with GDI in terms of rendering. DirectDraw was old, deprecated, and broke Aero on newer machines. GDI, on the other hand, is still supported, and doesn’t need to lock the screen surface.

Along with the move to GDI, hardware fullscreen was removed. This at first sounds like a major loss, but this is for the best, I think. After all, Verge games are entirely software-drawn anyways, and many video cards do not support the lower resolutions that most Verge games are made in. Verge now instead uses a fake fullscreen mode, which means that non-native resolutions can be used without problems. As a result, that window switching is also much faster if you’re doing multiple things, and switching back and forth between fullscreen mode and windowed mode with ALT+ENTER is almost instant.

This however, wasn’t the only thing that got changed. There were a couple bugs and undesirable behaviours that somehow crept their way into the engine. Until I fixed them, that is.

When I added type-aliases to VC a bit of a while back, I somehow wrecked arrays in structures, but that is now fixed. I noticed that it was only expecting ONE dimension of the array when compiling (if you actually put one dimension only and it was a multi-dimensional array, the interpreter would choke). Now that’s taken care of.

I also fixed a bug I introduced with FileEOF. I thought I was being smart by making Verge’s FileEOF for physical files (non-packed files) into a simple call to feof(). But then when I later found this sort of thing in one of my older games:

    s = FileReadLn(f);
    // ...

…I noticed it was freezing! It turns out that FileEOF() had slightly different semantics than feof(), because the latter only is true when you’ve read PAST the end of the file. Meanwhile, FileReadLn apparently just returns nothing and does not trigger EOF if there’s nothing left to read. So I reverted that change. Instead, I’ve made the internal filesize() call on physical files be cached (since FileEOF should only be used in read mode anyways). If at some point, we get an “update” mode for files, I may need to turn off caching in that instance, but at any rate, this will cut down on the number of seeks to calculate file size happening EVERY time you call FileEOF().

Kildorf added escape characters to string literals. But most VC games were written without this, and expected a \ to put a single raw backslash. So I added an “oldstring” configuration setting. When oldstring is found on a line in the verge.cfg, it will go back to the old way of handling string literals. Sadly, there’s no way to mix files which use backslashes raw in string, and files that use escape characters in string without adjusting one or the other, but I think this is acceptable, since it’s a pretty trivial thing to do. I just added in the backwards compatibility so that old projects ran with a newer Verge would still work without digging through and fixing every string in the code.

I also fixed a bug with ColorFilter, where translucency settings were not being obeyed. Apparently that has been there for a while, and is now fixed. The code WAS blending the pixels, but it turns out directly after the blend, it just did a direct pixel copy of the filtered color (which wasn’t necessary, and prevented the blend from being displayed).

Oh, and I also added a few new window scaling settings. There are a couple modes to how the Verge screen can be scaled/fit into its window and fullscreen view. This called for new configuration settings. For windowed mode, there is “scalewin”. For fullscreen, there is “scalefull”. Both of these have a few settings that can be taken on:

  • scalewin 0 / scalefull 0 – Letter-box. The old Verge method of scaling the screen, which often resulted in distorted pixels. If the window was not perfect aspect, it would scale according to ratio (but the ratio could be non-integer, resulting in the chunky distortion), and it would fill in with letterboxes along the shorter axis. No longer the default, or only way of scaling. But left in, in case anybody prefers this.
  • scalewin 1 / scalefull 1 – Aspect-aware mode. Get the largest integer factor of screen size that fits in the render area. Makes sure that no distortion of the screen occurs, only uniform integer scaling. (Default windowed mode setting).
  • scalewin 2 / scalefull 2 – Scale to size of render area. (Default fullscreen mode setting).

    In most cases, a little bit of stretching can be acceptable. For instance, my monitor is 1440×900 (16:10), and game resolution is (4:3), but since the game is low-resolution pixel graphics, the bit of non-uniformity doesn’t stand out too badly (I think).

If you already looked at the SVN before this post, then you should know that I updated one other thing. I fixed ALT+ENTER from fullscreen to maximized (fullscreen is also maximized, so the window size doesn’t change unless you restore first). I also greatly improved the GDI renderer performance by removing accidental triple-buffering from the engine, which was slowing my netbook down to a crawl when I was doing a simple 640×480-sized window (eek!). So that’s been repaired.

You can peruse the SVN (anonymous/anonymous), or to be a little more friendly, you can download the exe here. If there aren’t any major bugs, maybe in a couple weeks we can have a full release.

So what are you waiting for?

Get it here!

Tags: , , , , , , ,


A lengthy departure.

Posted by Overkill on May 14, 2010 at 3:15 pm under Uncategorized

Well, I had hoped to return here a lot sooner than I actually did. But plenty of sleep-depriving schoolwork and various family crises all played a part in hindering my desire to write again. As a result I felt very burnt out, tired, and uninspired.

But it wasn’t all awful, the past school year especially. I had fun being able to write a Pascal-like compiler for my Compilers class. I learned a bit more about 3D graphics, like heightmaps and fake shadows in my Graphics class. I managed to better leverage multi-threading and played with a bit of cluster programming in my Parallel Architectures class. I acquired some knowledge about neural networks, support vector machines, evolutionary algorithms, and logic inference engines in AI classes. All of these classes consumed a fair deal of time, but it was pretty interesting. 

In March, I finally replaced my dying computer with a much more powerful quad-core Intel i5 750 desktop. It felt really awesome to actually have a fast and functional computer. I no longer had to live in fear of my flaky power supply, and screwy video card. But I only got to use it when I was off campus (which wasn’t often, with several all-nighters and lengthy days to finish schoolwork), so it was a gradual battle to reinstall everything I used to have.

Once exams were almost done, things were starting to feel normal. I had free time, actually started to relax and play games again, and I actually got to sit down and use my computer. Eventually I got back to looking at my own projects, but it was slow going. There were plenty of interferences too, since I bought Wario Ware DIY and so I was playing around with that. I also had to pack all my stuff up. 

About two weeks ago, I moved home, and I’ve been job-hunting locally and hanging out with my friends, and very slowly unpacking. Yesterday, I finally got the motivation to look after my site again, and I revamped a few things, layout-wise. The colors were adjusted a bit, and borders made a bit thinner and tidier looking.

So how’s the job-hunt going? Badly. Everytime I try to look at employment stuff, it feels really unpleasant and makes me feel nervous, and I end up getting distracted. It’s silly, I know. Especially since I know I should be qualified for plenty of software engineering jobs out there. Really I don’t know why I’m doing this. I mean, it’s the only thing I really have to do now, at this point. School’s done, and that portion of my life is over with. Onto the several remaining boring decades to live through. Blah.

I’ve also not really gotten that far on any of my projects. Very similar to how I’ve been avoiding a job, I’ve been side-stepping really making any sort of progress on any of my work. It’s crappy. That said, I’m still working on things, but my lack of progress is very painful. 

It wasn’t widely announced, but I’ve been working for a bit on a project called Molasses Monsoon, which is a sidescroller envisioning of Molasses Meow. It features less seizure rooms, and more exploration and item collection. Armed with the Love Buster, you are saving the Neoniverse from the peril of the Evil Candy Fiends, and go on a quest to better the world around you. I’ve most recently been working on adding dialog to the game to actually give the exploration some purpose. But it’s going really slow, because this game has always meant to be a cheesy side-project. Here are some screenshots:

Unfortunately, my real projects keep changing and dying and hitting roadblocks. 

In order to let me develop Verge games under Windows 7 and Vista without Aero being disabled, I made a GDI renderer for Verge, which is now in the Verge 3 SVN (U/P: anonymous/anonymous). The secondary reason was because DirectDraw is a deprecated API, but I wouldn’t have cared if it didn’t affect desktop composition effects. I need people to test its performance on older machines (Windows XP boxes, older video cards, single core machines, those sort of specs would be nice) to make sure it’s as performant as DirectDraw. If you’re more knowledgeable of Windows API things than I am, please review my code (keeping in mind that it’s greatly derived from the DirectDraw), I’d like to make sure there aren’t any bugs or bottlenecks I’ve overlooked, since this will have a drastic effect on game performance in Verge. 

I’ve also worked a little bit on my engine Plum. It’s ready enough to make certain map-less games, but other kinds require more engine work. Recently I’ve been planning a bunch of shapes and collision detection things to add to the engine. The engine feels fairly clean for the most part and can be checked out on github

Occasionally, I’ve also been working with a friend, planning a large-scale RPG project we’ve code-named “Eternity”, which is rather fitting. It is going to be a realtime battle system with programmable AI, and combinable spells, among other craziness

Apologies for the rather disorganized post. It’s just been a really long time, so I sort of brain-dumped as much as I could into this.

Well, okay, so this is my return to the Gruedorf competition after about 9 months of failure. What have you been doing? You have no excuse, just like me. Get a job! Make games!

Tags: , , , , , , , ,

No comments (make one!)

History repeats, with delicious treats

Posted by Overkill on July 10, 2009 at 2:41 pm under Uncategorized

Hello! Been a while since the last time we talked.

I am an inconsistent person, and I forget things. I quickly fell out of Gruedorf again. And I don’t really have much to show for it yet.

I haven’t been able to find a job since early May, but I’ve still been wasting a lot of time struggling to find one. Sort of depressing, y’know?
Early after my last web job (which ended late May), I started working on a web paint tool, which I dubbed “Laser Toast”. It was pretty fun to make something interactive like that, especially since it was mostly in Javascript (and just a little PHP + JSON). It let you draw a super zoomed 64×64 image. It worked pretty well in my tests on Opera and Firefox. But it would do terrible things in IE7, where apparently it was running out of memory or took a really long time manipulating DOM objects.

I gave up on that eventually after I got bored, but it was a fair deal of fun while it lasted.
In other news, I have been working on a 2D game engine, which I’ve called Plum. (This is actually a revision of Brockoly, but with less ridiculous-to-type/say name. It also has plenty of features that weren’t in Brockoly.) If you want an silly acronym, something funky like Platonically Loving Unicorn Machine, or Poetically Lavish Universe Maker will do the trick.

For starters I’ve got Lua scripting, FMOD Ex for audio, Corona for loading images, zlib for compression, zziplib for archives, and SDL for the input, timing, and video. Nothing too fancy.

I added a packfile loading mechanism. Packfiles ARE pretty useless, but I figure it’s nice to bundle Lua libraries (like splash screens or an ‘rpg’ library) and stuff this way. To save myself time, I just use a ZIP format, renamed to .pit (Plums have pits… yep). I use zziplib to do the heavy lifting. And I made it so pretty much all my code properly uses ZZIP_FILE* instead FILE* for reading. I got to learn about the different ‘read’ callback APIs for Corona and FMOD Ex in the process. Heh.

I’ve slowly been making the implementations for my sprite, tileset, map and world layouts. They are all written in Lua files! I decided this allows a lot more flexibility and less bugs than with that crappy language that I “invented” called Mungo, especially since the Lua API under C is pretty simple to use, and can easily do error checking. I do a bunch of checks to make sure the data is valid, and I also ensure that no control statements can appear by using “return <Value Read From File>” in a dostring.

Sprites are so far pretty much just images with animation strands defined. Eventually I want to add metadata so that information about a particular sprite can be stored in the format itself. But for the most part, it does 99% of the job I want the engine to do. The rest I envision will be user code written in Lua.

Tilesets are a little more advanced, but in different areas. For one, you can specify an externalFile attribute in your tiles table, which the engine will autoimport upon changes (provided that file exists). It saves imported data in the tileset format itself, and it keeps an SHA1 checksum to lower redundant reloading.

The data is a zlib compressed chunk of raw data, which is then base64 encoded so it can be stored in Lua. This was shamelessly ripped from ika.

I am still planning to add the other, more sophisticated features to the Tileset format. It needs a structure for ‘arrangements’ which will denote preplotted tiles and obstructions. These would be useful for plotting an otherwise tedious collection of tiles, for something like a tree. The engine would not be capable of distinguishing what plotted tiles belong to which group without annoying amounts of extra info or sluggish pattern searching. So I decided the engine would know arrangement composition for plotting, but would become regular tiles once plotted. I figure this is a good enough.

There will also be ‘categories’ for tiles, which help classify tiles and give them useful meta information. A tile can belong to many categories. This would be useful for assigning terrain costs to tiles in a tactical game, or as a way to accomodate autotile functionality. Entire arrangements could be added to a category, too, but the engine would add the individual tile components of the arrangement to the category rather than adding the actual arrangement. This is for sanity reasons, again.

And tilesets would have animations that can be assigned to tiles, that would be fully scriptable with strings like ‘F3W10F4W10F5W10R’. Any tile index would only be allowed to be used once across all animations, to allow there to be simplistic grouping, and have it so each tile has a transition into exactly one other tile.

I need to eventually add a cleanup mechanism to my file parser, so that after a data entry is parsed and stored, it can be safely deleted. The reason being, I don’t really want to keep large data strings in memory, if I’m ALSO.
So hold on, isn’t this whole making-a-game-engine thing pointless? You bet!

Do I consider it to be reinventing the wheel anymore? Not really. It’s more like mashing a bunch of wheels together in a horrible attempt to make a Frankenwheel. I’m generously reusing existing GPL/BSD/Public domain code, to save time and effort, and only rewriting the aspects that need to be changed to make this thing flexible. It’s targetted at being portable and fairly lightweight.

It’s mostly there though. In fact, it can do a lot of what Verge and ika can, without maps/tiles/sprites. This steps from the fact, there was a fair deal of inspiration off those. It also my own intuition to make reasonable decisions.

Note that this engine isn’t intent on replacing Verge or ika. It’s an exercise for me, first and foremost. If I can draw the interest of existing users when it’s release-ready, I guess that’s good. Ultimately, though, this is a tool for my use. To improve my software design decisions, to see if I can remedy problems I saw in other engines or if I will fall into a similar trap.

Some of my code was unnecessarily reinvented back in the Brockoly days, but I am really trying to harvest from existing frameworks, to modify and improve. A lot of these ideas are incompatible with Verge, but on the other hand, I could adapt Verge source to fit in my engine. There’s nitty gritty implementation things to blame there. But mostly, this is for fun.

Once I get a reasonable amount of engine done, making games will become much simpler.

If you want to play around with my engine, it’s available at Github under a BSD license. It guarantees only limited stability at this point, and some code needs serious refactoring but feel free to look here.

Git is awesome, by the way. It had a bit of a learning curve at first, but I definitely like it a lot more than SVN now.

My repo includes a silly demo which shows a tileset loader test (might be removed soon), and (if you hit Enter) a simplistic rotating heart screen that does funky things when you click.

My repository also has a demo game called Maximum Yak Maniac, which I talked about last time I posted. It was pretty easy to remake, since it doesn’t require maps, sprites, or tiles. It just uses raw images and audio. Yay.
So there you are. I’m unemployed, and writing a game engine in spare time. I have also been juggling a couple game projects, but I’m not really prepared to talk about them yet. Next time, maybe.

Also I didn’t really check the formatting too much while I writing this, it might be too wordy, in that case tl;dr sorry.

Tags: , , , , , ,

1 comment