OpenGL GUI anyone? Updated on 11/17/05
well, the way I see it, the coder already has the option to not use the sliders built in label and place it anywhere they want using panels, so taking away the label option doesnt provide any new functionality, while leaving it doesnt subtract from functionality either. So, from those two options, I would suggest that it be left, though, to propose a third option, perhaps a choice of where the label appears?
Author
I will definitely think of that later on, thanks for the suggestions [smile]
I updated the main post with the new win32 binaries using the std::string class.
On a side note I'm about to start working on a project similar to DXUT frame work that you see a lot in NVIDIA SDK, only this one will use OpenGL and require a single header file and a single .lib
It will facilitate creating windows and will have this GUI built in :)
I updated the main post with the new win32 binaries using the std::string class.
On a side note I'm about to start working on a project similar to DXUT frame work that you see a lot in NVIDIA SDK, only this one will use OpenGL and require a single header file and a single .lib
It will facilitate creating windows and will have this GUI built in :)
Author
Thanks to Mr Reiland for combining the win32 and linux files into a single package and tracking down the segfault on linux boxes.
I updated the main post and I cleaned it up a bit, check it out [smile]
I updated the main post and I cleaned it up a bit, check it out [smile]
That first post sure is alot better.
I can't say I 100% approve of putting all class definitions in a single header, but its really a matter of preference (and something not hard to change if I want to), but otherwise, its looking great.
So, whats left to do on this GUI anyway?
Other than text areas and fixing up text boxes a bit and adding the ability to move windows, I cant think of anything.
By finishing up text boxes, I mean changing the start index of the text when the text overflows the box instead of just not displaying it, adding a max length to text boxes, allowing the blinker to be dragged to select text, and possibly clipboard support.
I can't say I 100% approve of putting all class definitions in a single header, but its really a matter of preference (and something not hard to change if I want to), but otherwise, its looking great.
So, whats left to do on this GUI anyway?
Other than text areas and fixing up text boxes a bit and adding the ability to move windows, I cant think of anything.
By finishing up text boxes, I mean changing the start index of the text when the text overflows the box instead of just not displaying it, adding a max length to text boxes, allowing the blinker to be dragged to select text, and possibly clipboard support.
I found this thread a while ago when I was searching for a light weight and portable GUI for my game (and other projects) and I'm very impressed!
I'm currently trying to implement it into my game and was wondering what the status is on its development? notice I'm calling it 'it' a lot :) What was the official name in the end?
I have some Qs that someone could perhaps kindly help me with:
1. JavaCoolDude, you stated that you were currenly integrating this project into another one similar to DXUT, what is the progress on this? What are the implications of such a development?
2. Is anyone still actively working on this project?
3. Is there a controled source repository set up for development purposes? I ask because when reading the thread I noticed that JavaCoolDude said some things were fixed such as not being able to grab hold of the outside side (if that makes any sense) of the slider handle when its at the end of the slider and in the version I downloaded from the updated first post, that problem still exists. However the custom string issue seems to have been removed.
4. I noticed the sourceforge project page is up but its devoid of content, any plans to start using this?
5. I currently use FTGL (with freetype2), a font glyph renderer for opengl), to render text and I was wondering how easy it would be to merge this with the GUI, as I understand that the fonts are loaded from a .tga file at the moment, how engrained into the gui is the .tga (texture fonts I assume) functionality? Perhaps this should be another pluggable part of functionality similar to what was being mentioned about the proprietry texture manager? (everyone should be using DevIL anyway :P).
I guess I'm just concerned that this fine project will stop being developed. There are some things I'd like to add, including a list box widget, as well as clearing up the other things such as the text box issues that relpats_eht mentioned in his post (10/17/2005 4:07:18 PM), etc... and adding a text area, all if my humble programming skills are up to the challenge!
I also have this nasty habit of documenting things as I use them, to solidify my knowledge of them, so I want to write a user guide with tutorials/examples sort of affair but, what format should this take?
An absolutely superb effort guys!
I'm currently trying to implement it into my game and was wondering what the status is on its development? notice I'm calling it 'it' a lot :) What was the official name in the end?
I have some Qs that someone could perhaps kindly help me with:
1. JavaCoolDude, you stated that you were currenly integrating this project into another one similar to DXUT, what is the progress on this? What are the implications of such a development?
2. Is anyone still actively working on this project?
3. Is there a controled source repository set up for development purposes? I ask because when reading the thread I noticed that JavaCoolDude said some things were fixed such as not being able to grab hold of the outside side (if that makes any sense) of the slider handle when its at the end of the slider and in the version I downloaded from the updated first post, that problem still exists. However the custom string issue seems to have been removed.
4. I noticed the sourceforge project page is up but its devoid of content, any plans to start using this?
5. I currently use FTGL (with freetype2), a font glyph renderer for opengl), to render text and I was wondering how easy it would be to merge this with the GUI, as I understand that the fonts are loaded from a .tga file at the moment, how engrained into the gui is the .tga (texture fonts I assume) functionality? Perhaps this should be another pluggable part of functionality similar to what was being mentioned about the proprietry texture manager? (everyone should be using DevIL anyway :P).
I guess I'm just concerned that this fine project will stop being developed. There are some things I'd like to add, including a list box widget, as well as clearing up the other things such as the text box issues that relpats_eht mentioned in his post (10/17/2005 4:07:18 PM), etc... and adding a text area, all if my humble programming skills are up to the challenge!
I also have this nasty habit of documenting things as I use them, to solidify my knowledge of them, so I want to write a user guide with tutorials/examples sort of affair but, what format should this take?
An absolutely superb effort guys!
Well, the SF.net site could and should be used, but no one has ever contacted me about it, so it is just sort of sitting there.
Also, I am actively developing an AllegroGL port of it, which is a bit futher along than the version which can be downloaded from this thread. Not much farther though, all I have really done is reformatted all the code, removed all dead code, made the fonts not have to be upside down in the texture, and finished the textboxes. I am still working on it, but unless you use Allegro(GL) for your projects, it really wouldn't be of much use.
As far as changing the way it handles fonts, during my port, I found it was as easy as one large backspace and 5 new lines, and all of the changes where pretty much localized to the font loading function.
However, proper documentation for OpenGLUI (SXML GUI?) would be a good thing for everyone.
Also, I am actively developing an AllegroGL port of it, which is a bit futher along than the version which can be downloaded from this thread. Not much farther though, all I have really done is reformatted all the code, removed all dead code, made the fonts not have to be upside down in the texture, and finished the textboxes. I am still working on it, but unless you use Allegro(GL) for your projects, it really wouldn't be of much use.
As far as changing the way it handles fonts, during my port, I found it was as easy as one large backspace and 5 new lines, and all of the changes where pretty much localized to the font loading function.
However, proper documentation for OpenGLUI (SXML GUI?) would be a good thing for everyone.
Honestly I think the most important thing for OpenGLUI is getting the destruction of the widgets correct.
At this moment, there are a few key destructors that aren't being called correctly because they're not virtual, nor are their children virtual. If you do make them virtual, you start getting segfaults when deleting widgets. I think there's an issue with the order of destruction , ie, somethings being deleted that's a part of something else.
I really haven't had the time to look as closely at the code as I could, but I've thought of several solutions, ranging from complex to not so complex :) Ultimately what I'd like to do is use a tree container of some type to keep track of destruction order, et al. At the moment it's all handled by the widgets themselves. This would allow us to add/remove lifetime constraints much more easily. I also would like to more properly map out the constraints for the widgets. Things like exact lifetime, may only have 1 parent, etc.
I haven't really brought any of this up to JavaCoolDude, but I guess this would be the best time to do it :)
If anyone would like to discuss this with me, you can contact me at
AIM: mreiland1978
YAHOO: mreiland1978@yahoo.com
At this moment, there are a few key destructors that aren't being called correctly because they're not virtual, nor are their children virtual. If you do make them virtual, you start getting segfaults when deleting widgets. I think there's an issue with the order of destruction , ie, somethings being deleted that's a part of something else.
I really haven't had the time to look as closely at the code as I could, but I've thought of several solutions, ranging from complex to not so complex :) Ultimately what I'd like to do is use a tree container of some type to keep track of destruction order, et al. At the moment it's all handled by the widgets themselves. This would allow us to add/remove lifetime constraints much more easily. I also would like to more properly map out the constraints for the widgets. Things like exact lifetime, may only have 1 parent, etc.
I haven't really brought any of this up to JavaCoolDude, but I guess this would be the best time to do it :)
If anyone would like to discuss this with me, you can contact me at
AIM: mreiland1978
YAHOO: mreiland1978@yahoo.com
Author
Honestly I think the most important thing for OpenGLUI is getting the destruction of the widgets correct.
At this moment, there are a few key destructors that aren't being called correctly because they're not virtual, nor are their children virtual. If you do make them virtual, you start getting segfaults when deleting widgets. I think there's an issue with the order of destruction , ie, somethings being deleted that's a part of something else.
I fixed that in a newer version that's going up tonight [smile]
Looks incredibly useful.
Dual PII 400 MHZ 512 L2 Cache (1mb in all)
512 MB of RAM
Gforce FX5200 128 MB
Runs ~200 FPS in initial size
Fullscreen (1600x1200) ~80 fps
Dual PII 400 MHZ 512 L2 Cache (1mb in all)
512 MB of RAM
Gforce FX5200 128 MB
Runs ~200 FPS in initial size
Fullscreen (1600x1200) ~80 fps
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
