Ashley's Forum Posts

  • I can't reproduce any problem: I opened the 'Physics - basics.capx' file in the example directory, selected 3 of the shields, and set density to 2. It worked fine. I'm on Win7 64-bit too. Can anyone else reproduce?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Oh right I thought you meant the runtime. The edittime is different, it uses the editor's OpenGL renderer through some custom methods that are exposed. It doesn't have many features - only those that are used by all existing plugins. Is there anything you need help with specifically?

  • BTW if you ignore every message or click Retry the project should load OK. You'll need to find an object with a missing image though and replace it.

  • You do not have permission to view this post

  • guicole, what were you hoping to use AJAX for in an Arcade game? We're worried about the security implications of playing an arcade game which can possibly maliciously AJAX in the background.

  • Ah, so is this a trigger calling another trigger? So runtime.trigger() is being called recursively?

    I didn't write it to support that yet, so if that's the problem I can try and correct that...

  • Pre-loading is not necessary at all, it's just to reduce the latency for sound effects. If you don't pre-load it just streams it from the server which is ideal for music. I guess this is why I need to hurry up and write the Audio documentation :) So yeah, just get rid of all the preloads.

  • How come you're still on r70? I tried to improve this in r71, so a report from r70 isn't really very useful...

  • I'd say don't preload anything, except maybe the 1 or 2 most commonly played sound effects (e.g. player's gun firing, first explosion sound). There'll be a little bit of latency on some sound effects on the first play, but it probably won't be very noticable if there's no latency on the preloaded gun/explosion/etc. Then, on all subsequent plays the game is cached so everything will play instantly anyway (making the preloads redundant).

    There was a bug reported that seemed to be the browser choking if too many sounds were preloaded at once, so I really wouldn't try to preload everything.

    So preloads are just really for the first play. I guess you could also preload one or two extra sounds on the start of each level as you progress through the game to keep the latency less noticable.

  • There are two modes for plugins to draw in: Canvas 2D and WebGL.

    Canvas 2D is just the ordinary HTML5 canvas with a 2D context.

    WebGL is too difficult to use at a low level so it's wrapped with a C2-specific class called 'GLWrap' - you can see its methods in glwrap.js in the install directory.

    TBH your best bet is to find a similar plugin (e.g. Tiled Background or Sprite) and see how they implement their drawing, and base your plugin off that.

  • There's also a link on the start page in the editor itself. 'Free bundle download' under 'Useful links'.

  • Sounds like this bug - the minifier breaks physics.

    I made a post to Google about it, their Closure Compiler is used for minification and seems to break Box2D. It might take a while to fix, but I'm slowly working on it. In the mean time disabling the minifier is the workaround.

  • Mipey, that post reads like a load of nonsense to me. Node.js is non-blocking for I/O. That guy rants about how it blocks for the CPU (obviously it has to). The CPU is not I/O, so they're arguing about something different to what Node.js is for :P They also complain that you have to use javascript, which is also another big advantage, since you can share code between the browser and server...

  • Input problems are a minor problem that can be relatively straightforwardly solved. That's not an argument for an EXE exporter! By default Construct 2 blocks the key press actions in the browser if there are keyboard events for it. So if you want to prevent scrolling add some empty 'on arrow key pressed' and 'on spacebar pressed'. That fixes the keyboard scrolling issue - we've automatically done that on the arcade which is why it doesn't scroll. Also, for accidental selections, the canvas uses the onselectstart="return false;" attribute, which prevents you being able to accidentally select the canvas. If you accidentally select other things on the page, you can easily prevent this by adding that attribute to the other elements. You can even add it to the body tag which prevents anything in the entire page being selected (but that might be annoying for the user). Alternatively fullscreen-in-browser games never have these problems.

    So input isn't because HTML5 sucks nor is it impossible to fix and therefore we must have an EXE exporter; it's just a difference in the technology and if you know how to use it you can get it working exactly like you want.

    Of course an EXE exporter won't come soon! I've been trying to convey just how busy we are - at times we've both been working 14 hour days for long stretches of time. I think you don't really understand how insane it would be for us to try and take on another huge project like the EXE exporter right now. It has to be pushed back out of pure practicality.

    The editor is an EXE for a number of reasons, the main one being: the editor is literally orders of magnitude more complex than a game and that makes it much more painful to make in HTML5. If you're seeing pain points in HTML5, imagine those times ten for an editor in a browser. We think it's an interesting idea but HTML5 really isn't ready for that yet - but it's ready for games which are in comparison a lot simpler. Then there's other points like licensing, the tools we're familiar with, etc.

    This thread is 9 pages long and still nobody's persuaded me anything that an EXE does better other than slightly better performance. HTML5 introduces some features that are very different to the "usual" web that most people are familiar with. The people designing HTML5 are deliberately designing it to be able to mimic native apps but in a browser. There are some quirks and differences (like the scrolling issue) but they are all solvable, or will be solved, since the tech is still being actively developed. An EXE exporter would be useful for high-performance demanding games, but there really is nothing else it does better for games! I know it takes getting some used to because it's a radical idea, but I really think it's true. HTML5 is better for you too, because way more people can and will play your game.

  • FireLight, I think you read too much in to my post. I didn't have too much frustration with developing the Classic runtime - I think we actually did a really good job. I think I'm actually more aware than most of what EXEs do well and badly against HTML5. HTML5 wins easily though. I disagree with all your additional EXE advantages you put as well:

    1) HTML5 only needs time to replace Flash, and it will. So supporting Flash is supporting a sinking ship. Also, a URL is a better shortcut to a game than anything else!

    2) If a user won't download a 10mb HTML5 game, I doubt they'll download a 10mb EXE either. And if you don't have hosting for a HTML5 game, where will you host your EXE?

    3) You're wrong, HTML5 games work fine without WebGL - they just fall back to the slightly slower Canvas 2D renderer. So WebGL is nice to have but not strictly necessary. Also, Microsoft just added identical features to WebGL in Silverlight 5, so I think they were just making up those security scares to give WebGL a bad name... total propaganda.

    4) Construct 2 obfuscates games by default on export.

    5) You can also make apps in Construct 2 - we just haven't got all the features Classic has, for the same reason as before. HTML5 is also still in development itself, and it is being designed to get better at system tasks too. For example, there's a whole file system API in the works for HTML5, and it's all done more securely than EXEs.

    And of course we don't have time right now anyway :)

    Maybe it's my turn to read too much in to your post, but you seem to think running a game in a browser is a disadvantage. I think it's an advantage. It makes it way easier to get to the game. The more hurdles you put in the way of the user and the game, the fewer people will play it - you'll lose players at every hurdle. Compare:

    HTML5 game: visit webpage -> now playing game

    EXE game: visit webpage -> manually download EXE -> manually launch EXE -> browser security prompt -> operating system security prompt -> won't run if not on supported OS -> now playing game

    For this reason I think it is better to have apps run in the browser than as downloads. I think it's old fashioned to have to go and download a separate app and run it for a specific OS. Games and apps of the future will run in a browser, and that's a good thing - they'll be accessible to far more people, and a lot more people will actually bother to run them. I think the technology makes EXEs almost completely redundant, except where extreme performance is necessary, which is still the only advantage I'm persuaded of for EXE games.