MasteR

Ok I've looked at the code some more and you'll need the following things: #include "glut.h" After rendering lights the regular LE way you can start to render all your GUI stuff. I have not tested the code below, nor do I remember exactly what each function does but it *should* work. int viewPort[4]; glGetIntegerv(GL_VIEWPORT, viewPort); gluOrtho2D(0, viewPort[2], viewPort[3], 0); glMatrixMode(GL_PROJECTION); glPushMatrix(); glLoadIdentity(); SetBuffer(BackBuffer()); SetBlend(BLEND_ALPHA); TFont font = LoadFont("Bitmap font..."); SetFont(font); std::string text = "winner!"; glScalef(pRenderScale, pRenderScale, 1.0f);//this is your magic function characterWidth = (FontHeight() * pRenderScale) * text.size();//labels can be multi lined for(int i = 0; i < text.size(); i++) { DrawText(0, 0 + characterWidth * i), text[i].c_str()); } glLoadIdentity();//reset gl matrix glPopMatrix();

Hi Rick, Short of reading through the forum thread you linked, I'm 99% sure that I implemented "a" solution to the same problem some time ago... How's that for a tease! Give me an hour and I'll hunt down the code. ***EDIT*** I began my own GUI implementation 2 years ago but never finished it as a result the code is far from complete. I don't have the patience this evening (evening in Australia right now) to re-learn all the specifics, so I'll give you the code as is. From what I can discern this is how I accomplished the task. 1. Decide on the main resolution you want your application to run at. That is, the resolution you expect the majority of your users to...use. This is an important stage. Armed with this "optimal" resolution your artists can go to town creating all the required GUI assets to suit. 2. The implementation uses bitmap fonts. 3. All your drawing can be done to the regular LW back buffer but you'll have to crack into some OpenGL functions from this point. I'll omit the meat of this stage but the "trick" is to scale the drawing of all your GUI widgets so that they occupy the same amount of window realestate regardless of the window resolution. pRenderScale = (float)GraphicsWidth() / (float)aWidth; where aWidth is the "optimal" width you chose in step 1. Use pRenderScale to multiply the width and height when drawing your GUI widgets. e.g. A label created at 10*10 pixels should be drawn at (10* pRenderScale)*(10* pRenderScale). I think a working example is really going to be the best thing to show at this stage as I've run out of time. You want to focus on the CLabel class as this is the text output. In main.cpp muck around with resolution values in the following lines: Graphics(640, 480); gui.SetBaseResolution(640, 480) There are going to be many ways to implement a solution and my code attached is old, messy and incomplete. But the key points to remember are: * Create all GUI assets, including a bitmap font, to suit an "optimal" resolution. * In your application draw "scaled" version of theses assets based on the formula in step 3. Follow these guidelines and you'll only ever have to create GUI assets once and the will always occupy the same amount of window realestate regardless of the window's resolution. I hope this helps, even if it's just a little.

I'm hoping to test this program on as many PCs as possible. If you all don't mind giving it a go and letting me know the results I'd very much appreciate it. It was developed using C++ 2010 Express x86 so you'll need to download the C++ 2010 Redistributable Package from here. It's a simple program which tests a class responsible for gathering system information. The test program is limited to OS, CPU, RAM and Video card. Cheers Test.exe

Hi Darren, I'd be very interested in seeing your implementation, I've sent you a PM.

The issue here is if a programmer does not call the Create()/Initialize()/Open()/etc. method but instead begins using the object as normal...well needless to say the results are undetermined. In this instance is it better to check a "fail bit" inside all class methods before executing code or simply take it on faith that the programmer will do the right thing?

As a semi separate question from the above. As a programmer, how annoyed would you be if you were forced to encapsulate a class within a try/catch block, because the class threw exceptions rather than returned error codes?

I'm after some opinions on how best to handle exceptions in class constructors. Mock example: I have an application log class. When an instance of this class is created the class constructor creates(opens) an output file ready to write to. As above, opening a file could cause an exception for a number of reasons. The issues are that class constructors have no return type so returning an error code indicating that something went wrong is not an option. Using "throw" to throw an exception or error code will crash the program unless the class instance was created inside a try/catch block. Possible solutions: (none of which I'm 100% satisfied with) * Create classes using the named constructor idiom. * Pass an error code variable to all class constructors as a pointer/reference argument. This allows the class constructor to modify the error code in the event of an exception, being a pointer/reference the error code can then be analysed from outside of the class. * Give all classes a public "Initialise" method that must be called after an instance is created and also before any other class method is used. * Give all classes a public/private error code variable which the class constructor can modify in the event of an exception. This member variable can then be analysed from outside the class via a “Get” type method. Which solution do people use/prefer, or does anyone have an alternate solution they'd be willing to elaborate on.

My current task has me detecting and logging a system's (PC's) information. My question is: How much information is too much? What information is useful to know and what isn't? My specific predicaments are: Is the build number of the installed windows version useful? Is the brand (NOT chipset) of the systems video card useful? e.g. Gigabyte, EVGA Is the brand and/or model of the systems CPU useful? e.g. AMD Athlon (Brand Model), Intel Itanium The information gathered is intended for reference with future program troubleshooting.

I would like to see the TVec data structures and Vec functions perhaps renamed to include an 'f' on the end. e.g. TVec2f TVec3f Vec2f Vec3f I also think the font load function should accept an image filename as its argument including the '.dds' (or whatever format is chosen)

Final call... Anyone else have an opinion on design question #4.

The Buffer approach?

SOLVED. I implemented a different approach so no answers here.

I can't reproduce it Rick, your implementation works for me. Could be some simple oversight like calling the wrong object Draw() method in your loop. Short of sending me your program (which I'd be happy to compile and look through) I'm at a loss.

try: 'protected:' instead of 'private:' with the base class properties. try: TTexture* _headShot; //as the class property _headShot = new TTexture(LoadTexture(FileName.c_str())); //inside Actor constructor and simply pass "abstract::KnightHeadShot.dds" as a std::string argument

No initial problems here... I assume you're creating objects of the derived classes and that is where you're encountering the issues. What happens when you create objects of the base (actor) class, same result? Or a mix of both base and derived?

Post up the code for the Actor constructor.

I'm trying to solve the graphical anomaly pictured below. I'm rendering the images to a buffer I created and then copying the colour and depth information to the back buffer. The images are being drawn in the correct Z-Order but as you can see when opacity is altered, the images ignore this information. I'm new to using custom buffers so this could be something simple. I'll post code if requested.

For me, I view music as a seperate piece to the meue puzzle. music combined with a GUI will make a menu. I don't personally thing music is part of the GUI itself. This brings up... Design Question #5 Where should sound playback reside? I believe it should be included in a GUI but should sound playback be the widgets responsibility or the GUI's. e.g. When you interact with a widget should the widget play the sound. OR When you interact with a widget should the mouse click (or any other form of user input) call a generic PlaySound() method native to the GUI as a whole?

Agreed. Design Question #4 When I think of sounds "roll over" and "click" come to mind, but nothing else. What other sounds (if any) does a GUI require?

LoadModel() requires the .gmf file extension on the end of the file name. But the function also loads .LUA, .INI and .PYH files of the same name. Why should LoadFont() be any different? The function loads image based fonts, and I feel it makes more sense to pass it an image file name. LoadModel() loads models so you pass it a model filename. I feel there is confusion breed here. It’s simply my thoughts after all this forum is for feature requests not feature demands.

For consistency I'd like to see LoadFont() accept a string with the .dds file extension. e.g. LoadFont("FontName.dds") instead of (currently) LoadFont("FontName") For consistency between the engine's load functions. The LoadModel() function requires .gmf even though it searches for and loads additional files just as LoadFont() does.

Worked out a solution, Following Flexman's train of thought (a solution I was already following for image rendering). Create a custom buffer with width = GraphicsWidth()/scale and height = GraphicsHeight/scale. Do all your drawing to this custom buffer then copy to the back buffer.

I'm after a little help. I'm after a solution which will let DrawText() render text that occupies the same screen space regardless of resolution. I'd much prefer to sort this out without having to write my own OpenGL DrawText() function. 3rd party libraries are also an option as I can simply write my own if I have to. Unlike DrawImage(), DrawText() does not have a width and height which can be scaled, glscalef scales properly but I'm at a loss as how to retain the texts correct screen position using this technique. Thoughts/solutions?

Reply away Rick, I'd like to keep the discussion going. Two heads are better than one. Some future questions may spark additional interest.

... This thread not the hub of input that I had envisioned (apart from you chaps above ) To counter this I'll pose specific design questions which arise. Design Question #1 Is there ever a need to render a cursor or text opaque (see through/semi-transparent)? Design Question #2 Should "gradient" effect widgets be up to the artist to create, or is this rendering style so universal that a GUI should have it "built" in? Design Question #3 Is there ever a need to tint a cursor or image based widget with an overall colour?