Ashley's Forum Posts

  • Huh... weird, that was definitely added to the code, but it didn't seem to get included in the 0.99 release for some reason. Should be in the next build.

  • It's just a handy helper function to do the math Mipey posted for you, so in the case of moving 50 pixels right or moving 50 pixels at angle 0, they're identical.

  • Persist files don't just save the state of the UI, they save which layouts/event sheets you had open when you last used the .cap. If you turn them off, .caps will only ever load the layout editor for the first layout, which can be annoying.

  • Can we animate mesh object points?

    Yes but only by always setting the mesh points manually by events.

    How do collisions work with Z-ordering? Do they only collide if on the same Z, or do they always collide while on the same layer?

    They collide as if they were at Z=0. There is no 3D collision.

  • It doesn't take long to add an include to the event sheets you need it for, plus you don't need to have the added complications of those events running on unintentional layouts (you don't need your main game code running on the menu!).

  • Then why don't make a function on sprite meshes that "rasterize" the mesh and transform it directly in a sprite? That would be easy and simple.

    There are technical reasons why this is a bad idea, essentially that's a massive hack. It would consume additional VRAM, and involve slow transmissions from GPU to CPU over an already bottlenecked bridge. People would complain that it's slow, and there are further technical issues relating to bounding box complications making it not a simple implementation even for that hack.

  • You can kick and scream all you like, but it's probably not going to happen: firstly, sprites and mesh distortion are made of textured polygons, therefore there is already a way to display textured polygons as you wish. Further, the collisions algorithm would be, as I said, a tricky and time-consuming thing to program. Of course it's possible, but the collisions engine is a highly optimized and low-level MMX based bitmask generator and tester, and would be difficult to adapt. In the same time it would take to do that, we could've done several things useful to 10x as many users. Therefore, it just doesn't make sense to implement it right now.

  • How do you mean?

  • gammabeam: those are both known bugs, the former is fixed in the next build.

    konjak: try it. It should do that

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You can also do this if you set the colour filter to black (so you get a black silhouette), then use the Invert shader.

  • Looks like you can pretty much do that with sprites, they're made out of two polygons anyway...

  • You can now reply to topics in this forum to comment on announcements. Only admins can start new topics though.

  • Construct 0.99 (unstable) released

    We finally made the 0.99 testing release - and as expected there were some serious problems with it, since a huge amount of code was changed for this build. So we'll follow up with 0.99.2 with a lot of fixes in a couple of days, which should be a stable build. If you haven't read about it yet, 0.99 introduces new 3D features (3D mesh distortion, a mesh editor, and Z elevation for sprites), new project bar organisation, and controls to manage the usage of VRAM in your application.

    The road to 1.0

    The next major build release of Construct will be 1.0. We have now implemented all the features we want for 1.0, and until then, we will focus solely on bug fixes. There are around 150 open items on the tracker, and through the 0.99 minor releases (.2, .3, .4...) we will aim to get these as close to 0 as possible. Once we're satisfied with the bug fixes, we'll release version 1.0!

    Beyond 1.0

    After 1.0, we will continue to maintain the 1.0 branch with bug fixes and minor features, but we will change focus to start work on our next project: Construct 2.

    As you probably know we're all volunteer student developers, and we've essentially learnt how to program properly in developing Construct, a huge and ambitious project which has been, overall, a success. However, in our relative inexperience when starting the project a couple of years ago, we made some poor design decisions, such as how to lay out the overall structure of the code behind Construct, and the technologies we used. As a result, we've ended up with some difficulties in maintaining code these days, and given our much increased knowledge of programming from our experience developing 1.0, we think we can do a lot better. Further, new technologies have since become available - like the MFC Fluent UI system - which would be a big step forwards for the editor usability.

    So the plan is to rewrite Construct 2 from the ground up. This isn't as epic a job as 1.0 has been: parts of Construct as it is right now, are very well written, like the new renderer and project bar. We can just lift those directly to the new codebase and reuse them with very few changes. That also eliminates the many hours of debugging and testing that has gone in to those areas. Also, given our experience with 1.0, we should be able to write code faster with less time spent on debugging and back-and-forth changes. This also makes it possible to involve a whole set of new technologies, such as an OpenGL renderer, unicode, ports to other platforms, cross-compiler SDK, XML/folder-based projects, even more 3D features, and so on.

    The last thing we'd want to do is shoot ourselves in the foot long-term by trying to coax the current codebase in to doing things it was never designed to do, and that seems to be common in the software world. Short-term, we will probably fall behind our competitors as we work on it, but long-term, we'd come out with something truly kickass And it always pays to think in the long term. The downside, though, is with such a complete rethink, it's unlikely .caps from 1.0 will be able to be ported in to Construct 2. Importing the old .caps would mean making 2.0 100% backwards compatible, including the dubious design considerations, and impede progress considerably. I know this will frustrate some people, but we're not dropping the 1.0 branch - we will continue to maintain it. Plus, it's necessary, for a clean, fresh start.

    If we do it right, we won't ever have to have another rewrite after 2.0. Everything will be upgradable from there in to the future. And the future is what we want to be thinking about

  • Actually I've noticed on my video card render-target surfaces can be non-power-of-two (ie. 1280x1024 instead of being promoted to 2048x2048), but I'm not sure if all cards can do that. It's still 5mb of VRAM for a 1280x1024 surface, though, and if you're using all possible effects, transitions, etc then the runtime may well need to create four or five temporary surfaces. It has to be done that way - you just have to live with it.

  • No, the control press conditions are triggers within the Mouse & Keyboard object... why do you need to trigger them manually? What are you trying to achieve?