Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.






Starting again

Posted by speciesUnknown, 19 December 2009 · 157 views

Its been a while since I last made a journal post (over a year I think) mainly because development slowed considerably; also, ive been working on physics rather than graphics, until now, so there wasnt much to show.

Here, have some per pixel lighting:
per pixel lighting with point light

However, people keep wanting to see screen shots, so ive decided to work on the renderer for a while. I've set up a nice system for loading / linking shaders, and I've vastly simplified my resource loading system. The previous system relied on loading a single resource, asking it what its dependencies were, and then loading those. This was fun when I was an academic, but now I realise it was overengineered and innefficient.

I have a new system, which took me approx. 1 day to write; whereas the previous one took two weeks. My engine is designed to load from two kinds of data; it can load from intermediate files, in which case it must calculate dependencies (I've hacked this up and its slow, but its not critical for loading intermediate files) and then each resource is stored in a table with a string key. Next, I assign each loaded resource an integer ID, and create a vector of references to each resource; this means I can perform an O(1) resource lookup, and I mean proper O(1), not an ammortised one; and its considerably faster than any kind of hash table. I then give each resource links, through these integer ID's, to all their dependencies.

This is a slow process, but it does have several advantages; once its done, I can index resources without having to give each object a pointer or reference to its dependencies. I can bind dependencies instantly by directly accessing the pointer.

When I serialise my resources into blocks of data, I send the integer ID's along with them; this creates a header file for each block of binary data. I can serialise the entire resource manager, or individual tables. From here on, its the same as my old resource loading system, except without the need for linking resources to each other. Rather than gathering a shopping list, I lazy load every resource, and demand that every resource table provide a suitible fallback resource if a resource that was requested is not currently available.

When the game loads from packed blocks, it first loads the headers of each resource table, which is simply the integer ID, the string name (which is still useful) the block they are within, and the start / end point within that block. When a resource is needed, it will load its data and cache it in GPU memory. There is no need to link resources because they also know the integer ID of their dependencies.

This should make things simpler, and faster when loading from blocks of data.




November 2014 »

S M T W T F S
      1
2345678
9101112131415
16171819202122
23 242526272829
30      

Recent Entries

Recent Comments

Recent Entries

Recent Comments

PARTNERS