This is Bananattack.

Tag: brockoly

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


Composting misspelled off-colour vegetables.

Posted by Overkill on November 16, 2008 at 9:40 pm under Uncategorized

People were right. I was pointlessly reinventing the wheel in an attempt to make something that nobody would’ve used anyway.

I discontinued Brockoly.

I was hitting major roadblocks, and redoing code that I didn’t really want to rewrite from the bottom up. I would never finish by myself in this lifetime.

However, I still assert that I learned a fair deal while suffering of Not-Invented-Here Syndrome. I learned how to write C++ code better, and how to do slightly-complicated software image blitting techniques. I also took a heavy inspection of ways to structure internal file formats like sprites, tilesets, and maps (which I am actually interested in — and what threw me into making my own engine to begin with).

But this madness stops.

Now.
 
 
 
From now on, this engine know-how should be invested smartly. I should be fixing things that are already out there. Things that just need improvement. Fix the wheel, don’t make a new one.

Verge is a great candidate for this. It’s already enough-to-make-games-with, just needs a push to make the whole ordeal of making a fully-fledged game a less tedious experience.

I think the internal engine stuff should be improved. And now let me go on about how.

Entities must have custom animation strands.

The .chr file format itself should allow animations to be scripted. This way you don’t need to write a custom animation system on top of Verge’s. This means that you can tell your hero to strike a victory pose without having to hardcode “F10W10F11W10B” and such in your engine — and it allows sprite editor to handle all sprite animation instead of HAVING to write out code for it.

Entities and Layers should be referrable by name.

So you don’t need to memorize index numbers. So now you can say in your script something like “Move Bob” instead of “Move Entity 34″, or “Change the rooftop transparency” instead of “Change the transparency of Layer 23″. It keeps you a lot more sane, and prevents scripting mistakes from creeping in.

Obstructions, Entities and Zones should be on each Layer.

Allow every layer on the map to have an obstruction channel, zone channel and entity channel. Instead of ONE obstruction layer, ONE zones layer, and so on. This, in turn, allows you to have bridges that you walk both above and below, without hacky tricks.

Maps need Waypoints.

Waypoints would be for a single spot on a map that have a name (constant lookup by name) and allow you to work it into your scripts quite easily. It would allow tile regions on a Layer to be referred to by name.

This is different from a zone, because Zones are for many spots on the map that all share the same events (constant lookup by (x, y) position).

Additionally, this single name to single position mapping means it’s ideal for pathfinding!
 
 
 
So say you have a water fountain, and you want your player to walk towards it. Currently, you need specify an exact path to walk to the fountain through a series of EntityMove(player, "X10Y11U10L10") like commands probably with a bunch of if statements and stuff.

Contrast this with just saying something like EntityMoveTo(player, "fountain"), which could pathfind automatically. It could be pretty quick about its search, and maybe have a restraint on distance to pathfind from, after which you could chain a bunch of Waypoints together and move from point to point.
 
 
 
Perhaps more interesting is, say, when you have a bunch of treasure chests on a map.

You can use zones for their activation on map, and waypoints for actually telling where the chest IS on the map, so you don’t hardcode positions.

So when you return to the map later, and need to set tiles for all the chests again, you can change the tiles at the waypoints! As opposed to needing to write coordinates in your map startup event, which gets messy quickly.

LuaVerge needs to be faster.

LuaVerge, the new twist on Verge, which has Lua instead of VergeC for scripting. Lua’s a language that I figure could replace VC at some point, because it’s much more expressive, and less restricted. LuaVerge has a lot of potential.

Sadly the potential that has gone sour by the fact that the LuaVerge is several magnitudes slower than the VC version right now. Surprisingly, the problem isn’t Lua, or its helper LuaBind. It’s our code that glues Lua into Verge. It was supposed to be fixed a long time ago, but I never figured out how to represent array-of-structure like things through LuaBind directly.

LuaVerge needs to play nice with packfiles.

Right now Lua scripts need to be outside of .vpk files, because otherwise they can’t be included by Lua. In short, this means people who release demos have to include source, which could be fun-ruining. Also I respect peoples’ desire to have their code stay private, just so nobody outright steals stuff.

This is probably a fairly easy fix, just make the Lua code use verge’s I/O stuff instead of the <stdio.h> library that comes with C. Kind of hairy though, since you need modify Lua itself.

I need write tutorials for vx.

So, vx (Verge eXtension) is my little code library that makes LuaVerge even nicer to use. The problem is, I need to write a tutorial on how to use it. Unexplained code means very few people are going to jump on it.

This brings me to my next point…

I need to entice people to switch over to LuaVerge.

Right now almost nobody uses LuaVerge, and I know that’s mostly because nobody has been encouraged or taught how to use it. So we need to get people interested in the newer Verge and to demonstrate how it’s better. Ey, ain’t that right, Kildorf, ustor?
 
 
 
Anyway, that’s a lot to think about. Hopefully I can redeem myself of my grand suckitude. School is murdering me, so I want my dev time to be useful and rewarding. That is all.

Tags: , , , , ,

4 comments


Brockoly improvements.

Posted by Overkill on October 27, 2008 at 11:59 pm under Uncategorized

I don’t have much time to talk today, since I have less than 10 minutes until I fail Gruedorf. So I’ll make this quick.

This week, with the help of Kael and andy, I was able to axe some godawful ugly macros from Brockoly’s software blitter code. I turned Color (which was a typedef for unsigned int before) into an inlined first-class object with methods instead of a macro function that returned a Color through bitshifts. I made blending code into an inline interface that implements SoftwareBlender, and all software drawing code on Images now uses templates. This means things should run faster or at the very least be a hell of a lot tidier.

After hearing a voice of reason from Grue, I decided that making my own data language was silly considering that there are existing ones out there that are already much better supported.

Well, kind of. I decided I’d use JSON in my map/sprite/world/tileset formats, but the existing parsers in both C and C++ are really primitive and don’t really cater to someone who wants to load and then poke at the elements. They expect you to parse as you go. And then there were a bunch that looked promising but just plain didn’t compile, or ended up having stupid library dependencies like boost.

So I’m considering writing a JSON parser for next week. Gotta go!

Tags: , ,

No comments (make one!)


Magical Mayonnaise

Posted by Overkill on September 10, 2008 at 1:49 am under Uncategorized

This week, while not extravagent, was a fairly good one. In Brockoly, I added in region-based grabbing for all the blit routines, in both software and hardware. So now this can be used to make powerful special drawing for sprites and tiles, and can still be combined with rotations and scaling and mutliple blend modes and texture tinting all that magic. So think of Verge’s GrabRegion on steroids.

I also started on the actual sprite system for Brockoly, but I’m trying not to rush it and screw something up. It shouldn’t be too tricky though, since I basically haven’t dramatically changed the sprite format layout since what Resonance does. So after that feature is in, something like a funky shmup game at the very least could be made.

I’m pretty excited. You should be too.

Tags: ,

No comments (make one!)


Strutting back into the spotlight.

Posted by Overkill on September 2, 2008 at 8:11 pm under Uncategorized

I’m pretty much over the first hurdle of lower-level stuff to add to Brockoly’s C++ codebase. Graphics are mostly there, in both hardware and software, just need the region-grabbing blitters before I get to sprites. Keyboard input controls are done. Timing (and handy support for builtin frame throttling) is in. Audio’s in. The executable so far is only about 300kb, so it’s pretty lightweight, but I expect that to rise sooner or later.

Started making work on the file formats. The format loader logic is in there (has a one-line header that specifies information on the format type, format version and format parser which is plugged in to generically load things).

One of the parsers already taken care of is an updated Mungo format, which now can handle auto-numbered keys for entries and lists easily, and a Verge format parser is being planned to allow for conversion. All parsers will convert the file format they loaded into a Brockoly::FormatTable which contains all the entries, and then this generic information table will then be poked at and inspected by the sprite loaders and map loaders (which need to be written), with clauses for how to handle version compatibility between the different table layouts builtin.

An exercise down the line is adding pluginable text encoders (like base64 or binary-to-hex) and binary compressors (like zlib or run length encoding) for when I actually store binary data in the format. I plan on for stuff like tilesets and spritesheets, to allow the formats to be stored outside the file, in case somebody ever wants to make the format file in just a text editor (which I know I will since I don’t always like using specialized editors for everything).

I’m about ready to embark on the more interesting design stuff. The actual implementation of my sprites system, and map and tileset system, and then a seamless world system on top of all that, are to be designed. They should be a fair amount of fun to do. I’m willing to hear suggestions for features that you notice a lot of 2D game engines miss out on! Oh, and of course, I’ll share the file format details with other engines that want to use the same stuff in their own engines.

Some of the planned features for sprites:

  • Frame padding details (for when you’re loading images from outside and want to decide how you’re laying the sprites out to some extent)
  • Custom frame width/height info (everyone has this by now — possibly with ability to guess frame size on sprites with a padding of at least 1.)
  • Custom animations
  • Custom hitboxes/hotspots for certain frames (so when crouching or diving or something, it’ll use a different hitbox than if you stand)
  • Special meta information (easily added when everything’s stored in tabular formats anyway)
  • Entities are higher level objects that contain sprites in them — entity construction information isn’t stored in the sprite. When Ruby is added to the build, the construction information will be stored at the map level, where it can actually tell the engine how to construct an entity. This way you could have “Enemy” and “Player” classes or a just or plain static sprite constructed, with a selection depending on how complex you really need the engine’s handling of it to be — and you could provide a chunk of metadata which it could then use to further improve the customizability in sprites through sharing information between maps and the code. (Whew!)

Planned for tilesets:

  • As with sprites, padding and frame size
  • Tile arrangements (“brushes”), which are specific placements of tiles (may be able to span multiple layers, too)
  • Custom animation scripting for tiles, which creates a special animated tile arrangement, which allows tiles to be reused across multiple animations (if you really need to — might be useful), and allows tiles to be specified in an ordering that doesn’t require the indexes in the tileset to be right beside each other (like it is in Verge — which is frustrating if you make bigger animated tiles)
  • Tile grouping (also groups arrangements), to allow certain categories of tiles to be found easier both by script generation and by editors
  • Special meta information (easily added when everything’s stored in tabular formats anyway)
  • Isometric or hexagonal tiles aren’t exactly on my TODO, but if someone else wanted to add them, I’d be happy to let them
  • Pixels should be readable from tilesets.
  • There’s no intention to make a special “obstruction” layer or obstruction group, and these are left up to specific implementations (like sidescrollers could use pixel based obstructions with color coding for the different kinds of floors , but another might want tile based obstructions). Rather than forcing one on the users, I want to leave this open to choice. There’s a few options that I plan on enabling, then they just need a particular implementation by a user elsewhere.

Planned for maps:

  • Tileset to use (possibly multiple tilesets at a later point — they’d all need to be the same tile size though)
  • Background music
  • Sprites on map, with a bunch of custom construction info (mentioned in sprite part actually), and metadata to share script-side. Sprites can be pixel placed instead of tile placed (with a toggle for snap to grid). Sprites can overlap on a map, too.
  • Tagging of map regions, so you can use this for pathfinding and scriptside spawning (for instance a key that spawns after you step on a button). Can be placed tilewise or pixelwise. You can look it up by a tag name to figure out its position, or look at a position to figure out what tag is associated with the location. You can overlap tags, if you so wish. Might have a variety of shapes, like lines, and rectangles (filled/non-filled), which can then be used for a bunch of different things, including custom obstruction systems?
  • Zones, for tagging map tile regions where a common functionality is shared (spikes that hurt you or locked doors that all say the same message or whatnot). Unlike the tagging, you only plot tilewise, and you can’t find the reverse lookup a zone’s position by its name, but this is because you can place the zones in any arbitrary tile arrangement. Zones may not overlap either. Fairly similar to tags, but unless I can find someway to merge them elegantly, they will be separate pieces of information. Zones have the benefit of being compressed as one chunk when placed because of the “no overlap” rule.
  • Many layers, which contain a tile grid, and a zone grid. Entities may be a member of any layer.
  • Region tags that have special meaning only at the “world” level, but allow a request to start seamlessly loading a connected map.
  • Other special meta information (easily added when everything’s stored in tabular formats anyway)

Planned for worlds:

  • A list of maps contained by this world.
  • Seamless loading of individual maps and their associated tilesets, and sprites.
  • A way denote direct, adjacent connection between maps (by a list of connections that tell to connect the edge of one map to the edge of the next)
  • The automatic generation of minimaps? (not sure)
  • A way to denote indirect connection between maps is already explained in the map section
  • A way for sprites to automatically cross between maps when by direct connection. And when not directly connected, the sprite must explicitly request to be moved to another area.
  • This format is actually quite undeveloped at the moment, I’ll figure it out more when the lower formats are implemented first.

As said before, your suggestions in regard to the engine are much appreciated, and I hope to be able to share this effort with other engines that want to share my format ideas.

So anyway, look out, Overkill’s still alive! Once these formats are relatively done and Ruby’s in, I can return to work on Resonance and then dance between the two projects. This is still hopeful. Lots of work, sure, but I can see the workload progressively getting smaller. Things are shaping up.

Tags: ,

1 comment


Eyecandy is eating me.

Posted by Overkill on July 21, 2008 at 3:43 am under Uncategorized

This week for Gruedorf, I spent more time on the graphics sections of brockoly.

I hand-optimized the crap out of the rotation blitter function, and so now it only iterates over the rectangle enclosing the rotation instead of iterating the entire image (bad), and I factored out a bunch of crazy calculation bottlenecks. I’m sure it could be further optimized, but not gonna bother since I plan on having hardware blits anyway.

I also made a nifty line drawing algorithm, which uses Cohen-Sutherland to clip the lines, and then Bresenham to draw them.

Oh and I added a fairly optimized scanline circle drawing algorithm based on some fancy-looking paper about fast circle drawing I found with google. I guess you could call that reinventing the spokeless (or infinite spoke) wheel.

I also made a bunch of slight improvements on the blending macros to make them slightly faster, and also added a global alpha that’s applied onto all blends (except Opaque — which is direct pixel copy).

With that, I’m left with gradient effects, palette maps, and drawing subregions of images for software.

I started coming up with some design planning stuff for how interaction with hardware textures will work. Here’s what I’m thinking: each of these textures each have a backend image — an image that can be retreived, drawn onto, and then applied to the texture once updates are done.

Sadly, though, I realized since a texture’s image can be changed, not all textures can be cached in memory. But the subsystems like sprites probably can be cached.

But okay there’s another interesting problem I read about — any time an SDL window resizes apparently the whole OpenGL context is discarded, so any texture bindings that were in memory are wiped out. I might have to disallow resizing of the game window at runtime just to prevent this, because this is preeeeetty bad.

I’ll be happy when all the graphical side of things is working nice, because it’s not until the graphical stuff’s done that I can really work on the cooler things, like the fancy world/area/tileset/sprite formats.

Oh right, and, The Dark Knight was epic and made of awesome. And so was playing Marvel Heroes vs Street Fighter in the arcade beforehand.

Uhm, anyway, that’s it for this week!

Tags: ,

3 comments


Leafy green goodness.

Posted by Overkill on July 14, 2008 at 1:19 am under Uncategorized

So about two and half months have passed since my last blog entry, which wasn’t even about Resonance. The last Resonance posting? About 4 months ago.

The funny thing is, despite the rarity of posting, lots of design ideas were tossed around behind the scenes. Sadly, I didn’t realize that I didn’t even have a design document for Resonance the entire time I was working on it. That realization helped immensely. And so I embarked on rewriting my Lua code for my game engine, and started to make some headway.

But along the way, the same redesign also caused me lots of woes, because I realized there was a couple things that I wanted and I was frustrated with how I’d need to write them in Verge.

I tried making my own custom map format in Lua, but the lack of bitwise ops sort of killed that progress. And I didn’t want to go through the hassle of patching up Verge to support my own map format. So eventually (this past weekend) I decided enough was enough. I started writing my own game engine from scratch in C++.

Part of me knows it’s foolish amounts of extra work. But part of me thinks it’ll pay off and I figure I needed to learn how to write my own C++ game engine at some point.

I named the game engine brockoly.

This misspelled vegetable name was zeromus approved.

Originally this name was supposed to be for the custom format I was making, but I decided the engine might as well have a name of some sort.

Anyway, so far, the following things have been done:

  • Loading of software images
  • Get/SetPixel
  • Clipping regions
  • Rect, SolidRect
  • Normal blit
  • Scale blit
  • Rotate blit (needs more optimization still, IMO)
  • Builtin blend modes on every operation, that are performed by macros (and it’s my hope that gcc’s -O3 is smart enough to further optimize it):
    • Overwrite (direct pixel copy)
    • Preserve (blends source with dest pixel without changing alpha — pretty much intersection of the images (the default behaviour because it’s featureful enough for normal cases))
    • Merge (blends source with dest and changes alpha to accomodate — pretty much a union of the two images (more “what you’d expect”, but slower than Preserve, and likely to be less common so this is why it’s not the default))
    • Add (adds RGB values together while obeying alpha — useful for lighting)
    • Subtract (subtracts RGB values while regarding alpha — useful for shadows)
  • SDL — although only to manage the window and flip buffers after I’m done drawing.

And here’s some things I need/want to do still:

  • Global alpha applied to all drawing operations (right now there’s no actual way “setlucent” or similar but alpha is supported when built into the image)
  • Rotate scale blit (holding off till I can get a more efficient rotate if that’s even possible)
  • Color filtering effects
  • A notion of “palettes” and a palette map for images that allows quick and easy color replacement that can happen all at once after the image’s palette alteration is complete.
  • Tiled blit
  • For every src->dest blit, another kind that blits only a subregion of the source
  • Hardware texture versions of all the blits (where textures can be made of software images and at any point the texture’s underlying image can be updated (it looks like it can be done by glTexSubImage2D at least — I’d just to see how many migraines are caused if this requires a different pixel format than the regular software blitting.))
  • Scripting with Ruby — bound to be less crippled than Lua. As nice as Lua is, it’s lacking too many features and has a bunch of quirks that still make me cringe a bit (like any non-nil value besides false is coerced to true in boolean expressions, indexing from 1, no bitwise, no classes (and although you can make your own, you can run into more complicated things like not being able to garbage collect everything, or certain limitations on LuaBind’s class that make me use tables which have no __gc metamethod)).
  • Audio through FMOD Ex or Audiere.
  • A nifty “huge world” format that will hopefully read areas of the world into memory seamlessly. Each area would have its own tileset, theme, set of entities, set of zone types, layers, and metadata. Any region of a layer could have metadata. Each layer gets its own tile plots (duh), obstruction, zones and and entity plots (handy for multi-layer maps)
  • A tileset format that allows scripted animations and tile arrangements (brushes) and tile categorization (for labelling metadata on certain tiles — could be useful for map events to be able to name tiles, especially for random map generation or “special” tiles)
  • A sprite system that allows for custom animations and multiple hotspots (useful for stuff like ducking/crawling or other crazy poses in games (especially sidescrollers) I figure).
  • Have error messages print in the game window instead of as a popup (this is really good for fullscreen and for looking more awesome). Probably will allow a customizable background. Would still probably need popups in extreme barf cases, but I’m trying to avoid platform-dependent annoying popups for a bit.
  • Might optimize alpha blending for software to lose slight accuracy (which nobody really cares about as long as we still fade/blend okay for about +80% accuracy) in turn for better speed.

So yeah, I have hopes that I’ll one day finish most of these, and then as a result be able to make Resonance super awesome and perform great.

I am crazy, I know. But if I can finish this, it’ll be a grand accomplishment that anyone can use, since I plan on releasing the entire thing under a BSD-like license or something. Eventually when I get more progress, I’ll see about getting an SVN for it — but right now that’s sort of pointless.

Anyway, that’s a short version how I’ve been and what I’ve been up to. I’m sorry for holding off on my planning, with excuses of being busy some times, and hopes of eventually wowing people later other times.

But Grue made me realize that nothing gets done as soon as you start thinking of small progress as not worth bragging about. This is what Gruedorf is about.

Now, beware, my many adversaries! I’m back, and I will kick you in the behind (if everything continues to go well and I don’t screw this up again).

Tags: ,

4 comments