Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

  • Days Won


DerTroll last won the day on May 27

DerTroll had the most liked content!

Community Reputation

154 Neutral

Personal Information

  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. DerTroll

    Wizard Character Model

    Looks fine to me. Good work
  2. DerTroll

    Projectile Motion not behaving as expected

    You can basically choose any unit you like for dt as long as your velocities and accelerations are in the same unit. He chose frames as units and a fixed dt of 1 frame. Since dt=1, he can drop it in his equations. If he can maintain a fixed framerate, you won't notice anything. Only if the frame rate changes, his game would run faster or slower. At least from what you answered, I would think the time integration scheme is the issue here. Try an RK4 scheme. If the problems vanish or are reduced significantly, then you have a strong hint that your problems are related to the time integration scheme. Greetings
  3. DerTroll

    Projectile Motion not behaving as expected

    Okay, just read the Wikipedia site. I couldn't find any coding errors, but what might be an issue is that you are using a first-order time integration scheme on a second-order differential equation. In Euler methods, the velocity (the first time derivative) is treated as constant over the period of a timestep. So your position changes linearly. But if you have a constant acceleration, the velocity changes linearly and the position quadratically in time. If you have a look at your second loop, the first thing you do is increasing the velocity. Then you use this velocity and add it to your position. So the velocity over your timestep is constant and has the value of the theoretical solution at the end of the timestep. You are adding too much y-displacement since the true velocity at the beginning of your timestep is lower. So this: is a flaw of the first order method you are using. With float offsetT = t + 1; yAcceleration = -4 * (a - (2 * b) + c) / (offsetT * offsetT); float yVal = ((3 * a) - (4 * b) + c) / (offsetT); you are just reducing the acceleration and compensate for this flaw. However, I am not really experienced with time integration methods and I am still wondering why you hit your target even though the bullet drops faster than it should. Maybe you could experiment a little. What happens if you move the velocity increment of the second loop to the end of the loop? If I am not wrong this should turn your time integration into Euler explicit. The bullet should now drop slower as the theoretical solution and maybe you now need to increase the acceleration by using offsetT = t - 1 to meet your 15 frame target. If this is true, your issue is probably the order of your time integration scheme. This can easily be fixed by using RK4 or any other method of 2. or higher order. Greetings EDIT: One thing you could also try is to subtract yAcceleration/2 from your velocity vector v before the second for loop. This way you should use the correct intermediate velocity during each timestep.
  4. DerTroll

    Projectile Motion not behaving as expected

    Hi there, don't have much time right now (bedtime :p) and just had a short look at your code. What do you mean with "semi-implicit Euler"? Implicit time integration usually involves solving a system of linear equations and I didn't see that in your code. I have seen some things that might be an issue, but I haven't really thought that trough. So I'll check it tomorrow and give you a better answer. Greetings
  5. 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
  6. 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
  7. 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
  8. DerTroll

    Celebrating 20 Years of GameDev.net

    Congratulations and thank you for providing this great site.
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  • 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!