chaosmaster's Forum Posts

  • I was messing around with XAudio2 and the 360 controller, trying to scale the controller's rumble to the volume of a positioned sound, when I realised there's no way to get the current volume of a channel with the XAudio2 object. I guess there's only limited uses for it, but it would be useful if you could test the current volume of a sound. That way, you could change the visuals on-screen according to your proximity to a sound, might be a cool effect for 'atmosphere' games. I was just going for 'the closer you are to an explosion, the more rumbling the controller does.'

    • Tom

  • This example should give an idea of what I'm trying to achieve:

    http://www.mediafire.com/file/qamdwzzi2vm/SoundTest.rar

    Basically, I'm trying to do directional sound with multiple levels, with certain parts of the sound only becoming audible when you are close to the emitting object, and the sound fading out completely the further away you are.

    I initially tried using the positional sound built in to the XAudio2 object, but this didn't seem to work correctly. The actual volume of the sound didn't decrease over a distance, rather, the sound just seemed to 'intensify' the nearer the player object got. Also, there doesn't seem to be any function in the XAudio2 object to set the range of the sound; to set the distance limit at which a sound is audible, which would be necessary for the type of layered sound I am trying to achieve.

    I set up events to change the volume of the sound manually, based on distance from the object, but using this method the sound seems to become distorted. The channels 'pop' every time the volume is changed, which makes the sound crackle as you move nearer. Also, the sound sounds crackly and slightly distorted when played at full volume (when the player is directly on top of the emitter).

    Is there any way to achieve the effect I'm going for in Construct at the moment? Am I simply missing a trick with the XAudio2 object?

    Many thanks,

    • Tom

  • Yeah, selectable resolutions would be simple enough to add in, but with this method you always get the best resolution for your monitor. Also it could be adjusted to scale by height instead of width for 4:3 resolutions, and you could switch between fairly easily using variables. Can I aks how you managed to make scrolling work? I've tried simply making the layer with the bars on non-scrolling, but then I can't work out whether you can reposition the layer to the right place or not. I've also tried repositioning the bars with maths, but I can't work out the correct algorithms to place them reliably for every monitor, without cutting off the edges of the screen.

  • Objective

    The objective of the article is to implement a system for dynamic fullscreen scaling, maintaining your game's aspect ratio on all monitors. By default, when using fullscreen mode, Construct will stretch or squish the display to fill the entire screen, which will distort your graphics on a monitor with a different aspect ratio to yours. With this method, the application scales to fill the screen without altering the aspect ratio, and adds black bars to the parts of the display outside of the visible area.

    The example I�ve used is for making games in the HD resolution 1280x720, and supports any monitor resolution between 640x480 and 1920x1080. In this case, black bars will appear on the top and bottom of the screen if you are playing on a monitor with a non 16:9 aspect ratio. You could easily alter it to work with 4:3 as standard, adding horizontal bars on widescreen displays.

    Setting up

    First, you need to work out the maximum size of monitor your game will display on, in this case 1920x1080, and decide the resolution you want to build your game in, 1280x720 here. Make the layout size the maximum resolution, and you then need to �box off� the game resolution space in the middle with black boxes. In the example, the 1280x720 game space is in the middle of the 1920x1080 display, with the rest of the space blacked out. You then need an object placed at the very centre of the screen with the �centre view on me� attribute, to make sure the game always centres the visible layout.

    I�ve set the default resolution to 640x480, to enable it to launch on any monitor. Applications sometimes have trouble starting in a higher resolution and scaling to fit a smaller monitor, so it makes sense to start with the smallest possible resolution. It�s also important to start the application in windowed mode, to allow for resizing before fullscreen mode is activated. Make sure that �Resizing� in �Window Properties� of the application is set to �Show more window content�.

    The events

    You�re going to need to add two objects to the scene, the Window Object and the SysInfo Object, these are vital for scaling.

    <img src="http://img15.imageshack.us/img15/7928/img1tne.png">

    With that done, you can start adding events.

    Step 1: The system object is used to set the application resolution for the resolution of the monitor, using the GetScreenWidth and GetScreenHeight expressions of the SysInfo Object. The Window Object then resizes the app window using the same values.

    <img src="http://img38.imageshack.us/img38/4236/img2r.png">

    Step 2: Now that the screen size matches the monitor resolution, we need to scale the visible layers by the difference between the screen width and the native width of the application. In the example, I�ve used the number 1280 because that�s the width of the visible window. The equation for zooming the layers is 100*(Screen Width / Native Width).

    With that done, you can activate fullscreen mode.

    <img src="http://img18.imageshack.us/img18/3459/img3d.png">

    And that is the essence of it. Download the example here http://www.mediafire.com/file/mjkdue0ee ... caling.cap to see it in action. The example uses a simple loop to ensure that if any more layers are added to the layout, they will scale correctly as well, with no extra events.

    This method is limited in that currently it only works for one-screen-per-layout games. I�m trying different ways of making it work with layer scrolling, but haven�t had any luck so far. Feel free to take the example and modify it to your needs, and if you can find a way to make it work correctly with scrolling, then fantastic, let me know!

    My thanks go to Davioware for introducing me to the Window object, as well as AshyRaccoon for pointing out the SysInfo object and Mipey for coming up with the required scaling coefficient.

    Hope this article�s been useful!

    - Tom

  • I've been having trouble with resolution scaling as well, check out this thread and try the .cap I posted, that should scale to fit the screen while maintaining aspect ratio, and as far as I can tell it works fine with effects as well. Give it a go anyway. I'm working on trying to get it working with scrolling and stuff, which I harder than you'd think it would be.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It is indeed a great game. I love the atomsphere and sense of intrigue it has, even though it's 'just' a fairly simple puzzle game. The presentation is truly top-notch. But DAMN those last few levels were tough...

  • I'm having trouble with positioning the black bars when trying to enable scrolling. My initial solution was to simply put the black bars on a different layer and set the scroll ratio to zero, so the bars don't scroll when the other layers do. Trouble with this is, that screws up the positioning of the bars relative to other layers, and I can't seem to reposition them.

    Is there a way to reposition a layer, without changing the scroll ratio? I've also tried repositioning the bars at runtime using equations, but my math is completely wrong. I made it work fine on my monitor, but trying it on one with an even slightly different ratio and it screws up completely.

    UPDATE: I've kind of got it working by repositioning the bars according to the dimensions of the screen. The trouble is, you can't see objects at the very edges of the screen when you are not playing on a 16:9 monitor using this solution. Have a look anyway:

    http://www.mediafire.com/file/wtlxlznqu ... Scroll.cap

    Also, I'm not sure if there's a way to stop the bars 'jittering' when the character moves, it's as if the 'Always' event isn't repositioning them fast enough.

  • ... I did what?

    You, my friend, wrote this thread:

    I nicked your example of using OriginalHeight'*(DisplayHeight/'DefaultHeight') to zoom the layers to the right amount. Would've taken me a while to work out for myself.

    I'm currently trying to make it work with scrolling. It's...interesting. I might've done it now, needs testing on other monitors first though.

  • I think I've cracked it! I've made an app that displays correctly on all the monitors in my house anyway. Test it out, let me know if it looks right on your monitors:

    http://www.mediafire.com/file/tnmykyzml1y/Scaler.cap

    Basically, it should display in widescreen, 16:9 format, with black bars at the top and bottom if your display is not 16:9. The circle should be round, the square square, and Samus should be pretty much in the middle. There should be corner markers right at each corner of the display.

    It works using the Window Object to resize the display to match the size of your monitor, then zooming the layer using the coefficient [monitor width]/[native app resolution], to scale everything to the new window size. Then it kicks the app into fullscreen mode.

    My thanks go to Davioware for introducing me to the Window object, as well as AshyRaccoon for pointing out the SysInfo object and Mipey for coming up with the required scaling coefficient (it's been a long, long time since I had to do any real maths, it would've taken me a while to work out by myself).

    Let me know if this works for everybody. If it does, I'll make a better example .cap and write up a proper tutorial on how to do it, as this is a useful technique for those looking to make HD games in Construct.

  • Hey, my SF account is chaosmaster2002.

    I'm hoping, once I'm sure it definately works for everyone, to add an article on how to do dynamic fullscreen scaling. Should help a lot for those wanting to make games in high-def but concerned about making them display right on smaller monitors.

  • >

    > Also are the DisplayWidth/Height expressions supposed to return the resolution of the monitor, rather than the game window, because I find it gives me the window size

    >

    >

    I saw your topic, though I am not sure what to do for widescreen-verus-not scaling myself. (I'll read through the rest of this topic..)

    However, after seeing the topic, I did find the Sys Info object (under System, near the bottom). It has SysInfo.GetScreenWidth and SysInfo.GetScreenHeight, giving the actual display's width and height.

    At least I guess it would before you enter fullscreen mode.

    Yes indeed, thank you sir, that's exactly what I needed. I'm getting there now, I think if I was only better at maths, I'd have this sorted by now. Time for much trial and error.

  • The issue of resolution is certainly an issue, and while it seems that you can do it in Construct, exactly what the best way to go about this is seems fairly unclear. I've started another thread in the support forum about this issue (before I found this topic, my bad), and there seems to be a few potential workarounds to it, but no definative solution.

    Also are the DisplayWidth/Height expressions supposed to return the resolution of the monitor, rather than the game window, because I find it gives me the window size, which is the same as using the ScrollXRight or ScrollYBottom expressions. If this is what it is supposed to do, then a new expression that finds the actual width and height of the monitors resolution would certainly make scaling much easier.

    I also like the two factions that seem to have sprung up, regarding high-res/low-res artwork for games. One group advocates the use of tiny windows and retro graphics to enable gameplay for as many people as possible, while the other group wants massive high-definition artwork on mega widescreen displays. I think both styles have their place, and some suit certain types of games better than others. For my current project though, I'm all up for lovely HD graphics at big sexy resolutions. And widescreen support is a must. I HATE it when games are made 4:3 only and look all stretched and crappy on my nice monitor. Support for ALL resolutions is greatly needed!

  • Okay, I've been trying this out for a while, and am still not sure how to go about it, or if it is impossible to do in Construct.

    I'm designing a game at 16:10 widescreen resolution, 1440 x 900. The game runs in full-screen. Obviously, on a 16:10 monitor, it displays on the full screen, and what I'd like to happen is, on dfferent resolutions (16:9, 4:3), for the game to run in 16:10 resolution with black bars at the top and bottom, so none of the objects are stretched. This currently doesn't seem possible to do.

    At the moment, if I try and run an app with a native 16:10 resolution in fullscreen on a non-16:10 monitor, it doesn't even open, citing a DirectX issue. I can make the app in 4:3 resolution, and it will open on widescreen monitors, but the display is stretched. I hate it when games do that

    Does anyone have any idea how I can make this work? Is it achievable with layer zooming, and if so, how, as I've had no luck using this method so far.

    Many thanks,

    • Tom

  • Very nice stuff. Your Metroid pieces capture the feeling of Prime's score perfectly, impressive stuff. If I didn't already have a composer working with me on my newest project, I'd snap you up in a heartbeat. Great work!

  • Certainly, I think lot of it is to do with the designers graphical abilities, or at least the time it takes to produce them. Most indie devs are one or two people with little to no budget, and are unwilling or incapable of creating huge amounts of hi-res artwork for a game. The smaller you make your graphics, the faster you can produce them. Certainly, for some of my projects I've used incredibly tiny screen resolutions in order to build much bigger worlds, with very low-res graphics. Look at Nifflas' games; they're about as small as they can get whilst still being visable, and yet he's used this to create intricate and absorbing worlds and an engaging art style.

    Another problem, certainly in my case, is familiarity. You know where you stand with traditional low-res sprites: 16 x 16 blocks making up rooms, and the user simply scales the game up to their monitor size and it's all fine. With a high-res game though, you lose these restrictions, and then where do you start? Do you make the game at its maximum resolution, then somehow scale it down to fit smaller monitors? Or do you design it to fit the average monitor (1024 x 768 is, I think, still the most widely used resolution) and scale it up, risking the graphics looking blurry on high-res displays. How do you go about making it scale anyway? It's certainly something I'd like to look into. I'd like to do a high-res game, with lovely high-def artwork 'n all, but I wouldn't really know where to start. It is certainly a large technical barrier that may persuade the majority to stick with what they know, low-res retro graphics.