cadcdev-tiki

[cadcdev-tiki] Thread::create weirdness

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

Is there some reason for this, or can we get rid of it now?

#if TIKI_PLAT == TIKI_DC
bool create(thread_t * hndout, void (*func)(void *), void * param);
#else
bool create(thread_t * hndout, void * (*func)(void *), void * param);
#endif

In the most modern KOSes pthreads are mostly available, so we should  
probably switch off to using them. If no one complains I'm going to  
make that change some time soon...

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

[Sam S. <sam...@gm...>]

I was actually going to look into fixing this, it needs to be the same on
all platforms, otherwise GCC on the DC complains when you create threads.  I
ran into that when I was working on the KOS streaming class.  If you fix it
(or if I do), I'll try to finish up the Stream class for the DC so we can
have working sound on there.

I'll also check in my old-school tone generator Stream class to go along
with ConsoleText so we can have hardcore oldschool fun!  It takes a
BASIC-ish string of notes and outputs them in a very PC-speakery way.  I'll
also add a method to play arbitrary frequencies for arbitrary durations, for
people that are into that sort of thing.

-Sam


On 6/2/06, Dan Potter <ba...@al...> wrote:
>
> Is there some reason for this, or can we get rid of it now?
>
> #if TIKI_PLAT == TIKI_DC
> bool create(thread_t * hndout, void (*func)(void *), void * param);
> #else
> bool create(thread_t * hndout, void * (*func)(void *), void * param);
> #endif
>
> In the most modern KOSes pthreads are mostly available, so we should
> probably switch off to using them. If no one complains I'm going to
> make that change some time soon...
>
>
>
> _______________________________________________
> cadcdev-tiki mailing list
> cad...@li...
> https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki
>

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

[Atani <at...@at...>]

On 6/2/2006, "Dan Potter" <ba...@al...> wrote:

>Is there some reason for this, or can we get rid of it now?
>
>#if TIKI_PLAT =3D=3D TIKI_DC
>bool create(thread_t * hndout, void (*func)(void *), void * param);
>#else
>bool create(thread_t * hndout, void * (*func)(void *), void * param);
>#endif
>
>In the most modern KOSes pthreads are mostly available, so we should
>probably switch off to using them. If no one complains I'm going to
>make that change some time soon...

The main reason for this was the KOS headers were declaring the return
type different then pthread (even in latest version from my last checks
sometime ago).

If you do remove it check that it still compiles cleanly against KOS, if
it does then I am all for the clean up.

Mike

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

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

On Jun 2, 2006, at 7:02 AM, Atani wrote:

> The main reason for this was the KOS headers were declaring the return
> type different then pthread (even in latest version from my last  
> checks
> sometime ago).
>
> If you do remove it check that it still compiles cleanly against  
> KOS, if
> it does then I am all for the clean up.

Yeah, it does seem to work fine now.

I'm trying to commit some stuff and SF is denying me. ;\ I guess I  
hadn't actually given myself SVN perms (whoops :). So when that  
finally works I'll check this in as well as a couple of other random  
things I ran into.

I've been working on a project for Dan Loosen with Tiki and I'm  
trying to get it ported over to the DC today. You guys have done some  
amazing work on this stuff... I think I only spent about an hour or  
two from start to playable on the DC.

There are a number of optimizations I'd like to make on the DC end  
eventually. One of the biggest is eliminating all the texture  
overhead. It'd be nice for it to internalize everything as RGB565 or  
ARGB1555/ARGB4444 for cases where a "canvas" texture isn't needed.

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

[atani <at...@at...>]

On Jun 2, 2006, at 2:55 PM, Dan Potter wrote:
> On Jun 2, 2006, at 7:02 AM, Atani wrote:
>>
>> If you do remove it check that it still compiles cleanly against
>> KOS, if
>> it does then I am all for the clean up.
>
> Yeah, it does seem to work fine now.

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

>
> I've been working on a project for Dan Loosen with Tiki and I'm
> trying to get it ported over to the DC today. You guys have done some
> amazing work on this stuff... I think I only spent about an hour or
> two from start to playable on the DC.

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?

> There are a number of optimizations I'd like to make on the DC end
> eventually. One of the biggest is eliminating all the texture
> overhead. It'd be nice for it to internalize everything as RGB565 or
> ARGB1555/ARGB4444 for cases where a "canvas" texture isn't needed.

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.

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.

Mike

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?

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

[Atani <at...@at...>]

On 6/5/2006, "Dan Potter" <ba...@al...> wrote:
>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 havent seen any information on this one yet...  But cool that you are
still working on DC stuff sometimes :)

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

Yeah it is nice that it just works :)
>
>Haven't hit audio at all yet.

Good luck with that, it still needs a bit of work in Tiki for anything
but OSX from my experiences so far :(

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

Sure, thats why I posted it here, see what people think of consolidating
the plx_* calls into a more Tiki like call, which can be platform
overriden (specifically DC)

>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?

Thats exactly what I was after :)

Mike

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

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

On Jun 06, Atani wrote:

> I havent seen any information on this one yet...  But cool that you are
> still working on DC stuff sometimes :)

Off and on.

http://www.cagames.com/phpBB2/viewtopic.php?t=579&start=25

> >Haven't hit audio at all yet.
> 
> Good luck with that, it still needs a bit of work in Tiki for anything
> but OSX from my experiences so far :(

So I've heard. I'll probably have to hit that up next.

> Sure, thats why I posted it here, see what people think of consolidating
> the plx_* calls into a more Tiki like call, which can be platform
> overriden (specifically DC)
...
> Thats exactly what I was after :)

Cool. I might look into doing that. It's a little bit wacky to have all that
indirection (plx emu -> Tiki prims -> plx real -> pvr ~:). On second though
what might be better is to just move everything over to GL calls and then if
you have something that really needs the speed, you can optimize it at the
app level for the DC. Which I think was the other thing you were suggesting.
:)

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

[Sam S. <sam...@gm...>]

On Jun 5, 2006, at 10:55 PM, Dan Potter wrote:

> Haven't hit audio at all yet.

I'm attaching my unfinished KOS stream patch if you want to take a  
look at it.  Stereo separation doesn't work (commented out), and the  
VorbisStream crashes when trying to pre-fill the buffers, but it's a  
start.  The mono sound from ZZTMusicStream seems to work, though.  I  
don't really know enough about what goes on under the hood in the KOS  
audio stuff to really get much further.

The declaration for the thread will need to be updated for the change  
you just checked in, this was written against the previous thread  
definition.

-Sam

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

[Sam S. <sam...@gm...>]

On 6/3/06, atani <at...@at...> wrote:
>
> 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.


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

-Sam

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?