Moving on from Construct Q

  • Ashley Hmm, I think the alternate exporter Chowdren beat C2 though? Can't remember if someone tested that, or maybe it was just faster than MMF's default exporter in general.

    Bunnymark also isn't a totally fair comparison for speed of an engine, since it's more about the number of sprites / particles it can render depending on the test, while MMF's native code has a big advantage over JavaScript out of the gate that might show up in games needing more CPU (like pixel-perfect platforming).

    You're right that Native alone isn't a good enough reason to switch engine though, it depends on a game's needs (eg: how much it tries to cram in and what platforms it's targeting). Construct's editor is still by far my favorite, even after I've been warming up to Unity in the process of remaking BPM in C# with it.

  • tumira No actually Blender 2.8 Eevee is a fully-featured PBR (physically based-rendering) engine for real-time visualization. Blender 2.8 is supped to be out in 2018 Playing with the beta. https://www.blender.org/2-8/

    Thanks for the upbge link. much appreciated.

    Nice vid buddy

  • If you like framework maybe try this http://kha.tech/

    If you looking for construct 1+2 alternative or clone maybe try http://compilgames.net/

    If you interested with new 3d game engine maybe try http://armory3d.org/index.html

    Its not free though and it is not based on bge (blender game engine) , this is a totally new game engine. I don't even bother to open unity or ue4 anymore because I'm having so much fun with it.

    Still, after all this years with Construct 2, Im still impressed that Ashley still openly allowed discussion with competitor game engines. But I still hate that C3 is a subscription based payment and not one time payment..

    Two VERY nice choices for game development tumira.

    I agree tumira. I am a paid patron of both C1 and C2 and would have bought C3 if they did not go subscription.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • in catapult physics templet how can I move the block according to pig and on touch end spawn another pig too hit again anyone knows please help me.

  • in catapult physics templet how can I move the block according to pig and on touch end spawn another pig too hit again anyone knows please help me.

    thinkGamer

    You have had enough warnings. Maybe a temporary ban will stop this nonsense.

  • I don't use C3. I actually want to get away from web technologies....

    Hey R0J0hound, this is unsettling news, am I reading this correctly?

    you wont be joining us on the C3 Mothership to Zion ?

  • NetOne

    Lol. Probably not. I do enjoy Many aspects of construct 2 though, so I’ll be around to use that I think.

  • > Clickteam MultiMedia Fusion 2.5, it may look like it's still living in the 1990's but it works well (especially the runtime, it's native and runs fast!

    >

    FWIW I saw a Bunnymark benchmark recently that Construct 2 in Chrome outperformed Fusion 2.5's native runtime. Native doesn't mean fast, and HTML5 doesn't mean slow. The C3 runtime will be even faster too.

    Undoubtedly on a brand-new device.

    I don't really want to bring up the story of when I took an old Clickteam Fusion 2.5 game entirely developed without mobile in mind, full of clumsy and un-optimised events and plugins and after removing one or two un-exportable plugins, it worked like lightening on my (old?) 2013 Google tablet.

    When I sent you my mobile app developed entirely for mobile with C2, you said the 2013 tablet was too old and that explained why it ran like a snail. So, Construct may be able to meet or even surpass native, but only on brand-new devices with exceptionally optimised events.

  • I thought that the C2 bunnymark in chrome outperformed Godot Engine (not Fusion 2.5 because it wasn't in the round-up) and the results were that Unity blew all of them away.

    Come to think of it, Pixi.js has by far the best bunnymark results. The c2 bunnymark thread and pixi.js bunnymark. Amazing.

  • Thanks Zebbi, i just sprung for CTF 2.5 Developer and Android exporter.

  • Zebbi - IIRC the device had a buggy GPU and was blacklisted for GPU acceleration. It only affects a few percent of devices in the world these days. It's just bad luck you had one of them really. It's nothing to do with event performance.

    Colludium - IIRC Pixi was using point sprites (same as Particles plugin in Construct) so it wasn't exactly an apples-for-apples comparison. Point sprites can't scale or rotate so aren't really useful for the Sprite plugin.

  • Ashley - I haven't looked too deeply at the pixi library but I reckon you're right.

    It would be good to have a more modular approach to sprite / drawn objects in c2 / c3 (in the new runtime?). I mean, if you're just using sprites for background imagery, for example, then there's no need for the runtime to keep arrays of data on unused components like collision polygons etc. It would be amazing if that horse hasn't left already and this sort of approach could be included in the future (like many more behavior options to add to a basic particle-like sprite). Just a thought and a hope...

  • Zebbi - IIRC the device had a buggy GPU and was blacklisted for GPU acceleration. It only affects a few percent of devices in the world these days. It's just bad luck you had one of them really. It's nothing to do with event performance.

    Colludium - IIRC Pixi was using point sprites (same as Particles plugin in Construct) so it wasn't exactly an apples-for-apples comparison. Point sprites can't scale or rotate so aren't really useful for the Sprite plugin.

    Bad luck for html5, quite clearly not bad luck for a native solution though. I wasn't the only person having issues like this at the time (a year ago) and it was a popular device. Any number of others could have had this exact same problem which wasn't a problem for a native solution (regardless of the reason why).

  • Ashley - I haven't looked too deeply at the pixi library but I reckon you're right.

    It would be good to have a more modular approach to sprite / drawn objects in c2 / c3 (in the new runtime?). I mean, if you're just using sprites for background imagery, for example, then there's no need for the runtime to keep arrays of data on unused components like collision polygons etc. It would be amazing if that horse hasn't left already and this sort of approach could be included in the future (like many more behavior options to add to a basic particle-like sprite). Just a thought and a hope...

    In general I doubt it's worth it. Adding different rendering modes adds a lot of extra complexity and that often causes bugs (e.g. render path A is not pixel-perfect identical to rendering path B). Also as I mentioned in the original thread, in these tests we're really talking about tiny differences on the scale of nanoseconds per sprite, that scale up to bigger results in specific benchmark tests. I rarely see real-world games bottlenecked on this as well, so it looks like a lot of complexity for no real-world benefit other than improving a specific benchmark result. This is one of the limitations of benchmarks: it tempts you in to running down a performance rabbit-hole which just ends up wasting time.

  • +Godot

    Godot 3.0 is now out. Godot has grown a lot since I started and you can find a lot of tutorials for it. Most of the basic 2.0 tutorials will work with little to no modifications.

    A lot of people are afraid of scripting, but after you learn the basic syntax, you will use it before you realize. A little sample camera script.

    extends Camera2D
    
    onready var player = get_node("/root/World/Player")
    
    var resolution = Vector2()
    var bounds = Rect2()
    var room_size = Vector2(3, 1)
    
    func _ready():
    	resolution = settings.resolution
    	bounds = Rect2(Vector2(resolution.x / 2, resolution.y / 2), Vector2(room_size.x * resolution.x - resolution.x / 2, room_size.y * resolution.y - resolution.y / 2))
    	set_process(true)
    
    func _process(delta):
    	var player_pos = player.get_position()
    	var pos = get_position()
    
    	pos.x = clamp(player_pos.x, bounds.position.x, bounds.size.x)
    	pos.y = clamp(player_pos.y, bounds.position.y, bounds.size.y)
    
    	set_position(pos)[/code:3ayz2oiu]
    There is Mono/C# support (still cannot export) and you can link C and C++ code with GDNative, so I think you get all the bunnies you need 
    
    There is also visual scripting now, but I am not familiar with it.
    
    [url]https://godotengine.org/news[/url]
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)