Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I've been using pixels as units for aspects of my game such as movement, but I've been told that this is a bad practice. However, I've never seen a good explanation on what I'm supposed to do instead. Can somebody provide a good explanation on how to handle units in my games?
It doesn't matter what units you use; they can be completely arbitrary. The only thing that you need to do is make sure that they are not fixed to the screen pixels, because you later find out you want to change the scale of things that are displayed. It's OK if the conversion factor happens to be 1; just make sure that the conversion exists, so that you can change it if you have reason to later.
(And, as a practical matter, don't make the conversion exactly 1 because that hides bugs if you forgot to convert in one place.)
For 3D realistic games, a common unit is "1 meter". Real world units don't matter, but the idea is to use a unit that is similar to the size of objects in your world.
For tile-based or voxel-based games, a common unit is the width of one tile. This also allows you to omit some conversions, but you're much less likely to have a problem tying to tiles than to pixels because tiles affect the game rules anyway.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I am aware that similar questions have been asked many times before. However, this is a different case.
I am writing a game in C++ using SDL2. Currently, all objects draw themselves. They do this because they all draw slightly differently.
For instance, a Button contains a rectangle, drawn with SDL_RenderFillRect();
Buttons also contain text, which are drawn using SDL_RenderCopy(), which takes a texture generated by SDL_TTF as a parameter.
Additionally, a MapView widget (basically a grid that can load a tilemap) draws the grid out using a 'for' loop containing horizontal and vertical SDL_RenderDrawLine() calls.
Finally, the tiles themselves are stored as textures, drawn using SDL_RenderCopy().
I understand that it is generally preferable to NOT have objects draw themselves. However, because there is so much variation in how the objects are drawn, I'm not sure of another way!
I thought it might be possible to have a GetTexture() function for each object, and the ones using textures could simply 'return texture', while the geometric objects could generate a texture. This gets complicated with my MapView object, because the grid is constantly updated when the user navigates around the game world (an offset value is changed and the grid is redrawn when moved).
Like so many questions of this type the answer is: it depends on your program.
If you are only every going to draw it the same way using SDL, then no reason why not. Another alternative might be to have a specific rendering class for each object, but that's doubling the effort. Having all your rendering code in a single class or function works fine too, but it gets big and complicated fast.
It's a judgement call based on the complexity of your code and what you want to do with it in the future, and my advice is to choose the simplest solution. As long as you've considered the potential downsides, you can make an educated decision.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
After learning about c++ through a couple different sources, I found conflicting advice concerning the use of cout/printf(). One source said that printf(), and I quote:
... does not provide type safety, so it is easy to inadvertently tell it to display an integer as if it were a character and vice versa. printf() also does not support classes, and so it is not possible to teach it how to print your class data; you must feed each class member to printf() one by one.
So, the more important thing to me would be the readability factor of using printf(). On the other hand, another source mentioned that cout, with its use of the overloaded operator <<, uses more instructions to execute and can therefore be more expensive in terms of memory over a large program. Although, the person who said this was a systems programmer, in which every bit of performance is vital. But say I wanted to go into game or application development.
Would the performance differences between printf() and cout matter all that much?
In general, does it really matter what I choose to use in an application program?
Thank you for any input.
You would measure the differences on your particular implementation for your specific use case and determine that for yourself.
I would say both lines of reasoning in the question have merit, but you can't generalise about performance.
If you want to go into game or application programming, printf/cout won't be needed too much. The only use in these cases is for debugging.
If you really need to use printf/cout a lot, the difference will be when writing a huge amount of data, otherwise you don't need to bother.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have tried blending and this seems to provide a basic glass effect but I feel there must be a better way to generate a glass or ice style effect. What would people suggest ? Is there something that can be done with semi-transparent textures ?
This is a very broad and complex question and the answer entirely depends on what kind of result (in terms of realism etc.) you are trying to get, what kind of lighting you want etc. Most of these effects, and materials in general, are the domain of shaders. A lot can be achieved with choosing the right textures with the right material parameters - again depending on what you consider an acceptable result.
GPU Gems book has a chapter on glass simulation (see 19.3.2):
GPU Gems 2 - Generic Refraction Simulation
When it comes to ice, there are again a ton of different things to consider depending on the complexity you want - see this answer here:
How to render realistic ice?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm creating a game and i'm really worried about hacking, so i'm writting a anti-cheat inside the game, i searched how the hacks now-a-days are written and i found some patterns, first of all, almost every hack uses a thread(Usually with CreateThread()) to create the checking loop(check if hack is on/off), do any of you have a good way to check if the thread is not from the game?PS:I also use threads from outside the code(inside DLLs)
It is almost certainly better to find a different way to "anticheat", since as cdhowie points out, there's nothing to prevent someone clever from splatting over your anticheat code with something that doesn't do what you want.
There are some techniques that work much better:
Let the server do all the "important" stuff, such as figuring out what score you get and how many lives you have left, and if the player becomes a zoombie (tries to move after he's dead), something is wrong.
Another method that I think works reasonably well is to basically record a "log" of how the player got to where they are - how many lives they used, how many enemies killed, what type of enemy, score of each enemy, weapon used, shots fired, how long it took to do all that, and then let a server verify that it's "reasonable" - so if someone ups the number of lives they have, or changes the weapon to create 100x the damage, or slows down the enemies or speeds up the players time, it will show up in the "log", and the log can then be discarded as "fake".
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
This is a question about 3D programming in general, but I'm learning OpenGL if that makes the answer any different. What I wonder is if all of the work in displaying a image always has to start from scratch for each new frame, or if there's some way to save intermediate data that could be reused when rendering the next frame, instead of having to be recomputed? Let's say you're standing right next to a mountain, then the stuff on the other side of the mountain are occluded by the mountain, there could be a lot of stuff on the other side of the mountain that simply doesn't have to be rendered because it can't be seen. Now assume that your character can't walk particularly fast, then there's no way that the stuff on the other side of the mountain could be visible already in the next frame, or maybe not even the next 100 frames. Is it possible to avoid having to do the same occlusion check in each frame?
The problem you're referring to is called "hidden surface removal" and "occlusion culling".
In realtime graphics it's usual to rerender each frame from scratch. However every good renderer will omit all the things that are definitively not visible. There are various algorithms for this.