Ashley's Forum Posts

  • Why are you trying to use <body> tags? In HTML a document should only have one body tag, which contains everything in the entire document. You should be using a different tag like <div> anyway.

  • Well, like most web specs it is written by WHATWG or W3C (I forget what the exact relationship between them is), and usually devised by browser makers and interested third parties. The Pointer Events spec was originally written several years ago now. This part of the spec seems to be relevant to how holding mouse buttons work (they call them "chorded button interactions").

    I guess conceptually they consider a mouse a single pointer device and so something that can only go down or up once, similar to how a pen device goes down or up (making and releasing contact with the screen) separately to its button press state. But I don't think it's actually very intuitive for a mouse - as developers you just want an event when each button is pressed. It was annoying for developing Construct too.

  • The blog is from 2013 so parts of it, like the reference to a 256mb VRAM graphics card, is out of date! It's overall point is still relevant though: composition is better than large images.

    You could go a lot further with large images on modern systems, and unified memory systems are more prevalent these days (where there is no separate VRAM and the GPU re-uses system memory, perhaps with an additional dedicated cache). However it still won't scale: no matter how many gigabytes of memory you're willing to use, composition can extend to essentially an unlimited extent, whereas a single drawn image will exhaust memory at a far smaller size, so it imposes tighter limits on the level size. Then there's the fact you have to split everything up in to tiles to work around the maximum texture size (4096x4096 tiles for best compatibility) which is inconvenient. A single tile at 4096x4096 is about 67 MB in memory. If you make a 10x10 grid of them (approx 40k x 40k pixels) you have already used well over 6 GB of memory, so your game will probably already crash on systems with 6GB RAM or less, and that's not including the memory requirement of everything else in your game. With composition you could make a same size level probably well within 500 MB RAM. It would probably render faster too as there'd be less pressure on GPU memory.

    Realistically for broad compatibility I'd avoid going over 1 GB RAM for the background alone, which as you noted limits you to about 4x4 tiles of 4096x4096, or approx 16k x 16k pixels. I suppose that could be enough for some games. So perhaps it is a somewhat more viable option these days within reasonable limits. However I wouldn't be at all surprised if it runs poorly, especially on weaker devices; if it's at all possible to achieve the same by composition, it's far more efficient, both on memory use and runtime performance. It also depends on how willing you are to have demanding system requirements for gamer-style GPUs with loads of dedicated memory, or compatibility with mobile devices and general web browsing.

  • We're responsible for Construct's firing of mousedown events on runtime, so that part could be fixed. File an issue for it and hopefully I can find some time to look in to improving the compatibility with normal mouse events. As for pointer events themselves, that is all web specifications, and the fact secondary mouse buttons only fire pointermove is by design...

  • In general it is not possible to design levels as one huge image, as it wastes too much memory. In practice virtually all games use composition of objects for level design instead. This is described more in the old but still mostly relevant blog post Remember not to waste your memory.

  • You do not have permission to view this post

  • Currently the text and icons are drawn with the same mode as the project.

  • Internally Construct uses pointer events rather than mouse events, and pointer events have a weird quirk where if you hold two mouse buttons, the first button is a pointerdown event, but the second button fires a pointermove event with different buttons. As Construct supports running in a web worker without direct access to input events, it posts pointer events from the DOM to the worker, and synthesises mouse events based on pointer events, but it has the same limitation. So yeah, I guess that's an awkward compatibility difference.

    I can think of two possible solutions to this:

    1. Use pointer events and watch for the button changes in a pointermove event. Construct adds a non-standard lastButtons property which helps identify new mouse button presses. (Using pointer events also makes it possible to support touch input with the same code.)
    2. Turn off worker mode and use the real browser events in the DOM (i.e. document.addEventListener() rather than runtime.addEventListener()).

  • The Share plugin does not open a new web page window, so it won't be covered by the popup blocker. However some browsers have similar rules about some features only being allowed in a user input event like a touch or click. It looks like your project already does that though, so I don't know what else might block it. Perhaps if it's used repeatedly some browsers might block further shares on the assumption it's being mis-used?

  • Press F12 and check the browser console for any error messages.

    Device-specific issues tend to be graphics driver problems, so try also checking for any system software updates or driver updates.

  • Modern graphics hardware cannot efficiently handle "set pixel" type operations. Sending data from the CPU to the GPU is a pretty slow, and normally things like textures are all pre-loaded in advance and re-used across frames so as much as possible remains on the GPU without needing to send much data (other than draw calls). IIRC even video playback is often handled on-GPU so the resulting pixel data is decompressed on the GPU rather than sent to the GPU.

    Probably the most efficient you can achieve is to fill an ImageData in JavaScript and display it in a Drawing Canvas with the loadImagePixelData() method. The example WackyToaster linked to is a good demo of that.

  • You do not have permission to view this post

  • My advice would be: don't use jQuery. Construct used to use it but we removed it years ago. Modern web platform features are now comprehensive and cross-browser compatibility is far better, and so you can just use the platform directly without needing a library to manage it.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You can update bundled addons by right-clicking the project name in the Project Bar, selecting Tools -> View used addons, and right-clicking the bundled addon. If you have a newer version of the same addon installed, there should be an option to update it.

  • Yeah, I got thinking about it and realised the WebGL 1 restrictions weren't too bad and the spritesheeting engine could relatively easily be adapted to do single sheets, so there's an option in the latest beta. However I'd say it's still kind of experimental and there may need to be a few weeks to make sure that no unexpected issues come up.