From macdev-3dosx@acm.uiuc.edu Mon Mar 3 04:03:50 2003 From: macdev-3dosx@acm.uiuc.edu (James B. Tuley) Date: Sun, 2 Mar 2003 22:03:50 -0600 Subject: [3DOSX dev] Box growing code Message-ID: <2423ABEC-4D2D-11D7-8B4E-00039354202E@uiuc.edu> Added box growing code, but could be improved, also extended the OpenGL matrix stack for when you have ALOT of successive platters open. -Jay _________________________________________________ Jay Tuley ACM MacWarriors Chairman CS in Engineering http://www.acm.uiuc.edu/macwarriors tuley at acm.uiuc.edu University of Illinois From macdev-3dosx@acm.uiuc.edu Fri Mar 7 21:27:44 2003 From: macdev-3dosx@acm.uiuc.edu (James B. Tuley) Date: Fri, 7 Mar 2003 15:27:44 -0600 Subject: [3DOSX dev] Powerglove Message-ID: Okay tomorrows meeting we are going to put collective macwarriors power into getting the power glove to work on Mac OS X in some form. I'm not sure what the problem is with the glove not working with apples sample HID code, it may be because it has 2 hid interfaces or it may be because the interface we need is that of a bar code scanner. I think it can be over come, if anyone knows any thing about hid devices or apples hid manager please suggest something. -Jay _________________________________________________ Jay Tuley ACM MacWarriors Chieftain CS in Engineering http://www.acm.uiuc.edu/macwarriors tuley at acm.uiuc.edu University of Illinois From macdev-3dosx@acm.uiuc.edu Fri Mar 7 23:36:30 2003 From: macdev-3dosx@acm.uiuc.edu (Steven Bytnar) Date: Fri, 7 Mar 2003 17:36:30 -0600 Subject: [3DOSX dev] Powerglove In-Reply-To: References: Message-ID: <20030307233630.GE19916@openprojects> Here's some suggestions. Have you tried any other devices with the sample program yet? Maybe it's broken? You could pick up a Gravis Gamepad pretty cheap. It advertises sane descriptors. (I have one of these.) http://www.bestbuy.com/Detail.asp?m=1581&cat=1588&scat=&e=11008476 Make it work with a 'good' device. Then try making it work with a 'bad' device. Understand the example and verify it works, before beating yourself to death on figuring out why a bad example doesn't work. -------------- Which HID sample code are you using? I have a Gravis Gamepad I could check out with it. -------------- How many configuration descriptors does the device have? Hack up /Developer/Examples/IOKit/usb/USB SimpleSample so that it matches the p5 by changing the idVendor and idProduct listed in main(). (I'm assuming it has a unique vendor/product ID. These values can be found in ioreg or in USB Prober under MacOS 8/9.) Put a "return" after: printf("dealWithDevice: found %d configurations\n", numConf); in dealWithDevice(). Run the program. If there is more than one config descriptor, you should try changing the dealWithDevice's SetConfiguration() to use a different configuration and see if the other configs present more 'sane' HID descriptors. --Steve On Fri, Mar 07, 2003 at 03:27:44PM -0600, James B. Tuley wrote: > Okay tomorrows meeting we are going to put collective macwarriors power > into getting the power glove to work on Mac OS X in some form. I'm not > sure what the problem is with the glove not working with apples sample > HID code, it may be because it has 2 hid interfaces or it may be > because the interface we need is that of a bar code scanner. I think > it can be over come, if anyone knows any thing about hid devices or > apples hid manager please suggest something. > > -Jay > > > _________________________________________________ > Jay Tuley ACM MacWarriors Chieftain > CS in Engineering http://www.acm.uiuc.edu/macwarriors > tuley at acm.uiuc.edu University of Illinois > > > _______________________________________________ > MacDev-3DOSX mailing list > MacDev-3DOSX@acm.uiuc.edu > http://clortho.acm.uiuc.edu/mailman/listinfo/macdev-3dosx From macdev-3dosx@acm.uiuc.edu Sat Mar 8 03:18:00 2003 From: macdev-3dosx@acm.uiuc.edu (James B. Tuley) Date: Fri, 7 Mar 2003 21:18:00 -0600 Subject: [3DOSX dev] Powerglove In-Reply-To: <20030307233630.GE19916@openprojects> Message-ID: <912E024D-5114-11D7-9FE6-00039354202E@uiuc.edu> On Friday, March 7, 2003, at 05:36 PM, Steven Bytnar wrote: > Here's some suggestions. > > Have you tried any other devices with the sample program yet? > Maybe it's broken? > You could pick up a Gravis Gamepad pretty cheap. It advertises > sane descriptors. (I have one of these.) > http://www.bestbuy.com/Detail.asp?m=1581&cat=1588&scat=&e=11008476 > Make it work with a 'good' device. Then try making it work with > a 'bad' device. > Understand the example and verify it works, before beating yourself > to death on figuring out why a bad example doesn't work. > yeah i've got it to work with out any effort with my Cyborg Stick back in December, that's why i thought it'd be a breeze. -Jay From macdev-3dosx@acm.uiuc.edu Tue Mar 11 10:22:42 2003 From: macdev-3dosx@acm.uiuc.edu (James B. Tuley) Date: Tue, 11 Mar 2003 04:22:42 -0600 Subject: [3DOSX dev] font rendering Message-ID: <64FB9D70-53AB-11D7-B90B-00039354202E@uiuc.edu> kerning pretty--now in cvs -jay sleepy From macdev-3dosx@acm.uiuc.edu Tue Mar 11 23:43:50 2003 From: macdev-3dosx@acm.uiuc.edu (James B. Tuley) Date: Tue, 11 Mar 2003 17:43:50 -0600 Subject: [3DOSX dev] glPushMatrix in 3DOSX Message-ID: <4FB6500A-541B-11D7-B90B-00039354202E@uiuc.edu> do not use glPushMatrix() directly, call the method of the instance [theMatrixStack pushMatrix]; it's glPushMatrix() except it keeps track of number of calls so that it can preemptively take over before the opengl stack overflows with it's own stack that allows us to have really big platter trees. Do not comment out lines such as [theMatrixStack pushMatrix] or [theMatrixStack popMatrix], they work and most of the time its call the SAME glPushMatrix() glPopMatrix() you are replacing it with. By commenting out MatrixStack calls and replacing them with glPushMatrix() and glPopMatrix you are causing great instability in 3DOSX. that is all. _________________________________________________ Jay Tuley ACM MacWarriors Chairman CS in Engineering http://www.acm.uiuc.edu/macwarriors tuley at acm.uiuc.edu University of Illinois From macdev-3dosx@acm.uiuc.edu Tue Mar 18 00:02:49 2003 From: macdev-3dosx@acm.uiuc.edu (Robert Chin) Date: Mon, 17 Mar 2003 18:02:49 -0600 Subject: [3DOSX dev] Performance Issues In-Reply-To: <4FB6500A-541B-11D7-B90B-00039354202E@uiuc.edu> Message-ID: Okay, so I tracked down the performance issues we had at EOH yesterday to StringRenderer. If we don't render strings, apparently our program speeds up a good 500% or so, possibly even more. Part of the problem was that some debug development code was left in StringRenderer that caused the font cache to be rebuilt every time a string had to be rendered (which is why there was the exponential decrease in speed in relation to displayed icons). With the help of Jay, this debug code was removed, and performance increased significantly, although it is still not as fast as the old version, even if we changed back to the old StringRender code. So I also vectorized the code with altivec extensions (if you have a g4 and compile with --faltivec, it will use poseAsClass: to load the vector code), which also increases the speed to a degree. One of the things I'd like to do is to vectorize the parts of the program that are not going to change, using vector float rather than the Point3D datatype, so we can avoid the penalty of loading data into the vector registers. Still, StringRender is quite slow. One of the things that needs to happen is caching of kerning information for strings (perhaps as an NSArray in an NSDictionary object). Any other optimizations that you can come up with would be very beneficial, as the renderString: method is currently the bottleneck in the program. Let me know if you make any changes though, and I'll take care of updating StringRenderVec to match. That's all I have to say for now -- can someone with a fast graphics card pull the latest source and give some information on the speedup? Oh, and if anyone else wants to work on altivec stuff, or wants to compile an altivec version, running: fixPrecomps -force -all -precompFlags -faltivec will speed up the compiles (and slow down all compiles without -faltivec). You can then revert back to the old precomps when you're done: fixPrecomps -force -all Robert From macdev-3dosx@acm.uiuc.edu Tue Mar 18 00:05:17 2003 From: macdev-3dosx@acm.uiuc.edu (Robert Chin) Date: Mon, 17 Mar 2003 18:05:17 -0600 Subject: [3DOSX dev] Performance Issues In-Reply-To: Message-ID: <4D2D22E6-58D5-11D7-AD00-003065D643E6@uiuc.edu> Oh yeah, I've also temporarily disabled font rendering on non-current platters -- whoever tests this code, please let me know the speed difference with and without this adverse change. It's on line 201 of FileNode.m Robert From macdev-3dosx@acm.uiuc.edu Tue Mar 18 00:52:24 2003 From: macdev-3dosx@acm.uiuc.edu (Nicholas Riley) Date: Mon, 17 Mar 2003 18:52:24 -0600 Subject: [3DOSX dev] Performance Issues In-Reply-To: <4D2D22E6-58D5-11D7-AD00-003065D643E6@uiuc.edu> References: <4D2D22E6-58D5-11D7-AD00-003065D643E6@uiuc.edu> Message-ID: <20030318005223.GA1947328@uiuc.edu> On Mon, Mar 17, 2003 at 06:05:17PM -0600, Robert Chin wrote: > Oh yeah, I've also temporarily disabled font rendering on non-current > platters -- whoever tests this code, please let me know the speed > difference with and without this adverse change. It's on line 201 of > FileNode.m Sorry about this - I can pretty much take responsibility for the lousy performance of text rendering since I rewrote it. I tested with and without font rendering last Friday, and didn't empirically notice any speed differences - with the 3D stuff turned on, it was too slow to use on my PowerBook with or without text. -- =Nicholas Riley | Pablo Research Group, Department of Computer Science and Medical Scholars Program, University of Illinois at Urbana-Champaign From macdev-3dosx@acm.uiuc.edu Tue Mar 18 02:03:28 2003 From: macdev-3dosx@acm.uiuc.edu (James B. Tuley) Date: Mon, 17 Mar 2003 20:03:28 -0600 Subject: [3DOSX dev] Performance Issues In-Reply-To: Message-ID: On Monday, March 17, 2003, at 06:02 PM, Robert Chin wrote: > Okay, so I tracked down the performance issues we had at EOH yesterday > to StringRenderer. If we don't render strings, apparently our program > speeds up a good 500% or so, possibly even more. String Rendering has always been slow, it adds a lot more vertices to our geometry, but it didn't make 3dosx slow. Since we reverted to the EXACT original string rendering code that runs in the fast version of 3dosx, and and the new 3dosx is still slow, suggests that there was something added that's as slow as string render or connected to string renderer such that when they both runs it's slow, and without one it's fast. I was thinking that it was the 8-bit blending but when i removed it there was no perceivable change. I'm going to check out the fast version of 3dosx and add the new string rendering to test my theory. -Jay From macdev-3dosx@acm.uiuc.edu Tue Mar 18 05:19:01 2003 From: macdev-3dosx@acm.uiuc.edu (James B. Tuley) Date: Mon, 17 Mar 2003 23:19:01 -0600 Subject: [3DOSX dev] Performance Issues In-Reply-To: Message-ID: <214F395E-5901-11D7-9FAD-00039354202E@uiuc.edu> On Monday, March 17, 2003, at 08:03 PM, James B. Tuley wrote: > On Monday, March 17, 2003, at 06:02 PM, Robert Chin wrote: > >> Okay, so I tracked down the performance issues we had at EOH >> yesterday to StringRenderer. If we don't render strings, apparently >> our program speeds up a good 500% or so, possibly even more. > > String Rendering has always been slow, it adds a lot more vertices to > our geometry, but it didn't make 3dosx slow. Since we reverted to the > EXACT original string rendering code that runs in the fast version of > 3dosx, and and the new 3dosx is still slow, suggests that there was > something added that's as slow as string render or connected to string > renderer such that when they both runs it's slow, and without one > it's fast. I was thinking that it was the 8-bit blending but when i > removed it there was no perceivable change. I'm going to check out the > fast version of 3dosx and add the new string rendering to test my > theory. eh theory seems to be wrong, new string renderer did slow things down even without kerning, i suspect it was my moving glBegin and glEnd into the for loop. i don't know why the new code was still slow with old string renderer. -Jay From macdev-3dosx@acm.uiuc.edu Tue Mar 18 18:39:42 2003 From: macdev-3dosx@acm.uiuc.edu (Mark Flider) Date: Tue, 18 Mar 2003 12:39:42 -0600 (CST) Subject: [3DOSX dev] Performance Issues In-Reply-To: Message-ID: On Mon, 17 Mar 2003, James B. Tuley typed: > it's fast. I was thinking that it was the 8-bit blending but when i > removed it there was no perceivable change. I'm going to check out the > fast version of 3dosx and add the new string rendering to test my > theory. Actually, we're not using 8-bit blending anymore, for the icons at least. We reverted to the old style of stenciling by alpha value > 0.6. -- Mark Flider From macdev-3dosx@acm.uiuc.edu Tue Mar 18 19:08:51 2003 From: macdev-3dosx@acm.uiuc.edu (James B. Tuley) Date: Tue, 18 Mar 2003 13:08:51 -0600 Subject: [3DOSX dev] Performance Issues In-Reply-To: Message-ID: <0E325896-5975-11D7-9FAD-00039354202E@uiuc.edu> On Tuesday, March 18, 2003, at 12:39 PM, Mark Flider wrote: > Actually, we're not using 8-bit blending anymore, for the icons at > least. > We reverted to the old style of stenciling by alpha value > 0.6. it's not old style, there are actually nice shadows and the cd icons are semi transparent, i'm looking side by side. Jay From macdev-3dosx@acm.uiuc.edu Thu Mar 20 07:39:43 2003 From: macdev-3dosx@acm.uiuc.edu (Robert Chin) Date: Thu, 20 Mar 2003 01:39:43 -0600 Subject: [3DOSX dev] Performance Issues Axed In-Reply-To: <0E325896-5975-11D7-9FAD-00039354202E@uiuc.edu> Message-ID: <1DF22813-5AA7-11D7-AD00-003065D643E6@uiuc.edu> Alright, So I rewrote StringRender about three times today, and the fruit of my efforts can now be had in CVS. String renderer is at least 2.5 times faster when executing in non-altivec mode and "much faster" with altivec enabled. It crashes on Frank's machine for some reason, I'm not sure why. Anyway, can someone else try this out and see if it works properly? Textures are now only bound per file node and at the 256 texture page changes. Additionally, almost all of the calculations are now cached -- performance is improved on all files with the same display name. Yeah, so try it out. Next up on the list are timers for animations so that my threaded icon loading is actually worthwhile... Robert From macdev-3dosx@acm.uiuc.edu Thu Mar 20 14:51:58 2003 From: macdev-3dosx@acm.uiuc.edu (ellick m chan) Date: Thu, 20 Mar 2003 08:51:58 -0600 (CST) Subject: [3DOSX dev] Performance Issues Axed In-Reply-To: <1DF22813-5AA7-11D7-AD00-003065D643E6@uiuc.edu> Message-ID: On Thu, 20 Mar 2003, Robert Chin wrote: > So I rewrote StringRender about three times today, and the fruit of my > efforts can now be had in CVS. String renderer is at least 2.5 times > faster when executing in non-altivec mode and "much faster" with > altivec enabled. It crashes on Frank's machine for some reason, I'm not > sure why. Anyway, can someone else try this out and see if it works > properly? > I just compiled it. Seems much faster than the previous versions. Opening multiple "platters" is no longer a problem. I went down about 5 levels deep thru various directories with around 10 platters. No problems with performance at all. Good Job! -Ellick From macdev-3dosx@acm.uiuc.edu Thu Mar 20 16:56:25 2003 From: macdev-3dosx@acm.uiuc.edu (Robert Chin) Date: Thu, 20 Mar 2003 10:56:25 -0600 Subject: [3DOSX dev] Performance Issues Axed In-Reply-To: Message-ID: > I just compiled it. Seems much faster than the previous versions. > Opening > multiple "platters" is no longer a problem. I went down about 5 levels > deep thru various directories with around 10 platters. No problems with > performance at all. Good Job! Oh yeah, that's because I had disabled font rendering on the non-current platters. I forgot about that. I've just re-enabled that in filenode.m, can you check to see what the performance difference is? I know on my machine there's a moderate, but noticeable difference, so I think this should be an option in the prefs. Additionally, does anyone know what kind of overhead binding textures has? Would I get a significant performance boost if I only bound the US character set once per screen draw, and drew all of those characters in one chunk, as opposed to now where each filename gets drawn in one chunk? Robert