Ashley's Forum Posts

  • How will this new XAudio2 thing affect .mod files? Will they still play normally?

    I don't understand... neither Directsound nor XAudio have had or will have MOD support. Rich wrote a separate MOD plugin, though.

  • Could you send your .cap with instructions on how to reproduce the crash to ?

  • Quick XAudio2 update - I've added more format support for XAudio2; a common problem with Directsound was that it only supported PCM WAVs. XAudio2 will support runtime decoding of ADPCM and xWMA WAVs. xWMA is a lightweight version of WMA specially supported by XAudio2. I'm also planning OGG support, but that will require fully decompressing the files in to memory first, but with today's computer memories, I don't think it's much important. For completeness, I'll throw in a Play MP3 action like Directsound had.

  • Woops, fixed those icons...

    XAudio2 is coming along nicely, and should be implemented in the next 0.98 build, but that might be a while away yet.

  • What's wrong with the screenshot you posted? I don't know what it's meant to look like, so maybe some comparisons?

    You could also try just using unbounded scrolling and setting your own limits manually (eg. ScrollX < 0: scroll to X = 0 etc). That might be a bit easier to set up.

  • What's this about multi-monitor support? you think you'll keep trying to make it work? I use 2 monitors so this would be incredibly cool.

    What sort of thing was it? like layout editor on one screen and events on the other?

    No, for the runtime. If you have multiple monitors you can already take advantage by snapping out the project/layers/animator/resource bars and leave them floating on another screen. You could do the same with the properties bar, but for convenience you probably want to leave it docked.

    Runtime multiple monitor support would theoretically mean you can go to fullscreen mode on both monitors and show different parts of the same layout, eg. map on right monitor, gameplay on left. Or, simpler, just duplicate the same view on both screens so you don't have a garbled desktop on the other one. The documentation for DirectX multiple monitors is so-so though, and after a lot of tweaking, I just couldn't get the existing rendering code to work with multiple monitors.

    By the way, can someone confirm redownloading 0.97.5 fixes the startup errors?

  • Download 0.97.5 again now - it should fix this.

  • OK folks, download it again if you have already and it should fix the 3D box and Template errors. Delete Template.csx from Plugins\ and Plugins\Runtime if you're installing over the old folder, it's an unused and broken plugin.

  • I can't reproduce any of the bugs in 0.97.5...

  • Try deleting sections of your events (after a backup!) and finding what the culprit is. Is it still the for-each events? If so, how many of them are there and what do they look like?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Ah, I think 3D box is relying on the latest D3DX perhaps - if you've been cancelling away the DirectX 9 updater in the installer, try letting it run this time - it should fix 3D box. I'll put up an update which doesn't require this soon, but in the mean time that should fix it.

  • If you resize the window, DirectX has a hard-coded linear-filtered stretch it does. I don't know why they designed it like that but you can't change it as far as I know. I would recommend Deadeye's solution with Unbounded scrolling: zoom in the display 2x with point sampling. With unbounded scrolling you might be able to go running off the side of the screen, so make sure you add your own scroll boundaries (a wall the player can't run past for example).

  • You won't use either of these in a 2D game, so you can continue to use Construct like normal. I'm going to release an update soon that should fix it...

  • This .cap may not act like you want but it is not a bug. The 'Destroy' action simply sets a flag and continues to work exactly like normal. At the end of the event list, objects marked 'destroyed' are then really destroyed. It has to work like this unfortunately - the runtime needs to know that objects exist until one point. It also needs to be like this to give plugins a chance to remove references to the object that is being destroyed - otherwise these plugins would crash and there would be no way to fix it!

  • You can't have multiple instances of the same object in a container - but you could do that if they're all different object types.

    As faggatron said, you should be able to do it with a single for-each: the 'Turret UID = Ship UID' condition has an internal for-each - it will test every turret and pick the ones whose UID is equal to the current Ship's UID. Conditions like this are much faster than using another for-each condition, though (it's optimised C++ code instead of a condition doing the iteration).