Ashley's Recent Forum Activity

  • Use the IStorage JavaScript API to integrate custom code with the Local Storage object's data.

    The database is only created on demand, so if you delete it, it won't come back until it attempts to write new data.

  • would a possible solution be to restrict this to just being able to trigger Functions in nodes?

    I think that is already possible with 'On tagged node change' in the Flowchart Controller object. Give the node a unique tag, and then that trigger fires when the node is reached, where you can then place any special logic for it. (Correct me if I'm wrong @DiegoM)

  • You can change the classes (and pretty much anything else) in already-loaded HTML with the JavaScript DOM APIs. In this case classList can be used to change an element's classes. For example: 

    const myElem = document.getElementById("myElem");
myElem.classList.remove("oldClass");
myElem.classList.add("newClass");

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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?

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,424,996 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x108
    Coach One of your tutorials has over 1,000 readers
  • x62
    Educator One of your tutorials has over 10,000 readers
  • x3
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x35
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs