Original date:2021-09-03 11:41:45 Edited by: petelomax Subject: 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.

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).

Not Categorized, Please Help


Quick Links

User menu

Not signed in.

Misc Menu