Jump to content

  • Log In with Google      Sign In   
  • Create Account


File Loading Module


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 LuckieLordie   Members   -  Reputation: 110

Like
0Likes
Like

Posted 22 May 2013 - 08:32 AM

Hey guys,

 

I've been thinking over a problem today and I wanted to have some input from you lot! :D

I have a DX11 engine I'm building up and I need a system where I can load in different model types, .obj, .md5 that sorta thing. But I can't seem to come up with a way to decouple the file loading from the data itself. 

 

I thought I'd start here because you have much more experience than me :P 

 

3oaP1BJ.png

 

This is the general Idea I have in my head. Using FileLoadingManager as a singleton and IFileImporter as an interface.

 

How would you do it? Design limitations?

 

This is a learning exercise for me so throw books, examples and whatever else you want at me too :D

 

Many Thanks.



Sponsor:

#2 btower   Members   -  Reputation: 888

Like
1Likes
Like

Posted 22 May 2013 - 08:43 AM

I think the main problem with this design is the genericness of the FileLoadingManager. If you rename this class to MeshLoadingManager, things will be more logical, and also the return types of various loading functions in the class is alot easier to comprehend (i.e. the LoadFile method returns an object of type IMesh).

 

You will then need different types of LoadingManagers for each type of object you want to load (i.e. Mesh, Sound, Texture, etc). You can then make a generic FileLoadingManager that contains a MeshLoadingManager, SoundLoadingManager, TextureLoadingManager and so on, with a file extension map to the different types of loading managers.

 

I would also rename the classes to FileLoader, MeshLoader and I wouldn't make them a singleton.

 

Hopefully you can adjust your design based on the above.



#3 L. Spiro   Crossbones+   -  Reputation: 12675

Like
0Likes
Like

Posted 22 May 2013 - 11:15 PM

btower, on 22 May 2013 - 23:34, said:
I wouldn't make them a singleton.

Quoted for emphasis.

In any case, an engine should typically only support one file format and that format is a custom format.
If you want to support multiple formats, such as MD5, OBJ, FBX, etc., you would make a converter from those formats into your own format. These converters would also each be separate utilities, not one monolithic utility that converts just anything to your own format.


L. Spiro
It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#4 Steve_Segreto   Crossbones+   -  Reputation: 1483

Like
0Likes
Like

Posted 23 May 2013 - 01:09 AM

But I can't seem to come up with a way to decouple the file loading from the data itself.

 

What an odd statement. What does "decoupling the file loading from the data itself" actually buy you? What does it even mean? Are you suggesting you should write your own generic ifstream/FILE routines? What improvements would you add to the standard runtime ones? Endian flipping for loading cross platforms?

 

And why are you making an engine from scratch? Are you trying to accomplish a specific goal? If so, just code towards that goal and write little one-off resource loader routines as you need them.



#5 Tispe   Members   -  Reputation: 982

Like
0Likes
Like

Posted 23 May 2013 - 03:07 AM

In my project, the loading module is a class that encapsulates creating and communicating with a new thread. I pass the 'this' of the loading module to the thread so that the thread has access to memebers.

 

6 mutexes to control 6 vectors that contain "data packets (pointer to struct)", for bi-directional asynchronous communication to the thread. Rx/Tx for client side, Rx/Tx between, and Rx/Tx for the thread.

 

The client (calling code) can at any time push a data packet to the Tx vector and at any time pop a packet on the Rx vector. Each frame I "tick()" the class to move data between the cleint vectors and the between vectors. I only "tryEnter" on mutexes on client side to avoid blocking.

 

The thread has a main loop which ticks data to and from the thread vectors and the between vectors. We can block here so I use EnterCriticalSection.

 

The thread then uses OverlappedIO asynchronous file loading. It controls all of the loading progress. Once a load is complete is takes the file to a processing function. Once processed it is encapsulated and sent to the client.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS