I'm making a platformer game, in which I have a powerup that lets you fly. On collision, I removed the powerup using powerup.gameObject.destroy() and disabled gravity using player.setIgnoreGravity(true). Now when I touch the powerup from different directions, it produces a different result like shown below.
Here's a minimal example: https://jsfiddle.net/prateek_1/rsoj0h2z/
Any help is greatly appreciated. Thanks!
Well the code works as it should, here is why:
Scenario 1)
you touch the powerup while not touching the platform (playertouchingground==false) -> no gravity, and the player doesn't fall to the ground. AND because the player is in the air you can't jump.
Scenario 2)
you touch the powerup while touching the platform (playertouchingground==true) -> no gravity, now you can jump, and when you jump you fly away, since nothing is "pulling" the player down.
The question is, what do you want to happen, when the objects collide?
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 :)
I am developing on a linux system using latest (at the moment) SDL2 (2.0.8) + openGL ES 2.0 (GLSL 1.0) eventually targeting a raspberry pi 3 board. I have so far done a few things like drawing text with freetype, drawing lines, text boxes (editable), text lists, waveform boxes (all i need to pass to a function is an array of vertices) and other shapes with glDrawArrays(). Now, there are things that need to be refreshed at, let's say, 10 times per sec and others that need 1 time per second. What would be the best approach to skip re-rendering everything at the rate of 10 times per sec? Because obviously openGL works by drawing everything from scratch on every 'frame'. However i know and you know that other approaches exist that include: rendering on top of the screen you already have or taking a screenshot and rendering on top of it only the fast changing things as well as other solutions. What do you thing would be the best approach to skip re-doing everything before calling SDL_GL_SwapWindow() ? How can i take a screen shot and render it on the invisible buffer then render only the fast changing objects and then call SDL_GL_SwapWindow() ?
This is a screen shot of the app so far drawing basic things
Thanks in advance.
i eventually had to realize that i should not have posted the question in the first place but since this is a place where people learn from others i now feel somewhat nicer :) . So, the thing i had to do was to simply stop clearing the invisible buffer (i will call it that for simplicity) and render on top of it only controls that change. Those that change are updated by covering the area that they take by a rectangle and then draw new stuff on that area. I have already done it and the frame rate just 'exploded'. I do not really think that there is a better approach since the way i do it requires no action at all. All i had to do was to add a few if conditions that selectively rendered or skipped every time the execution reached the point where functions iterate through the controls that have to be drawn on screen and therefore decide what to render and what not. However a well thought set of structures is required for every control instead of declaring and defining endlessly global variables which will only makes things confusing and difficult to maintain.
Regards to all.
I making an Arduino-based X-Y laser cutter. I've built the mechanics for it and accomplished basic motion, but I am having trouble getting it to plot lines and curves. I eventually want to be able to convert SVG or Illustrator files to Gcode or have the Arduino interpret and plot them directly
A picture of my setup.
There are libraries like GRBL and Rstepper that provide 2-wire (step and direction) instructions based on Gcode. The problems is that I'm driving two stepper motors using ULN2003 chips, which use 4 wires to step through the phases of the motor.
Could I make either of these libraries work for 4-wire control?
If not, I will need to find another way to plot my designs.
How I'm currently thinking of making functions for SVG or G-code style instructions.
//given a new position to go to and how we want to get there (i.e. curves)
for (i=0;xposition!==newx;i++) //run until x gets to the right spot
{
//get the values for X, Y, NewX, NewY, and any other parameters (e.g. for curves)
//figure out how many steps (say, +1 or -1) x should take for cycle number i
//figure out how many steps y should move given new x
//make the x stepper step the right number of steps
//make the y stepper step the right number of steps
//delay (control speed for adequate laser burning & don't make the steppers angry)
}
Will that be too slow?
Having been down this road and wasted much time, I would strongly suggest that you just get a couple of Easy Drivers for $15-$20 ea. and move on with your project using GRBL. It is a great library and there is a nice Java-based open source laser cutter front end project called Visicut. Visicut can handle either SVG files or gcode.
If you must use the chips you have, the Connecting Grbl pages lists this site Driving stepper motor using ULN2003 but cautions: "It is out-dated and uses Grbl v0.7."
(But seriously, hardware choices because "that is what one has" rather than what might be easier to implement can really suck the joy out of a fun hacker project like you have going)
I might be late, but there are a few modified versions of GRBL that support unipolars now. Here are the links:
https://github.com/TGit-Tech/GRBL-28byj-48
https://github.com/ruizivo/GRBL-28byj-48-Servo (this one didn't work when I tried it but it might work on your setup)
Note that in my testing the x/y axis invert messed everything up. It might be because I'm using a coreXY setup though.
"Super Meat Boy" is a difficult platformer that recently came out for PC, requiring exceptional control and pixel-perfect jumping. The physics code in the game is dependent on the framerate, which is locked to 60fps; this means that if your computer can't run the game at full speed, the physics will go insane, causing (among other things) your character to run slower and fall through the ground. Furthermore, if vsync is off, the game runs extremely fast.
Could those experienced with 2D game programming help explain why the game was coded this way? Wouldn't a physics loop running at a constant rate be a better solution? (Actually, I think a physics loop is used for parts of the game, since some of the entities continue to move normally regardless of the framerate. Your character, on the other hand, runs exactly [fps/60] as fast.)
What bothers me about this implementation is the loss of abstraction between the game engine and the graphics rendering, which depends on system-specific things like the monitor, graphics card, and CPU. If, for whatever reason, your computer can't handle vsync, or can't run the game at exactly 60fps, it'll break spectacularly. Why should the rendering step in any way influence the physics calculations? (Most games nowadays would either slow down the game or skip frames.) On the other hand, I understand that old-school platformers on the NES and SNES depended on a fixed framerate for much of their control and physics. Why is this, and would it be possible to create a patformer in that vein without having the framerate dependency? Is there necessarily a loss of precision if you separate the graphics rendering from the rest of the engine?
Thank you, and sorry if the question was confusing.
There are no reasons why physics should depend on the framerate and this is clearly a bad design.
I've once tried to understand why people do this. I did a code review for a game written by another team in the company, and I didn't see it from the beginning but they used a lot of hardcoded value of 17 in their code. When I ran the game on debug mode with the FPS shown, I saw it, FPS was exactly 17! I look over the code again and now it's clear: the programmers assumed that the game will always have a 17 FPS constant frame rate. If the FPS was greater than 17, they did a sleep to make the FPS be exactly 17. Of course, they did nothing if the FPS was smaller than 17 the game just went crazy (like when played at 2 FPS and driving a car in the game, the game system alerted me: "Too Fast! Too Fast!").
So I write an email asking why they hardcoded this value and use it their physics engine and they replied that this way they keep the engine simpler. And i replied again, Ok, but if we run the game on a device that is incapable of 17 FPS, your game engine runs very funny but not as expected. And they said that will fix the issue until the next code review.
After 3 or 4 weeks I get a new version of the source code so I was really curious to find out what they did with the FPS constant so first thing i do is search through code after 17 and there are only a couple matches, but one of them was not something i wanted to see:
final static int FPS = 17;
So they removed all the hardcoded 17 value from all the code and used the FPS constant instead. And their motivation: now if I need to put the game on a device that can only do 10 FPS, all i need to do is to set that FPS constant to 10 and the game will work smooth.
In conclusion, sorry for writing such a long message, but I wanted to emphasize that the only reason why anyone will do such a thing is the bad design.
Here's a good explanation on why your timestep should be kept constant: http://gafferongames.com/game-physics/fix-your-timestep/
Additionally, depending on the physics engine, the system may get unstable when the timestep changes. This is because some of the data that is cached between frames is timestep-dependant. For example, the starting guess for an iterative solver (which is how constraints are solved) may be far off from the answer. I know this is true for Havok (the physics engine used by many commericial games), but I'm not sure which engine SMB uses.
There was also an article in Game Developer Magazine a few months ago, illustrating how a jump with the same initial velocity but different timesteps was achieved different max heights with different frame rates. There was a supporting anecdote from a game (Tony Hawk?) where a certain jump could be made when running on the NTSC version of the game but not the PAL version (since the framerates are different). Sorry I can't find the issue at the moment, but I can try to dig it up later if you want.
They probably needed to get the game done quickly enough and decided that they would cover sufficient user base with the current implementation.
Now, it's not really that hard to retrofit independence, if you think about it during development, but I suppose they could go down some steep holes.
I think it's unnecessary, and I've seen it before (some early 3d-hw game used the same thing, where the game went faster if you looked at the sky, and slower if you looked at the ground).
It just sucks. Bug the developers about it and hope that they patch it, if they can.
i don't really know if it is actually possible, but i believe that it can be made. How possible is it to make a program that recognizes different sound bouncing from the screen and turn it into a position that will obviously be later fed to the mouse.
I know that it sounds kind of dumb, but lately i've been noticing that a very dull, strong sound is made when touching the screen, and that sound varies when doing so at different positions. Probably the microphone "hears" differently because the screen acts as a drum with the casing. Anyways, what do you think, anyone has any experience programming with sound?
First of all most domestic touch screens work by detecting pressure based on a criss-cross mesh layer underneath the display layer.
However I have seen an example where a touch interface was interrogated onto a pane of glass, it used 4 microphones to determine the corners, when you tapped a certain part of the screen it measures the delay in the sound getting to each microphone, therefore allowing one to triangulate the touch.
This is the methodology you would use, you don't even need to set up the hardware to test it, you could throw up an interface in VB, when you click in a box it sends out a circular wave and just calculate using the times it takes to reach the 4 points where the pointer is.
EDIT
As nikie suggested, drag & drop, or any kind of gestures would be impossible using the microphone method, as the technique needs a wave of sound to detect the input.
http://computer.howstuffworks.com/question7161.htm
I don't know if this will get you far, but you can investigate the techniques used in MIDI drums for returning various nuances of play.