I'm building my own game handmade style as I work through the episodes, except that the characters are in 3D. I'm now at the part where Casey moves the renderer into a 3rd tier, and here is where I'm running into problems.

My main issue is with the asset management: I have compound assets (textured meshes with skeletons and animations). Up until now I have stored these embedded assets as indices, which is no problem as the renderer has access to the asset cache and can quickly grab pointers to whatever it needs for each mesh. But what do I do once the renderer is on the executable side? Have both indices and pointers to these embedded assets? That doesn't seem very clean to me, but I can't think of a better solution other than exposing the asset cache to the renderer which would be a mess.

What do you mean specifically by "clean/mess" ? Forgive me if this is something talked about in later episodes, I haven't made it through all of them, but what do you mean by "executable side?" and why would the renderer move? like do you just mean moving the renderer into a third tier?

Almost from the get go Casey splits his code into two parts: platform layer, and game. The platform layer is compiled into an executable, and the game layer into a DLL which is reloaded whenever the platform layer detects it has been changed. Initially the renderer is on the game side, where the asset cache sits, but then he will move it over to the platform side when he starts implementing OpenGL rendering.

By clean / mess I mean general stuff like keeping subsystems as separate as possible, avoiding redundant data, etc. Casey goes over some of this stuff in ep. 26.

The renderer is kinda special in that way since the way you handle assets pretty heavily depends on how the renderer needs them.

Modular design is great and all but don't let it get in the way of usability or performance.

For example every graphic API of the last decade lets you map buffers. So the ReadFile entire file into memory to then give to the renderer which then uploads it to gpu is a memcpy (or two) that you don't need to perform.

Instead map the target buffer to memory and then read the asset data straight into that. If you are careful with alignments no memcpy will be performed and the cpu will never even touch the data.

All this requires that the asset loading code talks to the renderer.

ratchetfreak
Instead map the target buffer to memory and then read the asset data straight into that. If you are careful with alignments no memcpy will be performed and the cpu will never even touch the data.

Thanks for the reply.

I don't know anything about memory mapping because I've been trying to keep the 3D side of things as simple as possible, but I think I understand. Wouldn't it be possible however to use the render command system to get the mapping done without exposing the inner workings of the asset system? If the renderer has access to the asset file handles (which can be sent as part of the command), then you can send it file offsets into the data, and a pointer to a region in the cache that you want to map. The renderer would need to update the asset state, but I think that's all it would need to know about assets.

I really don't want to deviate too much from Casey's basic architecture so I don't paint myself into a corner.

aspiring_dev

Thanks for the reply.

I don't know anything about memory mapping because I've been trying to keep the 3D side of things as simple as possible, but I think I understand. Wouldn't it be possible however to use the render command system to get the mapping done without exposing the inner workings of the asset system? If the renderer has access to the asset file handles (which can be sent as part of the command), then you can send it file offsets into the data, and a pointer to a region in the cache that you want to map. The renderer would need to update the asset state, but I think that's all it would need to know about assets.

I really don't want to deviate too much from Casey's basic architecture so I don't paint myself into a corner.

but then the renderer needs to know how to read files. Also what if you use compressed files for your assets? Now your rendering system needs to contain a decompressor even when other parts of the engine needs to decompress data as well using the same decompression algorithm.

ratchetfreak
but then the renderer needs to know how to read files. Also what if you use compressed files for your assets? Now your rendering system needs to contain a decompressor even when other parts of the engine needs to decompress data as well using the same decompression algorithm.

I think my solution was a perfect example of the cure being worse than the disease. I agree, the renderer shouldn't be abusing the platform layer like that.

I'm going to give this some more thought before committing to anything, and start looking into memory mapping as well.

Thanks!