7:23 disassembled, not decompiled. Awesome video, really enjoying this series.
@JamesBlacklock
Жыл бұрын
Remeber that, especially in a CISC architecture, the number of instructions doesn't necessarily line up with the number of cycles. I'm pretty sure the `imul` is taking up more cycles than the `shl` even though there's an extra instruction.
@PhaestusFox
Жыл бұрын
Yeah, that's why I mentioned it was a different instruction, but I wasn't sure about the actual cycles or where to find that so I thought I would play it safe and dumb it down
@dandymcgee
10 ай бұрын
@@PhaestusFoxyou can find the number of cycles for every instruction in the manual for your CPU, which you can download for free on the manufacturers website
@WindOfFlatus
Жыл бұрын
Fun and informational video as always. I just need to say that its 'vertices' not 'vertexs' . Thank you :)
@PhaestusFox
Жыл бұрын
Yeah the spell check in my script agrees with you there 😂 I guess I just like the way 'vertexes' feels in the mouth I always end up saying it 😅
@JamesBlacklock
Жыл бұрын
Lol yes, came here to say the same thing. I'm super anal about such things, so it was hard to listen. VER-ti-seez
@Kram1032
9 ай бұрын
I think you could specify hexagons entirely in integer math using Eisenstein Integers. Every vertex you care about, I *think,* would fall on an Eisenstein Integer. - No float issues, nor finite precision issues. You would get the *exact* result 100% in integers. The trick is basically to calculate stuff in two dimensions in the Eisenstein basis. Every Eisenstein Integer has the form a + b w, where a and b are regular integers, and w is the complex number (-1 + i sqrt(3))/2 (or in terms of vectors in R², {-1/2, sqrt(3)/2}) Now obviously w *does* require you to do non-integer math. However, you only need to do so at the very end. You can delay doing that multiplication until the very final step when you actually need to determine the actual position of any given vertex for the purpose of rendering. All the operations you'd likely care about (translation, rotation, maybe scaling - as long as the result is confined to the grid) can be done then with regular integer vector math. Before that point, every vertex has a clear *integer* Vec2 that defines its exact location and so everything is going to be seamless and *perfectly* comparable with a fully decidable equality and all that jazz.
@PhaestusFox
9 ай бұрын
Right that does sound like something to look into, this was one of the major reasons I originally created my channel, to get suggestions for things I wouldn't have ever thought to even google
@Kram1032
9 ай бұрын
@@PhaestusFox this method ought to work with any sort of regular lattice tiling, and if you are a bit creative, you ought to be able to do it for pseudo periodic lattices (say, Penrose tilings) as well, though that's gonna be much tricker for sure. The same concept would also work for 3D tilings if you ever consider making those. Say, for a Minecraft clone that's not based on cubes but rather on any of the other shapes that can be used to tile 3D space. As long as you can describe all positions you care about in terms of integer-scaled vectors, you're in luck. (The vectors themselves don't need to be integers. But the locations expressed in the basis those vectors provide must be integers. Then all positions and comparisons can be done with integers until you need to realize the location)
@Kram1032
9 ай бұрын
If you want the super technical/rigorous take on that, this is called field extensions. You are extending the field of Integers with one extra quantity w which follows w³ = 1 and that gives you the Eisenstein integers. You are at all times abstractly operating on that w, getting the basis (1, w, w²), implemented exactly like how you'd implement complex numbers. You get stuff like w² + w + 1 = 0, i.e. w² + w = -1 and w² = -1 - w (which is why you can get away with only w. Anything to do with w² can be reexpressed in terms of 1 and w using that equation) a general Eisenstein integer multiplication looks like (a + b w)(c + d w) = a c - b d + (b c + a d - b d) w the square norm of an Eisenstein integer |a + b w|² = a² - a b + b² if you need the actual length, you don't necessarily get an integer, but if the square of the length suffices, that still is an integer. You also get the complex conjugate w* = w² which is slightly different from the complex numbers. You even get appropriate rounding this way, which is an issue you had, right? Take two Eisenstein integers: (a+b w)/(c + d w) = (a + b w)(c + d w*) /((c + d w)(c + d w*)) = using w* = w² (a + b w) (c + d w²) / ((c + d w)(c + d w²)) = (a c + b d + a d w² + b c w) /(c² + d² + c d w + c d w²) = using w² = - 1 - w (a c + b d + a d (-1 - w) + b c w) / (c² + d² + c d (w - 1 - w)) = (a c + b d - a d + (b c - a d) w) / (c² - c d + d²) = at this point, c² - c d + d² is a regular integer (no w appears) so you can divide by it in the usual way. = (a c + b d - a d)/(c² - c d + d²) + w (b c - a d) / (c² - c d + d²) so now you have two fractions that may not be integers. I *think* by simply rounding those two values, you end up with the right result. You might need to floor or ceil instead of regular round. But one of those three ought to do the trick. So the quotient is q = round((a c + b d - a d)/(c² - c d + d²)), round((b c - a d) / (c² - c d + d²)) and the remainder, if you need it, is r = (a+b w) - q (c + d w) I'm not 100% sure this is exactly what you need. But if it is, then you only need to keep track of two coordinates instead maintaining three that sum to a constant. The rules of the space you define that way would keep track of that constraint automatically.
@PhaestusFox
9 ай бұрын
@Kram1032 that's neat, maths going a bit over my head, haven't looked at this stuff in months since I got a full time job and don't have the time/energy. But I thought I was only keeping track of 2 of the 3, since s=-r-q. I'm sure this fancy math would be useful for the shader and rendering side of things
@Kram1032
9 ай бұрын
@@PhaestusFox not sure if that's still up to date but you mentioned in the video something about rounding and having to check three values and then discard one conditionally to get the sum to be right. There is a chance that fancy division on and rounding to Eisenstein integers might avoid that extra check.
@gilsson4693
Жыл бұрын
I have just a single question: why are you use bevy game engine? There are a plethora of complete and big engines, such as Unity and Unreal, and Godot engine with its simplicity and sufficiency. If you spend same time as you do here, you will gain more profit
@unhackablew00t
Жыл бұрын
Fairly sure the answer is Rust. Unity uses C# which uses a garbage collector. Unreal engine uses C++. Bevy uses Rust.
@PhaestusFox
Жыл бұрын
Yeah that fact that it is rust is definitely why I first found and started learning bevy. After learning it tho I think the biggest thing that would stop me from changing is bevy is built around the ECS paradigm, I know unity(dots) and unreal have their equipment ECS system but as afterthoughts not the way things are done
@user-di5wj8is7i
Жыл бұрын
bevy is also open source and available under a permissive license
Пікірлер: 20