Ashley's Forum Posts

  • Hahaha! Umm... writing a new display engine is a pretty big job, even just the SDL runtime is lots of work. Then OpenGL will be all that work again. Then getting OpenGL to run the effects engine, including restructuring effects in a language OpenGL understands, is a lot of work too. All our effects at the moment are written in HLSL, which is DirectX's shader language (OpenGL uses GLSL).

    But it'd still be funny to see that pic <img src="{SMILIES_PATH}/icon_wink.gif" alt=";)" title="Wink" />

  • Hmm, not yet, someone would have to write a plugin for it. Want me to add it to my todo list? It'd have to wait till after the 1.0 release though, because it's a nontrivial feature request.

    0.89 has an AVI object which might be useful for cutscenes.

  • SDL won't be able to do everything - like pixel shaders, because pixel shaders run entirely in hardware so require a hardware accelerated engine. The SDL runtime acts as a software renderer, which is slower but means your game can run even on computers without DirectX 9, which could be useful for lo-fi games aimed at the casual gaming market.

    And yes, in future we could move on to OpenGL-SDL runtime, which could potentially do everything the DirectX runtime does (including shaders) but work on other platforms <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

  • Fixed in next build - it'll never have a trailing dot.

  • Lol, can't wait? I've uploaded the preliminary 0.9 runtimes including this fix to here. Extract to the Data directory.

    I can't remember if we've changed anything else in particular, they might not work, in which case you'll have to wait!

  • I'm curious too <img src="{SMILIES_PATH}/icon_confused.gif" alt=":?" title="Confused" />

  • Thanks, this is fixed in the next build.

  • Just to reassure some of you, we will still be staying committed to events and script-free coding. If we add a new feature it will be available in both python and events. I intend that it be possible to write entire games either purely in events, or purely in script - or with both, in a way that each complements the other.

  • It won't straight away run on different platforms, we're still going for Windows only for the initial SDL runtime - but it certainly does make it a lot easier to port - DirectX is pretty much tied to Windows <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz" />

  • Can you send the cap to ashley@scirra.com? Thanks.

  • Yeah, we need a new physics mode - fixed framerate. At the moment it is dependent on a high resolution timer timing the exact differences between each frame, which varies every time you run, so it has differences each time. Fixed framerate physics should fix that, I'll try adding for 0.9.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Nice, chains in physics seem to work pretty well <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

  • Woops, that's a cosmetic problem, fixed for 0.89. The action still works like you made it (the image point is "point" and the stiffness is 99), it's just displaying it wrong.

  • Well I can't reproduce the collisions thing, if I add an event testing for collision between Sprite1 and Sprite2, it seems to work fine. Which objects dont seem to work correctly? Is it when using an attribute, or family, or something? Which events specifically "just don't get created"?

  • What happens when you think the game file is corrupted? I think it's rare the actual .cap file gets saved wrong, that code is pretty reliable - you're probably seeing UI bugs or other problems that need to be reported. If you sent a .cap to me that does this, then I may be able to fix it.