优化转移/移动平滑的2D Flash游戏 [英] Optimizing transition/movement smoothness for a 2D flash game

问题描述

更新6

Fenomenas建议我重新创造一切尽可能的简单。我有我的怀疑，这将使任何区别的算法保持不变，并表现似乎并不成为问题。无论如何，这是我得到了所以在这里它是唯一的建议：

Fenomenas suggested me to re-create everything as simple as possible. I had my doubts that this would make any difference as the algorithm remains the same, and performance did not seem to be the issue. Anyway, it was the only suggestion I got so here it is:

1. 30 FPS： http://www.feedpostal.com/test/simple /30/SimpleMovement.html
2. 40 FPS： http://www.feedpostal.com/test/simple /40/SimpleMovement.html
3. 60 FPS： http://www.feedpostal.com/test/simple /60/SimpleMovement.html
4. 100 FPS： http://www.feedpostal.com/test/simple /100/SimpleMovement.html

1. 30 FPS: http://www.feedpostal.com/test/simple/30/SimpleMovement.html
2. 40 FPS: http://www.feedpostal.com/test/simple/40/SimpleMovement.html
3. 60 FPS: http://www.feedpostal.com/test/simple/60/SimpleMovement.html
4. 100 FPS: http://www.feedpostal.com/test/simple/100/SimpleMovement.html

在code：

package {
    import flash.display.Sprite;
    import flash.events.Event;
    import flash.events.KeyboardEvent;
    import flash.utils.getTimer;

    [SWF(width="800", height="600", frameRate="40", backgroundColor="#000000")]

    public class SimpleMovement extends Sprite
    {
    	private static const TURNING_SPEED:uint = 180;
    	private static const MOVEMENT_SPEED:uint = 400;
    	private static const RADIAN_DIVIDE:Number = Math.PI/180;
    	private var playerObject:Sprite;
    	private var shipContainer:Sprite;
    	private var moving:Boolean = false;
    	private var turningMode:uint = 0;
    	private var movementTimestamp:Number = getTimer();
    	private var turningTimestamp:Number = movementTimestamp;

    	public function SimpleMovement()
    	{
    		//step 1: create player object
    		playerObject = new Sprite();
    		playerObject.graphics.lineStyle(1, 0x000000);
    		playerObject.graphics.beginFill(0x6D7B8D);
    		playerObject.graphics.drawRect(0, 0, 25, 50);
    		//make it rotate around the center
    		playerObject.x = 0 - playerObject.width / 2;
    		playerObject.y = 0 - playerObject.height / 2;
    		shipContainer = new Sprite();
    		shipContainer.addChild(playerObject);
    		shipContainer.x = 100;
    		shipContainer.y = 100;
    		shipContainer.rotation = 180;
    		addChild(shipContainer);

    		//step 2: install keyboard hook when stage is ready
    		addEventListener(Event.ADDED_TO_STAGE, stageReady, false, 0, true);

    		//step 3: install rendering update poll
    		addEventListener(Event.ENTER_FRAME, updatePoller, false, 0, true);
    	}

    	private function updatePoller(event:Event):void
    	{
    		var newTime:Number = getTimer();

    		//turning
    		if (turningMode != 0)
    		{

    			var turningDeltaTime:Number = newTime - turningTimestamp;
    			turningTimestamp = newTime;
    			var rotation:Number = TURNING_SPEED * turningDeltaTime / 1000;
    			if (turningMode == 1) shipContainer.rotation -= rotation;
    			else shipContainer.rotation += rotation;
    		}

    		//movement
    		if (moving)
    		{
    			var movementDeltaTime:Number = newTime - movementTimestamp;
    			movementTimestamp = newTime;
    			var distance:Number = MOVEMENT_SPEED * movementDeltaTime / 1000;
    			var rAngle:Number = shipContainer.rotation * RADIAN_DIVIDE; //convert degrees to radian
    			shipContainer.x += distance * Math.sin(rAngle);
    			shipContainer.y -= distance * Math.cos(rAngle);
    		}
    	}

    	private function stageReady(event:Event):void
    	{
    		//install keyboard hook
    		stage.addEventListener(KeyboardEvent.KEY_DOWN, keyDown, false, 0, true);
    		stage.addEventListener(KeyboardEvent.KEY_UP, keyUp, false, 0, true);
    	}

    	private final function keyDown(event:KeyboardEvent):void
    	{
    		if ((event.keyCode == 87) && (!moving))  //87 = W
    		{
    			movementTimestamp = getTimer();
    			moving = true;
    		}
    		if ((event.keyCode == 65) && (turningMode != 1)) //65 = A
    		{
    			turningTimestamp = getTimer();
    			turningMode = 1;
    		}
    		else if ((event.keyCode == 68) && (turningMode != 2)) //68 = D
    		{
    			turningTimestamp = getTimer();
    			turningMode = 2;
    		}
    	}

    	private final function keyUp(event:KeyboardEvent):void
    	{
    		if ((event.keyCode == 87) && (moving)) moving = false; //87 = W
    		if (((event.keyCode == 65) || (event.keyCode == 68)) && (turningMode != 0)) turningMode = 0; //65 = A, 68 = D
    	}
    }
}

其结果如我所料。绝对没有任何改善。我真的希望有人有另一种意见认为，因为这件事需要修复。另外，我怀疑这是我的系统，因为我有一个pretty的好的（8GB的内存，Q9550四核英特尔，ATI的Radeon 4870 512MB）。此外，每个人都问我迄今与我的客户有同样的问题。

The results were as I expected. Absolutely no improvement. I really hope that someone has another suggestion as this thing needs fixing. Also, I doubt it's my system as I have a pretty good one (8GB RAM, Q9550 QuadCore intel, ATI Radeon 4870 512MB). Also, everyone else I asked so far had the same issue with my client.

更新5：的顺利Flash游戏另一个例子只是为了证明我的动作肯定是不同的！请参见 http://www.spel.nl/game/bumpercraft.html

Update 5: another example of a smooth flash game just to demonstrate that my movement definitely is different! See http://www.spel.nl/game/bumpercraft.html

更新4 ：我跟踪的实时渲染之前（EVENT.RENDER）和渲染（EVENT.ENTER_FRAME）之后，其结果：

Update 4: I traced the time before rendering (EVENT.RENDER) and right after rendering (EVENT.ENTER_FRAME), the results:

rendering took: 14 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 14 ms
rendering took: 14 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 24 ms
rendering took: 18 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 232 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 16 ms
rendering took: 12 ms
rendering took: 14 ms
rendering took: 12 ms

范围为12-16毫秒。在这些差异中，令人震惊的/扭曲/闪烁运动已经回事。还有的232ms 1高峰期，在这个时候出现了一个比较大的扭曲。但是，这是不是最大problme，最大的问题是正常的运动过程中的连续小经线。这是否给任何人一个线索？

The range is 12-16 ms. During these differences, the shocking/warping/flickering movement was already going on. There is also 1 peak of 232ms, at this time there was a relatively big warp. This is however not the biggest problme, the biggest problem are the continuous small warps during normal movement. Does this give anyone a clue?

更新3：测试后，我知道了以下因素的没有的引起了我的问题：

Update 3: After testing, I know that the following factors are not causing my problem:

• 位图的质量 - >用photoshop更改为丑陋的8种颜色优化的图形，根本没有任何改进
• 形象而转向不断旋转 - >禁用它，根本没有任何改进
• 在浏览器渲染 - >试图用flash播放器独立的，根本没有任何改进

我100％相信，问题就出在任我code或在我的算法。请帮我出。它已经将近两个星期（1个星期，我问的SO这个问题），现在我还是要我金色的答案。

I am 100% convinced that the problem lies in either my code or in my algorithm. Please, help me out. It has been almost two weeks (1 week that I asked this question on SO) now and I still have to get my golden answer.

更新1：见底充分Flex项目源和现场演示，展示了我的问题。

Update 1: see bottom for full flex project source and a live demo demonstrating my problem.

我工作的一个2D Flash游戏。球员船被创建为一个对象：

I'm working on a 2d flash game. Player ships are created as an object:

ships[id] = new GameShip();

在移动和旋转的信息是可用的，这是被引导到相应的船：

When movement and rotation information is available, this is being directed to the corresponding ship:

ships[id].setMovementMode(1); //move forward

现在，在这个GameShip对象移动工作使用Event.ENTER_FRAME事件：

Now, within this GameShip object movement works using the "Event.ENTER_FRAME" event:

addEventListener(Event.ENTER_FRAME, movementHandler);

下面的函数，然后正在运行：

The following function is then being run:

private final function movementHandler(event:Event):void
    	{
    		var newTimeStamp:uint = UtilLib.getTimeStamp(); //set current timeStamp
    		var distance:Number = (newTimeStamp - movementTimeStamp) / 1000 * movementSpeed; //speed = x pixels forward every 1 second
    		movementTimeStamp = newTimeStamp; //update old timeStamp
    		var diagonalChange:Array = getDiagonalChange(movementAngle, distance); //the diagonal position update based on angle and distance
    		charX += diagonalChange[0];
    		charY += diagonalChange[1];
    		if (shipContainer)
    		{ //when the container is ready to be worked with
    			shipContainer.x = charX;
    			shipContainer.y = charY;
    		}
    	}

private final function getDiagonalChange(angle:Number, distance:Number):Array
    	{
    		var rAngle:Number = angle * Math.PI/180; //convert degrees to radian
    		return [Math.sin(rAngle) * distance, (Math.cos(rAngle) * distance) * -1];
    	}

当对象不再移动，事件侦听器将被删除。相同的方法被用于旋转。一切工作近乎完美。

When the object is no longer moving, the event listener will be removed. The same method is being used for rotation. Everything works almost perfect.

我已经设置了项目的目标FPS为100，创造了FPS计数器。按照FPS计数器，平均FPS在Firefox大约是100，而顶部是1000，下方是22。我认为，底部和顶部新鲜粮食店只在客户端（启动）的初始化过程中发生的事情。

I've set the project's target FPS to 100 and created a FPS counter. According to the FPS counter, the average FPS in firefox is around 100, while the top is 1000 and the bottom is 22. I think that the bottom and top FPSs are only happening during the initialization of the client (startup).

的问题是，该船舶似乎是几乎完全光滑的，而应该是只是没有几乎的一部分。这几乎就像如果船舶闪烁非常非常快，你不能真正看到它，但它很难重点关注的对象，而它与你的眼睛动。此外，飘飞，似乎是有点帧率秒杀，因为如果客户跳过几帧，然后会很快经。

The problem is that the ship appears to be almost perfectly smooth, while it should be just that without the "almost" part. It's almost as if the ship is "flickering" very very fast, you can't actually see it but it's hard to focus on the object while it's moving with your eyes. Also, every now and then, there seems to be a bit of a framerate spike, as if the client is skipping a couple of frames, you then see it quickly warp.

有非常难以解释，真正的问题是什么，但一般它的，该运动不是完全光滑。所以，你必须对如何使物体的运动或过渡的任何建议，完美流畅？

It is very difficult to explain what the real problem is, but in general it's that the movement is not perfectly smooth. So, do you have any suggestions on how to make the movement or transition of objects perfectly smooth?

更新1：

我重新创建客户端来证明我的问题。请检查出来。

I re-created the client to demonstrate my problem. Please check it out.

客户端： http://feedpostal.com/test/MovementTest。 HTML

的ActionScript项目（完整的源）： http://feedpostal.com /test/MovementTest.rar

（不是我创造）的顺利Flash游戏的例子：的 http://www.gamesforwork.com/games/swf/Mission%20Racing_august_10th_2009.swf

An example of a smooth flash game (not created by me): http://www.gamesforwork.com/games/swf/Mission%20Racing_august_10th_2009.swf

我花了pretty的很长一段时间来重新创建这个客户端版本，我希望这将有助于解决这一问题。

It took me a pretty long time to recreate this client side version, I hope this will help with solving the problem.

请注意：是的，它实际上是pretty的流畅。但它肯定是不够畅通。

Please note: yes, it is actually pretty smooth. But it is definitely not smooth enough.

推荐答案

我不知道是否有任何黄金的答案在这里，但我有几个建议。

I don't know if there's any golden answer here, but I do have a couple of suggestions.

首先，我会免除任何查询到的东西像优化Math.PI / 180，等等。在普遍高帧率应该说清楚，简单的计算没有放慢任何东西。

First, I'd dispense with any inquiries into things like optimizing Math.PI/180, and so on. The generally high framerate should make it clear that simple calculations are not slowing anything down.

二，解决显示器滞后偶尔会：像垃圾回收器的运行速度非常频繁，这些看起来对我有多大。通过您的code一个非常简单的介绍一下，我没有看到频繁的地方选区的任何明显的原因，但我有两个建议。首先，如果你有机会到Flash IDE中，我会尝试重新创建您的项目不使用Flex框架。 Flash项目不包括任何code，除非你把，但是Flex的采用了很多自己的arcanery，这可能并非总是很明显的，和你之间的code和框架部分的交互可能会导致地方选区。

Second, to address the occasional spikes of display lag: These look to me very much like the garbage collector is running very frequently. On a very brief look through your code I didn't see any obvious causes of frequent GCs, but I do have two suggestions. First, if you have access to the Flash IDE, I'd try recreating your project without using the Flex framework. A Flash project doesn't include any code except what you put in, but Flex employs a lot of its own arcanery, which may not always be obvious, and some interaction between your code and the framework might be causing GCs.

如果没有帮助，其他的事情，试图将是使你的code大大简化版本（在Flash如果可能的话），这将有希望足够简单不触发同样的尖峰。我的意思是，例如，一个类附着到图形，这仅仅是有一个监听器关键事件和第二监听帧（或定时器）的事件，在其中创建没有变量。如果最低版本不会显示这些尖峰，那么它应该是可能的和完整的客户端之间进行三角测量，找出是什么导致了峰值。

If that doesn't help, the other thing to try would be to make a greatly simplified version of your code (in Flash if possible), which would hopefully be simple enough not to trigger the same spikes. I mean, for example, a single class attached to the graphic, which merely has one listener for key events and a second listener for frame (or timer) events, within which no variables are created. If a minimal version doesn't display these spikes, then it ought to be possible to triangulate between that and your full client, to figure out what's causing the spikes.

最后，对于一般光滑，我唯一的评论将是Flash的屏幕更新本质上是轻微的不均匀，切实你只有用两种方法。要么你按照框架的更新，这使得他们的行动稍微不平的帧率改变移动你的角色，或者您可以根据经过的时间，这使得他们的整体移动平滑（每秒像素），但其显示略有不平移动移动（以像素为单位每帧）。的差被放大在较高的FPS。

Finally, regarding the general smoothness, my only comment would be that Flash's screen updates are inherently slightly uneven, and realistically you only have two approaches available. Either you move your actors according to frame updates, which makes their movement slightly uneven as framerates vary, or you move them according to elapsed time, which makes their overall movement smooth (in pixels per second) but their display slightly uneven (in pixels moved per frame). The difference is magnified at higher FPS.

此外，重要的是要记住，以后的Flash做出了更新，它们是如何出现在屏幕上在很大程度上受显卡的影响。特别是，你会发现，剪切和VSYNC问题能够在一个环境非常明显，不存在于另一个。没有真正的方式，开发人员可以解决这个问题，除了一般避免非常高的FPS动画和保持整体处理器负担尽可能低。

Also, it's important to remember that after Flash has made its updates, how they appear on your screen is heavily influenced by your video card. Especially you'll find that shearing and vsync issues can be highly noticeable in one environment and absent in another. There's no real way the developer can address this, except to generally avoid very high-FPS animations and keep the overall processor burden as low as possible.

编辑：更多关于我的意思大概帧更新时间是天生不均衡，请参阅的这个博客帖子。屏幕更新12-16ms之间变化之间的延迟是不是你可以做任何事情;这是一个事实，即OS和浏览器影响Flash的定时的工作方式的结果。 （这也是东西，你会在一个空的电影看就算了，这就是为什么在这个线程的很多评论关于优化数学等是不会帮你的。）你不能避免这种变化，但我上面说的，你可以根据你的视觉效果，以唤起你想要的效果。无论哪种方式，我觉得峰值是更值得担心。你看的变化是微妙的，并且将很难在一场比赛中有很多东西要去上看到，但峰值是令人震惊的。

edit: For more on what I mean about frame update timing being "inherently uneven", please see this blog post. The delay between screen updates varying between 12-16ms is not something you can do anything about; it's a result of the fact that the OS and the browser influence the way Flash's timing works. (It's also something you'll see even in an empty movie, which is why the many comments in this thread about optimizing math and so on are not going to help you.) You can't avoid this kind of variation, but as I said above, you can tailor you visual effects to evoke the effect you want. Either way, I think the spikes are much more worth worrying about. The variation you're looking at is subtle, and will be hard to notice in a game with lots of stuff going on, but the spikes are egregious.

修改2 你问：你真的认为那些流畅的游戏使用相同的运动算法怎么办？

edit 2 You ask: "Do you really think that those smooth games use the same movement algorithm as I do?"

答案是，我认为他们正在做的事情要简单得多。他们几乎可以肯定执行下列操作之一：

The answer is, I think they're doing something much simpler. They're almost certainly doing one of the following:

function onEnterFrame() { // move at a constant speed per frame
    ship.angle += dtheta;
    ship.x += speed * Math.cos( ship.angle );
    ship.y += speed * Math.sin( ship.angle );
}

function onEnterFrame2() { // move at a constant speed per second
    var dt:Number = getTimeSinceLastFrame();
    ship.angle += anglePerSecond * dt/1000;
    var dist:Number = speedPerSecond * dt/1000;
    ship.x += dist * Math.cos( ship.angle );
    ship.y += dist * Math.sin( ship.angle );
}

在换言之，无论是移动每帧一个恒定的距离，或每秒恒定距离。这些都是你可以接近这个两个简单的方法，并且是两个选项，会导致最流畅的外观在Flash中。他们将看到同样的在一个恒定的帧率，而后者方法看起来更平滑稍微不同的帧率，原因类似于您链接的文章中提到的时间混淆。但是，这些方法之间的选择真的可以归结为，如果CPU峰值出现后，它已经结束了，你要船一直保持移动或不？这实在是一个游戏设计的问题。有一件事我已经在过去做的是使用第二种方法，同时夹紧 DT ，最多2〜3次的理想帧的持续时间（1 / FPS）

In other words, either move a constant distance per frame, or a constant distance per second. Those are the two simplest ways you can approach this, and are the two options that are going to result in the smoothest appearance in Flash. They'll look identical at a constant framerate, and the latter method will look smoother at slightly varying framerates for reasons similar to the "temporal aliasing" mentioned in the article you linked. But the choice between these methods really comes down to, if a CPU spike occurs, after it's over do you want the ship to have kept moving or not? Which is really a game design question. One thing I've done in the past is to use the second method, while clamping dt to at most 2 or 3 times the duration of an ideal frame (1/fps).

正如你可能已经注意到了，我只推荐两种方法是什么帮你的时间步长！文章说不会做。这是因为这篇文章是关于数字集成物理引擎，这是不是你在做什么。如果你开始实施弹簧和重力，然后是，只要时间步长获得大会引入许多错误的，因为那样的模拟，过于简单​​化的东西，错误依赖于时间步长的大小。在你在做什么，它没有，所以偶尔的大时间步不影响仿真的正确性。

As you've probably noticed, the two methods I just recommended are exactly what the "Fix your timestep!" article says not to do. This is because that article is about numerically integrated physics engines, and that's not what you're doing. If you start implementing springs and gravity, then yes, whenever the timesteps get large it will introduce a lot of error, because for that kind of simulation, to oversimplify things, the error depends on the size of the timestep. In what you're doing, it doesn't, so occasional large timesteps don't affect the correctness of the simulation.

回复更新6

首先，我没告诉你，你的问题是性能，我明确表示相反。我提出了一个最小的再现，因为我相信你的问题是，无论是在别的地方在你的项目，还是不可避免的，我还有事。第二，我觉得现在pretty的舒适的说，你正在做的事情与任何其他Flash游戏，和任何问题，你看能不能得到解决比其他的看法。在您发布的新链接，动画看起来非常光滑，如果我在独立的SWF播放器观看，并有微妙闪烁的正面和背面在浏览器中的边缘（moreso在Firefox比IE中）。从技术上讲，我不认为它可以提高（特别是当它在独立播放器基本完善，这意味着，在浏览器中的任何抖动现象是由容器的影响。）

First, I didn't tell you your problem was performance, I specifically said the opposite. I suggested a minimal reproduction because I believed your problem was either somewhere else in your project, or unavoidable, and I still do. Second, I now feel pretty comfortable saying that you're doing things the same as any other Flash game, and whatever problems you see cannot be solved other than in perception. In the new links you posted, the animation looks perfectly smooth if I view it in the standalone SWF player, and has subtle flickering at the front and back edges in browsers (moreso in Firefox than in IE). Technically, I don't think it can improve (especially when it's basically perfect in the standalone player, implying that any choppiness in browsers is influenced by the container.)

当然，认为的表现仍然可以改善。如船舶未与背景反差那么厉害，例如，闪烁会更不太明显。此外，简单地使船移动速度比较慢会使动作显得更加流畅，并能与移动背景相结合，得到更快的速度的错觉（为你一个例子一样）。

Of course, the perceived performance can still improve. If the ship didn't contrast so sharply with the background, for example, the flicker would be much less noticeable. Also, simply making the ship move more slowly would make the movement appear much smoother, and could be combined with a moving background to give an illusion of greater speed (as one of your examples did).

作为一个全面的检查，这是我在IDE中提出了类似的最低版本。 http://www.fenomas.com/random/ship/ 其性能与我的机器上你的，正如我所说，我实在看不出有什么问题。 （除了偶尔秒杀，我现在发现只发生，我在Firefox浏览器。）此外，尤其是两个版本出现基本完善，我在独立播放器的事实进一步使我相信，有没有黄金算法在这里。我知道这不是你想要的答案，但它是一个我得到了。

As a sanity check, here's a similar minimal version I made in the IDE. http://www.fenomas.com/random/ship/ The performance is comparable to yours on my machine, and as I said, I really don't see any problem. (Except the occasional spike, which I now notice only occurs for me in Firefox.) Again, especially the fact that both versions appear basically perfect to me in the standalone player further convinces me that there's no golden algorithm here. I know that's not the answer you want, but it's the one I got.

这篇关于优化转移/移动平滑的2D Flash游戏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！