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

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

On Jun 3, 2006, at 9:46 AM, atani wrote:

> Great!!!  That means that we can now have a single unified API  
> again :)

Yes :) I'll try to get that checked in soon.

Even if we hadn't gotten pthreads working, I probably would've  
changed it to have a shim function to provide a compatible interface.  
It just defeats the purpose of having the shared API if you have to  
ifdef a bunch of stuff.

> Great.  I had it mostly working when I committed the initial version
> but Sam did a lot of work on it further to make it actually
> usable...  Glad to hear that you had only minor issues to fix to make
> it playable on the DC.
>
> Any hints to what the project is?

It's one of the announced ones: Donk. I've been working on it under  
Tiki/OSX for the most part, and just ported it over to the DC. The  
biggest problem I had actually was the lack of frame rate throttling  
(I had it running at 30fps on OSX). Doesn't matter so much in the  
long run since I'm planning to fix it so it runs at 60fps. It's very  
old code and has some issues with animation vs frame rates.

I was actually kinda surprised at first that the hodge-podge all  
worked. :D I mean we've got Tiki, running on top of KGL, running on  
top of the PVR functions, with a messy mix of Newlib/pthreads and  
other junk thrown in there. Yet it all pretty much compiled and  
worked right off the bat. The biggest problem I had was that I was  
double-initializing the PVR stuff to get a different mix of buffers,  
and that I was submitting verts outside of the Frame::begin/end  
calls. Once those were resolved I had perfectly working video. I had  
to resolve an issue with Time::sleep(0) hanging forever under KOS as  
well, but after that the input worked as well.

Haven't hit audio at all yet.

> Currently the DC Tiki stuff is kinda like that red-headed stepchild
> compared to the "PC" ports.  I know there are a lot of optimizations
> we can do for each platform but I think there are a few areas which
> may need some more abstraction (Tiki::GL::Texture for example) where
> each port maintains its own "optimized" version.

Right... Texture is probably a good candidate for such a thing. The  
GL implementations can pretty much all share a Texture class, but the  
DC e.g. really needs a custom one with a bunch of code ripped from  
Tsunami.

It really seriously needs improvement for Donk too, because of the  
way I've been accelerating it. Donk has a bunch of discrete sprites  
that used to be drawn by just blitting them to an off-screen buffer.  
I changed it so that it calls down into an accelerated blit, which  
caches the target sprite into a texture and then submits verts for  
it. Works nicely but it sure eats up RAM and time with all the  
texture data shuffling.

> Another area which we can improve upon would be the plxcompat.
> Inside Tiki I think we should not use it, instead converting to a
> comparable Tiki method or to standard OpenGL calls.  If we do want to
> keep it we should make the DC port use the real parallax lib instead.

I would like to keep plxcompat personally. I have a *lot* of code  
that makes use of plx_* calls that I'd like to keep around. I think  
it's also nice because it's very raw (and on the DC, very fast) but  
still platform agnostic. We could rename the plx_* calls into Tiki  
calls somewhere, and then make plxcompat just aliases for those. On  
the DC it could all call down into parallax still. I think maybe  
that's what you were implying above, right?