Jump to content

The new database system


EleSigma

Recommended Posts

So with the database being implemented in .20, what exactly does it do for the game? I remember a long long time ago (when there were still dev streams :( ) Nova or Harv mentioning that the database would allow the continuation of implementing new planets and working around overworking the unity engine somehow.

Link to comment
Share on other sites

It's not just about moving files around, the big thing is how they're handled.

Before, the primary entry point for assets were the .cfg files. That is, the game would go through all the part.cfgs (and others) it could find, read them and load files as needed. For instance, the part.cfg for the mk1 pod says it needs the mk1 pod mesh, its texture and some sounds, then each of those were loaded into memory in order to build the part.

Now, it's a much more efficient system. Instead of doing the above, we go through the assets first, loading every model, texture and other asset we find on the GameData folder structure, and only afterwards we run through the cfgs, and we assemble the parts, internals and other cfg-defined stuff.

This at first might not sound like it makes much difference, but it enables a few key things to happen. Most importantly, we now get to re-use assets across many parts. So if two part cfgs call for the same texture, it's already loaded, so we just use it again.

Also, we can load assets regardless of how they'll be used later. Take flags for instance. The new database loader system made it very simple for us to just add a Flags folder, where we can find bitmaps to use as flags. The loader itself just puts it in the game. The flag logic later is what gives them a use.

This works for just about anything. Imagine you're writing a tutorial, and you want to draw a texture on one of the tutorial pages. Before GameDatabase, you'd have to write the texture loading routine for that single asset, inside the tutorial logic itself. Now, you can just ask GameDatabase for the texture by giving it a url path, and not worry about file handling on bits of code that are doing other jobs.

There's a lot more to it, of course. But those are a few of the advantages we gained by switching to this new system.

Cheers

Edited by HarvesteR
Link to comment
Share on other sites

Now, it's a much more efficient system. Instead of doing the above, we go through the assets first, loading every model, texture and other asset we find on the GameData folder structure, and only afterwards we run through the cfgs, and we assemble the parts, internals and other cfg-defined stuff.

This at first might not sound like it makes much difference, but it enables a few key things to happen. Most importantly, we now get to re-use assets across many parts. So if two part cfgs call for the same texture, it's already loaded, so we just use it again.

Does this mean the loader checks if a texture has already been loaded, regardless of path (i.e. CRC Check)?

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...