[ODE] Re: ODE (and mainly OPCODE) for 64bits

Flavien Brebion f.brebion at vrcontext.com
Fri Jan 21 11:31:59 MST 2005

The "bad" one. I was running short on time and had to make the damn 
thing work, no matter
how :)

But honnestly i didn't care much about the memory usage. The application 
into which i've integrated
it requires Gigabytes of RAM anyway, so a bit more or a bit less... 
performance was more
important, but as i said it ended up being very acceptable.

Yeah it still compiles on 32 bits systems. It was a matter of redefining 
a new type ( with some
#defines depending on the OS ) and replacing pointers here and there by 
the new type. It's
a bit different than the "official" version though, since i applied a 
few other changes of my
own, namely support for saving / loading OPCODE's data structures to the 
disk ( to avoid
regenerating them on the fly each time ) and two-sided collisions for 
mesh vs capsules.

F. Brebion

Frederic Marmond wrote:

>thanks to share it! ;)
>What solution did you take:
>- the 'good' one (make a 32bit offset based on the real 64bit memory pointer)
>- the 'bad' one (change all ODE-pointers to 64bits)
>('good' and 'bad', according to the OPCODE goal, which was to take as less
>memory it can. I respect this obectif and I think it would be good to keep it
>on, even if for my particular purpose, memory size is not a problem)
>Does your code keep compil on 32bits system (is it portable?)
>Selon Flavien Brebion <f.brebion at vrcontext.com>:

More information about the ODE mailing list