The biggest obstacle to implementing my goal is being able to allocate memory that is fully accessible on both sides of the application/DLL boundary. This is key to being able to share objects across the boundary.

Inspired by some sample code from Technomage, I hooked the EXE’s memory manager into the DLL’s memory manager. Due to the differences in implementation, this required some intermediate functions, but, the DLL loaded and the EXE appeared to be able to allocate (and to a certain extent use) memory using the DLL’s memory manager… so things were looking up.

Unfortunately, as the initialisation phase was nearing completion, *BOOM* EInvalidPointer exceptions. The strange thing about this is that by that stage, it had already requested a number of blocks of memory that in many cases had actually had data written to them.

Try as I might, I couldn’t find the cause. But as soon as I compiled the DLL with BDS the problem went away and I had memory shared between the EXE and the DLL and I was able to pass objects across the app/DLL boundary with no problems at all.

I guess somethings just aren’t meant to be.

Still, there are other options for compiling the DLL, including the free Turbo Explorer, so I think I’m going to plod on and get the system working entirely with BDS and then worry about the finer points of implementation at a later stage. One option could be to actually have both the app and the DLL hook their memory managers into a memory manager in another DLL.

But, one good thing has come out of all this… many of the concerns and questions I had about the design of ORE are now cleared up as I’m going to make the assumption that I can share objects across the application/DLL boundary. This frees up the design quite considerably since I don’t have to worry about a whole bunch of pointer transfer mechanisms… I can just pass an object.

And on the design front, I’ve made some progress with the statemachines in the play engine.

Main play engine statemachine:-

Initialisation statemachine:-

Thats about it for now, overall progress has been a little slow over the last week or so, mainly due to trying to figure out all my convoluted data transfer mechanisms to get around the app/DLL boundary issues, but now I’ve got that side of things straight in my mind, I’m hoping things will speed up a little (they better do as I’m looking forward to making The Outer Reaches – Rise of The Raiders with the new engine )

Design… I’ve tried several times to design my software before I write it and every single time I reach a point I just can’t get past. My mind gets clouded with a plethora of questions… can it? will it? what if? and the whole design process grinds to a halt. This normally results in me sitting there trying to break though the mental blocks that have crept in… ultimately I fail and its at that point I say ‘screw the design… LETS CODE ‘

This time it happened, and I found myself hacking away at one of the data transfer objects. Now, I’m so glad I did because things have progressed… kind of, but more on that below… the thing is, my design was blocked by questions… I’ve answered some of these by coding and this is where I’ve been going wrong… so blinded by my desire to have a design before code have I been that I’ve forgotten some very important things.

Design is an iterative process, just like the actual coding… you can’t finish a design without doing your research, without being able to make informed decisions about the how’s and the what if’s… the only way to make informed decisions is to do… prototype, test, tinker.

It sounds obvious and it truly is obvious, but for some reason I just didn’t think like that. I have a CASE tool that can reverse my prototyping into the model, so I can tinker around, solve a problem, reverse it into the model and continue with the guts of the design. DOH! Why didn’t I think of that a week ago?

Anyhow, in my enlightened state, I’ve been tinkering with the general theory of how ORE is going to come together.

The concept of having the play engine (Compiled with BDS 2006) and a game function library (Compiled with FreePascal) is excellent… in theory.

Until of course you consider the reality.

I figured I’d ship data around with pointers… one of the things I needed was a TINIFile style object for a general purpose data store. I wrote one that used linked lists, but its performance against my favourite (TMemoryINI) was diabolicle, so back to the drawing board… I created a variant of TStringList called TExposedStringList that exposed its data store via a property, allowing you to create two instances of the object and plug one instances data store into the other (cross the App/DLL boundary for example) and then used this to create TExposedMemoryINI whic used TExposedStringLists for its data storage.

In the end, there were no strings in these two objects… everything was done with base data types, pointers and PChars for strings.

Unfortunately, across the app/DLL boundary its still no good. Weird things start to happen once you allocate memory on both sides and deallocate it. So, its become plainly obvious that I’m going to have to use a shared memory manager… the worst thing about this is that it has to be Delphi and FPC compatible.

But this is actually a good thing… with a shared memory manager, I should (if the object mechanisms are compatible) be able to ship objects across the boundary instead of transfering all the data using pointers

Many thanks to Robert, Technomage and Chebmaster on PGD for bouncing a few ideas around. Gave me a lot of food for thought and experimentation.

Since theres a good chance you don’t know what the aims of the competition entry were, let me give you a brief overview. We wanted to create a top down 2D retro style roleplaying game (Hence the name… Outer Reaches Retro Roleplay Engine – or *ORE* for short). To begin with, the competition entry was looking good considering it was the first time I’d ever written a client based game engine, but towards the end… it was a nightmare.

The first thing I guess is to say where I went wrong with the orginal… thats easy… time pressure throughout the competition meant I made decisions on the fly without actually thinking about what I was doing. The net result was some very poor decisions that had serious consequences the further into the project I got. I actually had to rewrite the whole play engine in an attempt to make the final deadline, but to no avail… we lost by a whisker to Tanx.

So, the first thing to do this time around is to actually think about what I’m doing and to try and address some of the issues that caused problems with the competition entry.

The first major hurdle was load times… All our image data was stored in an imagelist that formed part of the game data object that held everything about the game as a whole. When the game started, it had to decompress this object (a requirement of the competition was submissions that were less than 20MB in size)… this took an age, but what was weird was it took longer on faster machines? Scratch my head did I, but I couldn’t explain why this should be. Anyhow, this also created problems elsewhere… I was using unDelphiX and one thing that its not so hot on is dynamically loading media… you have to deinitialise it, load your media and then reinitialise. You also have to do this when changing from full screen to windowed mode. So, the more image data you have, the longer this process takes.

The other major hurdle was script execution times… Since I was going for flexibility everything was event driven and all the events ran Delphi Web Script II scripts. This sounds great, but it lead to some jerkiness when you moved…. you’d run into a new map cell and*clunk* a short but noticeable stop as the system waited for events to be checked and executed as required.

The final hurdle was one that any project can end up with if careful thought and consideration isn’t given to the guts of the system… Object/class/data mishmash. Not to put too fine a point on it, the code was a mess… convoluted callbacks, unnecessary checks in the play engine, and in general… code that was cobbled together on the fly in a complete rush to meet competition deadlines.

With these issues in mind, I’ve started work on a new version One which *shock* *horror* I’m actually designing… yes, you did read correctly… designing first. I’ve decided its about time I did a proper job on one of my own projects so that instead of it becoming a mess, it actually has a decent chance of becoming a real viable little product.

So, without further ado, I’d like to introduce the first three class diagrams….

First up, its the map editor brush classes. These will be used to build complex brushes within the map editor allowing the placement of multi-tile elements, scripts, visibility etc. with a single click.

Next up, the map zone classes. These will be used to provide ‘zones’ on the maps. You could be in a forest zone for example, that will have the sound of birdsong playing… you could be within earshot of running water (a river)… I’m sure you get the picture.

And finally… the map container classes.

Its not much, BUT, the map brush and map zone classes are complete So, its a start and a huge step in the right direction.

And here is what the old ORE engine did at the end of the competition….