hello!

i have my Xna.Game derived class embeded in my own framework which provides a gameloop. is there a way to pass my gametime to Xna.Game.Update()? or is it intended to create a new GameTime object with all time informations everytime Update() is called (which should be quite expensive)? the GameTime properties are all read-only.

If you are managing your own game loop, it's really not worth trying to also use the Game class. The point of the Game class is primarily to manage your graphics device and game loop. With you managing your own game loop you might as well just learn to manage the graphics device manager (a fairly easy task) and not bother with the Game class at all.

how do i create a window then?

(thx for the quick repsonse! :) )

Hm. Good point. On Windows you can use the standard WinForms libraries to create your window. For Xbox, though, I think you have to use the Game class.

Which raises a question: why do you want manual control of your game loop? If you relinquished that task to the Game class it would make your life quite a bit easier.

On Xbox, you dont need a window.  At least you didn't in 1.0.  Just pass IntPtr.Zero as the window handle when creating the GraphicsDevice.

> On Windows you can use the standard WinForms libraries to create your window.

do you know any tutorials or sources which covers Forms with XNA?

> why do you want manual control of your game loop?

im writing a programm which should be very flexible and allow to change between different rendering systems (XNA, OpenGL aso.).

zafuy:

> On Windows you can use the standard WinForms libraries to create your window.

do you know any tutorials or sources which covers Forms with XNA?

> why do you want manual control of your game loop?

im writing a programm which should be very flexible and allow to change between different rendering systems (XNA, OpenGL aso.).

 

That's going to make life very difficult. You will have to put wrappers around everything, or define everything as an interface, Vectors, Matrices, and every other XNA / OpenGL class. I tried doing that with OpenGL and DirectX using C++, and it was a world of pain. I would suggest you choose one platform and stick with it.

The trick is to abstract on a higher level than the API itself.  Abstracting textures, vertex buffers, etc. usually isn't the way to go.  You're much better off abstracting the rendering of models, your material system, your world geometry rendering, etc.

When you do it at this higher-level, the abstraction actually becomes a lot nicer and intuitive.  When possible, writing this abstraction is a good idea, so you can share code not only across projects but also across platforms.

Abstracting vectors/matrices are a little less efficient in managed code since you can't just re-interpret pointers like you can in C++, but its still not hard.

I guess the programmable pipeline would make it a lot easier. I did it a few years ago with Fixed pipeline.

The challenge with abstracting multiple API's is what do you do when one API provides more functionality than another?

For instance in this case, the XNA Framework provides automatic window construction and game loop timing, but OpenGL and native DirectX do not.

You have to decide whether to go for the lowest common denominator and only use the things that are common to all the platforms you want to support, implementing the rest yourself (which is fine, but makes a lot of extra work, and at some point you have to ask why you're even bothering to support higher level platforms if you aren't going to use the higher level features they provide), or you could decide to use the high level features on the platforms that have them, and build up equivalent functionality for the platfrosm which do not. For instance you could use the Game class and timing system in your XNA Framework version, then write something similar of your own for your OpenGL version.

ShawMishrak:

On Xbox, you dont need a window.  At least you didn't in 1.0.  Just pass IntPtr.Zero as the window handle when creating the GraphicsDevice.

Off topic question...

Is IntPtr.Zero the equivalent of null?

Swordshock:

Off topic question...

Is IntPtr.Zero the equivalent of null?

For all intents and purposes, yes.  It's almost like a "safe" NULL, if you will.  In C++, NULL is just 0L anyway.