It is "simply a informational/posted for further critique or advice". I was trying to show that loading into a .dll is pretty trivial with my setup, although I like embedding more.
By the way, a big reason for asking this question was to find out why so many games embeds pretty much no data into the executable, while it doesn't seem to have any disadvantages.
Of course, embeding into the executable is faster than reading from disk.
Yeah, i'd like to see proof of that statement.
In general a large executable will be swapped to disk, and plus windows doesn't load all the resources for an executable into memory unless it needs to. It will generally memory map the resource data as requested. Therefore, technically you are still reading it from disk, it's just the read operation is hidden from you under the LoadResource() etc call.
I disagree just a little with what Josh and Frob have said: Embedding your assets into the executable makes for an awful time in adjusting them without a rebuild and without technically oriented developer-centric tools like resource editors. Definitely make them separate unless you have pressing reason not to. Any non-technical team members, e.g. artists and musicians, will thank you in the long run...
I was trying to show that loading into a .dll is pretty trivial with my setup, although I like embedding more.
Okay, although I don't see what that example really does, as there is no DLL there and there's also no real embedded there. It looks like a bunch of overcomplex macros to fill out an enumeration. Unless your postprocessing that further or something?
By the way, a big reason for asking this question was to find out why so many games embeds pretty much no data into the executable, while it doesn't seem to have any disadvantages.
I disagree just a little with what Josh and Frob have said: Embedding your assets into the executable makes for an awful time in adjusting them without a rebuild and without technically oriented developer-centric tools like resource editors.
Er, but that's basically what I said?
The right solution has to meet your needs.
Big games are seperating files because :
a) Seperate assests per level/feature, not everything need to be loaded at once.
b) They can seperate their files into several batches.
c) Easier compression.
d) Easier resource managment. (AAA games include several teams working concurrently so if you need to replace something you can do it easily).
For small games I'd recommend embedding it into the executable because it allows a smaller package.
For small games I'd recommend embedding it into the executable because it allows a smaller package.
For small games I'd recommend embedding it into the executable because it allows a smaller package.
A resource doesn't magically shrink because you embed it into an executable.
This is probably not what WoopsASword meant, but its worth mentioning that packing very small resources, such as small, low-color sprites, into a file together can actually reduce the size of your installation on disk. Prior to 2009, 512 byte disk sectors were the standard so a 16x16 pixel, 8-bit sprite would consume a whole disk sector even though it only needed 256 bytes, for 50% wastage -- you couldn't make the physical file any smaller, but you could have stored another sprite inside "for free". After 2009, disk manufacturers started migrating to even larger, 4KB sectors and this was the majority of disks starting in about 2011; this would result in about 94% wastage (you could store up to 15 additional sprites "for free"). Of course, 16x16, 8bit sprites are not so common today, but a 32x32, 16b color sprite gets us right back where we started with 50% wastage, or 32x32, 8-bit sprites waste 75%.
The flash in SSD drives is (exclusively, as far as I know) 4KB sectors physically in silicon, so 4k or larger logically; and these 4K physical sectors are the unit of write-cycle endurance as well, so its extra considerate of SSD users to fully utilize each sector.
If you have lots of individual files that are smaller than 4k you really should consider packing them together to eliminate wastage, such as by packing sprites into a sprite sheet or simply flat-file. I mention this specifically since its a relevant consideration for 2D sprite games (lost of small images that aren't compressed) -- of course if you have larger textures/images and especially ones that compress well with acceptable quality, standard compression will do you fine with minimal wastage.
I still would not pack those kinds of files into the executable itself (better to pack them together in files/units that make sense), but it would achieve having less wastage all the same.
For small games I'd recommend embedding it into the executable because it allows a smaller package.
A resource doesn't magically shrink because you embed it into an executable.
I meant a smaller package by "Not too many files".
But Ravyne actually got a good point out of it (Hooray comments at 2 am).
And I've studied it a while ago, Memory is not always sequential and fragmentation issues often arise because the OS reserves memory or doesn't use all the allocated memory.
A good example is RAM. Even if the OS or the disk itself stores the memory sequantially (Let's assume that for a second), The loaded memory is not always sequential and then you hav whole sectors that are almost empty because the allocated memory is not big enough to fill the gap.
While if you had this part of embedded reasource, it whole fill the allocated memory it requested.
