I got a huge problem. I'm stuck there for two weeks now.
It's seems pretty simple.
I'm creating a plane, mapping a texture to it.
After that I bend it, using the bend modifier from as3dmod.
Of course the plane got smaller after the bending process.
I've tried to calculate the first and last vertices.
var sizeAfterBending:Number = (-1 * plane.geometry.vertices[0].x) + (plane.geometry.vertices[plane.geometry.vertices.length-1].x);
I calculate -1 cause the first vertex is always negative.
The result of that is, if the plane is 400*533 it working fine.
But with a plane of let's say 640*480 it's not.
I'm missing something. It's really driving me crazy.
Does anybody has any idea?
Thanks in advance.
Cheers, MisterDan
JFY, I solved it.
I was trying to access this information before the rendering was finish.
Of course that's not gonna work ;)
Cheers, MisterDan
Related
I am working in GDScript, and I'm trying to get the player to aim their weapon in the direction of the mouse cursor. The look_at() function is great, but it's not the smooth movement I'm looking for.
So, instead I've been experimenting with the lerp() math operation to make it smooth... but its very jittery and buggy movement which is obviously not ideal.
func _process(delta):
`rotation_degrees = lerp(rotation_degrees,rad2deg(get_angle_to(get_global_mouse_position())),aim_speed)
`
1 See the image of my code here.
I can't work out if I'm doing something really stupid as I'm fairly new to Godot. Any help would be massively appreciated!
Please use_physics_process() instead of _process()
_process runs at the fastest possible rate whenever it gets the CPU. That makes it jittery. It is not ideal for player movements since you will need consistency in your frames.
_physics_process() is consistent as it is frame independent and is ideal for player movement.
if you want more details I recommend you check this video by Godot Tutorials
Btw look_at() should work just fine :)
Im making a game in Rust(Im a beginner) for my son and am somehow struggling with platforms - specifically modifying their length. I can get the platforms if i use certain numbers but if i try to modify the platform width I run into problems.
If i use the const PLATFORM_WIDTH=400 then everything works fine (i seemingly can make any number of them and it all works), but I don't want to have platforms of a fixed width (length), I want each platform to be of variable width. If I try to make the platform width say 100.0 then it is rendered correctly but I can walk over empty space as if there was a platform there. If I make them greater than 400 they are rendered but the sprite will fall through solid floor at some points.
Really don't know where Im going wrong and this annoying issue is preventing me from making progress on my game.
Id really appreciate if someone could take a look at my code and tell me where im going wrong.
My code is here:
https://github.com/country-bumpkin-software/rusty-miner/blob/main/src/main.rs
Also can someone explain to me why the Rect function seems to take negative numbers for the x, y coords?
The problem is that you sometimes use the width from the platform struct (e.g. when checking for intersections on line 264) and sometimes use the PLATFORM_WIDTH and PLATFORM_WIDTH_HALF constants (e.g. when drawing the platform on line 346).
I've been tracing my code and comparing notes between my own code and some sample code
I'm working from this sample code: http://mbostock.github.io/d3/talk/20111116/bundle.html
My source example is here: http://www.nogumallowed.com/test5.php
My problem is the path lines. They work, they connect, but I love in the source how the lines have more seemingly random curves to them. I can'y figure out how to recreate that. Mine all flow incredibly well, but look rather plain in comparison.
Can anyone offer any insights? I've been coming back to this for a few days, and haven't figured it out yet. The documentation hasn't tipped me in the right direction yet either.
I'm just scratching the surface of "comfortable with D3", but there's still A LOT for me to learn on it before I give myself a D3 Jedi.
It doesn't look like your clustering code (if you have any) is working very well. The subjects should be clustered together into related groups, but it doesn't appear like yours are. For instance, your node "John Sly" is connected to almost very other node except the few on either side of it. It seems to me that those nine or so highly connected nodes should be distributed around the circle, not bunched next to each other.
I am applying A* (and IDA*) search with manhattan heuristic for finding solution to 15-puzzle problem.
Using the fact that i dont want an optimal solution for the problem how can i can speed up the search as the current routine is too slow.
Well, it's not exactly a solution, but it might help. Once I've been working for a HOG game with that same puzzle as a minigame and it turned much easier to generate a problem, than find a solution.
What I mean is, we can turn a solved puzzle into unsolved by randomly moving "window" according to rules. And logging each field position for future use. Then we let user play a bit and if she gives up, we can solve a puzzle for her easily by finding the common position in user and our log. We just play back via user log to the common position and back from it to the solved position via ours log.
Of course, this is a hack and not a real solution, but it works fine in gamedev. And not only for this particular game. Most repositioning puzzles can be "solved" this way.
I need to know how to determine fast if line intersects simple polygon.
It should work in O(log n) time, where n is number of polygon's vertexes.
I searched in google, but I didn't find anything useful, maybe I'm blind. ;)
Edit: I'm using C++ but I think language isn't a problem, and it isn't homework, just doing some algorithms training. Geometry is sick. ;)
Oh. I forgot it's only in 2d.
Thanks for future and actual help.
I've found a paper who solves this problem really fast:
"Fast MinimumStorage RayTriangle Intersection"
http://www.cs.virginia.edu/~gfx/Courses/2003/ImageSynthesis/papers/Acceleration/Fast%20MinimumStorage%20RayTriangle%20Intersection.pdf
EDIT: It even contains code :)