Ashley's Forum Posts

  • Hi all,

    Just want to check that the auto-updater's working OK for everyone. I put it in a few builds ago. It only checks for updates once every 24 hours so it might not be instant, but you should get prompts in old builds when a new build is available.

    I did test it myself, but online features can be a bit trickier, so just wanted to check Let me know if you had any problems!

  • cow_trix: what's broken?

    kiyoshi: I think I can reproduce this. Looks like when you delete an object type, actions which reference it in an object parameter disappear from view, but still get saved to the XML (which is wrong!). I'll try to fix it for the next build. Also looking in to the changing layer thing.

  • Well, for C2, MS Paint does suck, because it doesn't support transparency at all, which is a really important feature for game graphics!

  • In C1 there was a nice editor but in C2 the stupid MS Paint comes up.

    C2 is in an early state of development. It is incomplete. The image editor is one of many things that hasn't been coded yet. That, as well as other plugins like tiled background, are things we will get round to soon, but we're not quite there yet.

    BTW C2 launches the system program associated with editing PNG files. Paint.NET is a good alternative, with good transparency support. If you install that, it should launch as the image editor for C2 as well. MS Paint is what comes with Windows, and yes, it sucks!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I would definitely like a transparent background. Is that even possible? Also, is it possible to overlay an html5 game over other webpage elements?

    Yes, you can have a transparent background, I just need to add an option for it. You can overlay the canvas over other web page elements, you just need to set up the web page yourself so the canvas is positioned over something else in the page (just a bit of CSS).

  • It's described on the 0.x wiki, but note the C2 expression is dt (standing for delta-time) rather than the 0.x timedelta.

  • iPads (and mobile devices in general) don't seem to have very fast Javascipt or HTML5 canvases yet. The problem is probably partly that you're running on an iPad.

    Release 32.2 has a real delta-time, where supported, which should help - if you use dt in your movements, it keeps going at the same speed when the framerate struggles, rather than going in to slow-mo.

  • The other thing I'm curious about is this. How much overhead is there for objects?

    There is actually very little overhead for objects - even fully animated sprites. Reducing overhead is something we spent some time specifically working on.

    If you have hundreds of individual tiles, though, the overheads do add up. If you use a Tiled Background instead of grids of sprites, that should be a lot more efficient.

    [quote:167sxy25]What is usually the biggest bottleneck for Construct?

    I'd say most often shaders, because they're really intense on graphics cards (but look very cool!). Apart from that, inappropriate uses of objects like RTS movement's pathfinding can burn CPU cycles. Usually there are workarounds and more efficient ways of doing that though.

  • Events aren't converted to any other language. The runtime is a standalone compiled EXE application, which is optimised and actually very fast. Your events and game data are attached to the EXE as a block of data. The compiled EXE then builds an internal representation of the events in memory, and starts running them.

    It's basically an interpreter for events, but it performs very well - events usually complete quicker than the rendering on the screen, and rendering and events run in parallel together (since the game is rendered with DirectX on the GPU rather than CPU). In other words, your game code has no performance overhead unless the events take longer than the rendering.

    Also, although events are interpreted, all the actions, conditions, expressions, plugins and behaviors are written as compiled C++ plugins. This means code within them is very fast as well - for example, if you do pathfinding with the RTS behavior, that pathfinding code runs as quickly as it would in any other compiled C++ application. The only intepreter overhead is in deciding when to run each of these bits of code.

    That's a very brief overview, if you want any more detail I can provide!

  • OK, edited the OP to 32.2 which fixes the broken input plugins and solid problem. Redownload for fix.

  • Woops, knew I forgot something important. I'll push out a 32.2 later to fix.

  • Download Construct 2 public preview 32.2

    Link to release 31

    This build, with several other changes, introduces the behaviors engine. There is only one working behavior - 8 direction - which is there mainly to prove the engine works. There's plenty to do still, but this should give you something to try out, as well as a few other tweaks, and r31 is due to expire soon anyways

    Edit: updated to 32.2 to fix broken input plugins.

    Changelog

    • [Feature] Early implementation of behaviors. The behaviors dialog is modelled after the instance variables dialog, where behaviors can be added, reordered and deleted. Attributes have been merged in to behaviors (so 'solid' is now a behavior). There is only a primitive version of the 8 direction behavior - there are no behavior actions, conditions and expressions, properties or customisable controls, and 'solids' have no effect yet - it's mostly under-the-hood work to get it to basic functionality.
    • [Add] Can drag-and-drop .capx and .caproj files in to the Construct 2 window to open them.
    • [Add/fix] Can drag-and-drop PNG and BMP files from Windows Explorer in to a layout, and it automatically creates a new Sprite object with that texture. Could be a nice time saver when you have a lot of artwork, especially while there's no picture editor. (Previously this resulted in a check failure.)
    • [Add] 'Add blank sub-event' to right-click menu of events
    • [Add] Project bar and object bar right-click menus have options to edit instance variables and behaviors of object types
    • [Change] New About box
    • [Change] System expression 'dt' (delta time): previously was fixed at 0.016. Now the genuine delta time is measured. This requires a high-resolution timer in the browser. There is conflicting information on the web about this, but from my own tests it appears most modern browsers do have high resolution timing in javascript. If they don't, they might report a delta-time of zero. If so, the runtime will detect this and fall back to a fixed value of dt like before (0.016). Let me know how this works out and if there is any choppy motion using dt in your movement calculations (or in behaviors which always use delta time).
    • [Change] Selecting an object type from the project or object bar shows properties as if all its instances in the project were mass-selected. This is probably much more useful when working in the event sheet editor.
    • [Change] Object names (and behaviors) are now allowed to start with numbers as long as there are non-number characters in its name. In other words, names like "8Direction" or "3DObject" were previously not allowed, but are OK now.
    • [Change] Preview in browser has a centred canvas and dark background.
    • [Fix] Creating an object on a layer by number chooses the nearest layer if it doesn't exist (e.g. creating an object on layer 1 with a single layer, 0-based, now creates the object on layer 0 instead of doing nothing)

  • Oops, sorry, got mixed up

  • Sorry, I guess my other post was a bit critical for someone without much coding experience. It's cool that you're thinking through ideas like this, but there are still a few problems:

    • you can't assume all your players have a ramdisk (or SSD) - the reality is most people have traditional hard drives
    • writing files is probably quite slow, again because it's not designed for latency - complex games might take a framerate hit
    • the overhead of writing files is still large, so although your simple case works, you might find you can't add many players or much more data in transmission before it bottlenecks. It's not so much the maximum data rate as the latency that is the problem (i.e. how long it takes the message to arrive, rather than how much data the message holds).

    I think R0J0 did some python tutorials on how to use sockets? You might be able to search the forum for that. Also, you could try reading up on websockets - that's what modern browser games use for multiplayer.

  • This isn't a good way to design a multiplayer game! You shouldn't use files on disk (you're moving the mechanical drive head when you could be reading directly from memory), and using files or HTTP is the wrong protocol. These systems are designed for one-off transmissions: open connection, transmit data, close connection. You're introducing a huge amount of open-close overhead for every single message. Also, these protocols are designed for file transmission, where latency really isn't a big deal. They are only concerned with eventually getting the data there, rather than working in real-time. There's also no message ordering so you can get your data reordered in transmission and your players start jumping all over the place. The right way really is to open a socket connection and stream data. That solves all these problems, and was designed for such purposes.