Its been a bit of a slow week (and a bit) for ORE. Firstly… design… it doesn’t half get in the way and secondly… nice in theory… hellish in practice… my theories about how to shift data around the system have largely evaporated.

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.

This entry was posted on Tuesday, March 20th, 2007 at 10:07 pm and is filed under ORE, Programming. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.