I have two actors, and want to scale actorA to 1.2 in 1 sec, and then scale actorB to 1.0 in 1 sec ,too.
how to I finish it?
.addAction(Actions.sequence(action1, action2))
but this code seem to one actor.
You could do that with an added delay for actorB:
Actor a;
Actor b;
a.addAction(Actions.scaleTo(1.2f, 1.2f, 1f));
b.addAction(Actions.sequence(Actions.delay(1f), Actions.scaleTo(1f, 1f, 1f)));
Related
I am writing a Tetris program with PyGame, and came across a funny problem.
Before I ask the question, here is the pseudo-code:
while True:
# In this part, the human controls the block to go left, right, or speed down
if a key is pressed and the block isnt touching the floor:
if the key is K-left:
move piece left one step
if the key is K-right:
move piece right one step
if the key is K-down:
move piece down one step
# This part of the code makes the piece fall by itself
if the block isnt touching the floor:
move block down one step
# This part makes the while loop wait 0.4 seconds so that the block does not move
# down so quickly
wait 0.4 seconds
The problem is that, because of the "wait 0.4 seconds" part of the code, the part that the human controls can only move every 0.4 seconds. I would like it so that the block moves as fast as the human can press the key, while at the same time, the block dropping every 0.4 seconds. How could I arrange the code so that it will do that? Thanks!
The main problem I see here is that you are limiting your framerate using a wait of 0.4 seconds.
You should not limit framerate, but instead, you should limit how fast your block falls.
If I remember well, there was a formula you could use to do just that. It was based on the amout of time elapsed since the last frame. It looked like:
fraction of a second elapsed since last frame * distance you want your block to move in a second
This way, you can keep your mainloop intact, and the move processing will happen at every frame.
You could also do...
...
# This part of the code makes the piece fall by itself
if the block isn't touching the floor and
the block hasn't automatically moved in the last 0.4 seconds:
move block down one step
...
Just realize you'll be doing a lot of polling if the user hasn't struck any keys.
You may try asking gamedev.stackexchange.com instead. Check the site for Game Loops, and check out other example pygame projects to see how they're doing it. Having a good game loop is essential and will take care of things for you such as user inputs and a consistent frame rate.
Edit: https://gamedev.stackexchange.com/questions/651/tips-for-writing-the-main-game-loop
When doing games you should always try to do something like this:
while not finished:
events = get_events() # get the user input
# update the world based on the time that elapsed and the events
world.update(events, dt)
word.draw() # render the world
sleep(1/30s) # go to next frame
The sleep time should be variable so it takes into consideration the amount of time spend drawing and calculating the world updates.
The world update method would look something like this:
def update(self, events, dt):
self.move(events) # interpret user action
self.elapsed += dt
if self.elapsed > ADVANCE_TIME:
self.piece.advance()
self.elapsed = 0
The other way of implementing this (so you dont redraw too much) is to have events fired when the user orders a piece to be moved or when ADVANCE_TIME time passes. In each event handler you would then update the world and redraw.
This is assuming you want the pieces to move one step at a time and not continuous. In any case, the change for continuous movement is pretty trivial.
I want to see the amount of listeners of my radio station over the time. But the graphic shows values like "0.67 listeners" instead something like "12 listeners". I don't get how to read the y axis. Some clues?
thanks
The listener count shown in the statistics is the average listener count across the entire day, as a sum total of each measurement point (15 seconds or less apart from each other) added together and averaged.
(From a GitHub issue)
i'm new to games development
in 2d games i'm using a final delta time for all frames and for measuring speed and so on;
i want to know if there is a problem can happen when i use final delta time instead of use counted-by-engine delta time
and also where to use the final delta and where to use the counted one
like game in game.java
class game extends com.badlogic.gdx.Game {
final float delta = 1 / 60F;
#Override
public void create() {
}
#Override
public void render() {
if (screen != null) screen.render(delta);
/////////// do stuff Depended on final delta
player.translate(150, delta)
}
}
thanks :)
Why not just use Gdx.Graphics.getDeltaTime()? The value is approximately 60, but I often see it ranging from 59 to 61.
Meant this as a comment, sorry.
In LibGDX the default frame rate is 60.
As long as the device running the application can keep up with that, a final delta of 1 / 60 will appear correct because that will be about equal to the Gdx.Graphics.getDeltaTime(). If however you either change the frame rate or the device cannot keep up with a frame rate of 60 you will get weird behavior.
Lets say it can only run at 30 frames per second, then your movement will only by 30/60 of your intended distance. So your application will slow down to half speed. Unless that was your intention, it will be a problem.
Using Gdx.Graphics.getDeltaTime() as suggested by #Ezra is usually the way to go if you want the intended movement even on a slower device.
We transmit the IBP frames like IPBBPBB and then we display them in IBBPBBP. This is the question, why do we do that. I can't just visualize it in my head. I mean, why not just transmit them in the order they are to be displayed?.
With bi-directional frames in temporal compression, decoding order (order in which the data needs to be transmitted for sequential decoding) is different from presentation order. This explains the effect you are referring to.
On the picture below, you need data for frame P2 to decode frame B1, so when it comes to transmission, P2 goes ahead.
See more on this: B-Frames in DirectShow
(source: monogram.sk)
Since MPEG-2 had appeared a new frame type was introduced - the bi-directionally predicted frame - B frame. As the name suggests the frame is derived from at least two other frames - one from the past and one from the future (Figure 2).
Since the B1 frame is derived from I0 and P2 frames both of them must be available to the decoder prior to the start of the decoding of B1. This means the transmission/decoding order is not the same as the presentation order. That’s why there are two types of time stamps for video frames - PTS (presentation time stamp) and DTS (decoding time stamp).
Briefly: it's done for decoder's speedup. You've mentioned usual MPEG2 GOP (Group of Pictures), so I'll try to explain answer for MPEG2. Though, H264 uses absolutely same logic.
For coder, picture difference is less, when calculated using not only previous frames, but successive frames too. That's why coder (usually) processes frames in display order. So, in IBBPBBP GOP every B frame can use previous I frame & next P frame to make prediction.
For decoder, it's better when every successive frame uses only previous frames for prediction. That's why pictures in bitstream are reordered. In reordered group IPBBPBB, every B frame uses I frame & P frame, which both are previous, and that's faster.
Also, every frame has it's own PTS (presentation timestamp), that implicitly determines display order - so it's no big deal that reordering is made.
This wikipedia article can give you answer to your question.
I am designing a fairly simple space combat desktop game with no graphics, but i want the back end to be robust enough for lots of expansion. I want to rank three different aspects of a ship's capabilities on a scale from 1 to 100 (although i'm willing to reconsider these numbers.)
For instance, i have the hitpoint section of the ship class as follows:
// section private defense
float baseHull;
float hullMod;
float baseArmor;
float armorMod
float baseSheild;
float ShieldMod;
float miscMod = 1.0; // this can be “rarer ship types, i.e. elites or bosses or stations or the rich.**
these can be any arbitrary value, for now. i haven't designed anything to fit in the variables yet, because I'm trying to figure out how to rank the ships based on these sections... one each for movement, hitpoints, and offensive capabilities. As an added bonus, a global ranking would be nice too. the hitpoints section as above would just be "hitpoints" on the screen, like 50,000HP for a moderate support class ship and 100 for the space shuttles we have on earth.
the ranking would determine likelihood of winning a fight, and the "XP" rewarded for winning a fight. Adding them all up wouldn't work, because a ship with 10 meters of uranium plating isn't necessarily better than one with 1 meter of lead plating and shields. for reference, earth clothing would be a rank 1, an M1A1 tank would be like a 5, and the death star would be up around 40-50ish.
I've been searching for ways to do this with real world data, but i am neither a mathematics whiz or a statistician. is there a way to weight this into a handy function? is it possible to reverse the function to say input a value and have it assign the internals (this would be really cool, but not necessary.)
Well, a simple way to combine those variables to a total hitpoint value would be:
hitpoints = baseHull * hullMod + baseArmor * armorMod + baseShield * shieldMod;
You could then assign, say, values between 0 and 100 for the base values determining "how much" of hull, armor, and shield they have, and values between 1 and 10 for the modifying values, which define "how strong" each item is.
Calculating the winner of a fight could be done like this, for example:
totalPoints = ship1Points + ship2Points;
ship1won = (rand() % totalPoints) < ship1Points;
Where the points of the ships are some values calculated by the hitpoints and the offense values of the ships. So you calculate the total points of the two combating ships and pick a random number between 0 and the total points. If ship1points is, say, 20, and ship2points is 50, ship 1 has the possibility of winning of 20 / 70. To reduce the probability even more (say you want to be more sure that the stronger ship wins), you could multiply both points by a constant or square them before the final calculation.