So while working on a small game I discovered that the usual if statements for collision detection work fine for single directions, but when I had collision in multiple directions what would happen is say for example collision was detected in front of the player, but if there was a collidable to the right of the player, the player would be allowed to move to the right into the collidable. I discovered using bit manipulation works very effectively for detecting multiple directions. Below is not the code for my game but a very succinct example I made specifically for showcasing this. My question is, is there any drawbacks to this or any thing I should be cautious about when using this for collision detection?
So it's pretty much exactly the same as if I made a struct of directions and tested against that? Is there any benefits to using bit manipulation for collision as opposed to Boolean values? I'm thinking it would be fine for. Game like Pokemon blue where your constrained to a grid, but a game like Zelda link to he past where you can move freely, I don't know if it would be effective for that, and I don't know how complex either solution would have to be for something like a link to the past.
I was thinking of that as well, testing for only the direction the player is moving in or wants to move in, I'll have to look into that more though.
the computer works on a byte at a time. While bools can be compressed to bits (see, vector bool special case) they are not generally treated as such when doing comparisons and logic.
That means that in some cases, you can have better efficiency with a byte or up to 1 register's worth of bits (32 or 64 bits generally) WHEN THE PROBLEM LENDS ITSELF TO THAT.
So, for example, if you used 9 directions but only allocated space for 4 of them, you can be going north and east at the same time and may want to check 2 bits at once. You can't do that with bools or a struct of directions, but you CAN with an enum that is configured bit-wise for such logic.
I don't see any gains to be had from bits HERE, but maybe I am not thinking through your needs completely. If you can find a way to condense 2 or more comparisons into a single bit operation, and if you do ENOUGH of them in a tight loop or something that this microscopic performance gain has real merits, then you may want to proceed with bits.
If you do not have a LOT of them to do or you have no way to get a lift from using bits, then do not. Bit logic where it is not necessary is just confusing to the reader, as they muddle out what you did and try to fathom WHY you did it when its not necessary. Just don't do it in that case.
Note that fall-through switches can also be more efficient than if/then pairings. Here, its OK to use ... switch statements are not convoluted or difficult to follow so you may as well use them (they CAN be more efficient, but worst case, they are not LESS efficient than the alternatives, so use when you can).
If the other objects are stationary or relatively stationary (consider, planets for example can be treated as stationary over time periods like a couple hours, but in reality, they ARE moving) then you don't need to check for them moving into your path or ramming you from behind, ok, then only check what the object of interest is doing, what will it hit with its movements? In that case there are tons of optimizations you can do if the problem is gigantic (millions of objects or something bizarre, CFD or particle physics or whatnot) along the lines of grouping the objects into sectors by position or whatnot and only checking the ones that are actually potential collisions spatially. But its a lot of nonsense extra work if you are checking to see if your car will hit another car on a 2 lane road. Your common sense should tell you what the problem requires unless you are doing something very scientific. Also, if its just for graphical purposes, you can often fudge the collisions to do them faster without any notable loss to visual representation.
Another way is to just determine the new position and then check both X and Y. I put the mapWidth and mapHeight at global scope so inBounds() can see them. I also set the rocks outside the loop. They don't move. Finally, I changed the player's old position to a mapTile when I figured they were moving rather than every time.
what, exactly, does your struct bring that bool does not?
you can already default construct a bool:
foo = true;
z = foo
or whatever access
foo = false
and so on. the OOP is OSO (objects for the sake of objects, basically java code) that brings nothing to the table here... is there something you want to (but have not yet, perhaps) do with that object that justifies its existence?
That is not to mention the questionable name of it (Var? variant? Variable? ). George did a lot of work and using his name for the type is an honor to a founding father of computer science and related mathematics.
well i simply just like the way it reads haha. I find it easier to read and decipher code when it reads more like natural language, as for the Var name, I just named it that temporarily and forgot to change it cause i didnt have a better name for it. Its not a struct thats ever meant to be seen by the outside so i figured it didnt matter what its name was. but yeah i mean i technically could just use 4 different bools and not use a struct at all. but i like it when data is grouped under a name as well.
Ah. You can do whatever when its just you and yourself dealing with the code, but no one is going to accept that sort of thing professionally, because most coders are going to find it harder to memorize and follow a bunch of hand crafted tools whose only purpose is the change the language that they are used to reading into something else that is new and different. Every c++ coder knows what a bool is, but none of them know what you are doing there and have to spend time and energy making sense of it, only to discover... its just a bool. Be prepared for people to dislike that very much if you work on any group projects etc.