Forums » Help » Create Big Levels with Simplex noise

So this is a levelmap generated with Simplex noise.
https://dl.dropboxusercontent.com/u/3091827/noise/index.html

Navigate with arrowkeys.
Swich view 1 & 2.



As you can see there is allot of drawcalls!
Dropping the frame-rate way low, because of the amount of 8x8 tiles to be drawn.
If you leave the screen to the upper left performance will increase again.

I really want to be able to interact with the tiles, settings up rules and so on based on them. How would you do this?

Increasing the tilesize for once will produce chunkier and even more pix-elated world.

I want to draw even more details based on "land-type" and so on.

Food for thought?

If you look at the way the maps are implemented, there are quite a few quick tricks that can improve its speed :
1) Perform all precomputation (scaling, caching) to have only 2) two for loops, one on x, one on y, with no multiply, only add, and no property access.
3) within this loop call yourself the drawImage on the (var cached) context2d, and the version that takes only 3 arguments. So you have to pre-tile yourself. I might search for the code i have doing this if you want.
When calling Impact's drawImage with... is it 6 arguments ? don't remember. Whatever, then it will call again context2D's drawImage with 6 arguments. So that's 2 function calls with like 12 arguments, against one fn call with 3 arguments, not to mention the checkings and other operations not usefull to your case (ex : flip).
Have all your tiles in individual canvases and have them pre-scaled.
Impact does scale automatically when loading ig.Images, but 1) the scale has to be an integer. 2) if the scale is one, an Image remains an Image : ensure that images are copied into a canvas each time to win like 33% on Ch/FF.

The next improvements, i'm a little less certain of its gains, and it takes a little more work : taking advantage that only the borders will change when scrolling, save the constant part into a once allocated canvas, then on next move redraw that saved part -in one operation-, then fill the gaps.
Since it is also the number of operation that counts -not only the pixel count of each operation- that should quite reduce overhead.
It's only tricky if you want to handle sub-tile moves, but even with that feature, it is mostly about beeing carefull about what was the referential in the last snapshot, and what it is now. So remind avoiding the off-by-one frame issue and all this should run (more) smoothly.


By the way, you got an amazing result using this simplex noise !