1. orxEngine Wrapper Update

Hello all,

I have recently finished writing the bulk of the orxEngine functions (wrapping them). The only thing left to do is to wrap the physics functions and convert the inline functions to Euphoria code. One other step may be to convert the C structs(in orx) to Eu constants. Once the orxExecute function which is inline is correctly finished, a couple of demo programs will be able to be made. orxEngine currently uses a handful of structs/unions that can be converted using constants, although it might be better to wait until the memstruct feature is complete in Eu. Opinions and advice are welcome. Anyone that would like to help or contribute, please reach out here on this topic.


new topic     » topic index » view message » categorize

2. Re: orxEngine Wrapper Update

Do you sleep?


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

3. Re: orxEngine Wrapper Update

Icy_Viking said...

Opinions and advice are welcome. Anyone that would like to help or contribute, please reach out here on this topic.

Wow you've made quite a lot of progress! I'd still like to help out. How do you feel about organizing the functions into their corresponding include files?

For large libraries, I think it's helpful to maintain parity with the original library in the wrapper. So instead of one huge include orx.e we could break those files out to match the directories here.


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

4. Re: orxEngine Wrapper Update

public function orxLocale_SetString(sequence k,atom v) 
 atom str = allocate_string(k,1) 
 atom str2 = allocate_string(v,1) 
 return c_func(xorxLocale_SetString,{str,str2}) 
end function 

Either v is not really an atom but a string, or it should not be passed to allocate_string().
Ditto zs in orxResource_AddStorage()

There is also a compatibility issue with Phix (should you want that) for orx_Execute: [erm, I'm going to think about this a bit more]

--public procedure orx_Execute(atom _u32NbParams,sequence _azParams,sequence _zInit,sequence _zRun,sequence _zExit,integer _fnInit=routine_id(_zInit),integer _fnRun=routine_id(_zRun),integer _fnExit=routine_id(_zExit)) 
-- For Phix compatibility, instead of eg orx_Execute(?,?,"init","run","exit") it would need  
--                                       orx_Execute(?,?,orx_rid("init"),orx_rid("run"),orx_rid("exit")). 
global function orx_rid(string name, integer rid = routine_id(name)) return rid end function 
public procedure orx_Execute(atom _u32NbParams,sequence _azParams,integer _fnInit,integer _fnRun,integer _fnExit) 

Sorry about that, but that's just the way Phix is (it has a different way of resolving those sort of parameter defaults at compile-time).
[UGH, yeah, I know that's pretty horrible, and now I look at it you may as well just use routine_id() direct... Let me think about this.]
[The annoying this is, in a pure Phix world you could just code orx_Execute(?,?,init,run,exit), but that's not Euphoria-compatible]

Plus Phix does not like/permit ignoring results from (all in orx_Execute) orxDebug_Init(), orxEvent_AddHandler(), orxEvent_SetHandlerIDFlags(), orxEvent_Send(), and orxEvent_RemoveHandler().
Either they are not really funcs, or if they return an error code you should do or say something, which might just be quietly logging it.

Oh, and Phix does not permit enums above #3FFFFFFF (on 32 bit), which means it won't cope with orxENUM_NONE, orxDEBUG_LEVEL_ALL, or orxDEBUG_LEVEL_NONE in their current form.
It would be fine if those become constants, though for expediency (as I'm only doing a quick "does it compile?" test) I simply changed orxENUM_NONE to #3FFFFFFF.
Of course should that become a significant issue I could probably relax the rules for Phix enums a bit, hopefully sidestepping the predicted performance hit.
Currently Phix treats enums as type integer, and #FFFFFFFF or 4294967295 ain't an integer, or at least not the 32-bit Phix definition of an integer.

One last small thing (and similar in flags.e) which stops Phix including these, whereas Euphoria should completely ignore this change:

include std/machine.e 
include std/math.e 
include std/dll.e 
include std/os.e 

Looking forward to some demos I can test it with (on Phix).

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

5. Re: orxEngine Wrapper Update


Yes, lol. I just was able to spend a lot of time working orx.


Sure that is fine. I do need a little help with converting the orx structs into Eu constants and with some of the inline functions.


I wrote Orx with Euphoria in mind. However it is open source, so you free to edit so that it works on Phix. Also, thanks for the heads up on that function, I think I overlooked it when wrapping it. I'll go back and fix it.

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


Quick Links

User menu

Not signed in.

Misc Menu