Re: orxEngine Wrapper Update
- Posted by petelomax Sep 03, 2021
- 752 views
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).
