large levels peformance

0 favourites
From the Asset Store
LevelsManager is a Construct 2 & 3 plugin to manage your worlds and levels easily
  • Thanks for all the replies.

    As much as I don't want to, I think I will have to try GMs

    If I can't achieve what I want to do then I could ty learning torque 2D since its now open source.

    And ultimately unity now has native 2D capabilities, and learning unity sounds like the most sustainable option.

    I love construct 2 but its early days in my opinion

  • Very interesting observations about groups. I had no idea they impacted performance, as I use them only for organisational purposes, not for switching events on and off. Certainly something to be aware of.

    jayderyu, so are you saying that if C2 had been designed to be more objected orientated, with event sheets being attached to objects rather than scene level, then it would potentially have much better performance? Would be a nice option to have it both ways, but I guess that would require a complete architectural change. One of the things that is cool about Godot is that you can attach scripts at the scene level or the object level, which gives you a lot of creative options. GMS can certainly get confusing at times, when you come back to an old project and wonder where the hell you attached your code!

    Would have been interesting if C2 had gone down the Haxe/OpenCL path, but if the compile time is anything like Stencyl 3 then maybe not the best idea.

    I still think Scirra should hire an extra dev to just do native exports (most people just want Android/IOS/Windows in addition to html5) and then charge $100 for each exporter. It would solve a lot of problems.

    serpent ....If you want to go down the open source path, I would steer clear of Torque. Try the new Godot Engine, or even Enigma, which is a GMS clone. Or the free GameDevelop, which is very C2-like, but not as good.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • zendorf - perhaps you missed the posts above where it was discovered that groups actually have almost no performance impact at all - it's only while debugging that it uses a lot of CPU time.

  • zendorf - perhaps you missed the posts above where it was discovered that groups actually have almost no performance impact at all - it's only while debugging that it uses a lot of CPU time.

    Good to know, I was worried then since I like to group stuff. hehe

  • jayderyu - I don't understand your point about event sheets. If you put an event sheet in an object, how does that actually change anything? If it does not check the events every game loop, it's not remotely useful, because none of the events will work. If it does check the events every game loop, it's no different performance-wise to just having those events in a main event sheet anyway. Performance is just hard, period, and learning techniques to best optimise events can take time.

    With WebGL I am sure the engine will perform at around the same level as native engines. (Asm.js should do the same for heavily physics-based games.) The main problem with WebGL support is driver blacklists and reverting to software rendering, but that should recede over time - and it can actually be useful, since it works around severely broken drivers that would otherwise make the game unplayable. There are lots of other browser improvements in the works, like Chrome for Android gradually replacing the crappy stock Android browser, also getting asynchronous Javascript compilation, better garbage collection in Firefox, and so on. We also keep making performance improvements to the engine, such as with collision cells and segmented tilemaps to support extremely large levels like the OP describes.

    BTW the performance of groups in the debugger makes sense - the profiler will make extra calls to measure the CPU time of every group, which adds overhead that isn't there in normal preview or export mode.

  • if the event sheets would be in a object, you could just use the events when the object is realy used or on screen. What i mean is, you still have to check every game loop if the object is there but only have to check on the events if object is realy there. Should increase performance a little bit. Or im completely wrong?

  • You can do that already.

    If sprite.count>0

    • do stuff
  • sorry, but i dont get this, how do i set this up? i dont see something like count anywhere

  • New event>system>compare values, enter sprite.count.

  • ah ok, thank you very much! i totally missed this, comes very helpfull for a problem that i had for some time now, i used a variable to check if a object is there, but never liked this workaround.

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