Advertisement Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

The game continues to be formed pt2

Sign in to follow this  


So, after many hours hacking away and a fair few of those finding errors in my Lua code I have something which is starting to look like a game now, complete with a (no rendering yet) menu screen and a spaceship which fires missiles... huzzah!

One of the main 'issues' I had during testing (once you got past my inability to put 'then' after my 'if' statements, or my tendancy to forget 'self') was my state system; apprently my abuse of the language wasn't going to fly [grin]

If you recall from the entry below I was trying todo the following;

local instance = currentstate.instance
local func = currentstate.initFunc

However, it turns out regardless of how I try to hax0r it that just wasn't going to fly. However, as mentioned the instance:func() way of calling a function was just syntatic sugar for func(instance), so a change to that and it all worked fine, with the update/state swapping code looking like this in the end;

function update()
local instance = currentstate.instance
local func = currentstate.checkStateFunc
if func(instance)
currentstate = instance.nextstate
instance = currentstate.instance
func = currentstate.updateFunc

The only issue I have with this is that, currently, each module needs to know what state follows it; for the purposes of this assignment that's fine, however post-assignment I might well 'poke' it and add a 'state manager' class of some sort which lets me find the 'next state' to display on a state change.

However, things are progressing forward and I do effectively have a game in a few 100 lines of Lua code... huzzah! [grin]

The only problem I've got now is that of speed; namely rendering speed.

The graphics backend is all done with Java, so from Lua a call to draw an object looks like this;

function Bullet:render()
engine:translate(self.location.x, self.location.y)

This makes a copy of the current transform state, moves to the location, renders the actor (might rename this) and then restores the state once we are done.

In the engine class we draw to a VolatileImage class via a Graphics2D class; the theory being that these VolatileImage class objects should be accelerated. Each actor is also represented by a VolatileImage class internally, with the idea being to enable fast blitting.

This doesn't seem to be the case however as at around 20 on screen sprites (1 player, 1 enemy, 18 bullet) the framerate drops off a bit [sad]

I'm not sure where the problem is right now;
- too much Lua<=>Java overhead for all those calls? (2.2Ghz X2 processor, unlikely)
- Too much Lua code? (see above)
- Incompatibility between Vista and Java1.4 meaning that things are all done in slow software? (maybe?)
- Something else?

Again, speed isn't a huge issue here, but all the same it's a tad annoying.

ah well, I want to have all the gfx code done by midnight so that I can write up and be done with it by 4am, which is 15h away or so.

No problem? [grin]
Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!