structure of d3d programs

Started by
-1 comments, last by rileyriley 22 years, 4 months ago
I''m pretty new to D3D, and am attempting to convert my game from OpenGL to it as a kind of excercise. The program is structured so that each object in the game world is an object in the program, with a different class representing each type of object. All objects were derived from "Object," which had an array of vertices that would tell the "GamePainter" how to draw that object. Now, I''m trying to convert that to D3D. However, I''m also interested in switching to "meshes" and functions like D3DXCreateSphere, with perhaps the option of using x files to get models that don''t look like I did them by hand on graph paper (shh, don''t tell anyone ;p). Anyway, the problem that I''m running into is that you need a d3d device in order to manipulate a mesh (right?), and I certainly don''t want to make a new device for every single object I want to put into my game. I''m also kind of resistant to putting a pointer to a global d3ddevice into the object class. The options I''ve thought of so far are as follows: 1 - require that objects be "initialized" from within the GamePainter class before they can be used. The "initialization" function would take a d3d device as a parameter, use it to make it''s spheres or teapots or whatever, and store the resultant mesh as a member variable. Then when it needs to be drawn, the GamePainter can access that member variable and call DrawSubset on that. 2 - store the graphical representations of the objects outside of the class that is responsible for all of the other details about the object. I don''t really like this idea either, just because the objects would end up kind of smashed together in that area, and it seems like it would get sloppy. Does anyone else have any other suggestions? What do people think about the ideas I''ve already come up with? Thanks for any help, Riley
--Riley

This topic is closed to new replies.

Advertisement