Scrolling Game Development Kit Forum

I believe the SGDK2 code is smart enough not to draw sprites that don't intersect the visible view on the screen. You shouldn't have to rely on the browser's smarts for that.

   for(si = 0; si < this.sprites.length; si++) {
      var curSprite = this.sprites[si];
      if (!curSprite.isActive) continue;
      var frames = curSprite.getCurFrames();
      if (frames == null) continue;
      var frameSet = frameSets[curSprite.states[curSprite.state].frameSetName];
      if (typeof frames == 'number')
         frameSet.frames[frames % frameSet.frames.length].draw(ctx, curSprite.x + this.currentX, curSprite.y + this.currentY);
      else
         for(var fi = 0; fi < frames.length; fi++)
            frameSet.frames[frames[fi] % frameSet.frames.length].draw(ctx, curSprite.x + this.currentX, curSprite.y + this.currentY);
   }
Okay, I must either be fatally misunderstanding something in MapLayer.js or I'm using an earlier version of SGDK2. Where in your Javascript code is it checking for whether it's within the visible rectangle? If I am, I'm sorry, please correct me! (Either way, I manually wrote a check that would only draw sprites within the visible region of the screen using curSprite.layer.currentX/Y.)

Consistent speed was my reason for using a method like setInterval to draw frames instead of requestAnimationFrame. Did you consider comparing the result against the stock SGDK2 behavior with a constant (low) frame rate limit set. Of course if you set the limit too high, it won't be hit, but if you set it appropriately low, it should be relatively consistent.

I'd say I'm having smoother performance with the edits:

The only frame-rate that the original code was consistent at was 15FPS (At least on my slower Android phones) (PC seemed to be a mixed bag, but it was slightly higher around 25FPS). That original code was even more capricious in performance than this code I'm using now The setInterval handler was reported by Chrome to take around 100ms, sometimes even reaching 200ms for scenes with tons of tiles.

With this newer code, performance is stable at 25FPS on even the worst phone I can find. My requestAnimationFrame handler is reported to take 50-60ms at worst on an Android webview, which is close enough to 25FPS to not make things noticeable, despite flagging a Violation in console.


Are you also aware that you can pre-create most sprite instances and use "ActivateSprite" instead of add sprite so that you're not creating and deleting objects?
Nice trick. It was mainly the tile drawing that I made changes to, not the sprite drawing. Tons of local variables are created it seems whenever tiled layers are drawn and I'm trying to refactor this to only use global variables rather than polluting with local variables.

So I never call the AddSpriteHere method. As a Javascript developer I've had issues in the past with the garbage collector for high sprite games, and for things such as bullets, I try to create once them and activate them, then move them to where I need them.

The ActivateSprite is a rule I hadn't seen, I've been manually activating these by setting their properties. I'll look at it.

Most of the performance variance I have isn't coming from me creating or destroying objects, it seemed that it laid somewhere within the rendering code, and ctx.drawImage() was probably one of many other things I had to look into.
 

http://buildnewgames.com/garbage-collector-friendly-code/

Have a look at this:

I've smoothened out the performance of the drawing by removing all local variable declarations in MapLayer.draw() and many local variable declarations in the drawing functions in general.

This creates less garbage and when I inspect my Android game's webview in chrome://inspect, the memory peaks are smaller than before, and also seem less frequent.

The game seems a tad slower overall (With the added scope lookup time) but each frame seems to be less variable in timing. I'd much rather have a slower speed overall than a fast but insanely variable speed, especially when I have more being drawn on screen.

https://jsperf.com/global/4

That JSperf may explain this a little better than I can

You may have said that these optimizations are penny wise but pound foolish but when added up, these optimizations seem to really help the game's performance on low end mobile devices.

EDIT:

Is this code also drawing sprites which aren't on screen?
Maybe some browsers are smart enough to know that something is being drawn offscreen but is this something I can always rely on?

Such high praise -- and I very much appreciate it. Too bad it's after so much of SGDK2 has left my brain and been left in the past. I will keep your comments in mind as I consider where to invest efforts in the future, though. Perhaps I will yet find time to further develop SGDK2... like I did with lighting effects. There are at least a couple hangers-on (including you) giving me some motivation to keep it alive. Thank you.

No problem, I love this engine. What you've done by making this open source is selfless. You're a really good person.

I know you're busy now, and don't have time to rebuild this community again, but it wouldn't be difficult. Have you ever considered a SGDK3 (With some possible 3D support in both C# and HTML5)?

I'm confused how a different method of pushing animation could make much difference. If there's too much to do within 1/30th of a second (or whatever your frame rate is) there's not much you can do to save it. But I guess there could be some more subtle differences that would make requestAnimationFrame more consistent than setInterval. Again, I put less time (and experience) into the HTML5 code than into the C# code, but will try to remember this for future updates. Sounds like the right thing to do.

 
function fnAnimate(timestamp){
gameDraw();
     
   if (timestamp < lastFrameTimeMs + (40)) { 
      //if (draw3D != -1)
   
      requestAnimFrame(fnAnimate);
   return;   
   }    lastFrameTimeMs = timestamp;
   
gameUpdate();

requestAnimFrame(fnAnimate);
   };
This is the asynchronous game loop we're using rather than calling pulse() with setInterval, it draws to the screen much more frequently (when the window is ready) than it updates game logic, which is rate limited by the FPS. The timestamp is a value passed into the callback of fnAnimate.

gameDraw() and gameUpdate() are just the respective map drawing and map updating functions taken from pulse();

Even if the game lags (Due to the mobile operating system running background processes sometimes), the display still appears smooth and responsive!

It's not good, but I hope it gives an idea of what I mean.

Did you notice the Mobile Device sample project, which is essentially an HTML5 project designed for a mobile device interface. Is that the kind of thing you're talking about?

It's a good start.

A. It would be nice if the controls were represented as separate objects (Possibly overlaid canvases) which would allow us to bind separate asynchronous event listeners to them with Hammer.js. Using a fun library like Hammer.js you can have all sorts of cool browser events such as multitouch, panning, and even rotate. It even has polyfills for browsers that don't support the fancy touch stuff. We're using it right now with great results on all devices, and falling back to mouseInfo for the PC port.

B. SGDK2 uses a single mouseInfo event listener. This causes problems with multiple touch operations.

C. Canvas and touch events don't scale on multiple devices, or when the canvas is at the center of the screen. This can be fixed with modifying the style attribute, but the mouseInfo event listener is still hard coded to calculate its position regardless of where it is. (Maybe it's my version of SGDK2, I'm looking at some of the newer versions and see that you might have fixed this)

D. The HTML5 is useful, but for an exporter, it would be so nice if we were given an APK or some kind of device specific binary. Tools such as Crosswalk/PhoneGap can automatically generate an APK given a directory of HTML files. They can also generate binaries for any platform.

For instance, native audio is the best audio, but not all browsers can handle web audio (Older android webviews can't). An exporter is good for making a hybrid between HTML5 and native features

EDIT: Another thing I've noticed is that using XFrames is much faster and smoother than drawImage. This is because canvas copying seems to be faster than drawing images..

https://jsperf.com/draw-canvas-vs-draw-image/2

Perhaps you could use XFrames by default? I see no reason to continue to use Frame. Or, the SGDK2 user could just modify modulate alpha values by a bit (255->254) to turn Frames into XFrames

This should be a note, we need a separate thread for these optimization ideas.

In general, I'm wondering what is driving this need to optimize. Are you sure the problems you're trying to solve are the problems causing your performance issues, assuming you are even observing performance issues? Have you used Chrome's performance profiling features to check where performance is an issue?

What is "~~"?

ctx.drawimage is most definitely the problem. Something about it seems to be causing the game to lag. This is most noticeable when you draw tons of tiles.

SGDK2 is telling me that drawing  large images is faster than drawing multiple smaller images.

That doesn't make any sense to me because every JSPerf out there says drawing subimges of an image is slightly faster than drawing one huge image!

So I glanced at the Frame.draw function and slapped myself for not seeing the solution sooner!

I've discovered SGDK2's issue here, subpixels.

1. We need to disable image smoothing in the context.
2. All coordinates/parameters that are passed to drawimage should be wrapped with ~~.

https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Optimizing_canvas

This article states it directly as the second bulletpoint

~~ is my favorite operator that is similar to Math.floor() for "int" conversions. It's what I use to fix the coordinates and attempt to alleviate the lag. I've noticed less lag and slowdown when drawing high-density tile regions and ive managed to speed up X/Frame.draw.

Because of the subpixels (When sprites or layer.currentX/Y is in a non-integer location, drawImage has to perform extra unnecessary calculations.. which I suppose is causing the slowdown.

Try ~~ for yourself with a game that has tons of tiles/sprites with floating point positions on mobile.

https://jsperf.com/drawimage-whole-pixels/45 proof
https://jsperf.com/drawimage-whole-pixels/42

Next

One of my issues with dynamically loading Graphics is the way that SGDK2 handles modulate colors.

I know the difference between image url's and the base64 embeds. That isn't enough for me and I'm sorry for not being more clear, it isn't the issue. I currently use very large graphics 1024x768 and use color modulation for maaaaaaaaaaany frames of these large graphics... such as large high resolution color changing backgrounds and have many within my game, which make many calls to the ModulateCelColor function in Frame.js.. The repeated use of getImageData/putImageData creates garbage (at a glance, similar to memory leak, but it actually gets recycled at a certain plateau, 200MB on pc) so this is a known issue in Chromium.

https://bugs.chromium.org/p/chromium/issues/detail?id=242215

Imagine this now with a new Typed array of 1024x768 bytes for each frame.

You'll get nice little error in Firefox eventually which happens for me, which makes your project unable to load.

Look in Frame.js and see where and why.

document.write('Failed to process images. This may occur when running from local files; see <a href="http://stackoverflow.com/questions/2704929/uncaught-error-security-err-dom-exception-18">see details</a>');

The try/catch tells us this. Okay!

Except, that isn't the error, is it?

Nope. What?

There's a memory limit and I've quickly hit it in Firefox, even with base64 embeds.. so I know it can't be that security issue.

So I've just removed color modulation from my project altogether by removing that function, and no more issues on mobile...  and no more weird "security issue" in Firefox which isn't really a security issue at all but a memory issue!

Too bad for that actually.

It would be really nice to be able to control when and where these things happened.



Next

Another bulletpoint from the optimize canvas article is that transparent canvases are inherently slower to draw to.

Your points are correct.. my understanding of PNG/JPEG transparency would tell me that JPEG would be faster to draw, lacking the transparency of PNG and not needing sophisticated color blending, and since opaque canvases are faster.

So I created a performance test on jsperf to investigate

https://jsperf.com/png-vs-jpg-drawimage/1



In this test case, I was incorrect, surprising me. It turns out that PNG was faster.

Perplexed, I ran another test, this time, trying to take advantage of the fact that PNG has transparency and this matters more when overlapping images, so I made multiple in-place runs of drawImage.



JPEG was faster in the second test.. But not by much. They seem very close with performance differences mainly due to error.

I wanted to stress test it even further.. so I did this in a loop of 150 images... ( a real environment)



JPEG was once again faster.. but not by much!

----------------

I've sped up my performance on phone a tad mainly with double tildes. If you'd like, look into it the ModulateCelColor issue I mentioned also. PNG/JPEG isn't an issue.

Great engine btw!

To tell you the truth, I've been using this engine since it was released a decade ago but without ever registering here...

The HTML5 stuff isn't difficult but it isn't as good to me as the C# code (OpenTK, or even the prior DirectX code)

I'm sorry for disturbing you so much, We're really pushing it to its limit with all of the modifications/ custom JS code I'm adding (Our game really strains SGDK2 because we're trying to make SGDK2 into a 2.5D Sega Saturn on steroids with HTML5). So any optimization is good to me right now..

I've modified the code so much the only thing I use SGDK2 for is just project management of assets. Nearly all of the code I'm using now is very different from SGDK2.. The original code was useful for prototyping our project.

Despite using entirely different .js files, the SGDK2 project still loads and exports. I like the open source-ness of this engine!

Hello, bluemonkmn,

I shouldn't post my questions here in this thread. However, thank you for the support.

I'd be honored to help as a developer of SGDK2. I've seen so much done to this program over the years and I can't believe you'd invite me to work with it.

Thanks for the offer!

Will you upload this project to github?

As for a demo of the framerate problem, I'm just testing the LimitFrameRate call on Chrome. I'm not sure why it's happening.

I don't have a whole lot of OpenGL experience, and/or it's been a few months since did anything with OpenGL so my memory's getting fuzzy again; do you know what kinds of features are unique to post-1.x versions? I would have assumed the new lighting architecture (use of shaders) would be relying on something after OpenGL 1.x. So at a minimum, the map editor would not be able to show the effects of lighting.

Also, since you've dealt with it more recently, do you know when this requirement changed? How far back to users have to go to find a version they can use with OpenGL 1.x? Is there a hard version-based requirement that explicitly fails if the version is a problem, or do things just not work right and confusing errors occur? I wonder if it would be a simple matter of disabling a version check, or if I would have to back out the whole shader-based drawing architecture.

Hopefully there's some way to simply copy code from an older release and "switch" to it on user request, but your input might help me find the path of least resistance to doing so.

Version 2.2.10 is the version I currently use.

Firstly I would point out that you can create a tile definition for any tile index that you don't want to draw, and delete the frame from it, which should prevent any drawing function from being called for that tile index. I'm not sure how well that fulfills your request, but if not entirely, I would ask why a drawing function would be associated with a tile category, and what's missing in the ability to control tile drawing via tile definitions. I would also point out that you can also use Tile definitions linked to a counter to control how tiles appear at run-time versus design-time. Frame 0 of the tile animation can be how the counter appears at design time, and frame 1 can be run-time. Then you just need a rule to increment the counter to 1 when the game starts. And frame 1 can have 0 frames in it if you want the tile to not be drawn at run-time. If you find that 0-frame tiles are being drawn at run-time, I think that's a bug.

I am very sorry for this. This is an amazing feature that I did not know existed after nearly 12 years of using this program.

I think you can already do a lot of cool things with animated tile definitions by fiddling with how the counter is updated instead of assuming that the counter always simply increments on every frame, and is shared by all animated tiles. Hopefully a lot of what you want can already be done.

You have support for linear transformations (Through matrix elements) to resize and shear frames. For my application, I find myself doing complex things such as plotting each scanline of a frame to a position on a sine-wave and then modifying the argument of the sine wave to simulate wavy light-diffraction for a water-based level.

Things like these currently cannot be done with Framesets unless you go out of your way to have a frame for each scanline and stack the frames on each other. I've originally used this complicated method and other methods. Eventually I was forced to write my own custom draw function and heavily modify SGDK2's source code.

However, I'd REALLY love if we could have custom draw functions for each tile category! It would make things so much easier!

*It would be nice if you allowed us to apply our own custom linear transformation with a custom matrix to the frame in the Frameset editor like the shear matrix and scaling matrices that you use to resize, shear, and rotate the frame. (Though this wouldn't be intuitive to the non-mathy user), which would be similar in power to having a custom draw function. ******(But I feel letting us write our own custom draw function for each tile type would work just as well and be easier to implement)

You mean you want the real-time color blending that is available in the EXE build to also be available in the HTML5 build? Do you know how to implement that in JavaScript /HTML5 code? Or if it's even possible?

As of yet I haven't found any practical real-time way to perform this. getImageData() and putImageData() technically work but are very slow in real-time.

You mean for HTML5? Do you know of any good open source libraries? Or do you think yours would qualify?

I'm using Sound.js, but I had to go a little further than the average SGDK2 user to get it to work.

Do you mean to add an item to the menu to browse for a custom color wheel? Why replace the color wheel instead of replacing the default set of colors. The color wheel allows you to select all colors while the palette below allows you to select from a predefined set of colors. Alternatively, I think you can right-click on any pixel in the graphic sheet to pick its color if you want to store your palettes on the graphic sheets. Does that help?

I'm silly. You're a genius. Sorry ^_^

EDIT

LimitFrameRate doesn't limit the Framerate to the correct speed in my version of SGDK2, you may have fixed this in a later version.

In my current version priorities don't work correctly between layer priorities and sprite priorities in the HTML5 version, for instance, try having a layer priority of 0 and test this.