You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(131) |
Dec
(20) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(4) |
Feb
(16) |
Mar
|
Apr
(15) |
May
(18) |
Jun
(25) |
Jul
(13) |
Aug
|
Sep
(3) |
Oct
|
Nov
(7) |
Dec
|
2007 |
Jan
|
Feb
(1) |
Mar
(4) |
Apr
(11) |
May
(1) |
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Dan P. <ba...@al...> - 2005-11-17 07:32:11
|
On Nov 16, 2005, at 7:52 PM, Sam Steele wrote: > logxymover.cpp: Replace "Tiki::Math::..." with a "using namespace > Tiki::Math" so it compiles against dc/fmath.h Might be a better way to do this to 'using' them into the proper namespace. Other places inside Tiki use these and could benefit from the speed boost. I think there are non-macro functions you could do this with. e.g. namespace Tiki { namespace Math { using ::fsin; } } and so on... Or does "namespace Tiki::Math {" work? I honestly never tried it :D |
From: Sam S. <sam...@gm...> - 2005-11-17 03:53:19
|
On Nov 16, 2005, at 8:42 PM, Dan Potter wrote: > I haven't had a chance to look at the code yet, but how do you guys > [plan > to] deal with the fact that a lot of the graphics primitives in > Tiki are > talking to GL? Just plumbing through KGL? It'll never be terribly high > performance that way but that's probably simplest. > Right now it's going through KGL, and it takes a pretty decent performance hit (bubbles demo runs at 15FPS). Actually, according to your notes in the KGL version of bubbles, 15FPS is about right for the non-direct render version. I checked 4 changes into SVN, basically to make sure my credentials were working: math.cpp / math.h : This will use dc/fmath.h on the Dreamcast logxymover.cpp: Replace "Tiki::Math::..." with a "using namespace Tiki::Math" so it compiles against dc/fmath.h thread.cpp / thread.h : Always uses Tiki::Thread::... when calling member functions to avoid conflicts with KOS's function names. This is just copied out of Mike's SDL / DC tree that he sent me earlier. texture.cpp : Dreamcast uses RGB565 and ARGB4444 for loading images instead of ARGB8888 I'm not going to check in my changes to gl.cpp yet -- I'd rather fix KGL than hack around its bugginess. My local copy changes glDepthFunc to GL_LEQUAL, which makes the bubbles demo work (though the bubbles get clipped weirdly, but at least they appear now!), and it also makes genmenu work when z=0. I actually took a look at the tsunami genmenu demo (I didn't realize there was one, I was working blindly), and I notice you're moving the genmenu scene out to z=10. I did that with my menus, and they do appear using GL_GREATER, but certain objects in my scene still don't show up (sometimes it's the text, sometimes it's a banner, depends on the scene.. grr!). -Sam |
From: Dan P. <ba...@al...> - 2005-11-17 01:50:30
|
On Nov 16, Sam Steele wrote: > Ok, I had to fight with it a bit to get it to build. The main issues are > conflicts between Tiki and KOS, for example dc/matrix.h breaks > plxcompat.cpp. It's amusing that Tiki was originally meant as a compatability layer for KOS apps on other OSes, and yet it's being ported back to KOS and running into compatability issues. :D The best thing we can do, where possible, is patch stuff back into the canonical sources, even if that means some #if's. So e.g. instead of having plxcompat, just include the appropriate plx headers. I haven't had a chance to look at the code yet, but how do you guys [plan to] deal with the fact that a lot of the graphics primitives in Tiki are talking to GL? Just plumbing through KGL? It'll never be terribly high performance that way but that's probably simplest. > Finally, I'm still getting > crashes when loading wav files -- "snd_mem_free: attempt to free > non-existant block at 00000000". I'll try to track that down too. That's probably indicative of the sound having not loaded properly to begin with. |
From: Sam S. <sam...@gm...> - 2005-11-17 00:48:10
|
Ok, I had to fight with it a bit to get it to build. The main issues are conflicts between Tiki and KOS, for example dc/matrix.h breaks plxcompat.cpp. On the original tree, I #if'ed the sections of plxcompat.cpp that conflict out, and I think that's why the bubbles demo didn't show anything (the wrong matrices are being updated). This time, I modified kos.h so it doesn't include dc/matrix.h and left plxcompat.cpp intact, and the bubbles demo works! Well, it runs pretty poorly, but at least it displays something :) I also had to pull over thread.cpp from your original tree, since you forgot to add those changes to the new tree. The changes I've made so far are to replace tikimath.h / math.cpp with dc/fmath.h, which makes the bubbles demo run much faster (though still not as fast as the original parallax version). I also merged in my changes to texture.cpp, and added a glKosFinishList() to Frame::transEnable(), which should really go into tiki_scene_begin_trans_hook() but it doesn't appear that's being called (yet). I also had to #if out some parts of Frame::begin() that use constants that aren't part of KGL. I'm now at the point where TikiBlap compiles and runs, however I'm still hitting a few quirks. I still can't get textures to display with KGLX, all my polygons are just white. However, if I use KGL textures work fine, but my genmenu objects (located at z=0) wont show up unless I flip the depth buffer, which causes the stacking order to be inconsistent between the two platforms (if I put something at z=0.1, is it on top of or below z=0.0?). I'll try to compare KGL and KGLX and see if I can either fix KGLX's textures or KGL's coordinate system. Finally, I'm still getting crashes when loading wav files -- "snd_mem_free: attempt to free non-existant block at 00000000". I'll try to track that down too. -Sam On Nov 16, 2005, at 4:19 PM, atani wrote: > > My testing of the DC port with the new SVN version has been very > limited. Thats why I call it an "initial port". There are a > number of areas that will need adjustments. > > Mike > > > Sam Steele wrote: >> I will update after work and test it out. Have you tried it on >> the DC yet? I was running into some crashes with loading wav >> files on the Dreamcast, but I haven't had a chance to track them >> down yet. Hopefully the updated Tiki will fix it. >> >> -Sam >> >> >> On 11/16/05, atani <at...@at...> wrote: >> I have pushed out the current SDL and DC ports to the SVN repos this >> morning. >> >> Mike > |
From: atani <at...@at...> - 2005-11-16 23:22:16
|
Dan Potter wrote: >This all sounds awesome to me. It was actually my original intention to >build a small windowing system on top of Tiki for debugging tools a while >back, but I never really got around to finishing it. > > Well, I am planning some basics, we can then expand as needed :) >For the HID thing, are you thinking along the lines of something that can >hook all of the HID output exclusively for some time? Might be cool to even >have a stack of handlers or something. > Basically yes. We could do this in a couple ways: 1) deregister processHidEvent and register new processModalHidEvent 2) have an if/else in the processHidEvent method. Option 1 would be the least impact to performance, but I will need to do a lot of testing to ensure it works properly. Also we will need to add duplicated code between the two event handlers, but this can be removed by handling a proper copy constructor on Hid::Event Mike |
From: Dan P. <ba...@al...> - 2005-11-16 21:22:15
|
On Nov 16, atani wrote: > I am thinking of adding support for "Modal" style dialogs in genmenu. > Basically today the processHidEvent method blindly passes the events on > down to the inputEvent method. In the case of a Modal dialog this would > need to be changed to pass them to a modalInputEvent() method, or it > could simply send the event directly to a "Modal" dialog class. > > What do you guys think? Would this be useful? > > > Also I am working on another update to the processHidEvent method which > will allow for "clickable" drawables. The method of use would be along > the lines of GUI buttons which can have a callback method. This all sounds awesome to me. It was actually my original intention to build a small windowing system on top of Tiki for debugging tools a while back, but I never really got around to finishing it. For the HID thing, are you thinking along the lines of something that can hook all of the HID output exclusively for some time? Might be cool to even have a stack of handlers or something. |
From: atani <at...@at...> - 2005-11-16 21:20:33
|
My testing of the DC port with the new SVN version has been very limited. Thats why I call it an "initial port". There are a number of areas that will need adjustments. Mike Sam Steele wrote: > I will update after work and test it out. Have you tried it on the DC > yet? I was running into some crashes with loading wav files on the > Dreamcast, but I haven't had a chance to track them down yet. > Hopefully the updated Tiki will fix it. > > -Sam > > > On 11/16/05, *atani* <at...@at... > <mailto:at...@at...>> wrote: > > I have pushed out the current SDL and DC ports to the SVN repos this > morning. > > Mike > |
From: atani <at...@at...> - 2005-11-16 21:19:13
|
I will start working on splitting out the openal stuff from the basic sound/stream classes. Mike Dan Potter wrote: > On Nov 16, 2005, at 7:15 AM, atani wrote: > >> I am thinking we might want to split out the OpenAL bit from the >> src/audio/* and put them into a sub package such as src/audio/ >> openal. The code in src/audio would then have hooks in it which are >> defined in the openal package, or in a kos package used by the DC >> port. This would eliminate the need to duplicate the sound.cpp and >> stream.cpp files into the dc tree. > > > Yeah. Originally I had something like that but since Tiki was only > going to be for OSX and Win32, I figured I could just switch it over > to OpenAL and save myself some trouble. :) Anyway, I'd be fine with > that. > |
From: atani <at...@at...> - 2005-11-16 21:17:54
|
I am thinking of adding support for "Modal" style dialogs in genmenu. Basically today the processHidEvent method blindly passes the events on down to the inputEvent method. In the case of a Modal dialog this would need to be changed to pass them to a modalInputEvent() method, or it could simply send the event directly to a "Modal" dialog class. What do you guys think? Would this be useful? Also I am working on another update to the processHidEvent method which will allow for "clickable" drawables. The method of use would be along the lines of GUI buttons which can have a callback method. Mike |
From: Sam S. <sam...@gm...> - 2005-11-16 16:58:55
|
I will update after work and test it out. Have you tried it on the DC yet? = I was running into some crashes with loading wav files on the Dreamcast, but = I haven't had a chance to track them down yet. Hopefully the updated Tiki wil= l fix it. -Sam On 11/16/05, atani <at...@at...> wrote: > > I have pushed out the current SDL and DC ports to the SVN repos this > morning. > > Mike > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=3D7628&alloc_id=3D16845&op=3Dclick > _______________________________________________ > cadcdev-tiki mailing list > cad...@li... > https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki > |
From: Dan P. <ba...@al...> - 2005-11-16 16:42:48
|
On Nov 16, 2005, at 7:15 AM, atani wrote: > I am thinking we might want to split out the OpenAL bit from the > src/audio/* and put them into a sub package such as src/audio/ > openal. The code in src/audio would then have hooks in it which > are defined in the openal package, or in a kos package used by the > DC port. This would eliminate the need to duplicate the sound.cpp > and stream.cpp files into the dc tree. Yeah. Originally I had something like that but since Tiki was only going to be for OSX and Win32, I figured I could just switch it over to OpenAL and save myself some trouble. :) Anyway, I'd be fine with that. |
From: atani <at...@at...> - 2005-11-16 15:16:26
|
I pushed out the current DC port to SVN this morning. If you can give it a shot, it should compile fine and hopefully run! For the DC port I have disabled usage of the OpenAL based backend for audio in favor of the older DC audio from KOS (checked into dc/src/audio) Dan, I am thinking we might want to split out the OpenAL bit from the src/audio/* and put them into a sub package such as src/audio/openal. The code in src/audio would then have hooks in it which are defined in the openal package, or in a kos package used by the DC port. This would eliminate the need to duplicate the sound.cpp and stream.cpp files into the dc tree. Mike Sam Steele wrote: > Mike, > > I'll add the keyboard and mouse this weekend, if not sooner. I was > going to wait until your DC / SDL branch got caught up with the SVN > tree before I continued working on Tiki, to make it easier to merge in. > > -Sam > > On Nov 15, 2005, at 6:26 PM, atani wrote: > >> Sam, >> Currently with the plathid.cpp you sent over only the DC >> Controllers are supported. Any plans for the Mouse or keyboard? >> >> Mike >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by the JBoss Inc. Get Certified Today >> Register for a JBoss Training Course. Free Certification Exam >> for All Training Attendees Through End of 2005. For more info visit: >> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click >> _______________________________________________ >> cadcdev-tiki mailing list >> cad...@li... >> https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki > > |
From: atani <at...@at...> - 2005-11-16 15:13:43
|
Hmm... I guess time to do some digging then... It is possible it is a compilation thing on my linux system. Mike Sam Steele wrote: > Works on the Mac using the OpenAL that ships with Tiger, as well as > whatever OpenAL lib Dan includes with Marbol for 10.3.x users. > > -Sam > > On Nov 15, 2005, at 6:18 PM, atani wrote: > >> Does it work? I am not getting any output when using the SDL >> backend in my testing... And this is with the OpenAL libs >> providing the audio bindings. >> >> Mike >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by the JBoss Inc. Get Certified Today >> Register for a JBoss Training Course. Free Certification Exam >> for All Training Attendees Through End of 2005. For more info visit: >> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click >> _______________________________________________ >> cadcdev-tiki mailing list >> cad...@li... >> https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki > > |
From: atani <at...@at...> - 2005-11-16 15:13:06
|
I have pushed out the current SDL and DC ports to the SVN repos this morning. Mike |
From: Sam S. <sam...@gm...> - 2005-11-16 01:25:24
|
On Nov 15, 2005, at 8:07 PM, Dan Potter wrote: > The OpenAL I include with Marbol is just a copy of the Tiger code > (IIRC) > recompiled against the Panther SDK, with an installation_path > appropriate > for bundling. It's used even on Tiger. > I might look into using that for DCBlap, instead of requiring people to have Tiger. > I just grabbed Xcode 2.2 the other day, been itching to give a shot at > their new multi-SDK friendly outputs (e.g. 10.3 for PPC, and 10.4u for > x86). Should finally be able to make some realistic universal > binaries with > that :) > Are there release notes or something that list all the changes in 2.2? The announcement on ADC was pretty vague. That sounds like a pretty useful feature, and I had no idea it was available :P -Sam |
From: Dan P. <ba...@al...> - 2005-11-16 01:15:23
|
On Nov 15, Sam Steele wrote: > Works on the Mac using the OpenAL that ships with Tiger, as well as > whatever OpenAL lib Dan includes with Marbol for 10.3.x users. The OpenAL I include with Marbol is just a copy of the Tiger code (IIRC) recompiled against the Panther SDK, with an installation_path appropriate for bundling. It's used even on Tiger. I just grabbed Xcode 2.2 the other day, been itching to give a shot at their new multi-SDK friendly outputs (e.g. 10.3 for PPC, and 10.4u for x86). Should finally be able to make some realistic universal binaries with that :) |
From: Sam S. <sam...@gm...> - 2005-11-16 00:49:19
|
Mike, I'll add the keyboard and mouse this weekend, if not sooner. I was going to wait until your DC / SDL branch got caught up with the SVN tree before I continued working on Tiki, to make it easier to merge in. -Sam On Nov 15, 2005, at 6:26 PM, atani wrote: > Sam, > Currently with the plathid.cpp you sent over only the DC > Controllers are supported. Any plans for the Mouse or keyboard? > > Mike > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > cadcdev-tiki mailing list > cad...@li... > https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki |
From: Sam S. <sam...@gm...> - 2005-11-16 00:49:17
|
Works on the Mac using the OpenAL that ships with Tiger, as well as whatever OpenAL lib Dan includes with Marbol for 10.3.x users. -Sam On Nov 15, 2005, at 6:18 PM, atani wrote: > Does it work? I am not getting any output when using the SDL > backend in my testing... And this is with the OpenAL libs > providing the audio bindings. > > Mike > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > cadcdev-tiki mailing list > cad...@li... > https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki |
From: atani <at...@at...> - 2005-11-15 23:27:52
|
Sam, Currently with the plathid.cpp you sent over only the DC Controllers are supported. Any plans for the Mouse or keyboard? Mike |
From: atani <at...@at...> - 2005-11-15 23:19:39
|
Does it work? I am not getting any output when using the SDL backend in my testing... And this is with the OpenAL libs providing the audio bindings. Mike |