The LinkedList code has grown to support a handful of simple linked objects which together give us the ability to build a node structure similar to MAYA,
where you can create reference objects with inherited attributes, add new attributes to the reference objects later at will, have upper and lower clamping values for evey attribute, name our attributes whatever we like, have instances of reference objects that have unique attributes as well as those inherited from their reference object, oh I could go on, if any of you have played with MAYA long enough to screw with the node hierarchy, you will appreciate where I am coming from ... this is much more than an asm version of the "new" directive ... the next installment will allow you to create extra connections between the outputs and inputs of arbitrary nodes, which can be used as an aid in automation (again, MAYA fans will understand this)
for example you can associate the rotation of a jet airplane's landing gear with a limited range of the jet jairplane's own height in the Y axis.
As the plane touched down and took off, the landing gear is animated for you automagically through the marvels of modern mathematics.
This is pure example, the ability to make internodal associations turns our node hierarchy into somewhat of a neural network, in that it can be used to calculate which formulae should be applied in what order, if not to actually perform the math... well, I'm not that good at weighting yet :P

A very silly example provided which really does not do the code justice.
It doesn't really do much, it's just what I used to debug the code.
Posted on 2003-03-10 23:41:06 by Homer
Strange, the example didn't run by itself but ran okay in Ollydbg? Go figure.
This cool bit of code should work well for all kinds of stuff.
m_SetRefAttributeValue MACRO pAttribute, Value

m2m [pAttribute].RefAttribute.Value, Value
ENDM

m_SetRefAttributeMin MACRO pAttribute, Min
m2m [pAttribute].RefAttribute.Min, Min
ENDM

m_SetRefAttributeMax MACRO pAttribute, Max
m2m [pAttribute].RefAttribute.Max, Max
ENDM
Posted on 2003-03-11 00:26:33 by bitRAKE
This was compiled under XP.
Due to some weirdness, my exes dont run nice on lower machines... I simply rebuild the same source under NT4 or 98.
In this application I had trouble with a timing issue during initialisation.
Having checked that the stack was not being compromised, I went on to discover that if I tried calling for resources too quickly the app would crash.
If I stuck in a messagebox, or (in this example) used a threaded delay, the problem totally disappeared. Maybe your box is fast - I run a 333.
In that case, increasing the timeout before the thread fires up would probably solve the problem.
I actually had a situation where the app would run every other time, crashing about 50% of the time, and always inside NTDLL.
I reiterate that no stack problems exist in the source.
I think I've run into this problem once or twice before too, but cleared it up by recoding the offending passage in wya that really should not have made a difference but evidently did.
I have to assume that NT starts allocating process time before it has even completed allocating appropriate resources.
Did you notice that silly little StackSafe macro?
Thats what I used to detect stack corruption.
It deserves to be written properly - as it stands it contains a static label and so can only be instanced once at a time.

Anyhow, that new LinkedList code is going to be fitted to a scripting engine which is partially complete. The scripting engine gives console access to application functions. It will allow for realtime creation and editing of new and existing object definitions, ie, the gamecoder may tweak finely any attribute or attribute association.

I think I'm just about happy to commit to a binary file format now too.
It should not be difficult to pack up the proposed hierarchy.
Pack would be the key word here.
Despite my best efforts there remains much repetition of similar data.

Finally, AddChildEntry and AddSiblingEntry are to be overhauled.
I have put the root pointer in the linkedlist source for a reason.
It is representative of the fact that the linkedlist source is about to grow into a mini memory manager, and will perform a kind of batch allocation of resources... instead of allocating 30 when we need 1 and keeping a resource pool, I will simply allocate pages of memory, and them cut them up until they are not large enough to use.
That is to say, allocate say 10kb chunks of memory, and then internally calculate the start addresses of objects in each memory chunk.
This is more efficient in terms of usage of resources, and has the benefit that unknown sized objects may share a page.

whew:)

Also I been studying exception handling... I was thinking about making some kind of trap on request for resources - maybe I still will.

Anyway, enough gabbing, back to work :tongue:
Posted on 2003-03-11 03:09:15 by Homer
The new LinkedList code is being tested in an executable based around a ListView window (in Report mode - like a spreadsheet).
The testbed is basically a LinkedList monitor, allowing realtime editing and monitoring of a linkedlist hierarchical database.
The app currently allows dword, float4,float8 and formulaic data, with optional clamping threshold values, to be associated with any attribute you create within any linked object.
The exciting news is the introduction of my version of a formula parser.
I'm coding it to allow referencing of values in any other attributes in any objects.
Also, it will support two formulae per attribute value, one to be applied when an instance of the object owning the attribute is created, and the other to be applied constantly in realtime to the attribute value.
As an example, you might have one formula for generating the initial hitpoints of your player, and another for controlling the hitpoints during gameplay.
The formulae allow "soft-coding" of much of what we would normally have hardcoded within the game logic, and thus native to that game.
I expect to benefit from extremely flexible logic which will be akin to polymorphic code in terms of runtime logic flow. Formulae will aid in everything from automating animated objects to driving enemy AI, all with zero or little actual coding required, and with a relatively low performance hit due to the overhead of having to perform one or two dereferencing steps for nested subfields.
This will run almost as fast as real code (and faster than some), and allow any idiot within reason to dive headfirst into the editor and create a whole game from scratch, without the limitations associated with the gamut of "game construction kits", provided they have an understanding of hierarchies and assuming that the doubleclick which they performed when starting the application was not a happy accident.
This stuff is finally coming together.
As soon as I have the formula interpreter debugged, I'll post a beta example and its source (and a LL include update).
Next will be patching in the MeshLoader code, followed by the addition of more inbuilt datatypes including StaticMesh object definition.
From there on, any new object definitions will be added to the testbed application directly, and will be stored in a support database file.
Why's it so quiet in here? Everybody playing solitaire?
Posted on 2003-03-30 07:00:10 by Homer