Ashley's Forum Posts

  • Remember 0.x was developed by part time inexperienced volunteers, and it still went pretty far just on that. We're proposing to develop C2 fulltime and team members now have industry experience.

    Despite the fact we're confident C2 will be a substantial improvement in both development time and stability over 0.x, if you still have doubts, by all means just wait and see how it develops - although you might miss out on the early adopter licenses, which should be an excellent deal.

  • Hey, that's not bad (although it needs the preview scripts included to work as the preview HTML). Mind if we add something like this to the next build?

  • Sorry, this wasn't ever done for shadow caster - you can try composing a different shape out of several rectangular casters on top of each other, though.

  • I think it's just the DNS changing, not the web host - should keep all the posts in one place.

  • you will have exe's with html5 compatible features only

    Construct 2 is designed to allow different exporters to have different capabilities. We fully intend on making the EXE runtime (when we come to it) as powerful as the 0.x one.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • /if a sprite is already in-between, at, say, 64x40 ... is there any reason to expand it to 64x64? Is that any more efficient?

    No, there's no point doing that - both ways occupy a 64x64 surface in graphics card memory and they draw at the same speed.

    BTW Arima's post is really important for the OP: layers themselves don't use VRAM, only Sprites, and all instances of one object type share the same texture, so you can create more instances of an object without using VRAM either. So to answer the original question, no, many-layered backgrounds are fine, you can easily have loads and have no VRAM overhead.

    Construct does create some of its own textures at runtime for processing effects and such, but there's a limit - I think a maximum of about five, so it's fixed. Nothing like one per layer.

  • If you don't mind the game going slow-motion when the fps drops, you can safely override timedelta with a fixed value. For puzzle games and such, that's fine - it's more a problem for action games, where everything going in slo-mo can give you an unfair advantage since you have more time to react, or the change in game speed would be annoying. That's what timedelta is aimed at solving.

    Generally, though, I tend to say the best thing to do is enable timedelta, but not rely on pixel-perfection. That means don't make platformers with jumps that you can only make by a few pixels, or in your case, puzzles that can only be solved by a pixel-exact trajectory. Those are the things that might be affected by timedelta - and players might be less frustrated by your game if it's more tolerant, anyway

  • This is, as you say, something DirectX is doing, so we can't directly fix it. I think it's because the process priority is lower for windowed games, so it doesn't try quite so hard to sync up exactly. When fullscreen, you get a higher process priority because Windows assumes that's the only thing you're currently doing, and it v-syncs accurately.

    I think the solution is simply that for high quality v-sync you need to be fullscreen.

  • Your version is essentially frozen, in the same way once a major update is released, only that receives bug fixes and the old major version is no longer maintained.

    If there's a really embarrasingly serious problem we would probably backport a fix out of good faith, but it will be taken on a case by case basis, and it's much more likely you'd encounter the bug, report it and then we distribute a fix well within your updgrade period.

  • I think PC gaming has a long way to shrink before it's smaller than the next biggest gaming market after consoles (whatever that is). In other words, PC gaming may be shrinking, but it's still huge.

  • That's interesting, it looks like some browsers have a high resolution timer on their ordinary time expression. I didn't realise they did that! I only tried Firefox 4 though.

    Have you tested this on a range of browsers? I'm not sure if all modern browsers implement this.

  • I've already contacted everyone who donated since the start of the C2 public preview to offer licenses or a refund, because we went closed source after some donations were made. I'm under the impression that, as deadeye said, the donations made toward 0.x were a token of thanks, rather than a kind of purchase. However, if anybody has made a particular significant contribution to 0.x feel free to email me and I may be able to work something out for you.

  • Moved to the C2 preview forum.

  • If Internet Explorer implements WebGL, we can make a WebGL exporter that has the same capabilities as the 0.x runtime. That seems unlikely though.

    I'm not sure we're "obsessed" about HTML5 - we're seriously considering other platforms including an EXE exporter - as a two-man operation we just don't have time to work on any others until HTML5 is done, though!

  • C2 has a dt expression, but it always returns 1/60 (as if it were running at 60fps). There's an fps expression though, that gives you the real framerate, so 1 / fps gives you the "real" dt, but that only updates once a second.

    I was considering adding an "adaptive dt" mode where dt is given the value of 1 / fps, but it might be weird given that it only updates once a second... could get really weird if the framerate changes regularly, as if the timescale was randomly changing...