Jump to content
  • Advertisement

DerTroll

Member
  • Content Count

    63
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by DerTroll

  1. DerTroll

    How to Get to the Next Level

    Nice try! Sorry, but I couldn't resist πŸ˜› @topic: I think the answer of @fleabay basically nails it. Greetings
  2. Interesting topic (following)! I am currently coding all the stuff that I will need for humanoid characters based on physical calculations. I have a background in numerical mechanics and have my own plans on how to realize it. However, I am also quite interested in other people/engine solutions that I can learn from. Greetings
  3. DerTroll

    Problems with OpenGL

    If you want help, submit code and don't ask if you should try it yourself first πŸ˜› If you use git, a git diff of both versions might help too. Greetings
  4. DerTroll

    Celebrating 20 Years of GameDev.net

    Congratulations and thank you for providing this great site.
  5. Hi, I think you will only know it for sure by benchmarking it, even though I don't know a good tool to benchmark GPUs. I can't help you with HLSL but I dealt a lot with CPU sided vectorization over the last year. Let's say the HLSL compiler is not super smart, then the dot product is probably slightly faster since I guess this function is highly optimized. It probably does some vectorized operations like 'multiply - swizzle - add - swizzle - add - extract value' for a vector of length 4. These are six operations in total (not counting the creation of the vec(1,1,1,1) and storing intermediate results) where the swizzles are rather cheap operations. Loading a value from a vector is only cheap for the first vector element. --- However, I can only backup that efficiency claims for CPU vectorization. Things might be different on the GPU. I don't know. On the other hand, if you write v.x + v.y + v.z + v.w this are 4 extractions and 3 additions. Assuming the same operation efficiency as on the CPU, you have only one cheap extraction of the first vector value (v.x) and then 3 expensive ones + 3 expensive additions. So this solution is probably slower than the dot product. However, if the compiler is smart, it might vectorize the sum and then things are different again. What might work for a semi-smart compiler is the following pseudo code: vec4 v = vec4(1,2,3,4); vec4 tmp = v + vec4(v.y, v.x, v.w, v.z); vec4 rVec = tmp + vec4(tmp.z, tmp.w, tmp.x, tmp.y); float result = rVec.x; In this case, I hope for the compiler to turn vec4(v.y, v.x, v.w, v.z) and vec4(tmp.z, tmp.w, tmp.x, tmp.y) into cheap swizzle operations. This might be the fastest solution if the same rules as for the CPU apply. It would potentially result in the same instructions as the dot product without the multiplication. However, if the dot product has specific hardware support (I don't know), it might still be faster, which brings me back to my initial statement: You will only know the fastest solution if you benchmark it. In addition, the result of the benchmark might also be hardware dependent Greetings
  6. DerTroll

    advice/choosing a game engine

    Under the named circumstances I think the Python+Qt combination might work well for you. But maybe somebody else can also name some options since apart from C++, Python, and QT I do not have enough experience with other languages and GUI systems to give you a full overview. That's not too hard. Start with some simple Python tutorials after installing the IDE of your choice. You will see it is rather easy. I saw nothing in your description that needs some fancy operations that are hard to understand. Most of the stuff should be basic programming. The only thing you should learn as early as possible is how to use your debugging tools. For example, you can set breakpoints in your IDE where the execution of your program is paused. This enables you to check all the variables current values. Or you can just print messages to the console. Don't assume calculation results to be right, check them
  7. That's why I said, that the details can be learned later. I should have written "should be learned later". My intention was not to say, that it is not necessary to know the basics in general. it is just not necessary to know how everything works to start using it. You should absolutely learn how the stuff works under the hood, the question is just "when?". I think it is better to teach people the safer way of doing things and let them learn the details later instead of giving them all the basic knowledge and then say "now you better forget that". But that's probably personal taste. I am also not a fan of shared_ptr, but size issues and the mentioned problems are not exactly something beginners worry about, right? Again, I don't say knowledge should be hidden. Just saying it might be beneficial to change the order how it is taught to avoid troubles on the way. We can probably lose ourselves in analogies here, but I think you understand what I mean. Greetings
  8. DerTroll

    advice/choosing a game engine

    I think you should first write down the features/requirements of your game. From what I understood, that is not too much. If I am getting you right the game is just a GUI. In this case, if you don't care about nice Graphics, you can use an existing GUI toolbox. Qt for example. There is an integrated development environment (IDE) called QTCreator that makes it very easy to generate GUIs. As far as I know, you can also choose between some programming languages. At least my version gives me the option to choose between Python and C++. Which lead us to the next point: Choice of programming language: If text and basic graphics are the only things you need for your game, I would forget about C++. Reasons can be read here: https://www.gamedev.net/forums/topic/702672-help-me-choose-between-these-programming-languages-for-game-dev/ I think Python might be a good choice for you since it is a rather easy language to learn, has a lot of nice support tools and for such a simple game, performance is not an issue. Feel free to ask more questions. Greetings
  9. Well, I think that depends on how it is taught. You don't need to know how an engine works to be capable of driving a car. So, you can use STL containers, without knowing too many details. Everything you need to know in the beginning is, how you create a vector/map/whatever, fill it with data and how to access that data. Who cares what a template is. All you need to know is to put some pointy brackets behind the vector and put a type between them. Later on, you can still learn the details and why they are important. Sure, you can mess up with vectors too, but much less than with raw pointers. Its a matter of how you learn and understand stuff. People learn things differently. So I won't say using the current Standard will make learning C++ easier. I just want to point out the benefits. In the end, everybody has to find its own way Me too. Greetings
  10. I think you are wrong here. There are certainly a lot of very specialized changes, that you will probably never need. But some features are so easy to understand and will help you to avoid a lot of pitfalls. The problem is, that most tutorials/books are outdated and do not adjust towards the new standard. I mean what is easier to read/understand: for (std::map<int, float>::iterator it = myMap.begin(); it != myMap.end(); ++it) std::cout << it->first << ", " << it->second << std::endl; or the version with ranged based for loop (C++11) and structured bindings (C++17): for (auto& [key, value] : myMap) std::cout << key << ", " << value << std::endl; The second version is shorter, doesn't need the '->' operator and uses meaningful variable names instead of 'first' and 'second' I can understand, that a beginner has no motivation to go through a lot of reviews of a new standard and try to find all the things that are interesting for him. Most of the stuff he won't understand anyway. Even I don't get the point of many specialized changes. But if you find beginner tutorials for C++ that use the new standards to keep things simple, it will certainly make things much easier. YMMV Greetings
  11. Don't know which specific features @LorenzoGatti meant, but the current standard offers a lot of benefits. I won't go so far to say, that there are really obsolete language features, but there are certainly a lot of features that are not that important anymore. And some of these features, like raw pointers, can get you into trouble really fast if you don't know what exactly you are doing. Current standard allows you to write code that is syntactically easier to understand. Think of the new 'for each' loop notation or the using keyword instead of typedef. The std::function is much easier to use than the weird function pointer syntax. If you start with templates, 'constexpr' will remove so much code bloat. The auto keyword will also help to make the code more readable, which is so important for beginners. No more: std::map<int,std::vector<MyClassWithAVeryLongNameWhichIsAlsoATemplate<bool>>>::iterator = myMap.begin(); Though I have to admit, that excessive use of auto is also not such a good idea. Then you have static_cast, dynamic_cast, etc instead of C-style casts. There are a lot of articles, why you should avoid c-style casts. I always forget why exactly but it convinced me, So just google it πŸ˜› Another nice C++17 feature to reduce code bloat is structured bindings. As I said in the beginning, I don't see any real obsolete language feature. But in my point of view, the current standard and tutorials/books that teach it will make learning C++ much easier and less error-prone. Greetings
  12. Agreed. Most performance killers are language independent, and especially a beginner won't be able to utilize the possible speedups C++ offers. It is the same story for Vulkan and OpenGL. It is possible to write faster code in some situations with C++/Vulkan, but that does not mean that YOU CAN achieve that. You need to know a lot about the details. However, the thing is, if you start with C++ (or any other language that gives you full control -> C , Fortran, and all the languages I don't know), you are more often confronted with issues that more or less force you to understand what you are doing and by understanding stuff, you are capable to optimize it to some degree. If you are forced to use a garbage collection memory system and there is no way around that, why bother with object lifetime issues? The only thing you might learn is how to utilize garbage collection for maximum efficiency, but not about more efficient memory systems. Doesn't mean that it is necessary. I just want to point out, that you probably MIGHT learn more, if you take the more challenging path. But as I said in my previous post, you should be certain about the things you want to achieve. If your goal is to "just" make a game, use as much language and tool support as you can get, which means, C++ won't be my first choice. On the other hand, if you want the learn all the little details, C++ won't get in your way by forcing you to take a certain direction. I would rather say "steering into a possible direction". Personally, I don't like being forced to take a certain direction. I really HATE that Python forces me to format the code in a specific way. But I also know people who like that a programming language takes decisions from you since it often comes with the benefit that there are fewer things you need to code yourself (fewer things you can mess up). In the end, it is just a tradeoff of how much control you are willing to sacrifice to speed up program development. The extreme cases are coding everything yourself with C/C++ or using a toolbox like Unity. Your choice --- But keep in mind: More control is not equal to better/faster code. That depends totally on your capabilities and willingness to dig deeper. It's not about fear. It is more about that there might be easier ways to achieve your goals. Nothing wrong about choosing C++ as the first language. Well, it depends. In my point of using the latest standards will make a lot of stuff easier. I mean, that's the whole point of the latest standards. Make things better. Template metaprogramming got so much easier and understandable since you can mix it with constant expressions. The biggest problem is probably this: Unfortunately, there is not the right way to teach stuff, since each person learns differently. Well, in the end, it is not impossible to learn C++ and everyone who goes that route has to find its own path. I mean, I was capable of learning it, so it can't be too hard Greetings
  13. Then go for it. Nothing wrong with taking the long, but rewarding path. But make sure to get a good and up-to-date book. It should cover C++14 or even better C++17. You can also try some internet tutorials, but there are so many and they are not really up to date. Very important is, that you get yourself a good IDE (Visual Studio, QTCreator, Codeblocks). It will make your life much easier. Things I would also recommend (and what each good book should mention) is using git (GitHub) and CMake. Ahh... and in advance: If you get to the chapters about pointers and dynamic memory: Keep in mind, that there are new and delete operators, but try to avoid them as hell and check the alternatives Greetings
  14. this->IsSoTrue() --- :p With C++ you have full control over your whole computer. I find it extremely rewarding if you know what you are doing. But until you get to a point, where you can claim that you have a good understanding of the language, it will take you probably 2+ years of programming and learning. In the beginning, the level of pain is quite high. And it does not get better very fast. But as I said, once you get to the point, where you really know what you are doing, it is a great language. So if you "just" want to make a game without spending a lot of time learning before you can even start making a game, Unity with C# is probably the better solution for you. But if you really want to know the low-level stuff and get control over everything ---> C++ Another thing that might help you is reading the Book "Game engine architecture" by Jason Gregory. He was part of the team that made "The last of us". He talks about everything you need to know to make a good game engine. It will certainly help you figure out, how much detail you want to program yourself. This will make the language decision easier for you. Greetings
  15. DerTroll

    Weapon reload speed formula

    If you are familiar with python, you can use the scipy.optimize package. Use the least squares function to find an optimal set of parameters for some arbitrary formula. For example, you say that your formula has the form: a * BS + b. The optimizer gives you the best possible values of a and b to match your data. Plot the original data and your function to see how good the agreement is. If it is not good, just modify your function. Greetings
  16. DerTroll

    Updating Bounding Volume Hierarchy Leaves

    I am not at the point of implementing that myself, but I recently read some chapters of "real time collision detection" of Christer Ericson. From what I can remember you basically recalculate the AABBs. An alternative option would be, to use bounding spheres. They don't care about rotations. Greetings
  17. DerTroll

    Learning About Rotation

    This is probably what most people do. But I have to agree with this statement: First, you have to understand how and why the basic operations translation, scaling and rotation work before you can start messing around with multiple coordinate systems. But once you really understood all those details, the following Futurama cite does actually make sense πŸ˜› :
  18. DerTroll

    Learning About Rotation

    Don't be. I regularly mess up terms myself. Just wanted to clarify that we are getting a matrix and multiply that by a vector. You are welcome. A long time ago, I have been where you are now and I know how hard it can be to learn the stuff all by yourself. Greetings
  19. DerTroll

    Learning About Rotation

    Okay, first of all, there is no such thing as a rotation vector - at least to my knowledge. There is only a rotation matrix! A vector "... is a geometric object that has magnitude (or length) and direction" (https://en.wikipedia.org/wiki/Euclidean_vector) Let's try something different. Draw a 2d coordinate system with the y-axis pointing upwards, and the x-axis pointing to the right. Make the distance between each value on the axis 1cm. Now draw a point with x coordinate 2 and y coordinate also 2. Now draw a direct line from the Origin to this point. Make an arrow out of that line by placing an arrowhead at the location of the point. Now you have drawn the vector (2,2). You can measure the length of this line and will probably get to the result sqrt(2*2 + 2*2) = sqrt(8) = 2,83cm. You will also see that the vector points into the northeast if you treat your coordinate system as a compass with the y-axis pointing to the north. For a direction vector, its length does not matter. The vector (1,1) has half the length, but it points in the same direction as the vector (2,2): Northeast! I hope you can follow so far. The next step we will do is to switch to 3d by just adding a 0 to our vector. (2,2,0). If the third dimension is now the height, our vector is still pointing to the north-eastern direction, but parallel to the surface, since its third component is 0. So now try the following: Take a pen and place it vertically onto the origin of your coordinate system. It is now aligned with your z-axis. Think of the other end of the pen as a point which is located on your z-axis where the length of the pen is the distance to the origin. Let's call the distance L. If you would create a vector to the pen's tip, it would be (0, 0, L). Is everything clear so far? Now tilt the pen towards your y-axis while keeping contact to the origin until it lies on the y-axis. You have just rotated the point on the tip of the pen by 90 degrees around the x-axis, right? So the new vector is now (0, L, 0) since your pen is now lying on the y-axis with the distance to the origin still being L. The axis you rotated around was the x-axis, which can also be described by a vector: (X, 0, 0). X can have any value because all that matters for rotation is the direction of the axis. So next thing you should do is reset everything. Put the pencil pointing upwards again. This time tilt the pen into the direction of the x-axis until it lies on the paper. Now you have rotated around the y-axis. So your pen's tip is now located at (L, 0, 0). So if you repeat those two steps, you will notice, that rotating around one of both axes will maintain a right angle between the axis and the pen. So now comes the last step. Do the same but with the vector being the axis of rotation. Tilt the pen until it lies on the paper while keeping up a right angle between pen and vector. There only two possible outcomes. The pen can either be pointing to the northwest or the southeast, otherwise, there would not be a right angle between the vector ant the pen. So now you just rotated 90 degrees around a vector with more than one non-zero value!!! So if you measure now, where the tip of your pen is located in your coordinate system, You will get a new vector. Since your pen lies flat on the paper, it has only x and y values. The z value is 0. Due to the special construction of this example, both values for x and y are identical, but with a different sign. The exact value depends on the length of the pen that you have chosen and which one of the values is negative depends on the rotation direction. If you rotated to the northwest, your vector would look like this (-V, V, 0) where V is the length dependent value. Okay... after this rather long example, let's translate it to your code: glm::mat4 rotator { glm::rotate(glm::mat4(1.0F), glm::radians(degrees), glm::vec3(rotation.x, rotation.y, rotation.z)) }; MVP.view.direction = rotator * MVP.view.direction; Let's consider your view direction for the moment not being your view direction. Instead, it is a vector to an object... the tip of the pen ;). So give it the value (0,0,2). Now use the rotation vector (2,2,0) and 90 degrees as in the previous example. Run the calculation and what you should get is either the vector (-V, V, 0) or (V, -V, 0) with V being 1,414 = sqrt(2). Which vector you get depends only on the direction of rotation. You have just programmed the pen example. Keep in mind, that glm calculates you a rotation matrix out of the axis and the degrees you provide. So you are actually not using a vector and an angle for the rotation itself but a matrix. You just need them to create the matrix. Greetings
  20. DerTroll

    Learning About Rotation

    Well, essentially for the example I gave you, the names of the axis do not really matter. Just do literally what I told you. Take a bottle of coke or something else in front of you. If I say turn left by 90 degrees, do it. So where is the bottle now? to your right! So no x, y or z-axis involved in that example. You have just turned around your longitudinal axis, correct? See here: http://www.odec.ca/projects/2009/kirk9j2/background_research.htm I named that axis z, but you can also name it y to stick with OpenGL notation. So if you point your arm into the sky, it would be aligned with this axis and if somebody grabs your arm and twist it to the left, the thing described above will happen. If you point to the right, your arm is aligned with the frontal axis. Rotating 90 degrees around this axis will put you on the back or your belly and the bottle is now located under your feet or over your head. So far you have just rotated when your arm points into the direction of one of the coordinates systems axes. This means that your rotation vector has only one non-zero entry. But the mechanism stays the same, regardless of where you are pointing. Your arm will be twisted around 90 degrees and your body follows as if you were a stiff doll. Maybe you should get an action figure or something similar to try it out πŸ˜›
  21. DerTroll

    Learning About Rotation

    I think you are wrong - I don't use GLM, I have my own implementation. Therefore I don't know the specific function you posted, but I think they are not doing something to fancy there. What I guess it does is creating a matrix, that rotates everything 90 degrees around the axis (1, 0.5, 0) So imagine yourself standing in a room. The x-axis is pointing into your view direction. The y-axis is pointing to your right, and the z-axis is pointing directly into the sky. You are the origin of this coordinate system. Each axis value at your location is 0. Now think about an object directly in front of you. Let it be 2 meters away from you. So its location towards you would be described by the vector (2, 0, 0). If I tell you "please rotate by 90 degrees left" and you obey that command, the object would now be located 2 meters away on your right-hand side. So at (0, 2, 0). This is a rotation around the z-axis. What would have happened, if I told you to rotate around the y-axis? Point with your arm to your right-hand side (in direction of the y-axis) and imagine somebody grabs your arm and starts twisting it around 90 degrees. Okay, that might hurt, but imagine that instead of being hurt, your body is rotated. Depending on the direction of the rotation, the Object will end up being 2 m above your head or 2 meters below your feet. So at (0,0,2) or (0,0,-2). So now lets come back to the vector you specified: (1, 0.5, 0) Point your arm directly in front of you. That would be (1,0,0). Now rotate your arm a little bit to the right, so that you are not pointing directly in front of you but also not totally to the right. The direction you are pointing to is now something like this (X, Y, 0). Now imagine again, what would happen if somebody grabs your arm and rotates you around 90 degrees. Okay, the outcome might be a little bit hard to imagine unless you try it out, but one thing for sure: Since you just rotated yourself and did not change your position, the distance between you and the object remains 2 meters! The vector, which describes the object's location towards your new orientation might now have three non-zero entries (X, Y, Z), but its lengths remain 2 meters. By the way, a vector's length is calculated by sqrt(X*X + Y*Y + Z*Z) Hope that helped a little bit in understanding what is going on. Greetings
  22. DerTroll

    Learning About Rotation

    Maybe you should start by reading a book or some tutorials about basic linear algebra. I know, that this is boring if you want to do the fun stuff that is graphics programming, but not understanding the basics will just lead to more and more confusion and you might end up totally frustrated. Well, that's a common problem and I can understand your frustration, but learning the basics is necessary.
  23. Somehow, but most of the substeps can run in parallel and you can also have multiple pipelines being executed at the same time. Imagine rendering a triangle. It consists of 3 vertices. Transforming each of them to screen space in a vertex shader can be done in parallel since they don't depend on each other. After they have been placed, the rasterizer figures out, how many pixels on the screen are affected by the new triangle. This can only be done if all vertex shaders have run. For each pixel, a fragment shader is started, also in parallel. Of course, the fragment shader of the current triangle can only be executed after its vertex shader, but usually, you have more than one triangle to render, so while the fragment shader of your first triangle is executed, there might be some other triangles vertex and fragment shaders, that are also executed at the same time. Yep, they are great. Can't wait until the author finishes ihisVulkan tutorials
  24. No, you are totally right. I was wondering about that too. Only thing I could imagine is that the vector elements are a custom type with operator=(bool) overload. Otherwise, the compiler should reject it for the reasons you mentioned. Thatswhy I told him to check what happens in this line. Greetings
  25. for (int temp = 0; temp < cube.coordinates.size(); temp++) { cout<< "temp" << temp << endl; if ((cube.coordinates[temp] == true)) { sDirection = true; if (Count <= 90) {... In the first line, you loop over all cubes. In the third line, you compare an array member to true. Not sure what your intention is. If your coordinates array would store pointers, this would be a check for a nullptr but since you used cube.coordinates[temp].x I guess it does not store pointers. Don't know how your class/struct that is stored in coordinates compares to true, but from the output, you described, it always yields true. Then finally you compare to the count which yields always the same result for each loop iteration. So if the first branch is intended to check if a ball should start rotating, the reason why all are rotating at the same time must be that (cube.coordinates[temp] == true) always yields true. Find out why. if (Count <= 90) { ... } else if (Count > 90) { ... } else { sDirection = false; } Maybe I am suffering from a low caffeine level, but the last else statement can never be executed. The first else is only executed if Count is not less or equal than 90. In other words, if Count is greater than 90. In this case, your second if can only take the true direction since no value that would lead to the else condition passes the first branch. So you never set sDirectionton to false. The else statement for your keypress event is therefore also never called, once sDirection is set to true. This still does not explain why the switch always takes the path as if 'r' was pressed. I guess you messed up the whole event handling system of glut. The best way to fix that is to set a breakpoint at some key locations and check the call stacks. Place them somewhere in the display function and also in the key callback. Check which function is calling them. For the display function, I guess that it is called directly after window creation and therefore the for loop is executed without any key being pressed. The question is, who calls the SpecialKey function and why is the 'r' key path always taken to increase the angle even if no key was pressed. Check this and post the results. Greetings
  • Advertisement
Γ—

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net isΒ your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!