Spent a few minutes upgrading my ObjMem32 lib and DebugCenter (rebuild and use new Registry path).
Then I sent the new DLL and EXE (and all media resources) to Biterider for a test run.
We noticed its possible to generate a GPF if all the media files are not present, something for me to fix when I get bored - it won't affect games, but it will affect developers, so I will make it something of a priority, since I see developers as the primary users of GameEngine, rather than the end-users  :roll:
Posted on 2009-10-08 02:17:32 by Homer
Having a few problems getting the EXE to include the object templates without the code for the methods.
The problems stem from my use of Embedded Objects in the main object in the DLL.
I will begin to change them to indirect objects (pointers) and I bet it solves the problem.
The alternative, which is ugly, is to introduce an eventsink interface in the engine proper, and not let the EXE know about all of the GameEngine core object and its components.
That would make 'lowlevel gamedev' impossible under GameEngine, not acceptable.
Posted on 2009-10-10 01:22:33 by Homer

With help from Biterider (thanks!) I now have managed to build the EXE project in such a way that it contains no Code or Object Templates (!) other than the EventSink (callback interface) used by GameEngine to notify the EXE of various events (so far, only one)... and yet the EXE project's code is AWARE of all these objects, and given an instanceptr, can make calls to any method of any GameEngine object including its subobjects and dependancies.
This was done via a macro called 'VirtualObjects', which emits only the STRUCTURES of Objects, while suppressing their Templates and the code of their Methods.

This allows the Game Programmer absolute freedom with respect to GameEngine resources, its AS IF all that code and objects was embedded in the EXE, this is a really great outcome.

In solving the problem, ObjAsm32's Objects.inc file was slightly modified... I expect he's already made the file available via OA32's Smart Updater service.

Now I have very clean separation of the 'Engine Core' (DLL) and the 'Game Logic' (EXE), with no bloat in the exe due to having eliminated all duplication of object resources... perfect!

Posted on 2009-10-10 23:17:46 by Homer

I've been shovelling non-crritical 'democode' from GameEngine's core (DLL) into the demo executable, so that the Engine itself contains no irrelevant garbage, yet the existing demo executes as it did before.
That sounds pretty straightforward, right?
Well, it turned out to be quite some undertaking!
Especially given that I decided, at some point, to implement D3D_Audio support, which involved implementing an optional Derived camera to support 3D Audio.
The result is that I have made a complete mess of BOTH projects, however I am nonetheless on track.
That aside, saying that the two projects are in a state of flux would be a gross understatement!
Posted on 2009-10-14 07:23:07 by Homer
I have extended GameEngine's Launch function.

1) The Game Developer can now request that 3D Audio be used (if available) via a BOOLEAN parameter.
This involves the engine choosing whether to use D3D_Camera, or the derived D3D_Camera2 (the latter supports 3D Audio listener). If the local hardware does not support 3D Audio, then 2D Audio is used.
Audio support is courtesy of D3D_Audio, a class I wrote and tested a while ago, which supports cool things like streaming sounds from wav/mp3 files (sounds that are one second or less do not require streaming, but only wav is supported, for obvious reasons).

2) GameEngine no longer provides a Player object internally to represent the local human playing the game.. It is now required that the Game Developer provide GameEngine with a pointer to a Player object (or class template) which is derived from GE_Player. This allows the developer to extend the player class in whatever ways they wish, something I think is going to be pretty important and desirable.

The entire codebase is still in one hell of a mess, however slowly it is beginning to resemble a workable framework, and I think the pain I am going through will yield legitimate benefits for the Game Developer who chooses to use GameEngine.




Posted on 2009-10-15 03:21:24 by Homer
I've got the engine core (dll) built again.
I estimate that is 30 percent of the work required to bring the entire project back to stability.
Now I need to get the game client (exe) to build, and then I expect a few problems to arise.
I still feel that this has all been worth the trouble.

There was a new method added to D3D_Camera which supports 'chase mode' for third person views.
Its job is to manipulate the camera Position in order to keep the subject in the center of the view at some given Distance, while maintaining the current viewing angle.
This code snippet was developed for GameEngine, however I felt it really belongs in D3D_Camera class, which does support attaching of cameras to arbitrary objects, but did not respect any particular viewing direction.
Posted on 2009-10-16 23:57:24 by Homer
I've got the game exe to build again, which required a minor change to D3D_Audio class.
The demo is not working, which was expected.
Tomorrow I will investigate why, hopefully the only reason is that I haven't adjusted the Launcher Stub code to account for the extended parameters .. the caller needs to provide GameEngine with a (possibly derived) GE_Player object. This may change again, as it would seem to make more sense to provide simply a pointer to the player class template, so that GameEngine can create player instances as required, possibly throwing events to the Game's eventsink when a new instance needs initializing.

I can hardly believe how much I use OOP these days.

I am tossing around the idea of wrapping GameEngine's classes as VB-friendly dual dispatch interfaces.
That sounds crazy, right? The fact is that there's a lot of VB programmers who would absolutely love to write games, don't want to learn DarkBasic, and would like to write them on top of a nice fast engine with its own physics simulator built right in, I would have an instant fan-base for viral advertising :P


Posted on 2009-10-17 11:01:40 by Homer
today is officially a no coding day, marking it on next years calendar
Posted on 2009-10-19 07:50:07 by Homer
What's the special occasion Homer? :)
Posted on 2009-10-20 05:31:34 by rags
I have baby french rabbits, and celebrated with a nice pinot.
Posted on 2009-10-20 07:29:39 by Homer
Making some difficult design decisions.
I thought one day of ponderance would be enough, but its a rather big deal.
The problem is that my GE_Player class needs to be exposed to the EXE in order to allow the game developer to derive their own class from it - but it currently is itself derived from CollisionBodyInstance, and contains an embedded SkinMeshInstance - which is not a suitable arrangement, as I would need to implement all the code for all three classes, duplicating the code and templates in both the engine and the client.
Not acceptable !!

Several solutions exist, it is a matter of choosing the solution which best suits my needs, and that requires considerable consideration :P
Posted on 2009-10-20 08:17:42 by Homer
Wouldn't an 'interface' be the more standard OO approach for allowing users to create custom functionality that works within the bounds of your framework/engine?

I would think the user would want to interface with your engine rather than extend it. But semantics aside, having your GE_Player class as an instance variable/field of my custom player-like class seems like a totally reasonable use case. But my mindset may be too denormalized.

This thread is very interesting ... please continue.
Posted on 2009-10-20 14:53:01 by r22
I do use 'interfaces' - C++ compatible ones.
The issue is that I need to expose an object class (GE_Player) which has dependencies, and I really don't want my closed sourcecode ending up in the binary exe - the solution I have chosen is to make those dependancies 'satellites' of the object - the player class will provide pointers to those, which will be initialized and destroyed from within the Engine (which lives in a DLL). This way only minimal code is exposed inside the EXE.
I know that no serious hacker would have trouble following the pointers and identifying the templates and code inside the DLL, its really more about avoiding duplication of code and templates than it is about security.
And its only really a buildtime problem, as I can pretty much do what I want at runtime.
You could say that the problem is that I have code in two separate binaries which are not aware of each others content, just the structures underlying some of the interfaces, no pointers and no code are available at buildtime which causes the linker to whine a lot ..
I've spoken at some length to Biterider about this particular dilemma, and he has stated that there are a couple of possible workarounds to enable our OOP model to handle this situation more gracefully.
I have a habit of doing things that were never really considered before, and every time I do, our model becomes more functional.

Posted on 2009-10-21 02:10:55 by Homer
I'm about half way through implementing changes that I expected to take only a few minutes, now its been two days. Basically I am just feeling lazy, and this project has no timeline (let alone deadline), so I am not inclined to rush ahead.
I've modified the GE_Player class to use satellite objects as mentioned.
Now I need to implement (fully) the GE_Player class in the Game EXE project.
And it's time to start thinking about a GE_AI class which MAY derive from GE_Player, and which implements Neural Network to present a genuine AI which learns from its environment and 'gets smarter' in response to input.
Finally, I need to start documenting the engine in great detail, which will probably take the form of a set of html pages, providing an online guide, also suitable for compiling to CHM format.
Posted on 2009-10-23 03:09:55 by Homer

Success building both projects :)

The problems I was having (with the VirtualObjects in the EXE project) appear to stem from my use of StaticMethods within dependant classes (such as D3D_SkinMeshInstance).
By changing the referenced methods to VirtualMethods, I was able to overcome all obstacles.
Methods which are to be referenced under a VirtualObjects scenario must be either VirtualMethod or DynamicAbstract... they cannot be Static, since this implies that pointers to the functions are generated at BuildTime instead of at runtime. That is NOT to say that StaticMethods cannot be present in such classes, only that StaticMethods cannot be referenced under a VirtualObjects scenario (IE, across separate binaries). If the code/binary to which we're trying to expose a VirtualObject doesn't explicitly call a particular method, it can be static.

I am yet to execute the new binary, I totally expect it to GPF... but thats ok.
Posted on 2009-10-23 20:47:22 by Homer
Yeah a few teething problems as predicted.
Fixing a few things, making appropriate changes.

GE_Player.Init was extended to take three new params:
-pBoundingMeshPath = ptr to String describing the D3D_Mesh to be used as an Imposter for collision-detection (and indirectly, for Mass calculation of Sphere hulls).
-Material Type = the ID of the physical material to be used by physics simulator (eg MATERIALID_MEAT)
-Hull Shape = the ID of the Shape to be used as the Collision Hull by physics simulator (eg SHAPEID_SPHERE)

Since it's the responsibility of the Game Developer (and not the Engine) to initialize their (derived) Player, they have the opportunity to declare these attributes.
Posted on 2009-10-23 22:25:41 by Homer
Pretty good progress - I am rendering 2D sprites and instances of 3D meshes and skinmeshes which were initialized by the Game client, via various Managers located within the Engine.
Basically, I have a working client, and a working engine, implementing everything that the early democode was doing, but with the engine being relatively unaware of what a particular game might expect of it.

Also, GE_Player's code is no longer duplicated across the two projects.
In the Client, pretty much everything is a VirtualObject, except for GE_Player, which is "fully-implemented".
And in the Engine, basically vice-versa...
So there is now ZERO duplication of class templates / method code across the two Binaries  8)
:thumbsup: Acceptable !! :thumbsup:

Posted on 2009-10-24 00:15:35 by Homer
I've started documenting my GameEngine Project:
http://asmcommunity.net/projects/homer-game-engine

It still doesn't have a name, got any suggestions?

BTW, there's seven little french bunnies.
Posted on 2009-10-26 03:59:19 by Homer
HIVE (HIgh VElocity) Engine.
Posted on 2009-10-26 11:40:45 by SpooK
Not a bad suggestion, since it does handle high velocity collision detection (swept tests).

Today I added a class to the Audio Engine, its a container to hold a set of 3D sounds that might be emitted by a particular entity, and is designed to be attached to that entity. This reinforces the pecularity of Streaming audio assets, that they are particularly unsuited to instancing from a reference asset ,ie, are "not shareable" in the traditional sense.




Posted on 2009-10-28 07:32:22 by Homer