• entries
455
639
• views
423274

# The game continues to be formed pt2

63 views

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.instancelocal func = currentstate.initFuncinstance:func()

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)	then		currentstate = instance.nextstate		instance = currentstate.instance	end	func = currentstate.updateFunc	func(instance,sys:currentTimeMillis())end

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:beginObject()	engine:translate(self.location.x, self.location.y)	engine:renderActor(self.actor)	engine:endObject()end

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]

There are no comments to display.