RecastTimer.cpp change to build on Xbox360

[GoogleCodeExporter]

I found that if you change #include <windows.h> to #include <winbase.h> then 
RecastTimer.cpp will compile on Xbox360.

Original issue reported on code.google.com by armstron...@gmail.com on 15 Apr 2010 at 1:35

[GoogleCodeExporter]

Original comment by memono...@gmail.com on 7 May 2010 at 7:16

• Changed state: Accepted

[GoogleCodeExporter]

It might be an idea to change the timer code to be an abstract class much like 
you did 
for the duFileIO...that way you keep your core code free of platform specific 
issues. I 
found that the current implementation did not compile for PS3, obviously this 
issue 
would be eradicated by an abstract interface.

Original comment by armstron...@gmail.com on 7 May 2010 at 9:39

[GoogleCodeExporter]

I'm not big fan of abstract interfaces. Although the Log and Timer might could 
potentially go that route. Yet to 
update the winbase.h, as I have not booted to Win for quite some time.

Any hints what might work on PS3?

Original comment by memono...@gmail.com on 7 May 2010 at 9:45

[GoogleCodeExporter]

I think abstract interfaces are perfect for divorcing platform specific issues 
from 
your code...which is ideal when supplying a 3rd party library of code. An 
alternative 
would be to have a global (yuck) structure of function ptrs (callbacks) that 
the 
client fills out (a commercial AI system I've used did this).

Areas where the client needs control due to platform specifics:
- File IO
- Timers
- Rendering
- Memory Management

These are the only areas of Recast/Detour that I've had to intrusively modify. 
But, 
thankfully, you have supplied abstractions for FileIO and Rendering.

>>Any hints what might work on PS3?
I changed the Recast code to use timers in my companies cross platform engine. 
This 
does however make a rather nasty direct link between the two :( 

Looks like you need to include:
#include "sys/time_util.h"
#include "sys/sys_time.h"

Then:
sys_time_get_timebase_frequency(); // Gets you the number of timer ticks per 
second

And:
SYS_TIMEBASE_GET(t); // Gets you the current time in ticks - where "t" is a 
long long

Original comment by armstron...@gmail.com on 7 May 2010 at 10:18

[GoogleCodeExporter]

I'll add new issues for abstract timer and memory management.

Any pointers to libraries which handle custom memory management particularly 
well?

Original comment by memono...@gmail.com on 7 May 2010 at 11:32

[GoogleCodeExporter]

The only experience of have of another 3rd party AI library doing custom memory 
management, the lib expected the client to fill out a structure containing 
callbacks. 
They basically had callbacks for: malloc, realloc, free. Recast/Detour would 
need to 
use placement new. 

I *think* my preference would be for a memory management interface to be sent 
into 
any recast/detour functions that need to new/delete memory...at least then it's 
totally obvious to clients which functions have the potential to require memory 
management. It also give the client chance to setup their concrete memory 
management 
class in preparation (e.g. they could select a particular heap/memory-pool).

I will see if any of my colleagues have good suggestions...I haven't been 
involved in 
writing any of the company's memory management code, so there are better 
informed 
people ;)

Original comment by armstron...@gmail.com on 7 May 2010 at 2:20

[GoogleCodeExporter]

I have same problem. I know the simple tricks, but I have never really had to 
solve the problem so I'm not sure 
which way is better. What you suggest sounds fine, but since some people are 
finding the user interface 
cumbersome already that would add extra burden.

Original comment by memono...@gmail.com on 7 May 2010 at 6:09

[GoogleCodeExporter]

>>but since some people are finding the user interface cumbersome already that 
would 
add extra burden
I guess the default implementation of the memory management interface could 
just call 
standard malloc/free and you could use a default param on functions that need 
memory 
management. e.g.

void rcRecastFunctionThatAllocatesMemory( int param1, char param2, 
memoryManagement* mm 
= defaultMemoryManagement() );

Original comment by armstron...@gmail.com on 10 May 2010 at 10:12

[GoogleCodeExporter]

There is one thing I do not like about that. It allows you to shoot yourself in 
the foot big time if you forget to 
specify the allocator.

If I weight that against a global variable holding the mem manager interface, 
the global wins. 

Original comment by memono...@gmail.com on 10 May 2010 at 10:24

[GoogleCodeExporter]

Yeah - I'm not a big fan of default params...I was trying to think of ways to 
lessen 
the burden on programmers who find the interface "cumbersome" ;)

You're not suggesting that you have a global mem-manager variable in your lib 
are you? 
That might be bad for multi-threaded apps. I guess you're suggesting that 
clients 
potentially keep a global ptr to their own mem-manager?

Original comment by armstron...@gmail.com on 10 May 2010 at 11:37

[GoogleCodeExporter]

Actually I was thinking about having something like rcContext struct, which 
would
have pointer to log, timer, profiler and memory manager and which you would 
need to
pass to each of the functions.

Don't quite like that, thought. But then again, all the options I can think of 
are
ugly in a way or another.

Original comment by memono...@gmail.com on 10 May 2010 at 11:46

[GoogleCodeExporter]

The rcContext idea is very similar to another system that I've used. I guess it 
has the 
advantage of keeping all user defined things together in one neat package. Like 
you 
said, there's no really nice solution (isn't that always the way? :)

I'm happy with rcContext or separate interfaces per area of responsibility. 
Whatever 
you feel is best.

Original comment by armstron...@gmail.com on 10 May 2010 at 3:51

[GoogleCodeExporter]

Ok. I will probably go with it then. It'll break the API, but it will not 
change fundamentally how things are done.

Original comment by memono...@gmail.com on 10 May 2010 at 4:42

[GoogleCodeExporter]

Fixed in R197.

The rcBuildContext allows you to define your own timer. See 
SampleInterfaces.h/cpp for an example.

Original comment by memono...@gmail.com on 19 Aug 2010 at 9:29

• Changed state: Fixed