Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 08 Mar 2000
Online Last Active Today, 03:48 AM

Posts I've Made

In Topic: Low level serialisation strategies

Today, 03:47 AM

You say this is 2 separate problems, but I don't see it that way, because even "largely-static data" can have a "complex, richly-typed, and dynamic [..] in-memory representation" (forgive the quote-juggling). If I have a 3D model, with vertices/indices/materials/shaders/textures/animations, some of which are obviously composed of the others, others merely associating with the others, that's all static data (as far as running the game is concerned), but is going to have a relatively complex in-memory representation. No?


I think what I've found interesting is that some developers have exactly that - fairly complex objects in memory - that they're reading in via fread and some fancy pointer twisting. I guess that is probably facilitated by something in the build process ensuring these objects are all contiguous - or just writing them out in such a way and going back to patch up pointers later. Since I've never worked on the build pipeline I've not been exposed to these methods before; it's only after hitting a couple of deserialisation bugs that I realised this sort of thing was common.


Let me steer this towards a practical question then; for those using these low-overhead methods, what are you doing to ensure that the layout of data is exactly what you expect - endianness, platform dependent types, 32bit vs 64bit, alignment (inc. SIMD requirements), padding, etc?

In Topic: The right tools for making a FM-inspired database reliant manager game?

Today, 03:08 AM

What you're working to create is something known as a CRUD application


I agree with the rest of your post but this line implies that the game would be allowing the user to add and delete rows from a database, but that's not really the case. The database will pre-exist (at least in some form) and the user will mostly just be shown different views on it based on the game state. Apart from the fact that it uses a relational back-end, it won't have much in common with a typical database accessing-application at all.

In Topic: Low level serialisation strategies

25 August 2016 - 09:02 AM

There is no reading code -- you declare those structures and then you use them without a deserialization step.


Right, I guess I just can't mentally work out how that operates given the code that you show, because (for example) the writing code has appeared to add a stringtable at the end that didn't exist prior to serialisation. No doubt there's something tied up in the StringOffset and Offset types that does the magic!


Some code I've worked with was exactly like that - per-field serialization, load-blob-and-cast deserialization. And I think that was the approach that caused me the most problems, mostly because there was no real attempt at making the types work well with it, just a mixture of POD types (which work fine, when you stick to explicitly-sized types), structs (which align differently on different platforms, breaking stuff), and pointers (which change size based on architecture, breaking stuff, and requiring a fix-up stage, and some sort of composition vs. association strategy). I expect that can be mitigated a lot if the pointers are all replaced with smart pointers (and ideally ones that understand association vs composition).


Personally I wouldn't really want to change a lot of the types involved in the data just to facilitate quicker serialisation; but I can see that it's definitely something people can make a case for (and especially for the GPU data like you said).

In Topic: Converting world rotation to body rotation

25 August 2016 - 07:40 AM

You can't know anything intrinsically about the plane orientation just from the camera orientation alone. If there is another data source you can use to get the plane orientation, you can just compare the two.

In Topic: Low level serialisation strategies

25 August 2016 - 07:21 AM

You only use this for plain old data. If you're building an engine system and want to be able to load it form disc with a memcpy, then you're able to make the choice to design it as POD.


I guess I find it hard to imagine a situation where I could do that and still find the code convenient to work with. Some objects are intrinsically hierarchical, and some have varying length contents; trying to flatten all that just seems to move the complexity out of the serialisation and into everywhere else in the engine.




your build system needs to generate binaries for each platform


Sure, but it's easier said than done, especially when you have pointers and you're going for a memcpy/fwrite type of approach.


Re: the stringoffset stuff - what I understand of it looks much like some of the pointer serialisation stuff I've dealt with in the past, but the code is essentially back into writing out each field one by one, right? Which isn't a bad thing, just that I thought you were trying to avoid that. And the reading code would appear to have to do the same.