glgui-dev Mailing List for glGUI (Page 2)
Status: Alpha
Brought to you by:
druid-
Menu
▾
▴
glgui-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(11) |
May
(1) |
Jun
(21) |
Jul
(3) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(2) |
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(1) |
Nov
(13) |
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: sfranke <sf...@us...> - 2000-06-27 21:16:31
|
added a couple simple but cool classes: DraggableViewFrame DraggableFrame I'm very happy about how easily these were added. It tells me that I did at least one or two things right in the underlying design. You can select the active frame based on a string name, like selecting resources. The callback functions are much more robust and useful now. It's similar to win32 and glut, where you have a function that gets passed frameIDs when they have been clicked (or are being dragged). They have arbitrary parameters (based on the type of the frame) that are also passed back. I won't know how well all this really works until I (or someone else) implements something in a real (or semi-real) app. But I feel pretty good about it. I'm going to write a list box class now, and that is the last low-level frame I'm going to do. Then I start working on the controls which are higher level classes (though they inherit from CUI_Frame to get the base functionality they need) that automatically create and handle a number of frames below them. These are the controls I have planned right now: menubar popup menu chooser spinner toggle button radio button group textfield (one liner) console Any other suggestions? Or any input at all? Scott Franke [druid-] sf...@gl... |
|
From: sfranke <sf...@us...> - 2000-06-23 23:20:00
|
It's fixed (relatively) now. There are still some directories that should never have been there, but everything should be updated and buildable. I released another version/build with dynamic lib support (dll) and a few other fixes. See the readme. At some point I'll probably work on building this thing for Mesa in linux and putting up some Makefiles. Unless someone else wants to. Scott Franke [druid-] sf...@gl... |
|
From: sfranke <sf...@us...> - 2000-06-23 21:43:59
|
It's momentarily screwed up. I'm trying to import the new dll code, which requires a restructuring of the directories. Due to my inexperience with CVS, I have made all sorts of problems. I'm working on fixing those and updating the correct structure and files now. Hopefully it won't take too long, but I thought I should let everyone know in case anyone is trying to do anything Scott Franke [druid-] sf...@gl... |
|
From: sfranke <sf...@us...> - 2000-06-21 14:34:02
|
On Tue, 20 Jun 2000, SiO2 Software wrote: > > I did some profiling, and most of the time now is spent in STL. Whether > > this would be an issue in a real app is questionable (it's rendering 70+ > > fps (refresh locked on a geforce2), so it has to do a lot of traversal > > through lists, etc). > The trouble is that syncing to refresh nullifies any benchmarks. Some > GeForce drivers will sync windowed apps, as well as the more usual > fullscreen apps. You mean some drivers will async windowed apps? Yeah, I should try that setting and see. But I think the tests I've done are still useful. Most of the work is done in STL, which tells me that there aren't any excessively unoptimized parts outside of that. It originally prompted me to optimize the text rendering significantly (using a texture-coordinate lookup table), so that has helped a lot. Anyway, i'm working on converting the project to a dynamic library now, and am running into the STL in a dll problem. Anyone know what I need to do to fix it? Scott Franke [druid-] sf...@gl... |
|
From: SiO2 S. <si...@ne...> - 2000-06-20 17:14:00
|
----- Original Message ----- From: "sfranke" <sf...@us...> To: <glg...@li...> Sent: Friday, June 16, 2000 3:21 PM Subject: [Glgui-dev] selection > I did some profiling, and most of the time now is spent in STL. Whether > this would be an issue in a real app is questionable (it's rendering 70+ > fps (refresh locked on a geforce2), so it has to do a lot of traversal > through lists, etc). The trouble is that syncing to refresh nullifies any benchmarks. Some GeForce drivers will sync windowed apps, as well as the more usual fullscreen apps. Regards, Keith Harrison SiO2 Software. ke...@ne... (personal) si...@ne... (work) |
|
From: sfranke <sf...@us...> - 2000-06-16 20:47:45
|
Editable text boxes are in. I just finished uploading the release. Check it out. Scott Franke [druid-] sf...@gl... |
|
From: sfranke <sf...@us...> - 2000-06-16 14:24:51
|
I fixed a few memory leaks yesterday and optimized text rendering significantly (on the UI side, not OpenGL yet). I did some profiling, and most of the time now is spent in STL. Whether this would be an issue in a real app is questionable (it's rendering 70+ fps (refresh locked on a geforce2), so it has to do a lot of traversal through lists, etc). I also added some support for navigating buttons with they keyboard (though not actually "clicking" on them yet). A few things I'm not happy about with how it is right now: * the rendering is bad. Need a better way to render the selected button. Right now it draws an outline with a slightly brighter version of it's shader, but that makes it variable for different buttons. * Ordering - it's completely dependent on the order in which the app creates the buttons. I guess this is OK. * Groups - right now everything under the active frame is in the same list, having groups would make it more intuitive (switch between groups with tab), but would require some extra work on the organization of the list in CUI_UI (keeping track of different groups). Any suggestions on these? Well, I said I'd make a zip release today, so I'd better get editable text boxes working. Scott Franke [druid-] sf...@gl... |
|
From: sfranke <sf...@us...> - 2000-06-15 18:37:55
|
On Thu, 15 Jun 2000, SiO2 Software wrote: > > Yup. Might be another day before I get to that. Do you have any ideas > > for a format? I was thinking a nice simple ascii format like quake3's > > shaders would be nice, especially until we have a resource editor. > Ascii, ascii, ascii. ;-) Heh. Yup, it should do fine for now. [zip distributions] > Most projects that I have seen produce weekly zip distributions. If you > could manage that then it would be nice. :) I still haven't installed WinCVS > yet... I just use the command line utilities. I tried a few months ago, but couldn't get wincvs working very well. I just do simple commands (checkout & commit), so it's no bother using the command line versions. Anyway, OK, I'll start releasing a weekly zip (or less if I don't add any significant features during a week). The first release will be tomorrow with everything in CVS, a VC6 project, a win32 binary w/ sample gfx, and the class documentation (mirroring what's on the glgui.sourceforge.net page). I'll probably get key interface (for switching around the active widgets), and an editable textbox by then as well. Scott Franke [druid-] sf...@gl... |
|
From: SiO2 S. <si...@ne...> - 2000-06-15 17:19:07
|
----- Original Message ----- From: "sfranke" <sf...@us...> To: <glg...@li...> Sent: Wednesday, June 14, 2000 9:35 PM Subject: Re: [Glgui-dev] abstract rendering & more > > Make sure you don't forget about "LoadFromMemory()" style functionality. For > > example, I may have some data in my own file format (e.g. a Quake3 pk3 - AKA > > zip - file), so I would want to load the data into memory myself and pass > > the data to the GUI handler as a pointer. > > Yup. Might be another day before I get to that. Do you have any ideas > for a format? I was thinking a nice simple ascii format like quake3's > shaders would be nice, especially until we have a resource editor. Ascii, ascii, ascii. ;-) > [sample implementation] > > I haven't looked at it yet. Have you put together another zip distribution > > yet? > > No, I would have to make a release everyday to keep up with all the stuff > I'm adding. I'm trying to aim at a fairly complete functionality level > before I make a full release. That will include multi-platform demos and > better documentation. Or maybe I could release another little sample just > for win32 with what's in CVS this weekend. Most projects that I have seen produce weekly zip distributions. If you could manage that then it would be nice. :) I still haven't installed WinCVS yet... Regards, Keith Harrison SiO2 Software. ke...@ne... (personal) si...@ne... (work) |
|
From: sfranke <sf...@us...> - 2000-06-14 20:38:56
|
A quick note: I added viewable area to coordinate systems. This allows you to have a frame that is a window to a larger area. Fairly basic concept, but it took a considerable amount of rework on some of the class relationships. I also found a few big bugs. It's all working now, but I just have a simple demo, so there could still be problems. I'm using OpenGL's scissor function to restrict rendering. It requires some extra work to keep track of screen and local coordinates, but it's the best solution I could come up with. It only scissors frames that need it, so other frames are free (but should be expected not) to render outside of their [0,1] area. Now I'm going to write a textbox class for cleaner, more readable, multiline text chunks (non button/titles). and now to the reply: On Wed, 14 Jun 2000, SiO2 Software wrote: > Adding functionality if OK. What I was getting at was that developers don't > want the GUI to suck more CPU than neccessary. Hmm.. I'd have to test it in a real app before I could say for certain. Obviously the most complicated part is rendering (which I'm planning on optimizing at some point), but I think the core UI code is fairly efficient. There are parts that could probably be redone later to get more speed out of it. > Make sure you don't forget about "LoadFromMemory()" style functionality. For > example, I may have some data in my own file format (e.g. a Quake3 pk3 - AKA > zip - file), so I would want to load the data into memory myself and pass > the data to the GUI handler as a pointer. Yup. Might be another day before I get to that. Do you have any ideas for a format? I was thinking a nice simple ascii format like quake3's shaders would be nice, especially until we have a resource editor. [sample implementation] > I haven't looked at it yet. Have you put together another zip distribution > yet? No, I would have to make a release everyday to keep up with all the stuff I'm adding. I'm trying to aim at a fairly complete functionality level before I make a full release. That will include multi-platform demos and better documentation. Or maybe I could release another little sample just for win32 with what's in CVS this weekend. Scott Franke [druid-] sf...@gl... |
|
From: SiO2 S. <si...@ne...> - 2000-06-14 17:48:33
|
----- Original Message ----- From: "sfranke" <sf...@us...> To: <glg...@li...> Sent: Tuesday, June 13, 2000 3:44 PM Subject: Re: [Glgui-dev] abstract rendering & more > On Mon, 12 Jun 2000, SiO2 Software wrote: > [resource registry] > > Very nice, but please don't compromise speed. Us people who are going to use > > the UI will want to use it for our in-game HUD's too! ;-) > > Right now I'm just looking at using it to handle shaders, fonts, cursors, > coordinate systems and borders. So that it's easy to say, use the > "blue" shader. This will make it easier to define all the shaders in a > file somewhere and reference them. Adding functionality if OK. What I was getting at was that developers don't want the GUI to suck more CPU than neccessary. > I think I'll leave the actual frame/widget/etc creation as it is. Of > course it will be much smoother in a file loader, but I couldn't come up > with a good alternative. We can always work on it later if it's too much > of a problem. Make sure you don't forget about "LoadFromMemory()" style functionality. For example, I may have some data in my own file format (e.g. a Quake3 pk3 - AKA zip - file), so I would want to load the data into memory myself and pass the data to the GUI handler as a pointer. > > Soon as I get some free time I'll do the Direct3D port (piece of cake!) > > Did you take a look at the opengl implementation? There's not much to > it. I'm thinking about doing a more optimized version later (with display > lists and compiled vertex arrays), and then maybe one that created beveled > 3d buttons just for fun. I haven't looked at it yet. Have you put together another zip distribution yet? Regards, Keith Harrison SiO2 Software. ke...@ne... (personal) si...@ne... (work) |
|
From: sfranke <sf...@us...> - 2000-06-13 21:47:59
|
The resource registry is in. It only deals with non-Frame objects, and mainly it's just to make keeping track of pointers for freeing easier (the app is no longer responsible for resources passed to the registry). It doesn't change the complexity setup code much at all. I'm still debating whether or not to add Frames (without any get* function) so the app won't have to keep track of those pointers either. I also added a slider bar with variable range (width) that scales to the correct size in the bar. It inherits fairly nicely from CUI_ProgressBar. I'm pretty happy with the results, I got it interfacing with the cursor perfectly. Which reminds me, if anyone wants to do some work, you're really going to need to get the sampleapp code from me, because it's changed a hell of a lot from the original version. So if anyone needs it, send me an email (or just say so in a reply to the list) and I'll email it to you. Or is there a way to put developer-only files up on sourceforge? I'll look into that. Scott Franke [druid-] sf...@gl... |
|
From: sfranke <sf...@us...> - 2000-06-13 14:48:14
|
On Mon, 12 Jun 2000, SiO2 Software wrote: [resource registry] > Very nice, but please don't compromise speed. Us people who are going to use > the UI will want to use it for our in-game HUD's too! ;-) Right now I'm just looking at using it to handle shaders, fonts, cursors, coordinate systems and borders. So that it's easy to say, use the "blue" shader. This will make it easier to define all the shaders in a file somewhere and reference them. I think I'll leave the actual frame/widget/etc creation as it is. Of course it will be much smoother in a file loader, but I couldn't come up with a good alternative. We can always work on it later if it's too much of a problem. > Soon as I get some free time I'll do the Direct3D port (piece of cake!) Did you take a look at the opengl implementation? There's not much to it. I'm thinking about doing a more optimized version later (with display lists and compiled vertex arrays), and then maybe one that created beveled 3d buttons just for fun. [relevance of the project's name] Yeah, I've noticed that as well. Unfortunately, there's no way to change the sourceforge project name (to my knowledge), so that will have to remain. I've started calling it GameGUI in the class docs, but it's still open. I guess we could come up with a snappier name if anyone has any ideas. Scott Franke [druid-] sf...@gl... |
|
From: SiO2 S. <si...@ne...> - 2000-06-12 22:35:23
|
----- Original Message ----- From: "sfranke" <sf...@us...> To: <glg...@li...> Sent: Monday, June 12, 2000 8:05 PM Subject: [Glgui-dev] abstract rendering & more > The rendering is now abstracted. Excellent! > I wrote a generic opengl renderer that > interfaces to an already setup and initialized rendering context (must > keep it platform independent). To further that goal, all the code in CVS > is platform independent except for a single #ifdef WIN32 include (does > that count?). Don't worry about #ifdef's - they certainly don't compromise platform independancy (in fact you'll probably find it hard to get by without them). > I also added a multi-state buttons for checkboxes and whatever else. > > I am now working on tackling the whole resource registry problem, and then > will work on importing prebuilt UIs (still undecided about the means and > method). Very nice, but please don't compromise speed. Us people who are going to use the UI will want to use it for our in-game HUD's too! ;-) > After that it's fonts and editable text boxes, and then integrating my > glConsole. > > When all that is done, I'll probably make a release with a sample & > code. Having the sample run on non-win32/opengl platforms would be nice > (as would having a cooler sample). So if anyone is still interested in > helping out, just mail the list. Soon as I get some free time I'll do the Direct3D port (piece of cake!) Regards, Keith Harrison SiO2 Software. ke...@ne... (personal) si...@ne... (work) |
|
From: sfranke <sf...@us...> - 2000-06-12 19:08:43
|
The rendering is now abstracted. I wrote a generic opengl renderer that interfaces to an already setup and initialized rendering context (must keep it platform independent). To further that goal, all the code in CVS is platform independent except for a single #ifdef WIN32 include (does that count?). I also added a multi-state buttons for checkboxes and whatever else. I am now working on tackling the whole resource registry problem, and then will work on importing prebuilt UIs (still undecided about the means and method). After that it's fonts and editable text boxes, and then integrating my glConsole. When all that is done, I'll probably make a release with a sample & code. Having the sample run on non-win32/opengl platforms would be nice (as would having a cooler sample). So if anyone is still interested in helping out, just mail the list. Scott Franke [druid-] sf...@gl... |
|
From: sfranke <sf...@us...> - 2000-06-08 18:03:54
|
Since I hadn't heard from anyone, I went ahead and updated all the existing source to use the qt commenting style so doxygen can be used to make documentation. http://www.stack.nl/~dimitri/doxygen/index.html Please look at the commenting style and make sure any code you check in conforms to it around the same level of commenting as I did in the existing code. http://www.stack.nl/~dimitri/doxygen/starting.html#starting If you've already made changes that you haven't checked in, you'll have to modify the comments or get the latest version and make your modifications to that. I also finally created a simple little link page for glgui.sourceforge.net, which has a link to the documentation. The page on GL Journal has not been updated because I still don't have net access at home. I'll get around to that at some point. I'm going to start working on abstracting the rendering and implementing a resource registry/manager. After that I'll be working on a file format and i/o. Contact me if you have any input on this or want to work on anything else. Scott Franke [druid-] sf...@gl... druid-'s GL Journal http://www.gljournal.org |
|
From: sfranke <sf...@us...> - 2000-06-06 16:51:05
|
On Tue, 6 Jun 2000, bosco wrote: > I'm actually headed to the sack right now. Seems the project is dead? I > certainly hope not.. From the demo program it seemed like there was a lot > of promise. I haven't taken much of a look at the code recently.. I've been > working on some texture and font code as a side project to occupy some > time.. :) Check out the archives for this list on sourceforge. There have been a few messages recently. Also look further back and see the kind of suggestions that have been made. I'm going to be working on resource management, abstracting the rendering, and improving the fonts. At some point I'm going to change a lot of the formatting so a documenting processor can make the docs instead of me doing it by hand. Anything else you come across in the archives that you want to do, just let me know. Or if you already have an idea of something you'd like to work on. Scott Franke [druid-] sf...@gl... |
|
From: bosco <bo...@ho...> - 2000-06-06 05:33:28
|
Greetings, I'm actually headed to the sack right now. Seems the project is dead? I certainly hope not.. From the demo program it seemed like there was a lot of promise. I haven't taken much of a look at the code recently.. I've been working on some texture and font code as a side project to occupy some time.. :) I'll be checking it out in detail tomorrow. I'd like to find a nitch of it to start improving. Anyway, I guess I mainly wanted to say hello to anyone out there still monitoring this.. tim < a.k.a bosco > |
|
From: sfranke <sf...@us...> - 2000-06-05 15:22:18
|
On Thu, 1 Jun 2000, Keith Harrison wrote: > I've been real busy on an Intel contract. Anyone else actually done > anything? I guess not. Well, I'm going to get started on the resource management pretty soon, and then will probably define some sort of file format. If anyone has any input on thess, send it in now. Do you have anything that could be integrated into the cvs code Keith? Core ui stuff is more important at this point than platform specific demos. scott |
|
From: Keith H. <ke...@ne...> - 2000-06-01 23:24:43
|
----- Original Message ----- From: "sfranke" <sf...@us...> To: <glg...@li...> Sent: Wednesday, May 31, 2000 4:04 PM Subject: [Glgui-dev] long downtime > Hi, how is everyone doing? I'm finally settled down from the school to > summer job transition, should have an internet connection at my apartment > by next week, and then can get started on this again. > > If everyone who's still interested in working on this could email this > list and let us know what you'd like to work on, we can all get started > again. > > I think the first issues to work on are: > * changes to code to support a post-processing documentor - I found a > good one, but can't remember what it was called. > * resource editor (still willing to work on that Travis?) > * resource management > * better font system > * better and multiplatform demos > > How does that sound to everyone? I've been real busy on an Intel contract. Anyone else actually done anything? Regards, Keith Harrison SiO2 Software. ke...@ne... (personal) si...@ne... (work) |
|
From: sfranke <sf...@us...> - 2000-05-31 15:06:39
|
Hi, how is everyone doing? I'm finally settled down from the school to summer job transition, should have an internet connection at my apartment by next week, and then can get started on this again. If everyone who's still interested in working on this could email this list and let us know what you'd like to work on, we can all get started again. I think the first issues to work on are: * changes to code to support a post-processing documentor - I found a good one, but can't remember what it was called. * resource editor (still willing to work on that Travis?) * resource management * better font system * better and multiplatform demos How does that sound to everyone? Scott Franke sf...@gl... |
|
From: SiO2 S. <si...@ne...> - 2000-04-30 10:00:21
|
I'll let you all know what I've come up with Real Soon(tm). ;-) ----- Original Message ----- From: "Scott Franke" <sf...@gl...> To: <glg...@li...> Sent: Wednesday, April 26, 2000 5:28 AM Subject: Re: [Glgui-dev] Issues > > I suggest a fully implemented Bridge. We can then allow any developers > who > > dislike our implementations of the D3D and OpenGL classes extend the > > abstract base class which defines the interface easily. Or create a > simple > > adapter and integrate their own versions of D3D OpenGL bridge with our > own. > > That would also allow a very easy extension to anything else, even (dare I > > say it) a software renderer. Then no ports will be necessary, we can just > > derive from GraphicsAPI (or whatever we want to call it.) This is what I > do > > in my engine, and it is one heck of a timesaver. Admittedly it will add > an > > extra layer, but I think the increased flexibility would be worth it. > > This was what I was going to suggest. As of now, there's a pretty limited > portion of the GL that needs to be abstracted. I haven't used d3d in a long > time, and don't know how other api's implement similar functionality, so > I'll leave it to someone else to lay out the abstraction class. But I'll > write the opengl version once the base interface is done. > > > Also let me say here and now, I love the stl. I know on a few systems it > is > > still unsupported, but it is the biggest time saver save templates > > themselves. I say we should use it to its fullest. > > I like it too, but if there are too many support problems, it may not be > worth using. > > > PS. Sorry I haven't been active, school has hit me harder than I thought > it > > would. This is finals week, so hopeful If I survive I should be able to > get > > back into the swing of things next week. > > Same goes for me. Except that I'm in my last week of classes and will be > starting finals next week. I'm also lining up a job for the summer which > will include a good bit of time moving, etc. I may be unable to do much > work for a few weeks still. But I'll try to stay a part of the discussion > and can even spend a few hours here and there to do some simple design / > programming. > > One of the things I'd like to work on next is a more complete shader class, > with functionality similar to that in quake3. But the issues Keith has > made, as well as some of the others that have been mentioned (other widgets, > better text, etc) should take precedence. > > Scott Franke [druid-] > sf...@gl... > druid-'s GL Journal > http://www.gljournal.org > > > _______________________________________________ > Glgui-dev mailing list > Glg...@li... > http://lists.sourceforge.net/mailman/listinfo/glgui-dev > |
|
From: Scott F. <sf...@gl...> - 2000-04-26 04:33:35
|
> I suggest a fully implemented Bridge. We can then allow any developers who > dislike our implementations of the D3D and OpenGL classes extend the > abstract base class which defines the interface easily. Or create a simple > adapter and integrate their own versions of D3D OpenGL bridge with our own. > That would also allow a very easy extension to anything else, even (dare I > say it) a software renderer. Then no ports will be necessary, we can just > derive from GraphicsAPI (or whatever we want to call it.) This is what I do > in my engine, and it is one heck of a timesaver. Admittedly it will add an > extra layer, but I think the increased flexibility would be worth it. This was what I was going to suggest. As of now, there's a pretty limited portion of the GL that needs to be abstracted. I haven't used d3d in a long time, and don't know how other api's implement similar functionality, so I'll leave it to someone else to lay out the abstraction class. But I'll write the opengl version once the base interface is done. > Also let me say here and now, I love the stl. I know on a few systems it is > still unsupported, but it is the biggest time saver save templates > themselves. I say we should use it to its fullest. I like it too, but if there are too many support problems, it may not be worth using. > PS. Sorry I haven't been active, school has hit me harder than I thought it > would. This is finals week, so hopeful If I survive I should be able to get > back into the swing of things next week. Same goes for me. Except that I'm in my last week of classes and will be starting finals next week. I'm also lining up a job for the summer which will include a good bit of time moving, etc. I may be unable to do much work for a few weeks still. But I'll try to stay a part of the discussion and can even spend a few hours here and there to do some simple design / programming. One of the things I'd like to work on next is a more complete shader class, with functionality similar to that in quake3. But the issues Keith has made, as well as some of the others that have been mentioned (other widgets, better text, etc) should take precedence. Scott Franke [druid-] sf...@gl... druid-'s GL Journal http://www.gljournal.org |
|
From: Travis M. <Tra...@st...> - 2000-04-26 01:03:08
|
Sorry Keith, I meant to just send it to the mailing list. I suggest a fully implemented Bridge. We can then allow any developers who dislike our implementations of the D3D and OpenGL classes extend the abstract base class which defines the interface easily. Or create a simple adapter and integrate their own versions of D3D OpenGL bridge with our own. That would also allow a very easy extension to anything else, even (dare I say it) a software renderer. Then no ports will be necessary, we can just derive from GraphicsAPI (or whatever we want to call it.) This is what I do in my engine, and it is one heck of a timesaver. Admittedly it will add an extra layer, but I think the increased flexibility would be worth it. Also let me say here and now, I love the stl. I know on a few systems it is still unsupported, but it is the biggest time saver save templates themselves. I say we should use it to its fullest. PS. Sorry I haven't been active, school has hit me harder than I thought it would. This is finals week, so hopeful If I survive I should be able to get back into the swing of things next week. -----Original Message----- From: SiO2 Software [SMTP:si...@ne...] <mailto:[SMTP:si...@ne...]> Sent: Monday, April 24, 2000 10:41 AM To: glgui-dev Subject: [Glgui-dev] Issues ----- Original Message ----- From: "SiO2 Software" <si...@ne... <mailto:si...@ne...> > To: <glg...@li... <mailto:glg...@li...> > Sent: Friday, April 07, 2000 10:23 AM Subject: [Glgui-dev] Bonjour > Subscribed at last! The archives are still fubar, so I haven't a clue what's > been discussed in my absence. > > Anyway, I'll have my set of mod's done over the weekend (Famous Last Words). > I'll post the URL to the list (binary attachments are *evil*) so you can all > see what I'm doing. > > Scott and I have been discussing a few things over the last three weeks or > so. Here's a segment of an email I sent to Scott last week: > > >I have some points I'd like to discuss on the mailing list: > >1. Use of C++ and how/if this effects portability. > >2. Use of stl. > >3. Usability with Direct3D. I can port glGameGUI to d3dGameGUI, but we need > >a common base! > > There's no problem with doing the Direct3D port. That will be a "piece of > cake". But what do we call it? We can't call it "glGui"! Does anyone have any comments on these issues? I'm just about to start work again on glGui, so it would be nice if we had the relevant discussions *before* I begin. [My contract work with Intel has taken prominence over the last couple of weeks] For those who don't know, I will be using glGui in my next game title. I will definitely be doing a Direct3D version of glGui, but we absolutely need to keep full OpenGL functionality. ;-) Regards, Keith Harrison SiO2 Software. ke...@ne... <mailto:ke...@ne...> (personal) si...@ne... <mailto:si...@ne...> (work) _______________________________________________ Glgui-dev mailing list Glg...@li... <mailto:Glg...@li...> http://lists.sourceforge.net/mailman/listinfo/glgui-dev <http://lists.sourceforge.net/mailman/listinfo/glgui-dev> |
|
From: SiO2 S. <si...@ne...> - 2000-04-25 18:09:39
|
----- Original Message ----- From: "SiO2 Software" <si...@ne...> To: <glg...@li...> Sent: Friday, April 07, 2000 10:23 AM Subject: [Glgui-dev] Bonjour > Subscribed at last! The archives are still fubar, so I haven't a clue what's > been discussed in my absence. > > Anyway, I'll have my set of mod's done over the weekend (Famous Last Words). > I'll post the URL to the list (binary attachments are *evil*) so you can all > see what I'm doing. > > Scott and I have been discussing a few things over the last three weeks or > so. Here's a segment of an email I sent to Scott last week: > > >I have some points I'd like to discuss on the mailing list: > >1. Use of C++ and how/if this effects portability. > >2. Use of stl. > >3. Usability with Direct3D. I can port glGameGUI to d3dGameGUI, but we need > >a common base! > > There's no problem with doing the Direct3D port. That will be a "piece of > cake". But what do we call it? We can't call it "glGui"! Does anyone have any comments on these issues? I'm just about to start work again on glGui, so it would be nice if we had the relevant discussions *before* I begin. [My contract work with Intel has taken prominence over the last couple of weeks] For those who don't know, I will be using glGui in my next game title. I will definitely be doing a Direct3D version of glGui, but we absolutely need to keep full OpenGL functionality. ;-) Regards, Keith Harrison SiO2 Software. ke...@ne... (personal) si...@ne... (work) |
7 messages has been excluded from this view by a project administrator.
