Re: [cadcdev-tiki] Thread::create weirdness

[Dan P. <ba...@al...>]

On Jun 05, Sam Steele wrote:

>    Since everything is running on top of OpenGL anyway (even on the DC,
>    through KGL) my vote is to go with OpenGL directly instead of plxcompat. 
>    I'm itching to use GL_QUADS in ConsoleText so it actually works on the DC
>    :)

There's a pretty good argument to be made that plx and KGL are about 90% the
same thing anyway. The plx calls just make things a little more compact for
stuff like setting a texture and color on each vert (and reduce the call
and memory write overhead a little bit). For any sort of optimized usage
where you absolutely have to have the speed, it's probably still no problem
to have a specialized DC vertex submitter. For 99% of the stuff out there
(you guys like how I pull these numbers out of my rear? :) there's probably
no real speed difference anyway. 20k polys/sec? 50k? 100k? 2M? Whatever...

So I feel sorta like this makes the most sense at this point:

- Convert all the internal plx usage to straight GL calls.
- Leave the plxcompat wrappers for non-DC platforms so that direct plx calls
  on a DC port will still compile on a PC for testing/debug.
- If you have the Need for Speed(tm), then use plx and get the advantage on
  the DC. Otherwise go straight GL.

After all even with the built-in Tiki drawables, one can always override
the draw method and make it use plx for optimization's sake.

Does that sound like a pretty OK plan?

Oh, and to not get completely off track from the original thread subject :)
I was thinking of making some place to put code shared among multiple
platforms. E.g. OSX, Linux, and DC can all make use of the pthreads impl
of the threading. OSX, Linux, and Win32 can all make use of the OpenAL impl
of audio and textures, etc. Any thoughts on a good dir tree structure for
that?