Jump to content
  • Advertisement
Sign in to follow this  
Nemesis2k2

Type safety, templates, mutable classes, and serialization

This topic is 4680 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

The title doesn't really sum up my problem, so please read this in detail. I am implementing some "basic" resource types for my engine. The two resource classes that are involved in this problem are VertexBuffer and IndexBuffer, both of which inherit from a virtual base class Resource. Both are defind as follows: IndexBuffer is an array of indices. Indices can either by 16-bit integers or 32-bit integers. VertexBuffer is an array of vertices. A vertex is a collection of attributes. A single vertex in a given vertex buffer may or may not have various inbuilt attributes, such as vertex position, normal, color, etc. These attributes may be either of type float or of type double, and data types can differ per attribute within a vertex (this point is flexible). In addition, a vertex may have an unlimited number of custom attributes for use in vertex shaders, either of type float or double, with up to 4 elements per custom attribute. In addition to that, outside entities must be able to obtain direct pointers to each attribute at each vertex, in order for the renderer to obtain pointers for rendering the interleaved array. It of course follows from this (and basic performance concerns) that each vertex and its elements, if they are to be implemented as classes, must be POD types. In addition to these resource types, there are nodes in my scene graph which reference these resource types. There is an Object class, which references a VertexBuffer, and there is an IndexedObject class, which references both a VertexBuffer and an IndexBuffer. In addition to this, I must be completely free to create vertices that have new attribute compositions at runtime, switch the type of VertexBuffer and IndexBuffer an Object node refers to, even if the types and attributes differ to the previous ones, at runtime without re-creating the node, and as if it wasn't as complex enough, all resources and nodes much be completely serializable to disk, meaning based on an ID and some stored data, these objects must be completely re-createable. Now I've got all this working, but I'm not all that happy with it. I've got void pointers flying around the place and all that kind of nasty stuff. I'm not making use of templates at all, as I couldn't think of a single way I could use them in this context without breaking at least one of the requirements, and the requirements aren't very flexible in this case. As a result of all this, I have no type safety whatsoever in this area, and it's not a situation I find ideal. I haven't been able to find a way to solve this problem however within the constraints of the C++ language, so I'm asking if anyone has any suggestions, or if anyone else has solved this problem and has a solution they're willing to share, before I give up on improving it for the time being and move on to other areas. I haven't had to resort to a single thing I consider a hack however anywhere else in my design, and I really don't like the ugliness this introduces. It's far too brittle for my liking, and vertex buffers and index buffers are two of the most fundamental resource types there are in a current 3D engine. Any suggestions would be appreciated.

Share this post


Link to post
Share on other sites
Advertisement
I think i know what your getting at, you want something akin to DirectX's Vertex Declarations but in a portable and type safe manner. There was a discussion about this in #graphicsdev chatroom and believe it or not what you have is probably the most flexible system despite it not being very nice although there is way you can have type safety but at the cost of some rigidness and dynamic dispatching/binding.

You can use pointer to data members and a technique called automatic type erasor for your Vertex Declarator type. I'll code something up and post here later for you to see.

[Edited by - snk_kid on August 27, 2005 6:56:25 AM]

Share this post


Link to post
Share on other sites
Actually scrap that idea its not worth overhead of dynmiac dispatching on such low level types with little gain, considering you are going to be dealing with POD-class types you can do it all with offsetof macro in header cstddef and always add a type safe layer over it with just templates etc.

For serialization you could check boost serialization

[Edited by - snk_kid on August 27, 2005 6:29:58 AM]

Share this post


Link to post
Share on other sites
Thanks for the input snk_kid. I'll probably just tweak what I've got then. I've got some ideas about how I can make it a bit safer than it is currently.

I looked at boost serialization quite a while ago, and ultimately decided against it. Some of the goals and supposed outcomes of it were unattainable with some of the resources I would be working with. Compressed textures for example cannot be stored in a platform-independent form, as issues like byte order, and more significantly twiddling, are platform dependent, and the engine itself won't have knowledge of the precise structure of each texture format for each platform, it just passes it to the rendering API. If the user must specify the target format when exporting the texture, he may as well do it with the rest of the resources too. At the end of the day, I decided I'd go with a simple chunk-based file format. The precise knowledge and control over the file structure has proven beneficial, and ultimately I don't think boost serialization offers me anything extra that I need which I haven't already got with my own system.

Share this post


Link to post
Share on other sites
Why would it need to know the format of the texture at all? You simply use some simple common format. For that matter, why would you want to serialize game data at all? You save the game state; theres no need to save the model and texture resources.

Share this post


Link to post
Share on other sites
Quote:
Why would it need to know the format of the texture at all? You simply use some simple common format.

My engine has to be able to support multiple texture formats, specifically it must be able to support a variety of both uncompressed and compressed texture formats, and it must do so on multiple platforms where these formats are implemented differently. The only way I can achieve this without my engine knowing the precise layout of each texture format for each platform is to save it without deconstructing and converting the texture data, either when saving or loading. The generation of texture resources is handled by my texture exporter for photoshop, the rendering API, and nothing else. No simple common formats offer the variety of platform and format support I would require in order to be able to rely on them for my engine. Besides, they're all little more than a header slapped on some data anyway. I can add my own header. The layout of the data is dictated by the hardware.

Quote:
For that matter, why would you want to serialize game data at all? You save the game state; theres no need to save the model and texture resources.

There is the allowance in my engine for the user to generate and modify resources at runtime. Although personally I wouldn't be generating any resource at runtime I couldn't derive from other data attributes upon reloading, the allowance is there. At any rate, the resources themselves are stored in a unified format which is handled by my engine. Textures, models, sounds, etc can all be stored together in "resource libraries", which are single files which can store any type and number of resources. These resource libraries are created by the tools that support my engine, and they all use the same engine as the game uses, hence the engine must support the serialization of resource files.


Back to the point, Boost serialization would offer me nothing of benefit over my current system.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!