From macdev-3dosx@acm.uiuc.edu Sat Feb 1 04:46:24 2003 From: macdev-3dosx@acm.uiuc.edu (Mark Flider) Date: Fri, 31 Jan 2003 22:46:24 -0600 (CST) Subject: [3DOSX dev] Updates to CVS Message-ID: I committed some changes this morning that shoudl hopefully speed things up... I can't test it, though, since OpenGL Profiler won't display frame rates and/or crashes. Let me know how it goes. Oh, BTW, there's a define in the platters' methods file that is something like "ROTATE_SUBNODES" -- need to make this into a pref for people. -- Mark Flider mflider@uiuc.edu 217-417-4341 From macdev-3dosx@acm.uiuc.edu Sat Feb 1 17:18:58 2003 From: macdev-3dosx@acm.uiuc.edu (James B. Tuley) Date: Sat, 1 Feb 2003 11:18:58 -0600 Subject: [3DOSX dev] Updates to CVS In-Reply-To: Message-ID: <3FF36430-3609-11D7-9677-00039354202E@uiuc.edu> Cool, i'll make the pref, are the display issues that were there yesterday fixed? On Friday, January 31, 2003, at 10:46 PM, Mark Flider wrote: > I committed some changes this morning that shoudl hopefully speed > things > up... I can't test it, though, since OpenGL Profiler won't display > frame > rates and/or crashes. > > Let me know how it goes. Oh, BTW, there's a define in the platters' > methods file that is something like "ROTATE_SUBNODES" -- need to make > this > into a pref for people. > > -- Mark Flider > mflider@uiuc.edu > 217-417-4341 > > > _______________________________________________ > MacDev-3DOSX mailing list > MacDev-3DOSX@acm.uiuc.edu > http://clortho.acm.uiuc.edu/mailman/listinfo/macdev-3dosx > From macdev-3dosx@acm.uiuc.edu Tue Feb 4 06:24:49 2003 From: macdev-3dosx@acm.uiuc.edu (Robert Chin) Date: Tue, 4 Feb 2003 00:24:49 -0600 Subject: [3DOSX dev] Multithreading and 3DOSX Message-ID: <5CC21149-3809-11D7-B149-003065D643E6@uiuc.edu> Alright, so I've been thinking about threading the GL and other code stuff, and I see two possible ways of handling this: 1) We keep shared instances of objects across two threads, and use NSLock to synchronize between the threads. The OpenGL calls and functional code are separated into different methods, and we use NSLock to make sure that only one thread at a time sends a message to an object. 2) We create new OpenGL objects for FileElement3D objects, one OpenGL object for each FileNode/PlatterNode and each other object that currently has OpenGL calls has a new object that is directly related to it, but contains only GL code, the parent object would contain only functional other code, and we would use distributed objects to talk between these two objects, since the GL stuff would be running in one thread and the functional code in another. I guess the first option is a lot easier to implement for the way the code is currently structured, but seems a lot more messy. More importantly, it violates the whole idea of encapsulation and message passing in ObjC. The second option seems like a more object oriented approach to things, but will require a larger rewrite of a lot of code. is there another way to structure the code to make 3DOSX more conducive to multiple threads that I can't think of? One that uses message queueing instead of NSLock, and continues to keep the code in its somewhat organized way that it is now? Robert From macdev-3dosx@acm.uiuc.edu Mon Feb 24 04:27:20 2003 From: macdev-3dosx@acm.uiuc.edu (Mark Flider) Date: Sun, 23 Feb 2003 22:27:20 -0600 Subject: [3DOSX dev] Billboarding is in Message-ID: <43DC359A-47B0-11D7-8C6C-003065A0FD90@uiuc.edu> OK, I just committed the code that does global billboarding, and fixed the feature/bug of text coloring. Can we try to clean up the build warnings? There seem to be a lot with methods not being recognized by certain objects, and NSProtocol errors. Danke. -- Mark Flider mflider@uiuc.edu 217-417-4341 From macdev-3dosx@acm.uiuc.edu Wed Feb 26 00:02:02 2003 From: macdev-3dosx@acm.uiuc.edu (Robert Chin) Date: Tue, 25 Feb 2003 18:02:02 -0600 Subject: [3DOSX dev] Please recheck out code from main branch In-Reply-To: <43DC359A-47B0-11D7-8C6C-003065A0FD90@uiuc.edu> Message-ID: <88894C76-491D-11D7-AA29-003065D643E6@uiuc.edu> I've just merged Development_1-3 into the main tree since we've been having so many cvs problems as of late. Please recheck out the code or whatever, you won't need a tag now. Although if we do work on a GNUstep version, we might want a tag for a GNUstep branch if cross platform compatibility becomes a problem. Robert From macdev-3dosx@acm.uiuc.edu Wed Feb 26 02:24:38 2003 From: macdev-3dosx@acm.uiuc.edu (Robert Chin) Date: Tue, 25 Feb 2003 20:24:38 -0600 Subject: [3DOSX dev] Removed commented code and warnings. In-Reply-To: <88894C76-491D-11D7-AA29-003065D643E6@uiuc.edu> Message-ID: <747A99CD-4931-11D7-AA29-003065D643E6@uiuc.edu> I've just removed all the compile time warnings and deleted all commented out code. This includes commented out NSLog stuff that was not enclosed in #ifdef __DEBUG__ directives like it should have been. Not that you'll miss the code that's been commented out for the last six months... Oh yeah, try to keep the code compiling without warnings by doing a clean build before checkin, please. Robert From macdev-3dosx@acm.uiuc.edu Thu Feb 27 00:14:18 2003 From: macdev-3dosx@acm.uiuc.edu (James B. Tuley) Date: Wed, 26 Feb 2003 18:14:18 -0600 Subject: [3DOSX dev] Unicode String Render Message-ID: <6962DAE7-49E8-11D7-864E-00039354202E@uiuc.edu> We now have unicode filename support, i'm still working on refining it, kerning seems to be a problem to overcome still. Update from cvs, try it out, see if it can't render something, beware though if you try to use every unicode character at once you better have more than 64 megs of VRAM. -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 Thu Feb 27 05:43:55 2003 From: macdev-3dosx@acm.uiuc.edu (Mark Levin) Date: Wed, 26 Feb 2003 23:43:55 -0600 Subject: [3DOSX dev] Unicode String Render In-Reply-To: <6962DAE7-49E8-11D7-864E-00039354202E@uiuc.edu> Message-ID: <75926526-4A16-11D7-BD44-0003937F901E@mac.com> On Wednesday, February 26, 2003, at 06:14 PM, James B. Tuley wrote: > We now have unicode filename support, i'm still working on refining > it, kerning seems to be a problem to overcome still. Update from cvs, > try it out, see if it can't render something, beware though if you try > to use every unicode character at once you better have more than 64 > megs of VRAM. It might be better to switch it over to the method we initially discussed way back when (before I short-circuited the debate by writing the current renderer), where we draw strings into temporary buffers and make textures out of them. Jaguar added a method that creates a GL texture from an NSView, which would make easier than it was at the time. --Mark "Verbing wierds language." Random acts of programming: http://homepage.mac.com/haveblue From macdev-3dosx@acm.uiuc.edu Thu Feb 27 05:13:43 2003 From: macdev-3dosx@acm.uiuc.edu (James B. Tuley) Date: Wed, 26 Feb 2003 23:13:43 -0600 Subject: [3DOSX dev] Unicode String Render In-Reply-To: <75926526-4A16-11D7-BD44-0003937F901E@mac.com> Message-ID: <3DB6A4C8-4A12-11D7-864E-00039354202E@uiuc.edu> On Wednesday, February 26, 2003, at 11:43 PM, Mark Levin wrote: > > On Wednesday, February 26, 2003, at 06:14 PM, James B. Tuley wrote: > >> We now have unicode filename support, i'm still working on refining >> it, kerning seems to be a problem to overcome still. Update from cvs, >> try it out, see if it can't render something, beware though if you >> try to use every unicode character at once you better have more than >> 64 megs of VRAM. > > It might be better to switch it over to the method we initially > discussed way back when (before I short-circuited the debate by > writing the current renderer), where we draw strings into temporary > buffers and make textures out of them. Jaguar added a method that > creates a GL texture from an NSView, which would make easier than it > was at the time. Well rendering characters seems to be okay, i think the kerning issue can be resolved, even then i don't think that it was ease which was the problem, but that rendering into a texture is still very expensive, that's why i cached all the fonts created by the new string render to disk, it takes way to long to do every time you start up. (and that's only 256 characters at a time) -Jay