1. Possible Orx Game Engine Wrapper

Hello all,

I recently came across this game engine. Its called Orx. Its written in C, but can be used with CPlusplus. It has a portable architecture. I was wondering if I could get some feedback on how feasible it would be to make a wrapper in Eu for this game engine? I glanced over some code and it doesn't look like it would be too difficult, but I'd like to hear what others think.

https://github.com/orx/orx

new topic     » topic index » view message » categorize

2. Re: Possible Orx Game Engine Wrapper

That looks like a lot of work, but I find myself curiously excited by a complete game development system with eu as the code binding behind it.

I say go for it. See you in about 3 years.

Cheers

Chris

new topic     » goto parent     » topic index » view message » categorize

3. Re: Possible Orx Game Engine Wrapper

Icy_Viking said...

Hello all,

I recently came across this game engine. Its called Orx. Its written in C, but can be used with CPlusplus. It has a portable architecture. I was wondering if I could get some feedback on how feasible it would be to make a wrapper in Eu for this game engine? I glanced over some code and it doesn't look like it would be too difficult, but I'd like to hear what others think.

https://github.com/orx/orx

Two major hurdles I'm seeing here:

  • Calling convention: Most of the library functions are declared using the fastcall convention, which Euphoria isn't currently built to handle (we only support stdcall and cdecl). It's possible this might only be the case when compiling the library statically so that it's embedded into the resulting executable and the shared library might still be using stdcall or cdecl. I haven't dug through the code enough to tell yet. The good news is that all those different conventions only affect x86 and on x64 there's just "the x64 calling convention" so it should work fine if you stick to 64-bit Euphoria (which you should!).

  • Inline functions: Some functions of the library are declared inline which means they're always compiled directly into the executable and don't get exported (or even compiled into) the shared library. You could either unmark these as inline and rebuild the library or reconstruct them directly in Euphoria. Unfortunately the orx_Execute function is marked inline, and it's literally the first function you need to bootstrap a program.

-Greg

new topic     » goto parent     » topic index » view message » categorize

4. Re: Possible Orx Game Engine Wrapper

ghaberek said...
Icy_Viking said...

Hello all,

I recently came across this game engine. Its called Orx. Its written in C, but can be used with CPlusplus. It has a portable architecture. I was wondering if I could get some feedback on how feasible it would be to make a wrapper in Eu for this game engine? I glanced over some code and it doesn't look like it would be too difficult, but I'd like to hear what others think.

https://github.com/orx/orx

Two major hurdles I'm seeing here:

  • Calling convention: Most of the library functions are declared using the fastcall convention, which Euphoria isn't currently built to handle (we only support stdcall and cdecl). It's possible this might only be the case when compiling the library statically so that it's embedded into the resulting executable and the shared library might still be using stdcall or cdecl. I haven't dug through the code enough to tell yet. The good news is that all those different conventions only affect x86 and on x64 there's just "the x64 calling convention" so it should work fine if you stick to 64-bit Euphoria (which you should!).

  • Inline functions: Some functions of the library are declared inline which means they're always compiled directly into the executable and don't get exported (or even compiled into) the shared library. You could either unmark these as inline and rebuild the library or reconstruct them directly in Euphoria. Unfortunately the orx_Execute function is marked inline, and it's literally the first function you need to bootstrap a program.

-Greg

Thanks for your input Greg. It looks like wrapping that exexcute function might take a little bit of work. I might attempt to make a wrapper for this. I wish there was more game engines written in C.

EDIT: I notice that Orx_Debug is exported in the DLL. That function is called in Orx_Execute. However Orx_Execute is not exported as its an inline function as you've mentioned. Orx_Debug is the first function called inside of Orx_Execute.

new topic     » goto parent     » topic index » view message » categorize

5. Re: Possible Orx Game Engine Wrapper

Icy_Viking said...

I notice that Orx_Debug is exported in the DLL. That function is called in Orx_Execute. However Orx_Execute is not exported as its an inline function as you've mentioned. Orx_Debug is the first function called inside of Orx_Execute.

orx_Execute starts out like this:

static orxINLINE void orx_Execute(orxU32 _u32NbParams, orxSTRING _azParams[], const orxMODULE_INIT_FUNCTION _pfnInit, const orxMODULE_RUN_FUNCTION _pfnRun, const orxMODULE_EXIT_FUNCTION _pfnExit) 
{ 
  /* Inits the Debug System */ 
  orxDEBUG_INIT(); 
 
  /* Checks */ 
  orxASSERT(_u32NbParams > 0); 
  orxASSERT(_azParams != orxNULL); 
  orxASSERT(_pfnRun != orxNULL); 
 
  /* Registers main module */ 
  orxModule_Register(orxMODULE_ID_MAIN, "MAIN", orx_MainSetup, _pfnInit, _pfnExit); 

Those first few lines are all macros. Both are defined in orxDebug.h on lines 220 and 316, respectively. These should be wrapped as Euphoria routines with the appropriate ifdef statements to reconstruct the same behavior.

-Greg

new topic     » goto parent     » topic index » view message » categorize

6. Re: Possible Orx Game Engine Wrapper

Icy_Viking said...

I wish there was more game engines written in C.

I don't think it'd be technically difficult to write a Euphoria game engine. It'd just be logistically difficult like any other from-scratch game engine. You'd probably want to use SDL as the base and then build actual "engine" parts in Euphoria.

-Greg

new topic     » goto parent     » topic index » view message » categorize

7. Re: Possible Orx Game Engine Wrapper

I may attempt to wrap Orx. Or at least keep it in mind. The one nice thing about Orx is that it has physics built in. In the meaintime I'll probably stick to wrapping libraries.

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu