This is Bananattack.

Tag: verge

Alive and Lethargic

Posted by Overkill on December 19, 2010 at 10:55 pm under Uncategorized

It’s getting closer to Christmas, and it as approaches, I can’t help but reflect a bit on the past year. I’ve had very mixed feelings on the whole thing. I won’t drag you too far into my life, but I’ll give you a bit of closure. I think it’s the right thing to do, given my large absense.


I was 21, and had just finished my second-last semester of school at the University of Guelph. It was good to be back after the stress of juggling several Computer Science courses, and finally having free time to work on projects.

Christmas was fun time with family, and I was happy to be off school. I was hacking away at Molasses Monsoon, drawing a picture for Pixelation’s Secret Santa event, and attempting to make a quirky sim-game for a winter contest with Syn. It was going pretty well, but this wasn’t going to last much longer.

First off, my uncle passed away shortly before Christmas. I felt kind of bad because most of my memories of that uncle were from childhood, and our family didn’t visit nearly as much when I grew up. We went to the funeral a few days after Christmas, and were back home around New Year’s Eve.

On the day of New Year’s Eve, my friends called me up and wanted to hang out. My dad was working on a puzzle in the afternoon, we talked for a bit, and then I was on my way. But that was probably the last fond memory from that break, and the last time I saw my dad feeling well. I came back after celebrating with my friends, and pretty much went straight to bed.

The next day, New Year’s Day, my dad was sick. I figured he had some bad Chinese food, or it was from the celebrations the night before, but it turned out to be much worse. It turned out that he had a stomach flu, but since he had a thyroid condition and Addison’s Disease, this was essentially a death sentence. He never bothered to explain his conditions so I knew very little about what they were doing to him, and he never asked to go to the hospital when he feeling was sick. By the time we took him to the hospital, it was already too late. My father died the morning of January 2nd.

Soon after, I caught the stomach flu, and so did my sister, my aunt and my sister’s boyfriend. Since I caught the symptoms the day of my father’s death, I thought I was going to die at the time. And I was really sick the rest of the week. I managed to pull through.

…I won’t go into further detail than that. It was a horrible time. I only felt that it was okay to disclose this, because it’s getting close to that time of year again, and I know that this Christmas definitely won’t be the same as those in the past.


Anyway, I went back to school, pretty much right after I recovered from my flu, and finished my last semester. I took Compilers, where we wrote a Pascal-ish (Pish) toy compiler that emits MIPS assembly, a 3D Graphics course with a bunch of OpenGL stuff, an course on AI stuff, and the obligatory Topics in Computing 4th year course where you do independent research (I made a cheesy painterly renderer). It kept me busy, and I managed to have fun throughout most of it.

Since then, I’ve turned 22, and graduated from the University of Guelph with my Bachelor Degree in Computer Science. I’ve felt no real motivation to do anything amazing with my life. School was like the last big obligation I had to complete, and my father wasn’t even around to see it. I have no real direction anymore, and I feel like I have as little idea about what I want to do with my life as when I was still in high school.

My projects have been stagnant for the most part, although I had a few surges of creativity. I worked on Verge for a short while after I got off school, around May, which you can see about in the post before this.

The next big burst of creativity was learning some 6502 assembly and how old Nintendo hardware worked. I attempted to create an NES game, and although I didn’t make it too far, I managed to make a small tech demo ROM, that looks like this:

It’s a fairly basic techdemo, which has a textbox and a player sprite, and it uses MMC3 scanline interrupts to do funky cloud tile scrolling. It doesn’t have any audio, because sound engines appear to be a tad more work than PPU manipulation. I wanted to eventually make a roleplaying game of sorts for the NES, but that might be a while, if ever, that I get anywhere with that.

Then I realized how tedious it was to type in assembly commands using official 6502 mnemonics. I went about making a 6502 assembler, which I decided to call “nel” (Nintendo Entertainment Language, or something, I don’t know). It was written in lex and yacc, and you can view its source here. For its purposes, it worked, but I felt like I could do a bit better. Lex and yacc were both a bit ancient and frustrating, and the error reporting in yacc was annoying. There were also annoying memory management problems with C++, which I coded the AST in, and it was going to be pain to fix all that. In fact, right now, the memory just leaked until the compilation was done and OS cleaned up. I

I eventually decided to make my own recursive-descent parser in D. D is pretty nice, if you don’t need any external libraries, and only really need file IO and some data structures, which was the case when writing a compiler. It’s also garbage collected, which was good. I got a little bored doing the rewrite though, maybe one day I’ll pick it up. I’m onto the AST-handling junk, which I can more or less port from my C++ codebase, but I’ve been a bit lazy.


In addition to a few creative swings, I spent a lot of time looking for a job with no results. I eventually (mid-October) found something through a school friend. I started in November, and although it’s probably a temporary thing, for now it seems okay. It’s a six-month contract for a company called MRX, which has the CHL and CFL as two of its primary web-design clients. So far it’s fun, and there are a few people in my developer team that also went to the University of Guelph.

Lately I haven’t felt an abundance of free time, and usually find myself tired and unmotivated when I get home from work. I watch some TV, or hang out with my flat-mate for a bit, then sleep and repeat. My hobbies like playing games, writing, drawing pixel art, and coding have all been heavily neglected.

I’m writing this now in attempt to stop this idle activity and do something with my time again. Especially since McGrue and Kildorf are back in the race and making progress, and the recent advent of the new vrpg homepage should be inspiring to me.

I’ve done only minor things lately, mainly decisions for Verge in the long-term, but which haven’t been executed yet. Decided to rip VC out of Verge, and to redo the Lua API, to remove FMOD in favor of audiere, and to do some major internal cleanup. API ideas so far for a future Verge version (Verge 3.3) are in my Dropbox public folder, so these files may change as I edit them. Here are some files with the rough ideas about the new API:

Take a look over that, and if you have any feature requests, let me know.

Anyway, this is about all I can write about for now. Hopefully, I will make another post soon, by the next week. I will have to see though.

Tags: , , , , , , , , , ,

1 comment


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!)

Quest for Colour

Posted by Overkill on April 12, 2009 at 5:50 am under Uncategorized

I remade my first compo game, Quest for Colour for fun this weekend. It was a neat experience. It taught me a lot about my old art and code, and how I’ve improved since then. I had plenty of head scratching puzzle along the way.

Among the improvements was a HUD showing the time limit, bits collected in the current area, and overall completion percentage. Gave the player way way more time. Scrapped the old battle system, and replaced it with a quest to capture all the slimes. Although it’s sort of annoying it’s less so than the battle system that was there.

There was some god awful hideous work-around code, that I commented out and replaced with like one or two lines of new Verge. It shows how both Verge and my coding has evolved.

At any rate, it’s there to download and drool at now.

I can’t say I was fully satisfied with what I’ve done, but I’ve made the thing a little more presentable and thus more playable for everyone. It was a fun diversion. So, go check it out.

UPDATE: Fixed more bugs with the game, and added a difficulty selector. With the addition of hard mode, which IS hard. If you switch maps which you haven’t cleared, all slimes return. Easy mode is the same difficulty settings as last update. Normal mode is slightly more challenging.

Tags: , , , ,

No comments (make one!)

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!)


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!)

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