Hadron Game Engine

[pstudio]

Hmm,

so you've dropped the OOP in HGE and made it entirely procedural. Honestly I'm not sure how I feel about that.
I suppose it may have to do with making language bindings more easily?

About the roadmap. My oppinion is that you should focus on making documentation and examples before adding new features. It may not be the most interesting thing to do, but I think HGE will benefit from it in the end.

[Hadron Games]

@pstudio
The way you access the majority of the API is procedural while the stuff that benefits more from OOP remains OOP. There is a thin OOP layer (THGEObject, THGEObjectList, THGEActor, etc) for object management. Yes, the current changes where needed for making language bindings easier. The HGE.pas and HGE.cpp are currently in sync which was a HUGE and important step. You can access the OOP layer from C++ the same way you do from Object Pascal.

Your existing code changes would consist of:[*]Changing PG.xxx.xxx to HGE_xxx_xxx[*]Changing TPGxxx to THGExxx[*]Only have to include the one HGE unit[*]No memory management to worry with.[*]Works with both Ansi and Unicode versions of Delphi

If there are a lot of requests for full OOP like before then the rest of API can still be wrapped. At this point the areas that most benefit from being OOP are already coded/wrapped.

The order of the current roadmap is pretty much the order that I plan to follow which has docs and example at the very top so your concerns should be covered there.

Thanks BTW for posting your concerns and views. Please keep them coming. The more I know the more I can tailor it to be a better product. Thanks to everyone who has dropped in so far. Keep it coming.

[paul_nicholls]

Hi Jarrod, I've downloaded HGE and will give it a try ASAP

cheers,
Paul

[Hadron Games]

@paul_nicholls
Coolness. Thanks.

Gonna start working on the docs.

[paul_nicholls]

Hi Jarrod,
I DID notice that in the HGE.pas file, there seems to be quite a few of the flattened classes that have a ..._Create() or I guess equivalent _Open routine which returns the Integer equivalent of that object instance, but don't seem to have an equivalent destroy routine to free them afterwards when you are finished with them.

Would we just use the generic "HGE_Object_Destroy" method on those?

There also seems to be a generic HGE_Stream_Close routine too, I guess this would work on all HGE stream 'classes'?

Unless I am missing something? LOL

cheers,
Paul

[Colin]

Hi Hadron - website works just fine now, btw i use latest opera with default opera theme.

[Hadron Games]

@paul_nicholls
You are correct. The whole game engine is OOP on the back end and those returned integer values are actual instantiated classes. Since all classes are derived from a common base class (THGEObject) every instance can be safely destroyed using HGE_Object_Destroy unless otherwise stated. The same with the stream routines, they are polymorphic so all stream routine can be closed with HGE_Stream_Close. I was able to save on the export count by returning an instance on first use for some of the routines. If a routine does not have a _Create export then most likely one of the other routines (_Open, _Alloc, etc) will return a qualified instance on first use.

More work up front but this should allow any modern programming language that supports binding to 32bit DLLs to work safely. One would only have to code the OOP layer (if it supports OOP) in the native language. Since this OOP layer is thin, it should not get in the way of your coding style and you should be able to build on top using it as a foundation. Or, you can completely build your own OOP layer on top of the procedural API. Again, giving you a choice and complete control.

@Colin
Wonderful, glad to know. Thanks for verifying.

[paul_nicholls]

@paul_nicholls
You are correct. The whole game engine is OOP on the back end and those returned integer values are actual instantiated classes. Since all classes are derived from a common base class (THGEObject) every instance can be safely destroyed using HGE_Object_Destroy unless otherwise stated. The same with the stream routines, they are polymorphic so all stream routine can be closed with HGE_Stream_Close. I was able to save on the export count by returning an instance on first use for some of the routines. If a routine does not have a _Create export then most likely one of the other routines (_Open, _Alloc, etc) will return a qualified instance on first use.

More work up front but this should allow any modern programming language that supports binding to 32bit DLLs to work safely. One would only have to code the OOP layer (if it supports OOP) in the native language. Since this OOP layer is thin, it should not get in the way of your coding style and you should be able to build on top using it as a foundation. Or, you can completely build your own OOP layer on top of the procedural API. Again, giving you a choice and complete control.

@Colin
Wonderful, glad to know. Thanks for verifying.

@Jarrod
Cool, thanks chief
BTW, I was able to compile and run the HGE lazarus examples just fine for your information
I hadn't tried the Delphi versions yet...

cheers,
Paul

[Hadron Games]

@paul_nicholls
Thanks. HGE should work fine with D5 (the lowest version I tested with) and up. Any issues let me know asap.

[paul_nicholls]

@paul_nicholls
Thanks. HGE should work fine with D5 (the lowest version I tested with) and up. Any issues let me know asap.

hmm....I can't get the Delphi version of the TestBed to compile using Delphi 6 Enterprise here at work or at home

It is this project I have loaded:

HGE\1.0\examples\pascal\Delphi\pasTestbed.dpr

When I compile, I get an internal fatal error:

[Fatal Error] Internal error: L594

Is this the correct version for Delphi to load, or have I tried the wrong project?

cheers,
Paul