I'm writing a game engine in C++, and I want to design it so that each of the major subsystems (graphics, physics, etc.) is in a separate .EXE. The separate processes will communicate game object updates via shared memory. I am planning to use Boost.Interprocess to manage the shared memory.
My initial thought was to put all of the X-coordinates in an array of X-coordinates in shared memory, all of the Y coords in an array of Y coordinates, all the Z coords in an array of Z coordinates, and so forth. It would be natural to want to packages sets of these buffers into groups of related variables, and possibly normalize the data and make it relational.
At that point I realized I was designing a database, and that I should call the groupings of related data arrays "tables". Since my plan anyway was to use Sqlite to share complex or infrequently written data and Boost.Interprocess shared memory for the simple and frequently written data, this is serendipitous because I can use one abstraction / set of interface classes for both kinds of tables and have the rest of the game engine code agnostic of whether the shared data it is accessing is implemented as an in-shared-memory table or a Sqlite table. I could even move tables from one to the other to trade off speed vs. shared memory consumed.
However before I embark on this I want to know if an existing DB library could serve this purpose or could be easily modified to. The problem of ensuring that the data is stored in a portable way between processes is subtle and I don't want to have to solve that problem if it has already been solved by a reusable library.
I am not sure if my problem is a good fit for a general purpose DB because a general purpose DB will be written with asynchonicity, ACID, and search in mind. But since I control all of the readers+writers, I could simply use semaphores and/or scheduling/timeslicing to ensure reading and writing doesn't cause data conflicts. I don't need search or multiple indices, so I don't need something fancy like a B-tree implementation. Keys are just O(N) array indices. All of the read and writes would be bulk operations.
And obviously it all needs to happen at 30 or 60 FPS without unpredictable latency.
Given these constraints, is there any existing library that might work?
Aucun commentaire:
Enregistrer un commentaire