Engine Design Help
Author
I''ve just been playing around with a bit of design and I''m running into headaches left and right.
I''m trying to design a simple engine with the following ideas:
-All objects are linked or parented in some way such that you can get to every object by traversing a linked list.
-Rendering code is abstracted so that the engine doesn''t become dependent on a particular API.
-The engine itself consists of a few items which define the world, and also some controllers (like texture managers, font engine and such).
I''m wondering about two things here. Trying to abstract the API is giving me a hard time because I''m not sure how to handle the loading of textures and such so that they would be compatible with different APIs. Initially I though I''d store just the bitmap array data, but then I realized that I''m losing all kinds of info that I need like compression. Also storing all textures in memory doesn''t seem like a good idea, and I need some kind of efficient way of requesting a texture and keeping common ones in memory.
Another issues is the sorting of all objects. I can get to every object by starting at the root, but its not the best order for drawing them. Perhaps you guys have some pointers on how I might use texture id''s to render objects using the same texture... and also ideas on how to sort the objects for rendering.
Basically the root node is everything. It splits into 3d and 2d... 2d would be UI elements and such that get drawn. I''m thinking using some kind of panel system to group UI elements for easy transformation and such would work well. So in my linked list I''d add a panel to the interface node, and I''d add text and other UI controls to the panel. That way I could move, scale, rotate a panel easily.
One issue with the panels that is driving me nuts is do I want to treat all 2d elements as 3d objects? If so, is there a more efficient way of drawing them then to texture a rectangle? I''m thinking that if I have a rectangle for each character and each element, I''d be dealing with a lot of geometry since each object would require 4 vertexes and such (2 polys).
I''m just looking for some general pointers, ideas, concepts to intergate into my design.
Appreciate all your input guys,
Aaron
how about an entity based system
adding physics to above
-- Start by creating a visual to represent my entity. For this -- example I''ll just use a simple textured cube local cube = StdLib.Cube(1, 1, 1) local shader = Render.Shader() shader.texture = io:fromFile("Data/moon.png") local visual = Render.Visual(cube, shader) -- Putting it into a Body allows me to attach it to the entity local body = Scene.Body() body:addVisual(visual) -- Finally, assemble the entity. Note that the Pose must appear before any -- attributes that it is to effect, so it usually should be first. self.entity = Scene.Entity("MyEntity") self.entity:addAttribute(body) adding physics to above
The Physics attribute provides rigid body simulation, including collision response, to an entity. It works as a drop-in replacement for Pose, and automatically updates itself according to the physical properties which you set. local pose = Scene.Physics() pose.body.mass = 10 pose:setPosition(10, 10, 0) entity:addAttribute(pose)The Surface attribute provides a collision detection volume and collision response parameters. Use this attribute for anything that may be collided with. local surf = Scene.Surface() surf:addBoundingShape(Collider.BoundingSphere(1)) local response = Physics.ContactPhysics() response.friction = 0 response.restitution = 0.5 surf:setContactPhysics(response) quote:I''m not sure how to handle the loading of textures and such so that they would be compatible with different APIs. Initially I though I''d store just the bitmap array data, but then I realized that I''m losing all kinds of info that I need like compression. Also storing all textures in memory doesn''t seem like a good idea, and I need some kind of efficient way of requesting a texture and keeping common ones in memory.
If you wish to support multiple APIs, like Quake 2 does, or like I did in my 3D engine :D You need to have a different texture format for each API. Some APIs don''t even store the coloring info in the same way. This can be done with a base class. You also usually want to keep a reference count (based on the file name) to textures in a texture manager, so that you only load a texture once, even if its used 200 times.
quote:Another issues is the sorting of all objects. I can get to every object by starting at the root, but its not the best order for drawing them. Perhaps you guys have some pointers on how I might use texture id''s to render objects using the same texture... and also ideas on how to sort the objects for rendering.
First, you usually want to partition your 3D space, using one of the well known techniques available (BSP trees, Octrees, portal system). Most engines treat level geometry (polygons) and entities (interactive objects, players, monsters) separately. You can re-order the polygons within nodes so that they are ordered by texture. For entities, as they are dynamic, and there are usually not that much, you don''t want to bother with texture sorting (some entities don''t even use textures).
Space partitions also have the benefit of speeding up collision detection... Also, you can develop an entity hierarchy (scenegraph). Basically, a weapon belongs to a player, the player can belong to a vehicle, etc... This can speed up collision detection and rendering if the lower level entities are comprised within the culling volume of the top level entity.
Looking for a serious game project?
www.xgameproject.com
Author
Some more questions, what would be a good way to write a texture manger that could map a Unique ID and the filename to the data...
I want to have multipal texture managers (one for dynamic data and one for ui) But also if I load a UI element i want to load the textures to another tempoary manger or something...
is there a std:map that supports more than one index?
I want to have multipal texture managers (one for dynamic data and one for ui) But also if I load a UI element i want to load the textures to another tempoary manger or something...
is there a std:map that supports more than one index?
I don't understand why you'd need more than one texture manager (or what you mean by dynamic data). You should not have to use more than one texture manager.
For your texture manager, you could use an stl map to associate the actual texture data with the unique id (which could be the filename) as the key. You'd keep this map in a texture manager singleton class, and the flow of code for loading a texture would look something like this:
Your global texture manager would the stl map for the filename, and if it wasn't there, it would make a new entry, load up the texture, and return a pointer to it. If the filename was already there in the map, it would just return the already loaded texture using the stl::map::find() function.
When you need to bind the texture, you'd just call something like this:
The binding call wouldn't require a stl::map lookup or anything, it would just bind the data pointed to by myTexture. You could even set up a mechanism that keeps track of the current texture so that if you did this...
...the actual binding would only happen once.
You really only need just one texture manager.
[edited by - GreenToad on March 26, 2004 7:46:56 PM]
For your texture manager, you could use an stl map to associate the actual texture data with the unique id (which could be the filename) as the key. You'd keep this map in a texture manager singleton class, and the flow of code for loading a texture would look something like this:
Texture* myTexture = GlobalTextureManager.LoadTexture("filename");Your global texture manager would the stl map for the filename, and if it wasn't there, it would make a new entry, load up the texture, and return a pointer to it. If the filename was already there in the map, it would just return the already loaded texture using the stl::map::find() function.
When you need to bind the texture, you'd just call something like this:
GlobalTextureManager.BindTexture(myTexture);The binding call wouldn't require a stl::map lookup or anything, it would just bind the data pointed to by myTexture. You could even set up a mechanism that keeps track of the current texture so that if you did this...
GlobalTextureManager.BindTexture(myTexture);//draw stuffGlobalTextureManager.BindTexture(myTexture);//draw more stuff...the actual binding would only happen once.
You really only need just one texture manager.
[edited by - GreenToad on March 26, 2004 7:46:56 PM]
Author
Only reason i was thinking more than one is that, you can destory an entire collection of maps a lot faster when u do like a level change...
what i should of probably said is texture collection since yeah i would only have one interface to textures but it would be easy to load up a collection and later destory it without having to check each texture and such
what i should of probably said is texture collection since yeah i would only have one interface to textures but it would be easy to load up a collection and later destory it without having to check each texture and such
Author
The other issue is that some objects might have the same name for a texture... so i need to either track it using the whole path to the image... or i was thinking doing the hash trick to generate the id....
how good is the hasing thing? ie with... say... 5000 textures... are u gonna endup with the same hash values?
how good is the hasing thing? ie with... say... 5000 textures... are u gonna endup with the same hash values?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
