digitalsoapbox's Forum Posts

  • I already have it set to that.

    This isn't a bug, it's because you're using point sampling and whatever the original size of the sprite font is can't be divided evenly when scaling it. Though in your example, it's scaling just fine because it's using letterbox integer scale.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Problem Description

    Performance drops a little in FireFox and dramatically in Edge when using included shaders that effect color and blending. This seems to have more to do with the way the shaders are working than the size of any objects on-screen in relation to overdraw - without the shaders, performance is consistent and greatly improved. This issue appears using only the shaders included with C2, no 3rd-party shaders. This could possibly be related to browser differences but I wanted to report it because performance is so different in Edge and this may impact anyone who ports to XB1 when the ability to do so is officially released, and I definitely remember this not being an issue the last time I tested in Edge around 6-8 months ago.

    Attach a Capx

    https://dl.dropboxusercontent.com/u/14245368/performanceissues_colorblending.capx

    Description of Capx

    Creates 75 randomly-tinted sprites & changes their blending mode. Randomly chooses between Screen and Multiply blend modes on each sprite, then turns off the shader that isn't in use.

    Steps to Reproduce Bug

    • Launch Capx
    • Launch in Chrome, FF, Edge
    • Observe performance in debugger

    Observed Result

    Low CPU usage/high performance in Chrome. Higher CPU usage/Draw Calls but high fps in FF. Much lower performance in Edge, and if for example a single additional layout shader is added (eg the noise shader included with C2) performance can reach down past 10fps on a beefy PC. Maybe something broke in Edge?

    Expected Result

    Better performance with standard shaders. A further example can be found here from which the .capx is derived: http://fars.pixelmetal.com - go to the map screen and compare draw performance in the browser debuggers in Chrome/Edge.

    Affected Browsers

    • Chrome: NO
    • FireFox: YES, somewhat
    • Edge: YES

    Operating System and Service Pack

    Win10 1607

    Construct 2 Version ID

    243

  • Frankly I'm just confused now. The thread seemed to start as having concerns about how to import spritesheets. I think importing over the existing animation frames from a spritesheet is a useful idea. Beyond that, I'm still not clear what you want.

    Those screenshots you showed look exactly like what the importer would do. You set the cell sizes and then the editor knows what individual frames are. Whether or not it displays the entire spritesheet in the editor doesn't seem particularly significant to me - why is it useful to see the rest of the frames when editing a collision poly, for example? What does that make possible that was difficult before? It seems fine to just edit that kind of thing frame-by-frame. That seems like a useful view to see when importing a spritesheet, but once the editor knows what the individual frames are... what's the benefit of still treating it like a whole spritesheet?

    Also as I said before, if you force C3 to use an unmodified spritesheet, it effectively is a deoptimisation. You also can't do things like "crop all frames" which allows for a much tighter automatic spritesheet packing which saves memory, and also actually decreases the GPU fillrate which improves rendering performance. Your screenshots could probably save at least half the space, since there's a lot of transparency there. And with other images there could be issues with color bleed. So as far as I can tell, a better spritesheet importer would solve your problem and not have any significant downsides. Am I missing something?

    The issue may be the optimization being forced when the user may already have constructed an optimized spritesheet. There's also the question of whether such optimizations are really need in a desktop environment where saving a few MB isn't all that big of a deal. Being able to easily update a spritesheet and having C2/C3 import it without wiping out collision shapes, or being able to turn off what are occasionally problematic optimizations that end up causing seams in sprites, would be a big step forward in the way Construct handles spritesheets. It's also possible to manually process images through sometime like PNGGauntlet to provide more optimization (of file size on disk) that Construct provides, and currently this optimization is lost when importing into C2. This optimization can be re-applied after export, but this can be time-consuming when a lot of images are in use, and it has to be done every time.

    In terms of seeing the entire spritesheet in-editor, this could be useful for users to ensure that they're using the most updated spritesheet visually, instead of having to, for example, go through every frame of an animation to make sure they're all up to date. It's a quality of life feature.

  • We'll be providing the Xbox Live features for both C2 and C3.

    Is there a timeline on when this will be available?

  • Yes, we are working on an Xbox Live plugin and the UWP export can then be published to Xbox One.

    Is this for C3 only or C2 as well? I see that the MS post mentions C2 specifically, but as this is the C3 forum, I thought it may be good to ask for clarification since there doesn't seem to be any other publicly available information.

  • Great! Can you tell us more about what it can do already? Ashley

    So if we can finally publish games to Xbox without idwmg@xbox it should be possible to upload apps for Xbox, too? Or did someone already successfully upload a c2 app?

    It's possible to do this already for testing, however without any integration there's no way to launch on the platform.

  • Sorry but I'm gonna beat a dead horse here when I say that indie devs + subscription have nothing in common.

    I will not buy C3 which I thought was a natural progression from C2 but it's not.

    With the current model it doesn't benefit indie devs at all. In fact is a model that states: "take it or leave it. We are not changing it."

    See this for an example of community feedback being listened:

    https://blogs.unity3d.com/2016/06/16/ev ... d-pricing/

    I am jumping ship but I hope others don't give up to support Scirra. My point is I feel like I'm not a customer anymore because of the changes and this weighs so bad on my side. :-/

    I see a lot of posts like these, and I'm left to wonder: is the issue the subscription model - which I know a lot of people aren't fans of - or the value proposition of C3 with a subscription model? While I'm not especially thrilled with subscriptions, it's a fact of life these days, and my issue mostly lies with the lack of a compelling reason to subscribe to C3, which still just seems like a port of the C2 IDE to the browser with some very minor updates, and that's an issue when asking for more money, more regularly.

  • Lots of people are making statements like this which totally underestimate what you can do with a browser. We're aiming to prove that it can equal, and even exceed, native apps. It's not really possible to keep repeating this with the hundreds of posts we get every day, and people get sick of hearing me say the same things repeatedly anyway, so really the big thing is to wait for the public beta and see for yourself how it does.

    FWIW, we are still focused on indie devs and making it a better tool for them - it's still probably the largest segment of our userbase. We are interested in education as well though, so we're trying to expand there at the same time.

    Except...I'm doing no such thing. For professional work, I often find myself in browser-based prototyping tools such as inVision, Proto.io & Marvel. These are aimed squarely at the "pro" market, cost a pretty penny for larger organizations to license, sometimes per seat and sometimes per-location, and they're all perfect examples of why browser-based technologies aren't - at least yet - the way to go, often breaking with browser updates that are unavoidable unless you're at a large corporate organization that blocks automatic updates (common in corporate world, not so common in advertising/marketing agency or indie game world). These web apps all cost more than C3, are developed by teams larger than C3, and are targeted towards Enterprise organizations, and still constantly break down.

    As for making Construct a better tool for indie devs - I'd love to see that. But I have yet to see that. Instead I've seen posts about substandard image editors (compared to other, low-cost dedicated tools) that don't have the features I'd expect - easily accessible playback speed changes per-frame, image layers, REAL onion skinning with user-specified frame ranges and color tint to more easily identify which frames are behind/ahead of the current frame, some form of keyframe/timeline editor, which is bog standard now in image editors - and rounded corners on Events. How about better spritesheeting without unsightly seams (I emailed you about that, then had to roll my own solution)? If someone wants rounded corners on Events, couldn't they have added that with the new CSS styling options? How about inline comments? More fully featured NW.js support (again, I ended up using a custom-rolled plugin for basic, but necessary, NW.js features)? Rendering optimizations to improve performance on a wider range of PCs? More fully-featured WebGL2 support past non-power of two images? Maybe more portable Events/Actions that can be decoupled from objects? I could keep going but I can only bang my head on the brickwall between users and discussion of relevant or genuinely more beneficial features for game development in the coming update so many times.

    Again, it's your software and you're welcome to handle it any way you'd like. But I'm definitely not seeing many new, useful features in C3. Or features that were requested years ago - you have a forum full of them, that we can all see, keep in mind - and at the time you commented you'd look into them...and still no joy. So I think being a bit wary of what's promised should not only be expected, but that it couldn't really hurt to address them more directly as opposed to talking around them with vague half-answers. Especially for the few developers using C2 currently who are trying to do more than simple mobile games or template-based Steam Greenlight cash grabs. Much like calling XB1 support "beta," I'm not seeing many fully-baked new ideas outside of a browser-based interface, and only, once again, a vague suggestion that a desktop/wrapped version maybe, could be, at some point, coming down the road.

  • > who in their right mind is going to work on larger games through a browser interface?

    >

    Could you further explain this thought?

    Browsers can barely handle websites without crashing. Every browser-based tool I've used professionally has had stability issues, often crashing the browser, not to mention performance issues associated with browsers and all such products being dependent upon the whims of the third-parties developing browsers. Standalone applications based on web technologies (wrapped in Electron, NW.JS, etc.) seems to fare somewhat better, avoiding the forced updates of Chrome, Firefox & Edge, but achieve nowhere near the performance or stability of standard applications, including those created specifically for professional use, which are created by much larger teams of developers with proven track records working with web technology. And this is just desktop - Android/iOS bring their own issues with stability, memory usage, and performance.

  • From what I have seen... c3 is basically c2 that you have to rent. Whats the point? I feel as though I am part of a c2 community that begged for just a few simple features. Features that you sort of need to actually make a decent game (something beyond flappy phone games)... Heck, even working box2d physics sure would have been nice. We weren't asking for 3d, we were asking for the basic tools any game engine needs. (collision filtering, raytracing, collision callbacks, swept shapes, ... I could go on) Not to mention extreme scalability issues when making complex games. And javascipt is stupid for games (but thats obviously a given, a compromise that wont be changed)

    Is c3 going to address these problems? I haven't heard, frankly, I don't care because I got sick of not having the tools needed for really making a game in c2 and so dropped it.

    And I'm not someone who thinks a behavior should make my game. I program. I have rolled 3 different platform engines on my own, and a custom retro based physics behavior for c2. I just wanted basic features literally almost every other engine has.

    I've been happily using Unity for free. With c#. Why would I rent c3 when I only use c2 for simple prototypes ?

    I don't care that it is on mac (see above). I don't care that its in the cloud (see above). I don't care that it has a 3 in its name if it doesn't actually fundamentally address the major issues with making a game with c2.

    Anyone have any insight?

    The point is that tools which can run on tablets are aiming for the educational market, not professional game developers. I had some long, interesting conversations about the direction C3 is taking while at GDC and that's the conclusion which was independently arrived at by most everyone I spoke with. It is making itself the polar opposite of the "best 2D game development tool." Which is fine, if that's the tact Scirra wants to take, as it's their business, but it would clear up a lot if they'd just say that instead of announcing the porting of the sub-par image editor from C2 or...wait for it...rounded corners. Oh, and BBCode in comments, when the text & spritefont objects still can't handle multiple weights or colors.

    While it's an impressive coding exercise to run a tool like C2 in the browser - and let's be honest, C3 is really just C2 with a few visual tweaks in terms of features, based on what's been announced - who in their right mind is going to work on larger games through a browser interface? Is anyone really supposed to be excited we now have to scroll to see all Function parameters? Now, if we could name the parameters, that would be a big step, but scrolling forces further mouse interactions (and no, tabbing to the next field is no better), which slow down development, especially if you're typically using hotkeys rather than slowly navigating through C2/C3's multiple popups that would have been better off being combined into the rest of the interface if there's some use case requirement that they remain separate panels at all.

  • > SOMBRERO will be in the Intel area at GDC. If you're going, stop on by, give the game a whirl, and say hello!

    >

    > http://store.steampowered.com/app/472690/

    >

    I'll try and swing by!

    I'll be there tomorrow (March 1st) from 2-6p.

  • SOMBRERO will be in the Intel area at GDC. If you're going, stop on by, give the game a whirl, and say hello!

    http://store.steampowered.com/app/472690/

  • > OK, this should be fixed in the next build. The problem is it didn't understand TMX files with multiple tilesets. In the next build it will use the tileset associated with the imported layer.

    >

    >

    > > This is something I just do not like about C2, what I do not understand is why you can not edit tilesets directly from tool...

    > >

    > You can - Construct 2 has a built-in tilemap editor. You don't need to use Tiled. The TMX importer is just for convenience.

    >

    you're right! sorry for my misunderstanding > <

    i discover that is possible load them from editor when insert "tilemap" object > <

    me guilty sorry for mi english too

    You're better off using rexrainbow 's tmx importer. The C2 importer is for tmx files is...kind of completely terrible, and extremely limited. You can load your tilesheet (the tile images themselves) into the built-in tilemap plugin at runtime using Load image from URL, then using rex's plugin to retrieve the tilemap data and place the tiles into the Tilemap object. Keep in mind the Tilemap object is (despite claims otherwise) somewhat low-performance if you're building a scene that isn't designed for having relatively few tiles on screen at once.

    If you're going to have tiles that don't use default polygon colliders, you may be better off loading all of the tilesheet images into an empty animation in a sprite, then pasting the tiles into a Paster (the Paster plugin) object and then removing the sprites afterwards, and use separate objects to detect collision on the tiles you want to act as jumpthrough/solid/etc.

  • It may be easy for some, but not for me (or a majority of C2 users I would imagine). I don't know how to convert xml to json etc. I would have to either wait for the developers to update the plugins or pay someone to do it. Rex has what? 100+ plugins? How long would that take him to update, even if he wanted to spend the time updating them. Using Podes plugins? Out of luck there too. What about the paid plugins that are no longer supported or have limited support? I wonder how many people use the cranberry plugings in their projects. Most of the plugins I use are from users that have already left the community or from Rex, who has so many that it will take a very long time to get them all updated. With that being said, I'm not surprised that the c2 plugins aren't compatible out of the box with c3. I never expected them to be. My concern is that users are going to be quite disappointed when they try loading up their project in c3 and it doesn't open.

    I would imagine that this is why the only parts of the "big" projects we've seen open in C3 are the title screens. The definition of "high fidelity" also seems to have changed from any I'm familiar with, if C3 is unable to use C2 projects that use any third-party plugins, which is, I would again imagine, most of them.

  • >

    > >

    > >

    > > Any issues you run into with XDK will likely exist with any other web-based exporter, because you don't have control over it, and if you're doing anything it's not expecting the build will fail. The idea that Scirra will be able to provide better maintenance than Intel? What makes you even think that's possible, given the resources of each company?

    > >

    > > If you want the option to optimize your builds as much as possible, you're better off installing node.js, cordova, java & GIT on your local machine and compiling locally, which takes much less time and doesn't require uploading your assets to a 3rd-party server (that may potentially be unreliable), which is going to be configured to support a more generalized build as opposed to something specifically for your game projects. Reliability aside, if you're working on a bigger project, uploading over even a fast connection adds a lot to the build time - whether you're using Cocoon, XDK or Phonegap.

    > >

    > > Once set up locally, Cordova isn't difficult to use, and just requires a few command-line options or your setting up a batch (.bat) file when you want to compile. If you're interested in doing this, install in this order: java, GIT, node.js, then Cordova. Installing Cordova last allows it to set up the connections to the other components automatically and no manual configuration will be necessary. Plugins can be installed from the command line/powershell, and I'm sure there's a GUI-based installer for them as well if you're more comfortable with that after setup.

    > >

    >

    > I just don't believe it's possible to achieve the same performance as Canvas+ does with any exporter/wrapper, none of them seem to disassemble the inner workings and recompile as well, or whatever the hell it does. Would self compiling with a batch file improve performance? And by performance, I obviously mean fps. I don't believe optimising code could improve matters to the point where xdk or a batch file build would ever reach the smooth, fluid gameplay cocoon is providing, but it should.

    >

    No, doing the build online or offline is just the same... The performance won't change.

    The performance is only influenced by your code, the engine, the device, and the wrapper.

    Changing build options won't change anything but changing wrappers is another story...

    Changing from IntelXDK to Cocoon.IO or vice versa would change performance.

    But finding the best performance wrapper is up to you.

    No, the performance won't change if the exporters you're trying are all based on PhoneGap/Cordova, that's correct. I was referring to the speed of the build process, not the application that results from it. And as Ashley mentioned Canvas+ is a total mess, and non-standard, and performance isn't predictable across hardware because it's non-standard. There's little to "optimize" in terms of the build that's exported that's exporter-specific, other than Canvas+ they're all using pretty much the same backend to build. Canvas+ isn't really doing anything all that much different in terms of the game's overall codebase so if you're seeing drastically better performance using it over WebGL/Cordova export, you're probably doing something wrong. It's not doing what you think it does.