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.

Of course! I could even use the built in 'timer' function to continously scroll it. Quite simple, can't believe I didn't think of that. Thanks a lot!

• Tom

Concerning 'Set Image Offset', there doesn't seem to be a way to compare the current offset in the event editor, so I can't make it continuously scroll. Ashley's method works, but there doesn't seem to be any difference in memory usage. I guess this would be the case even in there was an 'infinate scrolling' option. It would still be a nice option to have in the settings though!

Thanks for the help guys!

• Tom

Hey,

One feature it seems Construct is missing right now is the ability to set layers to automatically scroll. I'm developing a scrolling space shooter game, where all the action happens in one still frame, while the background scrolls to give the impression you are flying forwards. There currently seems to be no way to let layers to automatically scroll while the player sprite stays still.

I've got around this by giving backdrops ball movements and using the wrap behaviour, but as I'm loading in large chunks of backdrop for scrolling, this eats up at lot of VRAM. A feature to set layers to automatically scroll would be really useful!

Many thanks, Tom

There seems to be a new bug in the platform behaviour, sometimes it 'jitters' when the object touches the ground. I havn't noticed this before in previous builds.

The 'max' function works nicely, now everything runs smoothly whilst still subtraction to zero. Thanks!

• Tom

Is there a way to force Construct to round up an expression to the nearest whole number, rather than having a decimal number result? I'm moving an object around using loops and timedelta in order to keep things smooth. An example is in the deceleration event:

['Right' key isn't down] [Value 'X Value' is greater than 0]

= [Player: Set 'X Value' to 'Player.Value('X Value')+(Player.Value('Deceleration')*timedelta) This subtracts a set deceleration value from the players X Value, and a loop is then run that moves the player according to the value of 'X Value'. The deceleration event should continue to subtract from 'X Value' until the value reaches 0 and the object comes to a stop. The trouble is, due to using the timedelta expression to maintain a smooth framerate, the deceleration value comes out as a decimal value, and so it sometimes doesnt reach the 0 value, meaning my object keeps moving a tiny amount even after it is supposed to have decelerated to a stop. Basically, is there some sort of expression I can use to force Construct to round up the 'X Value' to a whole number to ensure the value will eventually reach 0 through deceleration? Hope that makes sense, Cheers, Tom