I don't understand why tilesprite movement is awful in Phaser. Sometimes the scrolling is smooth and the very next movement it gets stuck randomly, then starts scrolling smoothly again. Why does this happen?
Are you using Chrome? Check out this bug on the Chromium project. Essentially, there's a bug in the Chrome implementation of requestAnimationFrame that causes it to miss the monitor vsync and get into all kinds of trouble.
Try running your game using Chrome Canary; it's got the fix, I think... or, at least, my game runs completely smoothly with no issues on it.
Related
Firstly, thank you for the great frameworks (Material and Motion) and generally awesome documentation.
I have been migrating to various Material and Motion classes in my app and enjoying it, but i have a situation I can't quite figure out an elegant way to handle with Motion.
I like to have a repeating background pulse animation that triggers on an IBAction and stops on an IBAction, but motion animations are 'one shot', and im not sure how to trigger a long running animation (unknown duration, repeating) and keep a handle on it, then stop it.
Is this a paradigm supported by Motion?
Thank you
I followed the Lighting tutorial on learnopenGL, modifying some of the code to work in a 2D game engine. Everything was looking great and my team got our game done and the lights were quite simple for our designers to use. However we ran into a rare bug. as shown here: https://www.youtube.com/watch?v=to0mMP5I0cs one team member was able to recreate the bug by switching his Nvidia settings to use the "High Performance Processor" as opposed to "Integrated Graphics". Otherwise everything renders properly. The bug doesn't appear when there are no lights and everything is rendered in its full color. We have gone through alot of Ideas already but they haven't worked and now I am at a loss. Does anyone have any ideas about what is going on?
Always make sure you initialize your variables. Apparently some cards and drivers automatically initialize vec3 to (0,0,0), but others don't. That was what was going on here. Garbage values causing different colors at each fragment. By Initializing my resulting color vec3 to (0,0,0) at the beginning the problem is fixed.
I am trying to fix an obscure bug in an old game by running it with IDA. The trouble is, the game runs fullscreen in 800x600 resolution and REALLY doesn't like being minimized, which makes it more or less impossible to actually use IDA while the game is running.
How might I approach this problem?
I'm having a weird bug on one of my computers with Visual C++. For some reason the screen will stop refreshing where my source code is. I can force a single refresh if I minimize and maximize Visual C++.
For example if I try to type something or use the scroll bar, it will not show any changes until I minimize and maximize. If I type something the changes have been made however. I can save and those changes will remain.
Oddly auto-complete still works as intended. If I type myClass.get_ it will bring up the auto-complete window.
It seems to occur randomly. It can happen if I leave the program up for a bit while doing other things or when I first start up the program. A fresh reboot nearly always fixes at that moment but what ever the cause is will occur after time. One thing that nearly always causes the program to stop working is if I start a video game.
I'd appreciate any help, thanks.
Assuming this is VS2010 - I think it does new-fangled GUI things with WPF and notably relies on hardware acceleration and write combining quite a lot more than before.
I had display issues in a virtual box gues installation (with multiple-monitor support in the guest enabled). I worked around it by lowering / disabling the hardware acceleration settings for the (virtual) graphics adaptor.
right click desktop
screen resolution
advanced/performance
use the slider to adjust acceleration level
Changing this setting apparently required a reboot on my system when I did it.
I've been playing with pygame (on Debian/Lenny).
It seems to work nicely, except for annoying tearing of blits (fullscreen or windowed mode).
I'm using the default SDL X11 driver. Googling suggests that it's a known issue with SDL that X11 provides no vsync facility (even with a display created with FULLSCREEN|DOUBLEBUF|HWSURFACE flags), and I should use the "dga" driver instead.
However, running
SDL_VIDEODRIVER=dga ./mygame.py
throws in pygame initialisation with
pygame.error: No available video device
(despite xdpyinfo showing an XFree86-DGA extension present).
So: what's the trick to getting tear-free vsynced flips ? Either by getting this dga thing working or some other mechanism ?
The best way to keep tearing to a minimum is to keep your frame rate as close to the screen's frequency as possible. The SDL library doesn't have a vsync unless you're running OpenGL through it, so the only way is to approximate the frame rate yourself.
The SDL hardware double buffer isn't guaranteed, although nice when it works. I've seldomly seen it in action.
In my experience with SDL you have to use OpenGL to completely eliminate tearing. It's a bit of an adjustment, but drawing simple 2D textures isn't all that complicated and you get a few other added bonuses that you're able to implement like rotation, scaling, blending and so on.
However, if you still want to use the software rendering, I'd recommend using dirty rectangle updating. It's also a bit difficult to get used to, but it saves loads of processing which may make it easier to keep the updates up to pace and it avoids the whole screen being teared (unless you're scrolling the whole play area or something). As well as the time it takes to draw to the buffer is at a minimum which may avoid the blitting taking place while the screen is updating, which is the cause of the tearing.
Well my eventual solution was to switch to Pyglet, which seems to support OpenGL much better than Pygame, and doesn't have any flicker problems.
Use the SCALED flag and vsync=True when calling set_mode and you should be all set (at least on any systems which actually support this; in some scenarios SDL still can't give you a VSync-capable surface but they are increasingly rare).