Hey you guys,!
I keep experiencing lag on Neko/CPP targets. Cpp is my primary target and Neko is just being just for debugging and fast building to test code. So I really don't care mush for Neko but I do care for Cpp.
I've posted on this topic before and I've posted this question on the OpenFL forum as well. Basically Cpp builds do not sync well with the hardware. I've made some test code for this. You don't need HaxeFlixel for this tests code, just OpenFL and Lime. Any version should work from old to new. (great for testing).
Does anyone have a solution for this? Obviously I want this code to run without lag on Cpp targets. Any comments on this would be appreciated!. For me this is a breaking point. I rater use Haxe then something else right now but this must be fixed!
package;
/*
OpenFL program to show lag. It runs great in HTML5 but Neko And CPP targets are laggy.
You can use any version of OpenFL + Lime, but Flash only shows a empty window :S ?
If you start the program either lag is already showing or it may take a while.
Keep restarting the program, eventually lag will show. Also dragging the window in
MS Windows can introduce lag. HTML5 does not show any of this behaviour.!, So i'm
guessing that SDL - implementation or SDL itself - is the culprit!
Please note that, resizing the stage is not implemented in this code, and
don't build with -debug! Debug targets can/may allocate new objects for debugging!
*/
import openfl.display.Sprite;
import openfl.geom.Rectangle;
import openfl.display.DisplayObjectContainer;
class Main extends Sprite {
// you can play around with these, but 200, 300 is heavily tested
// For windowed mode I use 1280x720
public static inline var kSize:Int = 200;
public static inline var kSpeed:Int = cast kSize*1.5;
var amount:Int;
var yoff:Float;
var instances:Array<Sprite>;
var colors:Array<UInt> = [0xFF0000, 0x00FF00];
var col:Int=0;
var current:Int=-1;
var world:DisplayObjectContainer;
public function new () {
super ();
world = new DisplayObjectContainer();
addChild(world);
amount = Std.int(stage.stageWidth / kSize)+2;
instances = new Array<Sprite>();
yoff = stage.stageHeight-kSize; // No subpixels, both are int.
for (i in 0...amount) {
newInstance(++current);
}
stage.addEventListener(openfl.events.Event.ENTER_FRAME, onUpdate);
}
function createSprite(color:UInt):Sprite {
var s = new Sprite();
s.graphics.beginFill(color);
s.graphics.drawRect(0, 0, kSize, kSize);
s.graphics.endFill();
return s;
}
function newInstance(column:Int) {
var s = createSprite(colors[col]);
s.x = column * kSize; // no subpixels, both are int.
s.y = yoff;
if (++col==colors.length) col=0;
instances[column]=s;
world.addChild(s);
}
function onUpdate(e:openfl.events.Event) {
moveWorldByDelta(1.0/60);
validateBuild();
}
function validateBuild() {
// Just math, no new Garbage() or "bad" + "string" + "concats"
var c:Int = Std.int((-world.x+(stage.stageWidth))/kSize);
var s:Sprite;
if (c>current) {
s = instances[0];
for (i in 1...amount) { // no iterator!
instances[i-1] = instances[i];
}
// No subpixels (both are int)
s.x = ++current * kSize;
instances[amount-1]=s;
}
}
function moveWorldByDelta(delta:Float) {
// Delta is open for discussion. But i've tried any sane value for it.
// Dynamic delta's, smoothing deltas, but Fixed Deltas (like this one)
// Give nice results. Also when in VSync (assuming 60hz), fixed delta's
// 1/60 should give best results. (don't forget that the caller/drivers can/will also
// adept their syncs when it fall behind, there no reason to do this yourself.)
// some much refered reading: https://gafferongames.com/post/fix_your_timestep/
// a suggested variable delta 0.01 or 0.02 makes the rendering really shakky.
// After applying that he interpolates the alpha, technically he's is just doing a
// complexed dynamic delta: (current_frame_time-_previous_frame_time), with
// overhead of potentially calling the physics multiple times instead of once.
// also in vsync this kind of methods should not be necessary, just use 1/refreshrate.
// Lets just say that even if 1/60 is inaccurate, then still the only real effect should
// be speed, and this should not result in lag!. Lag is created by not being synced correctly
// with the hardware. HTML5 syncs perfectly, CPP/Neko do not! Double Buffering is probably
// not well implemented!
world.x -= Math.round(kSpeed * delta); // No subpixels!
}
}
Although the problem lies more in OpenFL/Lime then in HaxeFlixel, still, if anyone has any great ideas on this..!?
Thanks!
