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?