Node-webkit Runs 10 FPS slower when exported

0 favourites
From the Asset Store
80 pieces of loopable game music, 10 game overs and 10 level complete pieces.
  • I didn't know where to post this so I figured general discussion was as good a place as any.

    As the subject says, we've optimized our game finally where it can handle 250 enemies on screen with the game still running around 50fps in node-webkit preview. The problem is, when I export the game to node-webkit to be ran independently, I only get around 40fps in that. What is the issue here? My friend who is the other programmer doesn't have this issue.

  • Computers work in mysterious ways.

    Same reason why the recent Total War Rome 2 game runs fine on my old Laptop but not my Nvidia Titan powered desktop.

  • Probably resolution. C2 stretches the game window if you use fullscreen, so a lower resolution makes the game faster.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • I've noticed this same problem. Not sure it's a resolution problem either...

  • Look into turning off behaviors/functions for sprites that are off-screen, maybe?

    I've been able to keep my game locked at 60fps at 1920x1080 with over 400 enemies in 1 level, as well as over 20,000 sprite tiles to make up the level artwork that get copied into a few canvas objects, so they're not all separate objects for C2 to track. This is on a 6 or 7 year old machine I use for testing with only an nVidia GTX 460. The main way I was able to do that (other than prodigious use of the canvas plugin) was by disabling any functionality for everything off-screen, including turning off any particle systems/webgl effects.

    In fact, it actually runs FASTER when exported to an .exe through Node-Webkit; I only get between 45-55fps when testing in the browser, though it weirdly runs at a higher fps in-browser when full-screen and I'm at a loss as to why.

  • Yeah it's a bit weird because you'd think the node-webkit preview would work the same as the exported version since it's running a node-webkit instance when you do preview.

    I'm not entirely sure if it's resolution myself. We increased the resolution from 640x480 to 854x480 (a 16:9 resolution) and it only impacted performance a tad because of our beta level stress test enemies since there were more of them on screen.

    digitalsoapbox That's very impressive that you pulled that off, I'm not going to lie. Maybe our best bet would be to make use of Canvas since I've made a ridiculous amount of effort along with the other programmer to turn off everything off screen.

  • corlenbelspar

    That would be my suggestion. The Canvas plugin been a lifesaver in terms of keeping the framerate as fast as possible.

    Also, what kind of video card do you have? Some cards handle things better than others.

  • I have an ATI Radeon HD 5450 and I already updated it to the latest beta driver available which actually gave me 10FPS more in performance.

  • digitalsoapbox Nice! I'm really wondering how you use the canvas plugin to deal with so many objects. This is very interesting!!!!! (and by the way can rescue my game fps...)

    Need a tutorial !! ;)

  • KaMiZoTo:

    A majority of the sprites in my project don't need collision since they're part of the level artwork, so after they're created - and if they have no collision needs - I paste them into a Canvas and delete the original, as it's no longer needed. 19 layers of tiles get comped together down to 4 Canvas objects - it could go down to less, but I wanted some parallax movement & foreground/background layers. For objects with collision, I have a separate layer set up that handles all collision for static objects, and the sprites themselves receive collisions for things like exploding objects.

    The way I've got it implemented is a little specific to the type of game I'm making (see below), but if you have any pressing questions I'd be happy to answer them. Maybe send a PM so we don't hijack this thread, or start another elsewhere so everyone can benefit from any discussions.

    In map editor:

    <img src="http://site.digital-soapbox.com/temp/C2/map.jpg" border="0" />

    In game (alpha art & gameplay):

    <img src="http://site.digital-soapbox.com/temp/C2/ingame.jpg" border="0" />

  • digitalsoapbox - That seems like a really neat trick! But do you know if it uses more memory (as the canvas object being a large single object would take up more normally than a bunch of little tiles)?

    I have one project that could really benefit from this, but the layouts are quite large, so if the memory usage spikes it would be a huge issue.

  • Memory usage never really goes over ~12MB, loading a TMX file (through the TMX importer plugin), spawning the tiles & comping to the large Canvas objects. It spikes a little at level load time (maybe ~14MB) and there's a slight hitch in the framerate as everything takes place, but nothing that can't be hidden behind a short loading screen, which could be skipped on future loads by saving the state of the game right after it loads the level to a unique save state for each level in the game.

    EDIT: I should probably mention this is all running in WebGL on the desktop, so I don't know what performance would be like on mobile devices, which aren't really my targeted release platforms.

  • Hi,

    One difference might be that the preview does not use compressed data.

    Have you tried checking the speed with uncompressed data in the exported package? Just unzip your .nw file (and delete the .nw), and see if it makes any change.

    Greg

  • Hi,

    One difference might be that the preview does not use compressed data.

    Have you tried checking the speed with uncompressed data in the exported package? Just unzip your .nw file (and delete the .nw), and see if it makes any change.

    Would that affect results after everything is loaded into memory, though? My understanding is that images, etc. are uncompressed when loaded into memory, so their initial state shouldn't really be an issue.

  • Keep in mind that VRAM and RAM are two different things.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)