Jase00's Forum Posts

  • Thought I'd post here as this relates to the monthly subscription :

    I haven't been round these forums in years but, Ashley and Tom: thank you so much for adding a monthly option. The price right now for me in the UK is amazingly affordable and, as a burnt out hobbiest, I feel there's less commitment to paying for a whole year (I'd use Construct 2 a couple of times a year, maybe miss a month or two if other life stuff comes up).

    I can also evaluate all the features for just over £10 for a whole month. That's brilliant, over the years I kept getting emails about all the features added, and I do think Construct 3 has become a mighty fine bit of kit, but the annual subscription felt very out of reach for my financial situation.

    I hope to finish a project finally for once in C2, then I wanted to check out some new software, and C3 is now at the top of my list, especially because of how passionate and responsive the Scirra team has been over the many years.

    One competitor software I was interested in, last I checked, I can't even find info on their next product anymore. They'd seem to get frustrated at their users for asking about their next big product which they initially teased with screenshots. Major shame.

    Anyway, I'm glad this is now an option and I'm excited to experience all the features I've missed out on for a substantially cheap price. I will definitely consider buying yearly if things take off for me.

  • ome6a1717 How many CPU cores do you have?

  • Yeah I agree that this doesn't give a good overall performance insight, as it doesn't cover everything or a few features. There'd certainly be vast optimisations in things such as object picking and as you listed with collisions and stuff, but even when having a completely minimalist project that is practically empty, there is a 200+ fps difference between two different HTML5 software runtimes (Construct's and GDevelop) when in the exact same NWJS environment & version, with the exact same two events, and exact same image.

    Thinking more about why I felt driven to post this, I guess I wonder why this is the case. Are there things under Construct's hood that are permanently switched on maybe? Could we be able to have the ability to switch these off to squeeze out an extra 100fps or so?

  • Hey all,

    I am fluctuating a lot with my view on Construct. I recently expressed my excitement from the news of a new Runtime beginning development at some point, I was impulsive with posting my enthusiasm... But I did start thinking about the time between the "start" of Construct 3's development and how that took a fair amount of time and caused a quietening for C2 updates whilst C3 was being worked on. I'm now presuming that rewriting a completely new runtime would take muchhh much longer than the editor did to develop, not to mention the whole maintaining two codebases now for C2 and C3 (unless C2 gets the axe, I'm not really sure what's going on there right now).

    So... with a growing impatience and curiosity of what's out there to support the type of game I want to produce (busy, fast-paced, action game, for Windows), I've begun to start peeking at other free software in the mean time, I wanted to get an idea of the raw performance from just having 1 thing going on in a game, which I'm unsure if it is the most best way to benchmark things, but I quickly smacked together some stuff just to see and thought I'd share with everyone. I did a test involving 1 sprite that you can move left and right with A and D... Nothing more, nothing less.

    I took a look at GDevelop, that software that looks similar to C2 albeit somewhat clunkier in my opinion, and a look at Godot, which is something I keep seeing mentioned everywhere and it's kind of like the layout editor but with coding (probably not something people are interested in, but I was curious about FPS strictly, even if it meant "learn 2 code heueh")

    Just for the record - I focus on Windows EXE support the most, that's my goal and aim, and also where I've recorded these FPS scores I have below.

    Right so, some points about these statistics, please read!:

    • I record 5 random instances where the FPS seems to essentially "float around", I wouldn't record a random performance drop if it dipped to a sudden 2fps for whatever reason.
    • I don't know the NWJS version I am using, it's sorta sitting there, most likely the most recent version offered from Scirra's website.
    • GDevelop doesn't preview in "HTML5 NWJS", I had to modify the package.json of my installation of NWJS to load the weblink that GDevelop generates, and the preview loads. Therefore, the exact same NWJS installation is used for both C2 and GDevelop.
    • FPS Counters work randomly depending on the software, but FRAPS and Nvidia Shadowplay were both constantly running throughout all of this, and one software may display Nvidia's FPS counter, whilst others display FRAPS.
    • I believe I unlocked my FPS in NWJS for Construct from a forum post somewhere in "Construct 2 General", thank you to who provided that topic! Interestingly, GDevelop has the option to disable VSync directly in the projects settings, and change the maximum FPS, which is something I remember being an issue in the past with C2 changing the max framerate? I don't get it. I haven't experimented at all though.
    • I did not go through the "Export to NWJS" and record results from C2, as I'm under the impression it's exactly the same as previewing except for spritesheeting and obfuscating the code.
    • I don't have any proof of these numbers, each project was quite literally a 64x64 square that you can move left and right (Pseudo code: two events, on "A" pressed, set sprite to sprite.x-1, and one for "D" pressed.), and then viewing the FPS from an external source (Fraps, Nvidia Shadowplay). I'm sure this is easily reproducible!

    Major point to consider: I am in no way experienced with benchmarking. This could all be completely redundant information, could be unfair in some way, do not take this as accurate findings and read replies below (if any) to see potential explainations to what I've posted. I'm posting because if I worry about making mistakes, then I wouldn't post at all and may not highlight any useful information for others.

    My Specs:

    Intel i7-3770 3.40GHz (8 core)

    8GB RAM

    Geforce GTX 760

    Windows 7

    Construct 2 - r243

    GDevelop - ? (couldn't find version number in software)

    Godot - v2.1.3

    Construct 2 - Previewed in NWJS

    NVIDIA COUNTER

    1940

    1927

    1911

    1942

    1932

    GDevelop "HTML5 Project" - Preview in NWJS

    NVIDIA COUNTER

    2158

    2225

    2215

    2182

    2193

    GDevelop "Native" Project - Exported

    FRAPS COUNTER

    2735

    2716

    2690

    2706

    2754

    Godot - Preview

    I don't really know what I'm doing since I've used it for literally 3 hours but I've setup a basic project to move a sprite with a texture left and right with the keyboard, and the FPS was strange when it came to switching between notepad to write the FPS and the preview. Switching to notepad seemed to permanently lower the FPS by a thousand, hmm.

    Godot Engine Preview (seemed to drop FPS whenever I focused on notepad to write stats)

    Floats around 6940.

    Drops to around 5140 when I go to notepad and back.

    My opinion on the results:

    The results aren't shocking, I mean it's pure native scripting with Godot that gives us the 5000+ FPS which is totally expected (Included just in case people were curious about the worth of learning coding/scripting).

    As for Previewing in NWJS with C2 and GDevelop, I was... a little bit surprised, I always saw C2 as the superior software when it came to HTML5 in every aspect, but a roughly 200fps difference was unexpected. I think this is what the Construct runtime rewrite would improve on.

    The GDevelop Native EXE export was more surprising, with GDevelop having around 800fps more than C2 NWJS.

    I guess maybe it's NWJS's fault?

    Perhaps others or maybe myself in the future, could provide stats for Android exports; C2 can export to Android through it's process (that I am not familiar with as of now), GDevelop seems to have this experimental "native" android support where you pick your Android SDK folder and it generates an APK right away I think, and Godot can export native too although I haven't looked into this nearly at all.

    This calls out a point that I'd love if anyone could provide any information on, but I have but I admit I may be very factually wrong since I only know Construct 2 and Scirra well, not so much GDevelop. I ask because I adore Construct and seek maximum performance out of its exporters:

    GDevelop, made by

    (I believe)

    1 guy, has made a Native EXE exporter (And an experimental native Android one) for a very similar product to C2, as well as building the rest of the editor alongside (I read it was made opensource too, not sure if that's relevant or explains where the exporter came from) AND gaining a strong FPS boost for the EXE one. I mean...how? It sounds like it would be astronomical work and would lessen the time for development with everything else in Construct when it's brought up on the Scirra forums in the past. I guess I just don't understand, maybe GDevelop uses some sort of shortcut in making these exports. If so, can't Scirra do the same method? I legitimately wish I had more detail on this.

    Share your own stats and experiments! Would be interesting to see exports from HTML5 from Fusion, Unity, etc. Could be very insightful for us developers.

  • I develop platformer stuff with the multiplayer plugin and in my experience, I have a blast with it.

    Whilst I appreciate the development that Ashley did for the code included in the Multiplayer plugin, I don't use any of the built in sync stuff. I strictly send messages back and forth between players and have tried different experiments in the past to see how different implementations of lag compensation feel. I'm not really well versed with the standards of lag compensation, I understand things like dead-reckoning, but currently don't comprehend systems such as rollback. I feel that I have more control when I don't use built-in "one size fits all" stuff, to allow me to fine tune when I want to send a message about the players state/input/etc.

    Don't trust my decision though, I may have missed out on an even better experience by not using the built-in sync stuff!

    The main bad things I experienced (strictly speaking from my experience) were: my games become CPU bound due to me making my own platformer engines (To give me the freedom to add more complex stuff such as half-pipe slopes/Sonic-esque wall&ceiling running), I mean I optimised my events as best I can but having more than 2 or 3 players can strain the framerate. On top of that, having all the other gameplay elements to interact with (what good is a game if your just running around and jumping with no actions or hazards). I mention this because, oddly enough, disabling the multiplayer events and having the players exist as local players on controllers didn't destroy the framerate as bad, so maybe my online implementation wasn't that great, but certainly felt good for two players! I wonder how it would pan out if someone tried it with the platformer behaviour.

    The other bad thing with my design was pings higher than about 70-80ms, which isn't too great; the game was functional but it didn't feel fair with things such as "Your opponent is 100 pixels behind you but still hit you!" kind of situations. (probably my failed lag compensation events, gimmie a break, I was only experimenting! )

    It sure as hell wasn't perfect, but it was functional, playable with the right ping, and I was happy with it, and I will continue to try to exploit all the potential out of this plugin in the future. Then again, what online games are perfect? Even in tightly designed online games, there's always moments of chaos where something feels unfair or unexpected, but that is usually caused by lag. I guess the solution to this could be to design your game to make sure to lock people into connecting with other players in a similar geographical location, or make your game only online with friends

    (not sure about this due to never looking into this with the Multiplayer plugin yet, considering you need to find a game in the signalling server)

    , then that can solve that problem!

    Networking is a fun concept to me, figuring out how to send data as lightly as possible, the whole ping/lag/latency/packet loss stuff and how/why it happens, it's all so interesting. It's Just as interesting as optimising the heck out of events, it's oddly satisfying to get things working really efficiently. But I could safely say, if I didn't have an interest networking and only knew the fundamentals like what an IP address is and what a server is, then I would most likely not touch Multiplayer in game development (and if I did, I know sure as hell I'd get frustrated fast, even if I had examples and guides laid out in front of me. Conceptualising how online synchronisation works can be incredibly confusing and stressful). I hope some of you guys develop an interest in the area. If you love it, it will feel less stressful to figure out in game development and more like "Ohhh how weird, lets figure out how that works. Ohh I seee, but then how does... woah... Internet u so crazy".

    ...or give me 2147483647 pounds and ill do a third of the events 4 u

  • ...that latest blog post certainly took me by surprise!

    I've been watching the whole Construct 3 announcement from the very beginning, and I remember being so pumped to see the first blog post that gave the first piece of information about C3, which was... insanely underwhelming. Upon reading it, I had a sinking feeling and felt demotivated, and predicted a lot of people aren't going to like this. (Also I was mostly worried about lack of offline support but that got clarified quickly).

    I continued watching, reading each and every blog post, and I didn't really feel affected by what was announced, although I did find some stuff interesting such as putting C3 on mobile, but it didn't make me feel inclined to subscribe to C3.

    Upon the beta release, I checked it out, thought "ah...c2 in a browser..." and thought this is game over for me now; blog posts are done, beta is out, this is it... No new fancy graphics stuff, no performance enhancements, no intricate control over things to lower CPU/GPU/RAM usage, etc.... ok... I figured C2 would eventually get phased out, so may as well move on from this editor that I've grown exceedingly comfortable with.

    Then KAPOW, checked out the forums during lunchtime, saw someone mention a blog post, read the blog post...

    https://www.scirra.com/blog/204/the-future-of-the-construct-3-runtime

    A rewrite of the runtime? Admitting the runtime may have some issues/performance issues due to compatibility code and pressured workload as Scirra was only starting out as a business when writing the runtime (very respectable to include this in your blog post)?Mentioning optimisation and lowering memory usage, etc? Hot damn. This is definitely worth the money from me now, even if I'm only a hobbyist. This feels like a professional route to take, offering optimisation and capabilities that were only possible for Scirra to implement and users were unable to do. (I hope I haven't misinterpreted the blog post at all, correct me if I'm wrong at all! )

    I don't post much at all and haven't shown evidence for this, but in my experience, I'm definitely bounded by CPU issues and I'm strictly developing for Windows. Having multiple particles, or lots of platformer enemies onscreen, it racks up fast. Perhaps over the years, I should have been more vocal about my CPU issues, but this blog post signifies that this issue can change, at least improve substantially. Games could be able to be big and grand.

    Ashley , If this is the route you are taking, I'd love for you to take this opportunity before you begin getting too deep into developing the runtime, to ask the forum/paid users/professional users/random homeless person from London/forum section for subscribers, for their opinions/ideas that they feel would aid them in creating a large or 'busy' game (Busy, as in, lots of stuff going on onscreen). I have a handful of suggestions I'm eager to share, probably stuff that has been mentioned in the past, but I don't want this post to be another bombardment of seemingly random suggestions. Perhaps peoples suggestions would be unfeasible, or impossible within HTML5, or perhaps it will enlighten you on what people have discovered when making a large/busy game, but I felt if I had certain things in Construct, I could go above and beyond in development with your software.

    I feel much more willing to subscribe and support the company, almost certain about the 1st year, even though this is only a blog post that isn't promising anything, but it does come across as eager and passionate; like saying "No" to Canvas2D and pushing WebGL to be the standard, to be able to provide much more graphical stuff for us. I hope I remain in this mindset on the official release!

    You guys seriously done this whole process backwards! Start with this blog post, then tell us the other features, end with the browser-based + subscription blog post. I would have had a consistent stream of excitement if so and would have only queried offline support right at the end!

    p.s. the multiplayer plugin is awesome, I used it a lot and will continue to use it when I get back in the grind of development.

    NotionGames

    Yeah... Some things have workarounds, like using VM's or WINE to run Construct 2 in Mac/Linux, but certain things don't have a workaround, such as this WiiU Export issue. You hit a dead end and there's no solution or workaround. Makes me wonder why time and resources were focused on doing things browser-based for Mac/Linux support when there was already a workaround for doing that, when there's loyal serious developers that would throw all their money at Scirra raising the concern that their export runs poorly and is hindering them. (Correct me if I'm wrong, as i have not used Mac/Linux, just going from memory here.)

    Perhaps spending years to have C3 be browser-based may not be strictly for multiple operating system support; I believe there are things such the new Array editor that may not have been able to be developed in C2's environment... but couldn't that have had a workaround? Have a tiny EXE that is a small lil array editor within C2's directory that you can run from C2 by clicking the "Array editor" button or something, which then hooks onto C2? I don't know the logistics of software development that well, I could be completely wrong here.

    On a more personal level, NotionGames, it's commendable that you are here voicing your concerns, especially in your position (Anyone else reading this that have been vocalising their opinions lightly or strongly, it's great! It's great to get everyone's opinion and learn what everyone is here for, even the frequent opinion of "can we have native exports".). I have mostly taken the back seat and observed, I've stopped developing in C2 due to a fear of a random unexpected direction that Scirra may/may not take, heck I've stopped developing completely and it sucks, although I'm only a hobbyist. But your thread has taken off, seeing it suddenly appear on the forum with so many pages really shows you have made an impact and created a lot of discussion, hence why I've crawled out from under the shadows once again to comment. Perhaps the sudden surge of discussion is due to your position, or it's the way you've written your posts, but either way, keep on keeping on, you speak for more people than you may realise.

    Such a shame to see all this chaos on the forums nowadays. I've lurked the forums every single day for years now (Not often logging in or posting), and it went from being generally quiet with a few odd users now and then, to frequent heated discussions/arguments amongst long-time users. I see people convert from being very supportive, then a blog post or the beta is released, and they switch, etc.

    In my opinion, to see that Construct 3 was quite literally an editor change is a shame, although it was told to us for a long time, but this thread shows why remaking the editor may have not been the best thing to spend years on. (tho it is impressive technologically!) It's not a terrible thing to have done, it's great for Mac and Linux users, and heck I'd love to be able to switch to Linux before Windows 7 is no longer supported and I bet a fair amount of people share that thought, but this is what we were waiting all this time for? Other things could have been focused on that seem to be highlighted frequently on the forums... Iuno...

    It could all change though, right? I mean, once the majority of editor bugs are gone, what would be the next thing for Scirra to develop in Construct 3, especially after the uproar on the forums? There are genuine concerns being raised and they can't seriously be ignored or shutdown with a statement about technology, HTML5, 3rd party issues, etc. I think a solid road map would be brilliant, to know exactly what direction Construct 3 will go, and for us to make the decision if we want to be part of that journey.

    Bleh, I wish Construct 3 was discussed publicly much much earlier, even if it was just a tiny bit.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Try setting the "Active at start" property of "Sine" to "No".

    And in your events, do this event:

    +On fade-in finished

    -Set Active (Sine)" Yes.

    Oh, and when the fade-out time comes; however you have programmed it to fade-out, just throw in another action to turn the Sine off.

    Let me know if this works!

  • MadSpy oh whoops, thanks! I only skimmed the Bugs and Closed Bugs section briefly hah

  • Problem Description

    Open Capx, notice there's two layers with one layer having a sprite on it. Delete that layer (Layer 1), then save. Then create a new layer, then save. You will get a Construct 2 Error message.

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

    Construct 2 Check failure

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

    Check failure! This is probably a bug:

    Layers indexed incorrectly

    Condition: (*l)->GetIndex() == expected_index

    File: Projects\Layout.cpp

    Line: 1547

    Function: void __cdecl Layout::VerifyLooksOK(void) const

    Build: release 230 (64-bit) checked

    Component: Construct 2 IDE

    (Last Win32 error: 0)

    You are using a 'checked' release of Construct 2, intended for testing, which causes certain errors to be reported this way. Hit Ctrl+C to copy this messagebox - it's useful information for the developers, so please include it with any bug reports! Click 'Abort' to quit (unsaved data will be lost!),'Retry' to turn off messages for this session and continue, or 'Ignore' to continue normally.

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

    Abort Retry Ignore

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

    Attach a Capx

    https://dl.dropboxusercontent.com/u/776 ... layer.capx

    Description of Capx

    Has two layers, with "Layer 1" with a sprite on it.

    Steps to Reproduce Bug

    • Open Capx, notice there's two layers with one layer having a sprite on it.
    • Delete Layer 1.
    • Save.
    • Create a new layer, no need to do anything else, just create new layer.
    • Save. You will get a the above error message.

    Observed Result

    Crash!

    Expected Result

    Not to crash!

    Affected Browsers

      N/A

    Operating System and Service Pack

    Windows 7 64-bit

    Construct 2 Version ID

    R230

  • Just to ask, regarding all of your curved tiles:

    Do you use a collision polygon with multiple points?

    How many points are on a curve usually?

    Roughly how many tiles are in the level that have these curved tiles?

  • Yeah just to chime in, I also get this. Sometimes it eats up my RAM to a point that windows gets angry and starts giving me a message to close things before the RAM is filled up. Can be about 10-20 NW.JS instances in task manager.

  • Ashley

    Perfect! Working in the beta2. Thank you, much appreciated!

  • I can really understand your frustration, it's hard to get a point across when you are standing on your own, as nobody else really cares about filesize on NW.JS. It sort of seems as though you may need to give a reason why you think that information should be provided, I mean I'm sure there's certain cases, maybe someone might want to distribute to an area where they have extremely limited bandwidth or something extreme and specific. Although it might be a bad idea to explain your own personal reason because it might become a backwards and forwards conversation with people that go "Well why not do this instead?" "No I can't do that" "Well what about this?", even if you know 100% that filesize matters in your situation. Maybe it's a tricky thing for Scirra to decide what information to put out because they will always miss something, maybe in the future a similar situation is going to occur where someone buys the software and realises something specific about one of the full versions features (can't think of a random example but I hope I make sense).

    Although one things for sure, it'd help a lot to have the free version give a limited export option. At least you can then retrieve all the information you want, knowing that when you buy the full version, the watermark goes and time limits go and everything is exactly as you'd expect.