Ashley's Forum Posts

  • I think this is a known bug with the image bank cacher. If you only run one instance of Construct at a time, it shouldn't happen - but I'll try come up with a fix soon.

    • Post link icon

    Please post all bugs on the SourceForge Bug Tracker:

    SourceForge Bug Tracker

    You need a registered SourceForge account to post bugs. We know this may be a bit inconvenient if you don't have an account, but we've had problems with being unable to reproduce problems posted anonymously in the past, in which case we need to contact the submitter.

    Bugs posted on the forum or sent by PM to admins may eventually be lost and forgotten - please don't report bugs that way. The tracker is the central place for dealing with bug reports. As usual, try to include with your bug report a .cap file and reproduction steps. Please attach the file to the SourceForge bug, or otherwise email it - upload sites sometimes expire files and not all bugs can be looked at immediately. Finally it is useful (but not required) to leave your contact details so if necessary I can contact you in case I need more information about the bug.

    Thanks!

  • How exactly are you numbering the tanks? For-Each iterates in order of creation, so maybe your first text object is labelled 8 by accident. Or the text objects were created in the wrong order.

  • I've had a quick look and it looks like a bug caused by families. Put it on the bug tracker and I'll take a look when I can.

  • That's interesting about Motion Blur still working... well, I query the graphics card and it says "I can't make floating-point textures". Then you go and make a floating-point texture and it works. Possibly a bug in the drivers? I'm not sure thats my fault.

  • Ah, thats interesting. I didn't imagine it'd come in useful! Personally, I like to stick with groups and toggling events, but your way is alright too!

  • Personally I'd side with using one large layout for something like this, and just scroll to the next place when you move past a boundary - it'll make editing the level a lot easier.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Dev-C++ is no longer maintained so you should find a new compiler anyway. I'm not sure if the SDK builds on anything other than VS - it might do - give it a try!

  • Can I just ask why you put 'Always' in a subevent? It's redundant - the actions may as well be in the parent event.

    Doing this:

    + Event

    ----+ Always

    ----> (actions)

    Is identical to this

    + Event

    -> Actions

    Imagine writing code that said:

    if (event) {
    if (true) { // redundant!
        func();
    }
}[/code:20eoptro]

  • Written a new article which explains the nuts and bolts of how conditions work. Essential reading for any beginner or intermediate users.

    http://69.24.73.172/scirra/wiki/index.php?title=Conditions

    Any thoughts, suggestions, questions, additions etc - let me know!

  • It's still running out of VRAM on 64MB cards, because the picture editor is creating a number of temporary surfaces. I should be able to optimise this - you'll have to wait until a future build, or upgrade your video card, I'm afraid!

  • Some of the For Each loops are redundant. In the group 'Pick tank to scroll to', the condition 'TankID' equal to global('LastPickedTank') already checks every Tank to find the one(s) with matching values, so the For Each has no effect. Also, in the group 'Pick tanks', every single For Each is redundant and can be deleted: remember the way conditions work normally, there is an implicit for-each since it checks if the condition is true for every instance, then applies the actions to all the instances that met the condition. In this case, the events work fine without a for-each!

  • The runtime uses linear filtering and mipmapping so it can scale high-resolution bitmap textures pretty well - there shouldn't be any roughness to slightly zooming a sprite. The problem is DirectX 9, as far as I am aware, has no support for vector graphics. There is no such thing as a bezier curve in DirectX - you have vertices and textures, and that's pretty much it. I can't think of a way of rendering vector graphics that is anywhere as near as efficient as rendering textures. Either you use tonnes of vertices and bottleneck the CPU/GPU bridge, or you render on the CPU and send the result to the GPU, which negates the benefits of hardware acceleration. Do you really want vector rendering that badly? I think textures suffice for most purposes these days...

  • I've had similar reports of issues with that same video card before - it's pretty old, and just doesn't have enough video memory. Some textures can't be paged out to system memory and have to physically exist in VRAM, and if these textures exceed 32mb on a 32mb video card, you run out. The picture editor doesn't have error checking for when VRAM runs out, so it crashes. I think I can reduce VRAM usage by the picture editor though, so I'll try and have something sorted by 1.0.

  • Well I'm actually using a DirectX function to retrieve texture memory - I think some texture memory is mapped to system memory so you have more room for textures... I'm not sure how it works, it's a bit annoying it doesnt have much to do with physical VRAM.