C3 on Mac - your experiences

0 favourites
  • 15 posts
From the Asset Store
[C2] [C3] Support C3 build service and Android 14
  • Hi there!

    I just started programming my game in C3 and even though it works smashingly well on PC's and even Android Remote Previews, my one year old MacBook PRO with 16 GB of Ram etc. stutters and spouts whenever going Fullscreen with the Game. It has some basic lighting and overlay effects as well as two particle effects on the test background, but it's at a Resolution of 256*144. The problem happens only when i set the fullscreen quality to "high", which i really want to do since i want to use Webfonts to support different languages. It doesn't really work all that great on "low" quality fullscreen mode either if i'm honest but oh well...

    I already opened up a Bug Report on the Scirra Github but i'm guessing there's not much they can do about it even though i think there should be a way to optimize this for the platform. And, yes, i tried every browser, my drivers are updated, etc. Other games work perfectly well on my computer, i'm an Interaction Design Student, i use it for 3D Modeling/Rendering, After Effects, Premiere Pro etc. never had a Problem. Of course, my uber super Gaming PC will be faster at those things but the Mac surely isn't too slow for a small Gameboy Resolution Game with some Effects...

    Especially since it worked perfectly well on PC's and even on my Android Phone via Remote Preview... I'm kind of desperate, since i was even contacted by the Apple App Store who took an interest in my Game for Promotion and i've told them it would be out for Mac as well, since i work on Mac and i mean... if it works on a standard Windows Computer it shouldn't have a problem with Macs either...

    Any Ideas?

    BTW, here's the link to the Bug Report: https://github.com/Scirra/Construct-3-bugs/issues

    Thanks!

    Joel

  • I have a 2014 13in i5 16gb MacBook Pro Retina and used C3 on it occasionally (whenever i'm closest to my Mac). Haven't had any issues with it so far. The projects i've worked on are set to 320x180 with high quality settings with point sampling. Don't havent any stuttering any issues whatsoever on it. I use to run C2 on it through VMWare on the Mac, which even then it ran surprisingly well - perhaps about 10% slower though but not very noticeable. On native OSX with C3 the performance is pretty much on par with the PC.

  • Cryptwalker Ooo that sounds promising Could you maybe try my file in the Bugreport for me on your Mac whenever you get the time? That would be awesome! Maybe there is a problem with my Macbook i just can't put my finger on it yet :S

  • So i loaded up your project on my MacBook Pro and my Dell XPS (9560) and ran them side by side on C3. I had to add a full screen toggle to the game as I don't like manually resizing it in preview. When it ran, both were pretty much identical. Didn't see any lagging or stuttering but i did noticed a slight one when the game just loaded initially. Didn't occur after that but i've seen this before in my projects too. However, it could just be my imagination but it appeared to run slightly slower when in full screen mode.

    Hope that helps some.

  • I'm fiddling around on some projects on an iMac 24Gb RAM, i5 at work, and I didn't notice any lag so far. Although I'm not really using any effects, and blend modes etc.

    Are you able to reproduce the problem in a clean project, to identify if it's any particular effect that's causing the slowdown on your Mac?

    I tested the c3p file in your bug report and no slowdowns for me, so seems very strange.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I havent noticed any issues running my game, however for me its the editor. When i reach around 1000 events the editor begins to lag and menus take a while to open. I filed a bug report but they didnt seem interested in investigating since i couldnt provide a way to reproduce, though i submitted a profile.

    I think it has to do with this blog post https://www.scirra.com/blog/ashley/35/layout-is-the-next-frontier-of-web-app-performance about how slow the layout is. A result of their decision to put the editor in a browser. I just have to put up with it i guess. I turned off menu effects and things, and there was a recent update to the layouts which may have helped.

  • That is really weird... I updated to the latest High Sierra OS now as well but unfortunately that didn't help... It's only relevant when going full screen, when i play back the game in about half the size it works fine on Macs. It ALWAYS works fine on Windows and works slightly better when i change the Macbook (2015, i7, 16 GB RAM) to a lower Resolution...

    Could you try this file (current version of the game i'm working on) too, if possible? Really sorry for asking, but THANKS A TON for all your help!!!

    Removed File since i fixed the issue...

  • I'm trying to narrow it down, what the big performance killer is and funnily enough, the main problem seems to be my vignette layer which is only a png image with darkened corners :S

    Might there be a less heavy way to do that?

  • Okay, i think i narrowed it down even further... i disabled "Use High-DPI display" in the project settings and though it still doesn't run as smoothly as on Windows especially when there's text drawn on screen i experience a small lag, it's already much better than before... I'm gonna play with the effects stuff a bit and see where i can optimize maybe making tha Vignette half the size and scaling it up on start of layout or something...

  • This is just another case of poor fill rate performance. We see people running in to this a lot.

    Intel GPUs (which most MacBooks have) have pretty low fill rate capacity. The project provided uses two force-own-texture layers, and enough content is displayed to count as another fullscreen draw, and then there's usually the overhead of a fullscreen draw to copy the game to the display. So it's at least 4x fullscreen draws per frame. On a high-DPI 2K display, one fullscreen draw alone will copy 3.7 million pixels, or around 14.7mb of data. The project does that four times, so it's about 59mb overhead per frame. If you want to reach 60 FPS, that means 3.5 GB/sec of GPU bandwidth.

    Presumably the Intel GPUs have a memory bandwidth lower than 3.5 GB/sec, so you can't hit 60 FPS.

    This is nothing to do with the fact your game is "only" 256x144: once you enable "high quality" fullscreen mode, it's rendering everything - including every layer - at full-whack 2560x1440 resolution. That's what "high quality" fullscreen mode is for! For this kind of game you really ought to use "low quality" fullscreen mode to avoid wasting GPU bandwidth - since that really will render the entire game at 256x144 (which is so small the performance overhead is probably negligible), then stretch the game up to the full-res 2560x1440 once at the end, meaning there is only 1x fullscreen draw overhead. That's probably at least 4x more efficient than your current high-quality fullscreen mode approach.

    By the way this is nothing to do with HTML5, browsers, Construct or anything else - you've hit a hardware limit. A native app would perform the same. 3D games are designed to perform minimal overdraw so don't tend to run in to run in to fill rate limits so much.

    Since a lot of Construct users end up having trouble with this, the new C3 manual's performance tips section was recently rewritten to focus a lot more on fill rate.

  • This is just another case of poor fill rate performance. We see people running in to this a lot.

    Intel GPUs (which most MacBooks have) have pretty low fill rate capacity. The project provided uses two force-own-texture layers, and enough content is displayed to count as another fullscreen draw, and then there's usually the overhead of a fullscreen draw to copy the game to the display. So it's at least 4x fullscreen draws per frame. On a high-DPI 2K display, one fullscreen draw alone will copy 3.7 million pixels, or around 14.7mb of data. The project does that four times, so it's about 59mb overhead per frame. If you want to reach 60 FPS, that means 3.5 GB/sec of GPU bandwidth.

    Presumably the Intel GPUs have a memory bandwidth lower than 3.5 GB/sec, so you can't hit 60 FPS.

    This is nothing to do with the fact your game is "only" 256x144: once you enable "high quality" fullscreen mode, it's rendering everything - including every layer - at full-whack 2560x1440 resolution. That's what "high quality" fullscreen mode is for! For this kind of game you really ought to use "low quality" fullscreen mode to avoid wasting GPU bandwidth - since that really will render the entire game at 256x144 (which is so small the performance overhead is probably negligible), then stretch the game up to the full-res 2560x1440 once at the end, meaning there is only 1x fullscreen draw overhead. That's probably at least 4x more efficient than your current high-quality fullscreen mode approach.

    By the way this is nothing to do with HTML5, browsers, Construct or anything else - you've hit a hardware limit. A native app would perform the same. 3D games are designed to perform minimal overdraw so don't tend to run in to run in to fill rate limits so much.

    Yesterday I watched a Unite 2017 talk on this very optimization. The developers were making a game in Unity that needed to run at 60 fps on an iPhone 4S. One of their key optimizations was to render the game at low resolution, then upscale to high resolution:

    I also had this problem in my game that I built with the Q3D plugin in C2 -- I couldn't understand why it was running so much better (60 fps) on a 2013 MacBook Air at 1366x768 than on a 2017 MS Surface Pro 4 (13 fps) at 2736x1824. I lowered the resolution to 1280x720 and let it upscale, and the game magically ran at 60 fps on the high resolution device.

    Edit: I had to chuckle when I read this, because I thought it was a Windows problem.

  • Thanks all for your suggestions, advice and also information Still learning, i never had a problem on Windows with the game so i'm glad that at least the issue came up, while i'm still at such an early stage and totally makes sense.

    Ashley : Thanks as well for your explanation, it makes total sense. Just for the record: i never blamed Construct or HTML5 or anything, i just thought it was more a question of Retina Resolutions than of GPU power so i thought maybe i was missing something.

    The reason why i wanted to use the high quality setting on the fullscreen mode in the first place was, that i wanted to use Webfonts in my game. Now, at this resolution and going with the "low" quality setting, as you can imagine, you can't make out anything anymore of the text. But it works without any problems on my MacBook. It works rather well with the Settin on "high", the high-dpi display setting OFF and the scaling set to "letterbox integer"...

    Which brings me to my question actually... What would you suggest to do? I see three possible options:

    1. Go with Spritefonts, which i don't really want to, since the game is already being translated into languages using special characters like äöü or â and so on, plus again, with a Gameboy Resolution there's pretty much just so small as you can go with sprites.

    2. Export all my assets double the res (512*288) and use Fonts there. They will still be blurry but at least less blurry than with half of that resolution.

    3. I don't know, this is a long shot, but maybe i'm missing something? Is there a way to use the "low" quality setting on a project but still keep crisp Webfonts when scaling up?

    I'm worried that when i upscale my assets, that i could run in performance problems again, since i'd like to use quite some effects (actually just one force own texture layer per layout, i think that second one was added by mistake )

    About performance i got a question too:

    When i, let's say, use my vignette png in half the resolution and then upscale it in the engine, does it use less performance than when i import a fullscreen vignette png in the first place?

    Thanks for all your help!

    Joel

  • For now I'd go with option #2 - pick the lowest resolution where text is still legible and use that with "low quality" fullscreen mode.

    In the C3 runtime we'll probably add a feature that lets you have low-quality and high-quality scaling on different sets of layers, but that's a long term plan at the moment. Also it can still impact performance, since each layer you render at full resolution adds another full-screen draw - so just one extra layer of high-quality text would bring you up to 2x fullscreen draws. I guess that's still better than 4x though!

    When it comes to fill rate, the important thing is the size the image is drawn at. That's why low quality fullscreen mode is so effective: it draws everything at a small size, and only stretches it up at the end.

  • Ashley Already began to set that up, seems to be the best choice as well and i could use larger SpriteFonts too, if i choose to go with those after all

    Thanks for all your help! I just wanted to say that i really love C3 and i advocated it very strongly in the Adventure Development Community so, i hope that makes up for some noob questions

    If you're interested, my twitter is

  • C3 is so great. I love it.

    The fact that I can use it in a browser is probably one of it's best features.

    My only complaint is that the hotkey buttons are just mirrored from PC versus being more mac specific. This happens a lot with cross-platform software. Blender comes to mind as one of these programs.

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