# duckflock

Member

52

1585 Excellent

• Rank
Member

• Role
Programmer
• Interests
Art
Audio
Design
DevOps
Education
Production
Programming
QA

## Recent Profile Visitors

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

1. ## Path Planning and Steering behaviors

TLDR: Path Planning: Where do I have to go? Steering: How do I need to adjust my velocity to reach a destination point? Path planning answers the question "which sequence of nodes should I follow to reach the target without being blocked by (static) obstacles", while steering handles "I have a next target position I would like to reach (the next node in the planned path). How do I need to rotate/accelerate to get closer to that target while avoiding (dynamic) obstacles that may be in my way?" In many games pathing only considers static obstacles, although it is possible to adjust the pathing graph every time a dynamic object (e.g. a monster) has moved. If that is the best way depends on your game -- I think it is rather expensive in games with many dynamic obstacles, but I am not experienced enough to comment on that. In a game steering is used to move an object to a single target position while avoiding other units. The idea is that a monster has multiple goals: reach the target position don't intersect walls (most of the time path planning takes care of this) avoid other entities in my path You implement these goals independently of each other: each goal has a function that calculcates a "guiding force" that makes the object move in such a way that it honors that goal. These are the individual steering behaviors. To compute the final position of the object you add up all these guiding forces and use them to adjust the object's velocity. There are many steering behaviors; item 3. is particularly hard to get "right" for larger clumps of monsters. Some basic steering behaviors are: arrive (takes care of reaching a point and stop) seek (move to a point but dont stop -- I have found that arrive works well enough even for paths) avoid (avoids obstacles in its way) path following (follow a list of positions successively) Then there are more advanced steering behaviors that handle groups of units well, e.g. separation, flocking, alignment, ... To conclude, two references on steering: A scientific one http://www.red3d.com/cwr/steer/gdc99/ and a tutorial that confuses physics terminology a bit IIRC (nothing serious), but is nice to understand and visualize individual steering behaviors https://gamedevelopment.tutsplus.com/series/understanding-steering-behaviors--gamedev-12732
2. ## My a* pathfinding is very slow... (c++)

Have you tried running your code with a profiler attached to find any glaring hotspots? Are you compiling your code in release mode?
3. ## Win32 message handling questions

Are you by any chance swapping buffers inside your message handler (WM_PAINT)? If the swap is in there and happens to wait for vblank it could explain your observed behavior.
4. ## reducing draw calls by batching

Static batching is an offline (or load time) process that transforms the vertices of 3d object instances into world space and stores all vertices into a single vertex and index buffer, so you can draw multiple objects at different places with only one draw call. Of course that only makes sense if the objects can't move at all and can be drawn with the same material. It's pretty much as if you do instancing on the CPU and store all resulting vertex positions in a new vertex buffer. This can easily explode memory requirements though, because a single mesh instanced 100 times in a static batch takes 100 times the memory.
5. ## BC3 format is not loaded correctly

From a quick glance you're missing a break in your switch.
6. ## Make this small algorithm branchless ?

sign(0) = 1 makes as much sense as sign(0) = -1. The most common choice, sign(0) = 0, is very useful for cases where you want logic to branch on positive or negative numbers, but not on 0. sign(0) is undefined in a mathematical sense, so the sign of 0 is 100% up to preference -- mathematicians choose 0 most of the time.   @OP: Notice that your else condition is run exactly once: in the last iteration of your loop. You can move the condition fabs(X) >= 1 into the loop condition and move the else part out of your loop. It probably won't make any difference as the branch is extremely predictable anyways.
7. ## Make this small algorithm branchless ?

That completely depends on which definition is most useful for your purpose. Zero is not considered a positive number; in fact, mathematicians commonly use non-negative to talk about all positive numbers and zero. Mathematically you can use whatever convention fits your use case for sign(0). Float/double even has +0 and -0!
8. ## Point around point rotation

There are two things that come into play here: - Floating point calculations are inexact most of the time by their very nature - Neither sine nor cosine can be evaluated exactly; computers use approximations to sin and cos that are "fast and good enough".   With a limited number of bits (float usually has 32) you will always have limited precision, there is no way to prevent this. Still, -4.3.e-8 is ~ -0.000000043, which is more than close enough to 0, considering this gets rounded to an integer value at some point in the drawing process.
9. ## Liquify and Image warping

Nice! Just FYI, in mathematics a function that maps each coordinate point to a vector is called a vector field :)
10. ## whats the "Big O" of this algo?

That depends on your problem and the constants in your complexity. For small n algorithms with smaller constants may be faster even though they are n^2 asymptotically. You can see this by comparing nlog(n) + 300*n with n^2; even though the latter is worse asymptotically it performs better for small n.
11. ## Rotational Matrix confusion

Well, atan2f takes (vertical, horizontal) as coordinates and assumes a right handed coordinate system. If y is towards, x goes right and z goes down. Try calling atan2f(-z, x) instead. The signs of course depend on your coordinate system axis, so you might need to switch some signs around.
12. ## Vulkan render-call performance drain

Are you using different Queues for present and render or the same Queue? Have you tried using fences on the present operation instead of vkDeviceWaitIdle? The documentation suggests that vkDeviceWaitIdle should be used to wait in a shutdown situation, so it might be rather pessimistic in some implementations. Vulkan's timeout functions are typically bound to the OS' timing granularity, which is usually 16ms on Windows (IIRC). Another way to make sure the driver really waits 32ms is to set the timing granularity to 1ms. Chrome does this by default, for example.
13. ## Math I need to know to make shaders

IMHO, for your requirement: Linear Algebra, Vector Calculus, and of course the knowledge required to implement the game.    This. You don't need to know how to handle abitrary vector spaces, but you should know matrix and vector operations by heart. Graphics programming requires tons of matrix/vector math.
14. ## Preventing a polymorphic class from being constructed directly

I don't know if your approach is sane (personally, it is not easy to follow your explanation without some example code), but regarding routing construction through some factory functions I will quote myself (http://www.gamedev.net/topic/675023-review-component-based-architecture-api/) in a slightly modified version:   The user can still shoot herself in the foot if she really wants to (by reinterpret_casting anything to an instance of the placeholder struct), but it can't be done by accident.
15. ## Figuring out where a projectile will go

Notice he computes force via distance / |distance|^2, which boils down to 1/|distance| * normalized direction. Square laws use distance / |distance|^3 or equivalently 1/distance^2 * normalized direction.