Roland

Yes. It's very possible. I even did a tutorial on that and placed in the Wiki. Now someone has removed it...

Sleep(1) will give a sleep time between 0 and 15.6 milliseconds. If you test with a loop of Sleep(1) you will get results varying between those values, Precision is 15 milliseconds on Windows, no matter what method that i used. There are way to trim this to about 10 msec, but 1 msec... No. Then you can always start tinkering around with using multimedia timers that uses the hardware clock in the sound-card to make things better. But that does not always work either. So in the end. 15 msec precision is what you have. There may be some method to solve this that I don't know about. In that case I would be very pleased as this is a reoccurring problem in routines sending audio over internet which is something I work with right now.

Ok. I see. But still thats a small thing compared to the fact that you get time i 15 msec step using function thats may mislead you to believe that you have a real 1 msec timer. That's my point. About clock() and Linux I have no knowledge but if it is like you say that means that clock() different resolutions in Linux and Windows. That would make it a bad candidate then. Good research Lumooja.

I don't know what new this brings to the subject. 15 msec is the resolution, as you also show in your example. About that article I have no further comments, its written by Johan Nilsson at Swedish Space Center.

You have to be aware that using any of mentioned functions only gives you a best precision of 15 milliseconds. All those clock, timeGetTime, GetSystemTime etc... is updated on each NT clock interval, which is 15 milliseconds. You may read a more detailed description on how to get a bit better results in this article Implement a Continuously Updating, High-Resolution Time Provider for Windows

Josh. You probably have this defined before the include of windows. I guess in stdafx.h #define WIN32_LEAN_AND_MEAN // Exclude rarely-used stuff from Windows headers // Windows Header Files: #include <windows.h> remove the WIN32_LEAN_AND_MEAN line and you will be fine //#define WIN32_LEAN_AND_MEAN // Exclude rarely-used stuff from Windows headers // Windows Header Files: #include <windows.h>

The compiler just needs a little hint on whats going on. So this will do the trick float ratio = 200.0 / 800; ration will get the value 0.25 as excepted.

Oh. Yeah. No problem

That one is made very simple as my need was just some buttons and simple things. Most simple games does not need more. Maybe (as you say) the text could be made better. But for most cases the in-game GUI's are very simple. If we are talking about making a tool or something like that something more complicated is need of course. In that case I would have a look at some third-party GUI (like some of the guys have). But I'm open to all suggestions although I'm working with some music recording right now. Cheers

Yeah... and my little GUI sample has event handling also

If you are talking about my little sample, I can agree. That is aimed to be a real full GUI. Its just some tests I did for my needs. My meaning was to give some idea of the event handling, not on how to write a GUI

I did this simple gui sometime ago. I has event handling. The source can be downloaded from that page. Maybe you could get some help from there. Edit: the provided link does not work any more. Sorry about that.

So this means that (in that sample ) Material* mat1 = new Material; mat1->SetColor(0,0,1,1); Material* mat2 = mat1->Copy(true); Material* mat3 = mat1->Copy(false); mat1->SetColor(1,0,0,1) mat2 is a new Material with same attributes as mat1 mat3 is essential a pointer to mat1. what happens with mat1 if mat3 is deleted, or with mat3 if mat1 is deleted? Also. What is the meaning of having a Copy( true ). That can be handled by a copy operator. Copy(false) is the better called something like CreateInstance or CreateReference Then it would be Material* mat1 = new Material; mat1->SetColor(0,0,1,1); Material* mat2 = new( *mat1 ) ; / Material* mat3 = mat1->CreateReference(); mat1->SetColor(1,0,0,1) or Material mat1; mat1.SetColor(0,0,1,1); Material mat2( mat1 ) ; Material* mat3 = mat1->CreateReference(); mat1.SetColor(1,0,0,1); or Material mat1; mat1.SetColor(0,0,1,1); Material mat2; mat2 = mat1 ; Material* mat3 = mat1->CreateReference(); mat1.SetColor(1,0,0,1);

What is the 'true' or 'false' in Copy used for ?

My sincerely condolences. May the board rest in peace.

Absolutely awesome. This looks like a game that i definitely would not miss. I hope the game will be as good as this start scene, keeping the strange feeling of coming disaster of some kind, keeping it clean from silly looking monster running around or meaningless shooting on everyone that moves in front. This start is so fascinating. And I would not add one extra bit to that piano during this intro. That single piano makes this scene just what it is... strange and a bit worrying of what to come. Adding more to that tune can't make it better. Great job and thanks sharing ... I got really inspired. Roland

Been thinking about this a bit. If try/catch want work - its not the whole world, there is a possibility to solve this by giving us some error-callback that will be called in case of errors, in constructors or elsewhere. Callbacks are no problem from C++ to C#

Procedural... Buy the GG mess then Just joking ;)

Well. Constructors are in fact used in the method CreateShader... right!

This is an outline on what I mean. class Shader { public: virtual void SomeMethod() = 0; protected: Shader() {} }; class OpenGLShader: public Shader { GLenum glprogram; // this one is used by OpenGLShader only public: OpenGLShader() {} void SomeMethod() { // use glprogram ... } } class DirectXShader: public Shader { IDirectXDevice9* pdev ; // just as examle. this one is used by DirectXShader only public: DirectXShader() {} void SomeMethod() { // use pdev .... } } // fictional class to produce graphic objects class GraphicsFactory { Shader* CreateShader() { if( weAreDirectX ) return new DirectXShader() ; else return new OpenGLShader() ; } } // usage void AFuncSomewhereInApp( GraphicsFactory* pFactory ) { Shader* myShader = pFactory->CreateShader() ; myShader->SomeMethod() ; // will call OpenGLShader::SomeMethod if we are in OpenGL mode // and DirectXShader::SomeMethod if we are in Direct mode } A little note: Making GraphicsFactory (or what you call it) a singleton would eliminate the need for sending a GraphicsFactory* around. In this case the usage would be // usage void AFuncSomewhereInApp() { Shader* myShader = GraphicsFactory::Instance()->CreateShader() ; myShader->SomeMethod() ; // will call OpenGLShader::SomeMethod if we are in OpenGL mode // and DirectXShader::SomeMethod if we are in Direct mode } Remember that this is no absolute truth. Its more suggestions on different approaches. All this can be done in so many different ways. The most important part is to hide the DirectX/OpenGL nitty-gritty details from the user. The user should not have to deal with that, nor have to handle any such graphics-system specific variables.

There is only one way to learn and that is by doing, so you are just right on track. Learning on how to avoid mistakes is by doing them. Happy coding

Welcome from Sweden

The returned shader is either a OpenGLShader or DirectXShander. You as user doesn't need to know. Just use the methods in Shader.

Shader* shader = new Shader(graphicsdriver); is of course the correct approach. There is a possibility to simplify all this. Implementing GraphicsDriver as a singleton would eliminate the need for passing the driver as an argument to all objects as shown above. I normally avoid globals or singletons, but in this case it could a possibility, as there will never been more that one (and one only) GraphicsDriver in an application. Just an idea....

I don't quite understand what the problem is here. The implementations of the abstract base (Shader) can have as many extra attributes and methods they need as long as they implements the abstract methods in Shader. The user only handles the Shader class without knowing if its a OpenGL or a DirectX implementation. The Shader base class should be designed as a device independent class. The implementations can do what ever they need to do, and have any kinds of variables and methods to fulfill their mission. The user of Shader should not need to know anything about that. There should not be a static Mesh::Load in my world. The file argument should be in the constructor Mesh myMesh( "abstract::theThing.gmf" ) ; or Mesh* pMyMesh = new Mesh( "abstract::theThing.gmf" ) ; fails to load a mesh will be taken care of in a try/catch statement somewhere.