This is Bananattack.

Tag: LuaVerge

We need Verge 3.14

Posted by Overkill on April 9, 2009 at 1:49 am under Uncategorized

Seriously need to sit down with Zeromus, and hammer out a release for Verge 3.14 already. These awesome Lua features are just sitting here being under utilized! :(

Both Textshmup and Resonance have been using the new LuaVerge, and new vx, and I need to share the love. In a more stable form.
When these things are released, I can make sure ustor updates his space game, and other people can convert.

Having this release also means we could possibly pave the way for a functional VergeC to LuaVerge converter. This in turn would mean games with giant code investment, like Sully Chronicles or any number of Verge 3 RPG systems could be seamlessly converted into similar Lua code.

Okay remind me not to post at 3 in the morning again when I am half-asleep and have an exam first thing when I wake up. Okay later.

Tags: , ,

No comments (make one!)

Anonymous Functions, and Textshmup: A retrospect

Posted by Overkill on April 8, 2009 at 8:53 pm under Uncategorized

Some of you may have recently played my 24h game textshmup. As expected, it wasn’t that well received. It was a bad concept to begin with, after all! :D

It was too hard to read quickly and type responses. Audio cues and colored text were added to make the game slightly easier to react to, but even then, it was just too tedious. It was just a randomly generated endurance test, with no goal, and no intermediate tasks.

That said, I had fun making it! I mentioned last time that I made it in LuaVerge. I never mentioned why it was so quick to write.

Well let’s go!

For one, I used the vx library I had written. It came with the spiffy nifty object-oriented class system that I made.

I had my entire game use a single well-divided render/update loop, which boiled down to this:

while true do

I declare two lists which contain all the callbacks done by the render and update events:

render_list = {}
update_list = {}

Here is Render(), in its entirety:

function Render()
    vx.screen:RectFill(0, 0, vx.screen.width, vx.screen.height, 0)
    for i, f in ipairs(render_list) do

The Render() function starts by clearing the screen, then it iterates over all entries in the render list, and calls them all. At the end, it shows the changes on the screen. This was ridiculously nice to hook in new rendering events.

Similarly, here was my Update() code, which used frame-throttling so each update callback could be written in per-tick logic:

function Update()
    local i = 0
    while i < do
        for _, f in ipairs(update_list) do
        i = i + 1
    vx.SetAppName(TITLE .. ' ' .. frame_limiter.frame_rate)

Both of these worked great for global functions and static methods.

There was one issue with the way they were designed though. Which wasn't immediately apparent, but here goes.

Say I made a class named BlueBox, which has an x, y, x2 and y2. I declare a method for it like this.

function BlueBox:Draw()
    vx.screen:RectFill(self.x, self.y, self.x2, self.y2, vx.RGB(0, 0, 255))

In Lua, the colon : in that function is syntax sugar for the following:

function BlueBox.Draw(self)
    vx.screen:RectFill(self.x, self.y, self.x2, self.y2, vx.RGB(0, 0, 255))

Which is syntax sugar for:

BlueBox.Draw = function(self)
    vx.screen:RectFill(self.x, self.y, self.x2, self.y2, vx.RGB(0, 0, 255))

See that 'self' parameter? Well, earlier when I'm calling the functions, I go like this:


That's a call with no arguments. If we try and add the method pointer for a particular blue box's render, it will call it without passing self, so 'self' is nil:

-- Won't pass the self parameter!
table.insert(render_list, self.Render)
-- Similarly, won't pass the self parameter!
table.insert(render_list, self:Render)

Thus object instances aren't passed around. Not good!

So how do you pass around the 'self' parameter to this list? Well, fortunately, Lua allows you to create anonymous functions, wherever you want because functions are first-class values. And these anonymous functions can be passed "upvalues", which are local values defined in a scope outside the function.

Using these facts, I wrote a trivial fix to bind method pointers to their objects, and leave Render unchanged! I made a function that did the method wrapping for me:

function MethodPointer(self, meth)
    return function(...)
        return self[meth](self, ...)

The function is passed the 'self' parameter and the method pointer to bind together, and it returns an anonymous function which will take care of calling, with 'self' being passed automatically.

Then I can go add to the render_list and update list:

table.insert(render_list, MethodPointer(self, 'Render'))
table.insert(update_list, MethodPointer(self, 'Update'))

This is actually pretty close to how Javascript gets around similar problems, but with its definition of 'this'.

This little tidbit allowed my various components of my game to plugged and unplugged from the main loop as it progressed.

For my text input, I used a callback to process commands when enter was pressed, using the same method pointer stuff. The callback passed around the piece of text, and would return true or false on whether or not the command was permissible. It was very nice.

Lua is just awesome. I love it.

Anyways. As you might see, coding isn't really a colossal obstacle, with Lua around. Instead, the new obstacle is coming up with good ideas!

Something to remember for the next time I try and make a 24h game, and what I always need to consider, while making Resonance.

Catch you later, everyone!

Tags: , , , , , , ,

No comments (make one!)


Posted by Overkill on April 5, 2009 at 3:35 pm under Uncategorized

For my 24 hour game, I made a weird game. A text-based shoot-em-up. Think of a text adventure, played on the console, but the scenario is constantly updating. You have obstacles to avoid and enemies to blast. Your situtation is narrated, and you type text commands to avoid things.

You constantly move forward, and need evade the hills and ceilings of the game’s endless cave.
As a result you need to adjust altitude to avoid things.
Crashing into obstacles results in an instant death.

As you fly along, you will encounter enemies, who need to be taken out quickly.

You have lasers and missiles. Lasers are weak, but unlimited and fast firing.
On the other hand, your missiles are powerful, but limited and slower firing, and recharge gradually as you go on.

Your shields protect you when engaged but gradually decrease in energy.
Your shields charge and replenish when disabled.
Your frame has limited health, and so as you go further in, toggling shields becomes crucial to survival.

At the end of a run, it displays the distance traveled, your score, and the enemies you destroyed.

It was all coded up in LuaVerge, making it ridiculously quick to code up.

So, now that’s it’s been introduced, download textshmup.

Textshmup now has the ability to speed up/slow down your ship.
The higher your speed, the less missiles you replenish, and the more obstacles you encounter.
So it’s sort of a difficulty modifier, I guess?
Also: it reports the time you were alive. I forget if it did that before, but whatever.

Tags: , , , , , , ,

No comments (make one!)

It is never too late to be great.

Posted by Overkill on February 2, 2009 at 10:19 pm under Uncategorized

Early on during the last week, me and Toen were having a nice talk about how so many of our projects fell apart due to lack of interest and direction. This led to a bunch of talk about planning, collaboration, and organization, something I’ve always lacked. After some disccusion, he decided to make an entry about how planning is urgent and so often overlooked (especially when working in groups), and specifically in the Verge community,

This inspired me to take a new approach to planning, and begin to write ideas down in detail before actual implementation. I decided, clarity is essential if I ever want to do something longterm. I think this will prevent feature creep, and keep myself from losing focus.

I started outlining general things that I want out of the gameplay, as well as making some level designs for shmuptroidvania. It will be a mix of bullet-heavy shmup action, and platforming with exploration, and the transition between the two modes of will be relatively painless.
But, then for a while during the past week, I just became too stressed out. I couldn’t really deal with the crappy weather, and the monotony of school and responsibilities. Started sleeping in and missing classes, and generally did nothing. It wasn’t until near the end of the weekend that I started to recover from this stress-induced aversion to work.

But I recovered! When I did, I started to piece together some of the final steps for LuaVerge. Got cracking, and finally put in a system for garbage collected resources.

To request a Verge resource be garbage collected automatically, you call a function v3.GCHandle(handle, destructor_name), which returns a reference that will manage this handle’s scoping. When that reference is no longer used, the destructor is called, and the variable is freed. I made this fairly low-level though, so v3.GCHandle have no public variables or any methods on them. They are a simply a mechanism for gc scoping internals. Here is an quick and extremely dirty example of it being used

function LoadImageGC(filename)
    local t = {}
    -- The resource handle, which is accessed from
    t.image = v3.LoadImage(filename)
    -- The returned table has a gc_handle that
    -- manages the garbage collection of this resource
    -- If this escapes scope, the image handle held will become invalidated.
    t.gc_handle = v3.GCHandle(self.image, "FreeImage")
    return t

-- A small scope block, allocates an image, and the image
-- will escape scope directly after.
-- Collection will occur on next Lua collectgarbage() event.
    local img = v3.LoadImageGC("hero.png")

I mainly put this in for OO wrappers, like the vx library, which of course uses it. All handle-style references use it, with the exception of vx.File, since files must be closed by the user anyway (especially if writing), and Verge reuses handles so defered collection could result in some bad issues.

vx.File was something I added today to the work-in-progress build. It basically wraps the Verge File library, which is surprisingly powerful, alongside the string tokenizing functions.

LuaVerge is essentially ready, but I’m withholding release until more tests are done, and vx is successfully updated. We’re getting there really quick! Then shmuptroidvania is back in the foreground.

Anyway, I’m back, and ready to rock through school and game making.

Tags: , , , ,

No comments (make one!)

Minty chewing gum.

Posted by Overkill on January 25, 2009 at 2:10 am under Uncategorized

This week, I poured over some more scripting language stuff in LuaVerge. Monotonous work really, but it needed to be done!

As a result, LuaVerge is nearly done. I’m convinced it’s at about the point where it’s usable again.
I added a way to load from .vpk packfiles with Lua scripts. So now require statements will also examine packfiles for source code, meaning that things like vx, and peoples’ games can be packed away in a single file.

I might add override loadfile and dofile too, if it’s actually required, but I figure those are mainly lowlevel things, and most work can USUALLY be done by require. I guess if someone were using Lua as a file format for game data (like a database of items or something) as well, then you’d need to worry about this. I’ll take peoples’ input here, for those Lua users out there.
One of the biger things I spent time scratching my head over was binding Verge’s builtin variables. You see, Lua shoves in getters and setters for variables as functions. So at the lower level, to get the backend variable VC-style entity.x[ent], it calls v3.get_entity_x(ent).

However forcing people to call raw functions rather than assign variables, I’m told is annoying. So, I added support, through Lua’s crazy voodoo magic with metatables.

Since ‘variable’-style accesses to builtins are more expensive than their raw function calls, a bit of optimization had to be considered, to at least lower these costs. After all, the older LuaVerge had issues with speedy access.

This was a bit of a surprise to me at first, but also really neat, local variables have a much faster access time than global ones. Storing local copies of global variables gives a significant efficiency boost. Some report about a 10% lookup for globals, so imagine if it were a nested table of some sort. Caching variable lookups as much as possible would very much improve performance.

So using this knowledge and a few tricks, I think I’ve constructed a way to make fast lookups to LuaVerge builtins. I won’t bore or scare you with the details.

But if you insist, and are curious, all the work is in the source repository for Verge at with username “anonymous” and password “anonymous”.

Particular files to look at are:

So after all this, I started to repair the vx library so it’d work after the giant rewrite. Surprisingly, it wasn’t too hard to repair.

Why? Because vx enclosed all its source in a custom class system. Object oriented code made things compartmentalized and simple enough to refactor.

I made a simple vergeclass function that declares a class, and basically allows you to declare objects of that class after it’s been made.

You declare classes like this:

vergeclass "Thing"

(Whoa! no brackets around the function call? Lua lets you omit them for literals like quoted strings or tables). Anyway, after that point, there’s a globally named class called “Thing” which can be instantiated.

Constructors are declared like

function Thing:__init(a, b, c)
    self.a = a
    self.b = b
    self.c = c

And methods inside the class are sort like

function Thing:method()
    print "Hody2!"

Objects can be instantiated like this:

mything = Thing(5, 3, "tacos")

Their methods can be invoked fairly simply:


The downside, was the original system I had (before LuaVerge was rewritten) was horrendously inefficient, but it worked somehow. Lua is magical and allows you to horrendously hack things that just work.

Anyway, I revisited this code not because of this but for another reason. None of classes could be ‘extended’ or ‘inherited’ from, making the OOP limited. Granted, for vx, inheritance wasn’t necessary, and I didn’t really desire people extending the core objects because I’d much prefer composition.

Basically objects should as much as possible use “has-a” relations instead, and avoid “is-a” whenever possible, however tempting it is. It decreases coupling somewhat that way.
But I had other code, with Resonance’s sidescroller engine that I wanted to salvage. It used a moderate degree of inheritance, which given for free by luabind. Luabind being the thing that glued LuaVerge behind the scenes before we tossed it, and it came with a class system with inheritance… Anyway.

So I added a single-inheritance system to vx’s vergeclass so I could eliminate this old dependency and have working code again. This involved entirely rewriting the old system now that I understand the Lua library, Lua-based optimizations and metatables a lot better.

It was actually pretty enjoyable to overhaul the whole thing, and… weird. Metatables have some godly power to them. Anyway I finished, and even gave two methods of setting up inheritance.

I supply a temporary global function super(...) which must be invoked in a child class’s initializer to ensure the object inherits all the attributes that its parent class has. Later, I might enforce the call be made on every subclass just to ensure undefined behaviour won’t happen.

Now any time a method is called, it’ll look in its own class first, and failing that it’ll look in it’s parent’s class. If a class needs to explicitly call a method of its parent, it can index self.parent and use self.parent.method(self, ...).

So using the Thing example from earlier, the calls to create a child class are either this…

vergeclass("SuperThing", Thing) do
    SuperThing:__init(a, b, c, x, y, z)
        super(a, b, c)
        self.x = x
        self.y = y
        self.z = z

…or this, which I prefer because it looks like Python kind of:

vergeclass "SuperThing"(Thing) do
    SuperThing:__init(a, b, c, x, y, z)
        super(a, b, c)
        self.x = x
        self.y = y
        self.z = z

Either one of them reads “The class SuperThing is a child of Thing”. And there you go! Inheritance! Nifty! Sexy!

I even added one other thing! Properties. Other languages provide properties to declare pseudovariables with functions that are called when their values are accessed or mutated. I do similarly, through a bit of metatable magic.

Let’s take an example of a typical RPG player for a second, who has an HP attribute. To declare a property, you can go something like this:

Player._property('alive', function(self) return self.hp ~= 0 end)

You can then use the ‘alive property like a readonly variable, for instance on a player object named bob:

if bob.alive then print("We're still kicking!") end

I might expand this class system to allow multiple inheritance or mixins at some point. Not a high priority, but it’d be nifty!
So yeah, this has been my week. I’d love to hear about yours too! :D

Tags: , , , , ,

No comments (make one!)


Posted by Overkill on January 18, 2009 at 1:47 am under Uncategorized

School definitely crushes productivity, it’s true. But I figure it’s not all a waste. If school is consuming programming time, and some of it seems moderately interesting to me, why not post a Gruedorf about it anyways?

For my Game Development class project, I taught myself some basic 3ds Max stuff this past week so I could start to make some simple lowpoly 3D models. Here’s a start of the model I’ve been working on so far!

The modelling was done with 3ds max. After some frustration in getting polygons to unwrap into nonoverlapping UV regions, I exported the UV Texture Maps and doodled on Paint Shop Pro. It was rather fun. The palette on the guy’s face and hair is shamelessly stolen from my Resonance hero sprite.

My intent is to hopefully make a face paced hack-and-slash + platformer with cube men everywhere. This might change later, when I feel more creative.
In my Computer Security class, I wrote program in Python that would use a dictionary attack to figure out a password that starts with “R”. It used Python’s telnetlib module, because the login was performed remotely over Telnet, and it used the threading module to perform multiple connections. The target server we were attacking certainly wasn’t very secure… Once the protocol was working, it was burning through about 100 words in the dictionary every minute, until it eventually made it up to “retribution”, the winning password phrase.
In my Image Processing class, the assignment was to write a program that rotates an image and uses bilinear interpolation to smooth the pixels.

This was especially easy since I had code left from Brockoly that did image rotation, and it used the Corona library in C++ to load images. I simply scaled back the code so there was less junk, and made it so images could be saved as PNGs.

Corona once again saved the day there, since it has a PNG writer builtin. Very handy. Also very easy, which makes me wonder why we don’t have png saving in Verge yet, since it’s quite simple — only about five lines! Ahem.

So when I was finished, I had a commandline program that could take any input image, rotation (in radians or degrees), scale, and the name of a PNG output file, and do all the processing work. Sexy.
In other news, LuaVerge works again more or less, thanks to Zeromus.

It’s quite different in how the internals are accessed. On the other hand, the internal variable and function things are successfully shared between Lua and VC code. In other words any feature (that’s not a language feature of VC) is available in Lua too.

The only thing that’s missing is boilerplate magic Lua code so the internal variables’ get/set methods are wrapped up in tables in a nice way. This can hopefully be added soon too, if I’m not too busy.

When that’s caught up, on to shmuptroidvania work and cube man game.
See you next week, folks!

Tags: , , , , ,

No comments (make one!)

LuaVerge: Take Two

Posted by Overkill on January 11, 2009 at 1:43 am under Uncategorized

Hey there.

This week, I didn’t get to work on shmuptroidvania just yet. But this was because there were other pressing issues to tend to.

The big priority was starting to fix LuaVerge so it’d work again. We used to have luabind do the dirty work, but it was too limited and wasn’t very maintainable. A rehaul was justified.

Zeromus and I discussed ways to tackle this, and we figured the cleanest way to make functionality shared by both VC and Lua is to make the bindings call the same internal functions for dealing with builtins.

I’ve added builtin function calls, through a bit of Lua glue and prodding at vc_builtins.cpp which handles the function glue. I also added reading of constants from Lua (HDEFs).

Zeromus has been working on the raw variable (HVAR) binding code, which will use methods like v3.get_systemtime() and v3.set_entity_x(ent, x). The variable-like access for these has yet to be defined though, and is bound to be much slower. But at least THIS time around, the functions that are called are visible to those who need the extra access speed.

These changes called for a lot of stuff being moved from the vc_core.[h/cpp] files to the ScriptEngine class (defined in g_script.[cpp|h]). There’s also a ton of methods in ScriptEngine that no longer need to be there now that luabind is gone, but refactoring that is gonna be hairy.

I am planning to get a packfile loader working with lua sooner or later, and then people can use vpk for lua scripts.

It is my hope that the vx library stays the same to the outside user. But the new variable binding crap should definitely speed things up a tad.

Oh! There was another neat idea being thought of, which while low-priority and possibly difficult at the moment, would be awesome: A bridge betwen VC and Lua directly, so that Lua and VC scripts can talk together. This would lower the barrier to entry, since old VC code could be used in new Lua projects. This means that written game scripts could make a gradual movement to Lua while still working in the meantime, encouraging reuse of old stuff, and giving a boost towards wanting dynamic scripts instead.

Anyway, this was my week. Catch you folks around!

Tags: , , ,

No comments (make one!)

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.

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: , , , , ,


Gruedorf: New Years Resolution?

Posted by Overkill on October 20, 2008 at 6:00 pm under Uncategorized

So this is the second year into McGrue and Kildorf’s fearsome competition known as Gruedorf.

What did I do in a year? This list summarizes it pretty well:

  • I lost Gruedorf several several times.
  • I added new features to Verge 3, and fixed the new Lua side of the scripting
  • I was one of the first people to use LuaVerge in a project, though Kildorf was the first to post
  • I made a scripting improvement for LuaVerge called vx (which you can read about here). Basically like Verge with OOP and awesome. Ustor uses it in his space game!
  • I made a data language called Mungo, which was basically a human-readable replacement for plain-text file formats. Better than XML in some ways, because it doesn’t have annoying tags, it just has bulleted lists with colons. I use it in my own projects at any rate.
  • I worked on a sidescrolling Metroidvania game idea I had for a while, called Resonance, which you can view the work-in-progress for with an SVN client from:
  • I attempted to create my own file formats for maps, tilesets, and sprites. And also thought about a container format known as a “world” that basically joins up a bunch of maps seamlessly. Unfortunately the results of this were…
  • …I got frustrated with existing game engines to an extent, and decided to make my own game engine from scratch which I’ve called Brockoly for the time being. I’ve been developing it under both Windows and Linux. You can view the intermediate C++ source and current crappy demo from:
  • This website was formed (thanks to Grue and Zeromus for hosting). I updated this website a tad, with a few different layouts. It’s been through varying degrees of eyesore. I think it looks better, but it’s still got a while to go. Plus it looks pretty damn broken in older low res browsers. I need to rehost all my games here :/
  • I drew a bunch of random pixel art. I think I finally am starting to get the hang of spriting in ways I never did before!

Speaking of art, I never posted this here, but I’ve been making changes to Resonance’s protagonist sprite with the help of Pixelation (a site dedicated to learning and critiquing Pixel artwork):

Anyway, most recently, I’ve put in my sprite system. It can do all sorts of funky things so far, like custom frame dimension stuff, hotspot setting, custom animation strands, transparency, and sprite rotation. And it uses Mungo! Really, not especially impressive, but it’s a start.

Anyway, seeing as it’s a new year of Gruedorf, maybe some resolutions are in order. If they’re anything like typical resolutions made on New Year’s, they probably won’t be kept. But like New Years, I can sure try!

My resolution: To lose 450099030984534095 pounds to actually post more on Gruedorf. And to be less lame.

Sadly, with school my attention gets diverted a lot, and I am typically pretty busy. So I’d appreciate nagging and support to keep me posting more!

In fact, it was McGrue who was nagging me to post this week. You should nag me too!

Anyway, maybe year two of Gruedorf will fare a little nicer!

Tags: , , , , , ,

1 comment

Repentance to my Gruedorf Deities

Posted by Overkill on November 4, 2007 at 3:08 pm under Uncategorized

Yes, yes, I get it. I failed. So hard that you’ve found the need to invent new words to describe it! I am an intense disappointment and I apologize for creating this depressing vortex of not-making-games suck.

I’ve been a horrible combination of busy and lazy. School work and stuff keeps me bogged down, and then my friends keep wanting to do things. Help me ruin my life so I can have free time to make games again! Much appreciated.

At any rate, a small return to progress is being made. I’ve discovered a few bugs with the LuaVerge v3 namespace I wrote, through further development. Support for joystick wrapping has been added. In the signal namespace, I created a “multijoystick” that polls all joysticks connected at once and treats them as a single joystick, and a button wrapper that allows an game action to be associated with both a keyboard and joystick binding simultaniously.

I added a really cheap placeholder beacon transmitter entity type, which is used to calculate the player’s signal strength when the beacon is on-map. Here’s a picture of this in action, not exciting looking at all really, I can assure you:

Get it here, but don’t expect to be amazed in even the slightest way, unless you want to try out the relatively non-exciting joystick input crap or something!

Anyway, back to talking about the beacon entity stuff, I quickly saw they had huge overhead when I was getting about 30fps with only ten signal beacons placed. It turns out the big bottleneck was caused by accessing entity properties from the v3 wrapper. Each reference to self.ent.hotspot_width and self.ent.hotspot_height hurt the performance drastically, because of the amount of magic lookups being done, both v3-namespace side and raw LuaVerge-side.

LuaVerge wraps entities in nested lookup tables that transform all that crap into a native C++ function call, one table being the index, another being the entity’s property (like hotw and hoth). Let’s not forget the global table entry for “entity”, either. On top of these things, I insert even more overhead by creating classes with properties through Lua-side. hot_height is a property that contains a _get(self) function, which returns entity.hoth[self.index]. All the table searching stacks up! So I got around this by storing the hot_height and hot_width locally in signal’s entity extension, which is reasonable considering these things won’t change once the entity is created (unless ChangeCHR() is called). Uhm, there’s some refactoring that needs to be done at any rate. I will hopefully be able to cut the slowdown for most of the read-only entity variables. Things like entity x/y, will still incur an overhead because they need to be writable.

Anyway, there’s my progress and stuff. That wasn’t very exciting was it? See you again soon. I am announcing my return to Gruedorf, and escape from shameville.

Next time, I hope to maybe get all the art drawn so-far actually in game. Then I’ll worry about animating and fixing it all. (Oh by the way, that 255 entity limit in Verge? It’s just silly. I really want to remove that.)

This site really needs a facelift, too. The temporary copypasta mash together until it works and then go back and make it somewhat presentable yet still ugly and apalling and I really could have just made a nicer layout of my own from scratch if I wasn’t too damned lazy in the first place template thing just isn’t doing it for me, and I also want to tie in some non-blog areas to the site, so if in the highly unlikely event I have a lot of free time and I’m feeling adventurous and creative, I might fix it.

Now I need to depart, it is time for me to complete a homework assignment that’s due at 11:55 pm today. Thanks for reading words and stuff!

Tags: ,


Older Posts »« Older: Progress Begins      Newer: Sloth »