scrolling is not smooth at all

[Mark]

hi guys,

In the middle of doing scrolling for a game and my problem is, scrolling is never smooth, whatever I do.

Imagine a platformer -or topdown- with a map made of tiles and a car running on this map in one direction only (up).
For testing I added listener to "Event.ENTER_FRAME" and I call redraw function with the delta time (no speed/movement/etc yet, just testing scrolling - so imagine the car's speed equals frame rate) which "n" number is used for moving visible screen by "n" pixels.

I tried this using Shape (instead of Sprite) as it is supposed to be faster. The methods I tested so far are:

a) I find out where the car is within the tile, and move shape's drawing point below zero by tile size, minus this amount and redraw screen.
e.g.: 32x32 size tiles, car stands on pixel 20, so I set up Point (0, -12) and then do "BMP.copyPixels(bmpdata, bmpdata.rect, point);", in a loop, increasing point's "y" by 32 on every iteration. so I draw a line of tiles to 0, -12; then another at 0, 20;, 0, 52; etc until I hit the bottom of the screen.

b) fill a shape to it's full 2880 px height with my map data and do ...scrollRect() with deltatime. if rect minus deltatime is lower than zero, I fill up another shape with map data coming in line (reading from csv), swap out current shape on stage, and start over moving scrollRect

My problem is that none of the above smooth. It is "jumping"/"jerking"/"flicking" so to speak and even when -rarely- it doesn't, the way my map is scrolled hurts the eye: it's not "smooth" as e.g. in a movie when the camera moves but pixels are blurred all the way.


Could anyone please advice what and how to do to scroll a map smoothly?


Thank you for all the trouble in advance.


Cheers,
Mark

ps.: I was thinking about using TileSheet too but first, I'm not sure it's faster and second, couldn't figure out how to display just part of a huge map, especially not showing "full tiles" all the time.

[Pier Bover]

Are you using OpenFL?
Are you loading / decoding images at the same time?

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

--
Pier Bover
y...@pierbover.com

[David Elahee]

You should check for Ludum darev games methods or some "timing a game" tut. The subject goes well beyond the scope of this mailing list.

Xoxo

[Mark]

yup, using the libraries I tagged and compiling to win.bin.

I load tiles from asset image, store them in bitmapdata array when class is created.
later on, throughout scrolling/moving I do copyPixel from those tile-sized & arrayed bmps to my target Shape, which has the size of stage.


related to the other post: checked some ludum dare codes but did not find a solution, possibly as my target is hxcpp/win, I don't know... I found after a lot of research an issue reported for openFL describing the same I did but that is supposedly fixed in 2013:
http://www.openfl.org/archive/community/programming-haxe/smooth-scrolling/


so.... even if the answer might be complex, getting one would be much appreciated as did not find the solution 'on my own'. experiencing pretty much the same as the guy describes on the above link.
scrolling is OK, it's not "laggy" or too slow because of poorly coded app, etc - it's just not smooth. blurred, sloppy, sometimes "jumping" as I previously described.


thank you again!

yoOBFUSCATEDpierbover.com

[Djordje Radakovic]

Don't use bitmapData.draw. It uses software rendering and it is slow... regular bitmaps should be faster. Also don't use if you cacheAsBitmap, it also triggers software rendering

Switching to tilesheet should be relatively simple, logic is similar to bitmapData.draw and performance gains are huge, especially in your case when you have a lot of tiles. You can also have scrollrect on tilesheet. Also, you only draw tiles that should be visible similary to your current method, just populate an array only with tiles that should be visible

[Philippe Elsass]

+1 don't draw bitmaps.

Animate bitmap objects, or use Graphics API (and don't forget to .clear when you redraw).

On 15 Oct 2014 21:05, "Djordje Radakovic" <djole...@gmail.com> wrote:

Don't use bitmapData.draw. It uses software rendering and it is slow... regular bitmaps should be faster. Also don't use if you cacheAsBitmap, it also triggers software rendering

Switching to tilesheet should be relatively simple, logic is similar to bitmapData.draw and performance gains are huge, especially in your case when you have a lot of tiles. You can also have scrollrect on tilesheet. Also, you only draw tiles that should be visible similary to your current method, just populate an array only with tiles that should be visible

[David Elahee]

I concur. Let s fire some advices :
Switch to tilesheet, prototype in flash target to iterate fast, start with a small viewport, dont forget to interpolate by calculating delta between frames,  snap pixel coordinates to integers to avoid sub sampling, go 30fps at first and start by making a small sprite loop smooth, then expand.

Paradoxally in flash, scrolling is always hard to get right because it is not well suited to do it.

Xoxo

Le 15 oct. 2014 22:05, "Djordje Radakovic" <djole...@gmail.com> a écrit :

Don't use bitmapData.draw. It uses software rendering and it is slow... regular bitmaps should be faster. Also don't use if you cacheAsBitmap, it also triggers software rendering

Switching to tilesheet should be relatively simple, logic is similar to bitmapData.draw and performance gains are huge, especially in your case when you have a lot of tiles. You can also have scrollrect on tilesheet. Also, you only draw tiles that should be visible similary to your current method, just populate an array only with tiles that should be visible

[Mark]

Djole: My my! I was so much in the code I forgot about sw/hw rendering! Will go for Tilesheet then indeed, and let the community (and future reader newbies like who I am now :) know. Thank you!

Philippe: I use copyPixel. I assume by "draw" both you and Djole mean that.
I read it was fast and seen it working in Nicolas' ludum Evoland code (however, my map is much larger so cannot load everything in one go as first, that would be suicidal and second, there are technical limitations of pic.data storing objects. So I really must build "tilesets" on the fly).

Call me a newbie, but what do you mean by "animating bitmaps" (scrollRect? tried that, same result)?
And by "graphics API"? I'm using container's .graphics.beginBitmapFill() in both test "a" and "b" I mentioned.
Could you please give just a pinch more details please so I can google up and learn more about this?

Thank you guys again!
Mark

You received this message because you are subscribed to a topic in the Google Groups "Haxe" group.

[Djordje Radakovic]

If you use tilesheet don't test in flash, test in neko :)

 

[Philippe Elsass]

Flash games with relatively small screens work great with BitmapData.draw because you are using software rendering inside a relatively small area.

 

As the area becomes bigger BitmapData.draw performance drops.

As you switch to hardware rendering, updating textures (modified in CPU memory and uploaded to GPU) becomes a performance penalty.

 

Combine both and you have crappy performance even on desktop :)

On Wed, Oct 15, 2014 at 9:41 PM, Djordje Radakovic <djole...@gmail.com> wrote:

If you use tilesheet don't test in flash, test in neko :)

 

--

To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

--
Philippe

[Pier Bover]

So using copyPixels will ensure using GPU only?

Pier Bover
y...@pierbover.com

[Mark]

Found this as of now: https://groups.google.com/forum/m/#!msg/Haxelang/Im4ddJx7lJY/DrniHbaD2D4J

So basically, they say, openfl always try to use hardware render but only TileSheet do tricks like batching or caching (and probably magic too :).
And my method, using ".copyPixels" and ".graphics" is the slowest possible way for desktop...

However, it is fast in flash.
Probably this is why Nicolas uses it in Evoland ludum code (flash/web based), and I technically shot myself in the leg going with it for desktop... Bull's Eye! :D

I'm very tired and just messing up things now. Must sleep. The will is strong but the flesh is weak :P
But tomorrow I'll learn into TileSheet, read it's code and rewrite my drawing. Will let the community know if it smooths things up or still sloppy.

You received this message because you are subscribed to a topic in the Google Groups "Haxe" group.

[Philippe Elsass]

All the BitmapData methods (draw and copyPixels) are CPU (software) and slow-ish because the bitmap has to be (re)uploaded to the GPU for rendering.

Using Graphics API, drawing rectangles/triangles filled with colours or bitmaps is fast. Moving Bitmaps is about the same.

Using a Tilesheet *can* be faster if you use it to "batch" many draw instructions for the same texture. Doing many Tilesheet calls won't be faster than other methods.

[Pier Bover]

So how do you batch? Any tutorial available?

[Philippe Elsass]

Check OpenFL's BunnyMark sample:

https://github.com/openfl/openfl-samples/blob/master/BunnyMark/Source/tests/TilesheetTest.hx

(it's basic as it defines only one bunny tile)

 

Or the RunnerMark for a more elaborate game-like sample:

https://github.com/jgranick/RunnerMark

 

The idea is that you want to render as many element as possible using one Tilesheet.drawTiles call.

[Mark]

Okay guys. I tested with Tilesheet today. Executing one "drawTiles" per iteration (ie per "ENTER_FRAME" call) and I've got _exactly_ the same results as with .copyPixels into Shape. Not even a slight difference (not faster, not slower, not smoother, not more blurry, etc).

So I'm adding lot more details for a better understand. Thank you in advance for reading this, for some help too. Your help is much appreciated!



I uploaded a video so you can see what I'm talking about: http://www.filedropper.com/openflscrollingissue
7MB flv vid: I sacrificed quality for size, and screen recording eats clock too, so textures won't look very good, but you can see what I mean by blurry scrolling and animation sometimes "jumping" (if delta time happens to be bigger than usually, perhaps?).


So either I do method "a" or "b" (see original post), or I fill up a Tilesheet and draw that I get the same result.


I also add some code, again, for a better understand.

1. Imagine a huge csv file, full of tile IDs, something like:
1,2,1,1,1,6,1,1,5,1,5;
1,1,1,1,1,4,4,4,4,4,4;
2,1,1,5,5,1,1,1,4,1,1;
(and 1000s more lines like this, for the long run, "map chunks" will be generated on the fly)

I have 11 tiles in a row, and 11 rows on screen so my screen is 11*64px by 11*64px

2. I have a tilegfx.png file: for now, it has 6 pieces of 64x64 pixel tiles (3 in the first "line", 2 in second and one in third)

3. I add a fair amount of csv data to an 1D int array (var "mapData").

4. Init Tilesheet

var myTS : Tilesheet = null;

[init]
myTS = new Tilesheet(Assets.getBitmapData("assets/tilegfx.png'));
myTS.addTileRect(new Rectangle(  0,   0, 64, 64));
myTS.addTileRect(new Rectangle( 64,   0, 64, 64));
myTS.addTileRect(new Rectangle(128,   0, 64, 64));
myTS.addTileRect(new Rectangle(  0,  64, 64, 64));
myTS.addTileRect(new Rectangle( 64,  64, 64, 64));
myTS.addTileRect(new Rectangle(  0, 128, 64, 64));

5. Subscribe to event / add listener: on enter frame

6. Call 'redraw' on every enter_frame tick (or every 3rd as I do on the attached video).  "Camera" is at the two-third of screen, folllowing hero. If here "crosses camera line", hero is "pulled back" and tiles move. Otherwise I do nothing.

For performance testing, there's no user-controlled hero and the amount of pixels the "hero moved", "crossing the camera line" equals delta time.
(So pretty much 15-30px per frame, or let's say every 3 frames as I do on the test-vid.
Please note that if I redraw e.g. every 20 frames, I get the same blurrieness-sloppieness as on the sample video, but screen is scrolling virtually slower of course)

//diffY == delta time
public function pE_ReDraw_TILESBASED(diffY : Int) : Void {
        heroPos -= diffY;
        var p0 : Point = new Point(0,0);
        p0.y = [calculated: some pixel within a single tile, so 0-64]
        //I also find out here how many tiles should be above and below the hero;
        //depending on the amount of pixels the hero moved, which for now is "diff"/delta.
        //This should be fast as I declare 3-4 Ints and do up to 10 basic math ('+, -, *, /')

        var tD : Array<Float> = [];  //tileData array for drawTiles() call
        //topTile & bottomTile, e.g. 80-91 (11 rows), calculated and declared above
        for (rrow in topTile...bottomTile) {
            var ifrom : Int = 11 * rrow;        //11 tiles in a row
            for (ttile in ifrom...ifrom + 11) {
                tD.push(p0.x);
                tD.push(p0.y);
                tD.push(mapData[ttile] - 1);   //above mentioned array with 1211 elements
                                               //-1 as addTileRect goes from 0, csv from 1
                p0.x += 64;
            }
            p0.x = 0;
            p0.y += 64;
        }
        this.graphics.clear(); //the class extends Sprite
        myTS.drawTiles(this.graphics, tD, true);
}

[NOTE: I'm working with const values in real code of curse, not "64" and "11", etc. Replaced here for an easier read]


Thank you again! ;)

yo pierbover.com

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

--
Pier Bover
yo pierbover.com

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

--
Philippe

[Philippe Elsass]

We'd want to make sure now that OpenFL is actually using the GPU for you.

 

How do we know if Lime is in software or hardware mode?

[Benjamin Dubois]

Just curious, how many elements are drawn ?

Cause from my experience, even on an old computers,  flash is still smooth with few elements (including some 2048*2048 elements) rendered by the CPU.

[Mark]

I described this below. Anyways:
Only visible elements are drawn. Also mentioned, this means 11 x 11 tiles, plus, if partial-tiles (e.g. 47px of 64) have to be shown I set top tile row's p0.y to a negative number and add an extra row to the bottom.
This means 11*13 (143) tiles, which is 11*64 x 13*64 (704x832) pixels.

[David Elahee]

Can you make a repo with your sample public so that maybe someone could have a detailed look ?

David Elahee

[Mark]

Good idea. I will create a compact app-pack showing the behaviour and publish.

[Philippe Elsass]

This number of tiles should be blasing fast - probably even using copyPixels. Something must be wrong...

[Mark]

it is fast. cpu is on 2-4%, my app eats about 25mb ram alltogether (debug build)... gpu for some reason has high utilization but not heating so I assume clock is not peaked.
the pc is an old notebook so this should be ok-ish (gpu is suspicious but it's an integrated radeon 6720M or something similar)

my problem is what I explained and can be seen on vid: lack of smoothness / blurred textures on high speed scrolling.
tried on a *somewhat* better pc (I'm a poor person :), same thing there. maybe even worse / blurry scrolling.

I'll share the test app when it's ready and you guys can see it for yourself.

[Philippe Elsass]

Ah then maybe you can try enabling vsync - it's an attribute of 'window' to set to true in your project.xml/hxp.

[Philippe Elsass]

https://github.com/openfl/openfl/wiki/2.3.1.-XML-Format

--
Philippe

[Mark]

already enabled. setting is:

<window width="1280" height="720" fps="100" background="#000000" fullscreen="false" hardware="true" vsync="true" resizable="true" />

[Philippe Elsass]

Why FPS 100? You should stick to 60.

[Mark]

it's desktop and read in forums "100 fps sometimes helps" with openFL. tried with both 60 and 100, same result.

[Philippe Elsass]

Sounds like a sample app will help discuss the issue - and that may be a nice sample for others :)

[Mark]

Aaaaand it's not a dream anymore! :)
http://www.filedropper.com/hispeedscrolling

I know. Could have used e.g. github but it would be a waste for a random test app, really.


What you should do?
1. May The Source Be With You! Download 7z file (31 kB)
2. extract (7Zip is free stuff if you don't have it, grab one please)
3. compile: can use "r.bat" in project folder on win, or go your way on your platform
4. r.bat runs app right after compile ('test' mode), so watch and cry, or tell me what I do wrong :)

I simplified/truncated app as much as I could to keep tilesheet/rendering only - which is exactly the same what I do in my app.
And (sadly?) it looks exactly the same when runs. Ugly, sloppy, blurry.

List of items I have installed:
hxcpp: [3.1.39]
lime-tools: [1.5.7]
lime: [1.0.1]
nme: [5.1.8]
openfl: [2.0.1]


Thank you for everyone contributed already, also for looking into this sample app!
May The Compiled Code Be Ever In Your Favor!


Cheers,
Mark

[Pier Bover]

I can't comment on the speed of rendering, but I'd like to point out that every Sprite and DisplayObject have already a stage property that points to the current stage. This property is null when the Sprite is not on the display list, but it will be available as soon as Event.ADDED_TO_STAGE fires.

y...@pierbover.com

[Mark]

Yes, but I'm fiddling around with stage before I can be 100% sure class has it's own pointer initialized, i.e. has been added to stage.
Could be it's not 'best practice', though... hm. I'll think about this. Thank you for pointing it out.

[Mark]

and before I forget. "if (Std.random(3) == 0)  { " is 33% chance, actually, not 75% indeed. So... don't trust me and my silly comments, trust the code! :))

...

[Benjamin Dubois]

There is nothing blurry in your scroll (see attached image), just human eyes have limits.
https://en.wikipedia.org/wiki/Persistence_of_vision ;)

Maybe you could try old cinema technique by adding a black image each 2 frames (not sure it will have any effect on modern screens)

[Mark]

Okay. Hm. But in this case, is there a best practice in openfl to keep animation speed as fast as possible, just below/before it becomes "objectionably jerky"? I mean. Computers are different. My -not very good- ones are slow, my screens are 60Hz (tops :), etc. but there are rich people out there with high-end muscle-machines... :)

So the game should be fine both on my low-budget PCs, and on high-end ones. Is there a ""standard"" / best practice for that (in openFL/nme/etc, so "Haxe environment")?

Thank you again,
Mark

[Brennan Kinney]

Hi Mark,

I've not read through this thread properly, just seen the flv video and going to share my own experience in the past with scrolling in flash(cpu and gpu rendering). From memory with traditional scrolling in flash you would get this jerky/jitter like movement where you are looking at a large visual moving along the screen. This had something to do with pixel snapping I think, so on a smartphone with a high pixel density it'd probably look much smoother. I can't recall if cpu based rendering handled subpixels(eg x = 103.23px), you could get this with gpu rendering in starling, what would happen is the graphic could be a little blurry as the bitmap data wasn't aligned perfectly with the pixel display so it might be blending info from the nearest pixels.

If you're referring to the larger movements like the black circle, the video shows it updates every 2nd frame(could be it was 30fps and you recorded at 60fps?) but I'll assume that's just the video and it's every frame. So to maintain the speed the graphic is moving at it needs to update it's distance every frame, if you are unable to render additional frames in between you will get this effect. You could try adding motionblur, I've not done this before so it might be too costly resource wise. 

[Brennan Kinney]

Oh another thing that was probably mentioned above already. If the jerky effect appears to be random/inconsistent, then might be a good idea to profile you code with something like Adobe Scout and see if a frame(s) is taking longer than it should to finish(60fps = 16ms). If that's the case Scout will show you what part of the code is causing the issue.

[Mark]

Thank you for the feedback. I can't go for adobe scout as I build native apps (my code already has sections which couldn't compile against flash), and scout can work with swf only.


Anyone else please? All little helps (openFL best practice for animation speed)

[David Elahee]

Hi, 

Had a look at your code (cannot build/run but I have quite a special conf).

1- Well, you can use native profiler (like codeXL ) and profile from there but being able to profile from Scout is really a _much_ better situation.

2- You should Array.push tiles but rather address them directly by index in an Array to avoir realloc() induced by array.push.

3- Keep the array as a member ref to avoid garbage that will cause GC stutters;

4- avoid loop vars (ifrom), prepare them before to some stack moves

5- Aside those i don't see any big problem _EXCEPT_ that you test in -debug and that has a very -==HUGE==- / 5 impact on performance : test without it and get back to us. /!\

6- Please consider that some advices are very important and crucial to improve your workflow, for example one of openfl greatness is the compile/test speed for neko and flash, that will greatly improve your productivity, don't dismiss it so fast ^_^

Good luck pal !

:) 

--

To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

--
David Elahee

[Brennan Kinney]

Depending how your app is built, you could use conditional compilation for code that is not shared between platforms. I did an AIR app for desktop/mobile, video playback required native extensions on mobile for performance. Adobe Scout is great and really helps you see where problems occur in your code :)

[Achmad Aulia Noorhakim]

Might want to try reading this two article:

- http://gafferongames.com/game-physics/fix-your-timestep/ - Fix Your Timestep!
- http://frankforce.com/?p=2636 - Time Delta Smoothing

In that order. This doesn't guarantee you smooth scrolling/movement though, there are other factor that progreammer have little to no control over, like user hardware quality and what not. But it helps.

On Fri, Oct 17, 2014 at 10:47 PM, Brennan Kinney <brennan....@gmail.com> wrote:

Depending how your app is built, you could use conditional compilation for code that is not shared between platforms. I did an AIR app for desktop/mobile, video playback required native extensions on mobile for performance. Adobe Scout is great and really helps you see where problems occur in your code :)

--

[Mark]

Thank you for the answer and for the great and very helpful links! There's still a lot to learn for me out there. After business apps, game development is very confusing sometimes :)

Thank you too for all and every other folks out there lending a hand and dropping some information ;)

[Achmad Aulia Noorhakim]

Don't worry, this kind of things takes time to get right (and understand). You're not alone.