Ashley's Forum Posts

  • You could load JPEGs from external files.

  • It's not possible to control VRAM how you describe. The runtime has no idea which textures you're going to need shortly. It can only guess, and when it gets it wrong, the game will become noticably choppy as it transfers textures to the GPU (it's a slow process). And if there are X megabytes of textures to show on-screen, you need X megabytes of VRAM, regardless of whatever limit you want.

    I haven't fully designed how the system will work yet, I'm still working on it, since it's important to get something which is useful and will work well before I start coding. But it'll probably take the form of:

    • Layout settings (load and free the layout's textures on an application or layout lifetime)
    • System actions (dump all VRAM, dump currently unused VRAM. or cache certain objects for customisation)
    • Object settings (load and free object textures in the layout or object lifetime) although this is not as effective a way to do it

    If you have any other suggestions how it could be configured I'm listening (now's the time to get your ideas in), however, in short, the user will have to decide how to load and unload VRAM. The runtime can't second guess what your game is going to do, nor can it magically lower the minimum requirements to less than what they really are.

  • Construct doesn't care what format you import your graphics as. It saves them as 32 bit PNG with alpha channel. You won't get a smaller filesize by compressing beforehand unless you make it more compressable by PNG (for example, by reducing colour depth).

    JPEG has no alpha channels so is not a particularly useful format for most games.

    40 frames of 480x480 textures will use about 41mb of VRAM. Due to other overheads, this might be too high even for 64mb cards. So now due to one single explosion sprite your game requires a graphics card with 128mb VRAM. That's not the way to do it: DirectX games are rarely based around imported video, even 3D commercial titles are more economical with memory than this. Compose your explosions out of a number of smaller, single frame sprites, dynamically stretch and resize them, and throw in a few particle effects. The system requirements will drop massively, it will look smoother, will look better with timescaling, and hey, it might even look better!

  • I think this counts as a bug, submit it to the tracker.

  • You'd actually get much better performance with an array object even if it used a lot of memory, because it's immediately available to the CPU.

  • It's doable, but it would be extremely slow. The textures holding the colour and opacity data are on the graphics card. The event engine, which runs expressions and events, runs on the CPU. In order to retrieve a pixel, you'd have to stall the GPU rendering (because it works in parallel), and transfer a pixel from the GPU to CPU over a high latency bridge already bottlenecked with rendering commands. Basically, although it's possible, the system is not at all designed for it. I think there are much better ways to achieve it than relying on pixel data on textures. The expression you want would totally strangle performance and I bet we'd get lots of people complaining that it's slow.

  • XAPOFX1_1.dll is an XAudio2 DLL. It's installed by the latest DirectX update which he should have been prompted to do when running your game. Did he not see that message? Why did they not update DirectX instead of you sending them DLL files?

    The 8 direction movement thing might be a configuration thing, I'll have a look.

  • LOL!

  • I prefer the pronunciation "goblins".

  • It's working fine in that .cap as far as I can see.

  • Releases

    February saw us release 0.98.8, which was a large build. However, there were a few initial problems, and since releases often now have significant changes, we're going to slightly change the way builds are released from now on.

    The first time a build is release it'll be marked "unstable". This means it's not fully tested, and you should back up your projects before using it. If it doesn't work, you can let us know and go back to the last stable build (you can install two versions of Construct on the same computer). When we know there are no serious problems in a build, we'll mark it "stable" and publicise it on the site. We need you guys testing our builds, but we also don't want to interrupt anyone who only wants stable builds for their serious projects!

    Next build: 0.99

    The next build is going to be an important step - it's the last time we're adding core features before we focus on making sure everything works for 1.0. We talked about this in the February update but 0.98.8 had a lot more bugfixes than planned, so it'll hopefully be here by the end of the month. The last features that need to be implemented are:

    • VRAM options. You'll be able to save video memory for objects which aren't currently loaded.
    • Better controls system. It'll support changing controls at runtime, and possibly multiple players.
    • Object organisation, including object folders, to simplify large projects
    • The inventory plugin, and a path behavior.

    After that we're on the home straight to 1.0 - which will be an exciting time!

    Wiki documentation

    We've had some great contributions to the Wiki in the past month, so thank you to all contributors! If you would like to help out, see this thread.

    Community

    We're starting to see some cool games pop up from time to time. Check out the Creations forum for some, including In Another Brothel, which was featured on two sites. Deadeye also recently released part eight of his excellent Platform School tutorial which you should definitely check out if you haven't yet. Also, jessejohhavoc announced a new Construct site, http://www.ConstructCorner.com, announced in this thread - the first unofficial Construct community site!

    That's all for now, catch us on the chat!

  • i see no purpose to having a SC when the C is also an S sound

    Ever said the word "science"?

  • Well, I'm signed up!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Just wanted to say thanks to everyone who's contributed anything to the wiki lately - it's a huge timesaver and it's all looking well written. I'm sure a lot of users benefit massively from it too! Thanks!

  • Yeah, as I said in my last post, we just can't do it. None of us could moderate a forum in a language we don't speak, and I'm not keen on shotgun hiring moderators for it.