Back to the topic, I did some 5-6 tutorials with the old OpenGL, now the next best step seems to be to read "Learning Modern 3D Graphics Programming" (why do people use the word "modern" in a book, I've always wondered). Nevermind, hope I don't have problems.
Thats a really nice online book thingy. It teaches pure "core" OpenGL, so no deprecated stuff at all. It also nails down the math nicely.
A bitset with 1,000 bits fits into two cache lines (64 bytes per cacheline = 512 bits per cacheline), and the very first iteration will shrink this to one cache line (it halved the search area), meaning AT WORST this causes one cache miss.
Wait a second, you're mixing a bunch of things: First you mentioned binary search over a vector, not a bitset. Second, you're suggesting binary search for iteration? That doesn't makes much sense, it wouldnt help you for iterating over a bitset.
For binary searching through a vector (what you initially suggested) you'd need 1000 ints for the IDs, thats 4kB of data and it'd really involve a bunch of cache misses.
There are plenty of ways to iterate over the bits of an int, but it has to simply check if each value of the backing array has any single bit on before fetching the next one, regardless of the technique you use to iterate over the bits themselves in the single int.
I wonder how fast a binary search over a vector would be compared to a custom bitset implementation...
Binary search fcks up the CPU's branch predictor. Its pretty much one random jump into memory each iteration, hard to predict, and many times the branch decides which memory segment needs to be loaded next if they're far apart enough, thus hindering the CPU's ability to preload it into a cache line. This cost is amortized if you're handling a lot of data.
Bitsets its a couple bitwise ops to find the word index in the array, jump to it, then do a couple bitwise ops again. Much more straightforward (although not as memory efficient if they're very sparse).
So I cloned Artemis Spaceship Warrior demo game, adapted it to dustArtemis (my own fork of artemis), made it spawn a shitload of enemies and bullets and I can play with around between 7k and 12k active entities flying around according to the counter, at 300 fps (minimum). Which is 3.3 milliseconds for each frame of the entire game, and its made on libGDX, which isn't known for performance. I get over 100k entities created and deleted after playing the game 15 seconds like this, 3.3 ms per frame minimum.
(it has a high entity count because each bullet, particle and background star is an entity, so it gets crazy high).
Don't draw to the front buffer. It causes artifacts.
The front buffer is conceptually the one you're showing in the monitor. So any tiny change in there will cause artifacts. Don't touch it. If you need more buffers, learn how to use framebuffer objects.
What I am looking for is some advice on possible implementations of a game engine that is able to handle many (100+) different entity types (e.g. Wrenches, Clothes, Wall segments, Grilles, Chairs, etc. etc.) and also efficiently allocate resources for many instances of that entity (50+).
5000 entities then? Thats nothing. Anything will work fine with that, unless you do something terribly wrong of course.
Also if say, a chair is something static, and a wall is static, its not a different entity. They're the same static kind of entity, with different textures. I very much doubt you'll have that many different kind of entities.
A game like Skyrim was made with probably less than 100 different kinds of entities (npcs, quests, statics, animated, weapon, armor, spell, and a couple more, thats it). Yours wont have as many as you think.
Hi! I wanted to hear your opinions on how to manage game objects IDs, at runtime and in save files or game data. Have in mind I'm talking about a persistent world, RPG, think of any Elder Scrolls game (Oblivion, Skyrim, etc), also single player, so no additional restrictions for network stuff.
Currently my tiny project has only runtime entity ids only for the things currently loaded, which means I create an entity, which has an ID, and use that to fetch its components when I need them. After the program is closed, everything is lost.
Eventually I'll have to move this into some form of persistence, I'd need a way to store entity instances and their IDs, for normal base game data, and do the same for storing player's save files.
Afaik Elder Scrolls games have a couple of "levels" for this data:
First is the main game data. This stores the base game data for all things (NPCs, places, quests, etc). All objects have their own ID.
Second the "plugin" data. This stores official addons, mods, and that kind of thing. These also have their own IDs.
Third is the player data. These are the game files, I'm assuming it kinda works like the other two, storing the IDs of things the player modified from the base game (say, player killed an NPC, solved a quest, looted a dungeon, etc, that stuff will be stored there,), and also the things the player "spawned". Say that you spawn a demon companion, that NPC is new, or say that you crafted a sword, etc.
I'm not quite imagining how to handle such things. For example, if we're going to make a new unique ID for a crafted sword, we need to know all used IDs in the game, even for stuff that isn't loaded so not to step over an existing item. I'm guessing the ID list is either present in memory all the time, managed through an embedded database or memory mapped file maybe.
Thats fine because we know the IDs occupied by the base game and the ones the player modified. But what if the user makes a mod that adds a new item? Or if I release an official addon that adds a new town or something?
Now I'd need to patch up all the IDs of the addon, and/or patch up the IDs of the player's save game and all their references. Moreover, now the load order of the game data matters. If I load up an addon or another before/after they were before in a previous game run, their IDs will be different (ie, run 1: addon a gets loaded before addon b, so addon a IDs are smaller, run2: addon b gets loaded after addon a, addon b IDs are smaller now), and thats a whole different kind of ID patching D:
By itself nothing really. Its an overview on how game engines are architectured, what kind of subsystems they have, how they communicate, with advice on how to go about designing them and coding them. That is why its "Game Engine Architecture".
And its big, its big because game engines are fucking big. So I'd advice you to read it anyway, so you know what you're getting into.
I'm wondering if you guys are aware of any simple C# projects that I can contribute to.
Small open source projects tend to be very personal, like one or two dudes team. You'll have a hard time convincing them they need your contributions.
You could fork something and expand it instead, but without a use case its useless (developing libraries in the void tends to do that).
So I don't think this is a feasible approach.
What you could do is develop your own projects, but read about the libraries you use, see their sources, see how they're developed. Maybe then, after you've used them, understood their development and gained experience, you can start to contribute back.
And as always, bug reports, those are contributions too.