DrawtoScreen and Xen framework

May 26, 2009 at 7:36 PM

hello,

 

I'm having few problems porting Xen into my own engine first of all because I can't derive IDraw and drawtoScreen classes. So I want to know how I can create gamescreen and component.

I want to create a single class and derive all my component from it that way I can access from my world class but since IDraw and drawTo screen So I can't take advantage of your framework.

Creating a actor class using only icontentowner and not IDraw is it a good idea or is it some performance hit ?what's the best way to create a gamescreen without getting drawtoscreen in the way?

I try few workaround but it just don't work.

Coordinator
May 27, 2009 at 12:05 PM

Hey. Can you give me an concrete example of something that is causing you trouble? (in terms of the code, and what you want to limit/restrict and what you want to abstract, etc). 
I'm struggling a bit to figure out exactly what your goals are, etc, which makes it very hard to give good advice.

As for DrawToScreen, generally an application will only have a single instance of this class. (Certainly, for any one frame only one should be drawn).

If you are trying to build an engine that is api agnostic, then that's certainly not a problem - however it'll be a matter of abstracting your code sufficiently.
Not knowing anything about what you are trying to create I can't really comment on if this is a good idea or not.

Jun 1, 2009 at 4:38 PM

Hi sorry I did not noticed you answer that question.

 

Ok so my problem is mainly caused because I4m trying to combine an already existing engine with Xen. So what my problem, just that every single instance has to be added to the drawtoscreen class, but I Can't really access it though other class or list.

So all my component as camera, model and 2d object are derived from a unique class component. this is a choice made for serialization and also allows to access the same type of date ( orientation, position etc..) but when I create my game screen I need to assign those componenet to it. for example the pause game screen ( font, panel etc) and in the background the game screen ( model light and camera). but my problem is if I want to draw all thes componenet I need to acces the draw class through the gamescreen ( to allows it to update or draw). So I create a box actor derived from component and IDraw. When I try to acces to boxactor as an IDraw it just don't work. It's a matter of security level and such I know but it really shows that big game are really hard to do with these kind of architecture. In order to port the game into a game editor I tend to limit the maximum actual game code. also if I want to serialize my component is really limited and demanding.

I'm not really a critic since I may not do better and maybe I'm not using your tool properly, but I really want to know if there is any way to have some kind of gamescreeen using drawtoScreen ( sounds like no).

I'm really interested in this framework and I already invest a lot of time figuring out a lot of stuff I would be a little sad if it was for nothing.

Coordinator
Jun 2, 2009 at 11:39 AM

Hi.
Firstly thank you for the effort you are putting in. I really appreciate it! And I'm sorry if not everything is working out quite right at the moment.
And thanks for trying to explain what's going on. It sounds like a fairly complex problem, and I'm still not 100% sure I understand completely (eg, things like "When I try to acces to boxactor as an IDraw it just don't work" are difficult to figure out what's going wrong :)

The first thing I'll say, is that I've kept IDraw intentionally as simple as I felt I could. So in theory practically anything can implement it.
What this means, is that as far as the DrawTargetScreen object (or any DrawTarget) is concerned, all it's doing is calling a method on one or more objects saying 'DRAW!'.
So, what that object is doesn't really have any significance. It could be a list of 500 meshes, actors, effects and the like. Or it could be a single object that manages an external geometry system.

So, in your example, as you are using an existing engine, I imagine you already have existing setup for complex systems such as how to draw things, materials, etc.
And I imagine you already maintain a list of actors, meshes, effects, etc. Which are all processed in game specific ways by your scene graphs, etc.
This doesn't mean each and every one needs to implement IDraw and be put into the same list. I don't see any reason why you couldn't have a single object that interfaces with your engine and given all the geometry /materials to be drawn, simply loops of them and draws them itself. Does this make sense?

The most important thing for you (I'd imagine) is that xen/xna doesn't become too deeply embedded, and I understand this is always very difficult with any engine.
You could, (for an example) have 'ActorDrawer', 'EffectDrawer' (etc) classes. Or you could do it another way entirely (such as directly implementing the interface)

Not knowing much about the structure of your engine obviously makes it difficult for me to suggest what is best to do (it would be foolish for me to try) but what I can tell you is *how* you implement it I hope isn't being limited by what I've setup.

DrawTargets are intended to wrap the (often subtle) setup of XNA render targets to get it exactly right (it can go wrong surprisingly easily) and then call back via the IDraw interface when they are ready to do so. If you have one IDraw implementing object or 5,000 in the list doesn't really matter. And what those objects do also doesn't really matter.
The intention is simply to make it a fixed piece of functionality, you call Draw() on the DrawTarget object and everything is handled for you, instead of micro managing render state. The difference is you get a callback via IDraw.

 

Did I go on too much? :) or have I entirely missed your problem? :(