next »

[rejwan]

Hi everyone,

I'm currently working on a hexagon map that will work with blit scrolling, meaning I draw only what is needed plus a small buffer and redraw whenever needed.


Now - Going left and right works perfectly - however, when I try to scroll down, a very peculiar issue occurs.


The map is first copied without the row that was removed from view, and then the new buffer rows are being drawn.


I've isolated the issue to the initial cropping of the photo and found a very unusual bug and was hoping someone here could help me.


Here's the screenshots from my debugs:


bufferBD.copyPixels(bufferBD, new Rectangle(0, 0, bufferBD.width, bufferBD.height), new Point());


bufferBD.copyPixels(bufferBD, new Rectangle(0, 400, bufferBD.width, bufferBD.height), new Point());


Now here the crazy begins, any Y given between (more or less) 0 and 400 causes this issue:

In this sample, HEX_HEIGHT = 87

bufferBD.copyPixels(bufferBD, new Rectangle(0, HEX_HEIGHT, bufferBD.width, bufferBD.height), new Point());


Please help!

Thanks,

Ron

[st33d]

You're copying from the buffer at some point down it and you've tried to copy the whole height of the buffer. To itself.

copyPixels should be used on the display bitmapData, copying from another bitmapData.

If you copy to the same bitmapData - it's just going to wreck itself!

[rejwan]

That's the thing - by copying itself from left to right or from right to left it works 100%.

Copying from Y 0 or 400 works 100% but in between it gets crazy.

EDIT:
These are the copy left\right codes that work 100%:

Copy left:
bufferBD.copyPixels(bufferBD, new Rectangle(((lastStartHexX + colsPerRow) % 2 == 0 ? -50: -100) * missing, 0, bufferBD.width, bufferBD.height), new Point());

Copy right:
bufferBD.copyPixels(bufferBD, new Rectangle((lastStartHexX % 2 == 0 ? 100 : 50) * missing, 0, bufferBD.width, bufferBD.height), new Point());

[BorisTheBrave]

If you copy to the same bitmapData - it's just going to wreck itself!

Actually the docs explicitly allow for this case. And it's correct for rejwan is attempting to do (keep the bitmap still, but give it the illusion of scrolling). However, it still seems likely that this is the source of the problem, you should implement double buffering to be on the safe side.

[rejwan]

I am implementing double buffering on all sides!

And as you can see in the screenshots, copying the bitmapdata to itself works fine when Y is 0 or 400, but in between it copies it choppy.

Really weird one, need help please

[st33d]

What is the specific height of bufferBD.height?

[rejwan]

What is the specific height of bufferBD.height?

892px

[bateleur]

OK, having done some proper tests on this it looks like a bug. I've implemented a quick demo on wonder.fl here:

 http://wonderfl.net/c/wObZ

As the copy "distance" decreases, the bug is more likely to occur. Similarly, as the width of the BitmapData used increases, the bug is more likely to occur.

Worse, it seems to be the case that the bug occurs unreliably for some combinations of parameters. I haven't been able to get good test data on that, though, so would welcome verification. Edit: Confirmed - results appear erratic!

Overall, looks pretty bad.

Edit 2: Suspecting the erratic behaviour might mean that the problem was at the render-to-screen stage I tried a variation in which the resulting Bitmap isn't added to the display list for 100 frames:

 http://wonderfl.net/c/tP6S

...unfortunately it's just as broken.

[rejwan]

OK, having done some proper tests on this it looks like a bug. I've implemented a quick demo on wonder.fl here:

 http://wonderfl.net/c/wObZ

As the copy "distance" decreases, the bug is more likely to occur. Similarly, as the width of the BitmapData used increases, the bug is more likely to occur.

Worse, it seems to be the case that the bug occurs unreliably for some combinations of parameters. I haven't been able to get good test data on that, though, so would welcome verification. Edit: Confirmed - results appear erratic!

Overall, looks pretty bad.

Edit 2: Suspecting the erratic behaviour might mean that the problem was at the render-to-screen stage I tried a variation in which the resulting Bitmap isn't added to the display list for 100 frames:

 http://wonderfl.net/c/tP6S

...unfortunately it's just as broken.

Yeah I figured it was a language bug

What should I do then??

[raigan]

What should I do then??

What's wrong with double-buffering as suggested before? Keep two bitmaps and ping-pong between them (reading from one and writing to the other) instead of trying to read+write from the same one.

[rejwan]

What should I do then??

What's wrong with double-buffering as suggested before? Keep two bitmaps and ping-pong between them (reading from one and writing to the other) instead of trying to read+write from the same one.

Hmm well it seems very redundant performance wise - the drawing process is a very costly one (not only hexes are drawn, also cities/units/resources/etc) - so I'd rather avoid drawing so much.

I'll attempt to use the bitmapdata.Draw() function, maybe it's not as buggy as the copyPixels one

[rejwan]

Alrighty - even though is seems very inefficient, when calling .clone() on the same bitmap patches this language bug.

So if you want to use copyPixels from a bitmapdata, you can do so changing the X axis, but to change the Y axis it needs to use .clone():

Code:

bufferBD.copyPixels(bufferBD.clone(), new Rectangle(0, HEX_HEIGHT, bufferBD.width, bufferBD.height - HEX_HEIGHT), new Point());

[st33d]

You should submit a bug report:

https://bugs.adobe.com/flashplayer/

Things like this won't get fixed otherwise.

(I'd do it myself but I didn't really follow what the problem was - I'm a bit tired this week.)

[rejwan]

You should submit a bug report:

https://bugs.adobe.com/flashplayer/

Things like this won't get fixed otherwise.

(I'd do it myself but I didn't really follow what the problem was - I'm a bit tired this week.)

K I posted that bug. thanks.

[BorisTheBrave]

Double buffering shouldn't be that much more expensive. By flipping which bitmap is visible each frame, you are still doing the same amount of copying that you were before.

[rejwan]

I'm actually single buffering + moving the X/Y of the bitmap by up to 1 hex to each direction, which causes the illusion of scrolling and only draws new hexes when absolutely necessary.

[agj]

Ah, I came across this bug once before as well. The docs do warn you that something could go wrong by copying a bitmap into itself, and says that what it supposedly does internally is make a copy of it anyway, so, if you make the copy yourself, there would probably be no great performance loss.

...Or so I thought, but the latest version of the docs show no mention of this. Hm. Are you using the latest Flex or Flash release, by the way?

[rejwan]

3.2 if I'm not mistaken - migrating to Flex 4 is too much of a hassle atm.