While training in the OpenAI gym environment I have the idea that the environment sometimes "stops". For many frames in a row no ball is visible/stops spawning.
Is this an error in the gym environment? Is this something that is part of the game Breakout-v0?
I was also wondering what the possible actions are in Breakout-v0. What I kind of figured out:
0 - do nothing/stand still?
1 - do nothing/stand still?
2 - apply "force" to the right?
3 - apply "force" to the left?
Edit:
For people wondering what I'm talking about: see this gif: http://imgur.com/a/pBLGX
The transition between 5 and 4 lives takes a lot of frames... Sometimes the break is even longer than this...
Its cause after end of life your agent needs to hit the fire button to get the game to start playing again. If it doesn't learn to do this then the game will not progress and looked paused like you say it seems.
I believe actions off the top of my head are:
0: no-op
1: fire
2: right
3: left
could be other way around on directions
Related
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 was thinking of implementing a labyrinth game in Haskell - the labyrinth will be of ASCII symbols and I would like it to be colored - for example walls to be blue "#", coins to be yellow 'o' and so on, and I was looking at System-Console-ANSI.
I would like to ask if it will be possible at all to do this with this packet and I was thinking how to refresh the labirynth when an action happens (for example it can have coins in it, represented by 'o' and when the hero steps on a coin, he gets it and it should disappear) - will claering the screen and printing the labyrinth again do the job smoothly?
Can you please give me some ideas and maybe packets if System Console ANSI won't do the job? Thank you very much in advance!
I suggest you have a look at vty-ui at http://hackage.haskell.org/package/vty-ui and http://jtdaugherty.github.com/vty-ui/. There's a very good user's manual for it. I've only played with it a little, but I think it would be well suited to your application.
When I'm designing a workflow using the built-in GUI, I noticed that after the fifth depth of timeout(timeout until x minutes, then do...) I can no longer add more steps. Vertically, I can enter many lines but depth-wise (i.e. to the right) it seems to give me a no-no and I can't add a sixth wait until, then do... clause.
Is it possible and I'm experiencing some other problem without realizing it or is it a limitation by design? Can it be worked around? I'm targeting both on-premise and on-line installations.
You could put the steps on the same depth (assuming that you're doing something besides the delays) - so they are aligned sideways. That way, you can enter arbitrary many waiting statements (i.e. 12, because that's what I've tested).
As for the five levels of depth, I've never run into a situation when I needed it. I suggest that you post a bounty if you'd like to learn more. But you might want to do that after the new years eve. Right now people are busy with that life thingy, not attending the only purpose in life (e.g. logging in onto Stack Overflow).
Well, there isn't much example code for this. I'm writing a game loop and I'm running into a snag. At first I attempted to create a schedule for the loop as this was listed under best practices as the way it should be done. My frame rate is 60 fps, and the loop was also running at an interval of 60 fps. I quickly noticed however that the interval time is little more than a suggestion, and the actual rate that the function is updating is highly erratic, ranging between 15 and 65 fps. This led to jumps in objects updating, even when their update distance was regulated as a function of time. Once updating dropped below 20 fps it became highly apparent when it updated and was quite ugly.
I then tried to create my own thread so that I could more closely regulate the update rate. With this method I was able to almost precisely regulate my updating rate. With this all movement and animations were smooth. The issue with this method is that cocos2d clearly doesn't support multithreading well as I periodically see screen tearing. Also, if my update rate doesn't precisely match my draw rate I see jumps. I believe this is due to the draw method firing in in the middle of my update loop, a common problem with multithreading.
The two ways I can think of to solve this problem are to find some way to closely regulate the firing rate of the scheduler, or to find a way to lock the drawing code until I can finish my update. I've been looking for quite some time for any examples on how to do either of these, and have met with no success. If anyone out there has a clearer idea of how to handle this kind of a situation I would be very appreciative of some advice. I'm just too used to C++ and having things happen at the rate I tell them to. If you need me to post any additional information, just ask! Thanks in advance for any assistance.
Your problem is in your scheduled function. It just can't run as fast as you want. Try running helloWorld scene from cocos2d and you will notice that fps are stable near 60 (59.8 - 60.2)
"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.