Author: Alistair Broomhead
Revision Date: 2011-02-18 22:29:05 UTC

This took a lot more work than I expected... To make head or tale of the whole thing I ended up creating a debug mode where every tile in the game is labled, and there's a whole load of extra debugging information spat out into the text pane...

I've created a new class for a trail of footsteps showing the path a characer is planning on treading. This will look cool when it's finished as well as helping with debug window. It's getting fairly messy to debug some of this stuff, so this could be a bit help. I've created a sprite to use for this but I haven't started rendering it onscreen yet. A list of tile positions is currently spat into the text pane when in debug mode.

I noticed part of the error was to do with translating the position the player is transferred to after passing through a door, and have made sure this is no longer needed, as well as deferring the recalculation of the character's bath until after they have entered the room and the door has closed behind them.

I moved the calculation of the points in a path spanning rooms into the span-finding algorithm, as I suspected this of causing a problem, however it may turn out that this was unnecessary and it would remove some of the algorithmic overhead to remove this once again if I can prove this is fine.

I had introduced a bug somehow which was causing a segfault on maemo 5 devices, which was to do with placing the main graphic view inside a placeholder widget, so I have removed the placeholder widget and placed this view directly into the layout - this is a cleaner implementation, but viewing the .ui file does not show what the game ui will look like any more. Still better than when there was no .ui file, and the inner workings of the main graphics view are too complex for my current grasp of the WYSIWYG editor anyway. I'm not even sure if it's possible to implement what I have in python via the Qt Designer.

I changed the self object in _Display/_DisplayObject.py to fit in with the usual convention - the confusion is not worth the hassel just to make it easier to work with on my phone's display.

In addition to this the DisplayObject is no longer a subclass of QMainWindow, but a normal object which delegates some functions to a standard QMainWindow.

Author: Alistair Broomhead
Revision Date: 2011-01-14 20:20:24 UTC

Fix'd kineticScroll issue

Author: Alistair Broomhead
Revision Date: 2011-01-14 22:04:44 UTC

'Engine' Complete