Ok, thanks for the follow up. I think we found an easier way of doing it in the end, but this will be good for reference in the future.

Here's a screenshot of an upcoming title from us at Pangolin, I think it looks good so far

The girlfriend and I have been working on the visuals for a few months!

Problem Description

Line of sight seems only to take object origin into consideration and not object bounding box. Therefore line of sight checks do not work very well with a narrow scope.

I'm trying to build a laser with a very narrow scope for a schmup and LOS would work great if not for lack of bounding box checks.

If this is the intended behavior, it's somewhat counter-intuitive.

Attach a Capx

Here's the .capx

Description of Capx

The capx has test boxes for which the laser should size according to the wall it has hit, otherwise reach the top of the screen. You can control the player position with arrow keys.

The origin point for these walls is in the bottom right corner of each instance.

Steps to Reproduce Bug

• Use arrow keys to move the laser about
• Notice how the laser only reacts when in line of sight of the origin point (shooting the bottom right corner of any given wall)

Observed Result

The laser shoots through walls even though they are blocking line of sight, unless shooting directly at the origin point.

Expected Result

The walls should block the laser at any point of the wall.

Affected Browsers

ALL

Operating System and Service Pack

Window 8.1 Pro, 64-bit

Construct 2 Version ID

beta r169

BUMP FOR UPDATE

I've updated the first post of the thread, I've made modifications to the utility so that it provides more detailed information and allows for custom game screen resolution!

Let me know if it sucks! I haven't tested it very thoroughly, but it should work on any device.

HTML5 ResUtil 2.0

This is awesome, I don't have a macbook to test this on right away but a breakthrough all the same!

slanw

Sorry for the late reply.

LONG, ARDUOUS ANSWER:

What is best for mobile is also what is best for PC - that is to target all aspect ratios that can appear on any device. 99% of all monitors are one of these 3 aspect ratios - 4:3, 16:9, or 16:10. Keep in mind 16:9 is the defacto standard going forward and monitors are rarely made in 4:3 or 16:10 any more due to the standard set by 1080p (1920x1080 - 16:9).

That said, there are still plenty of 4:3 and 16:10 monitors in the wild, and it's never a smart thing to target one specific aspect ratio.

All normal aspect ratios fall between 4:3 and 16:9, there are a few outliers but for the most part you only need to target 4:3 to 16:9.

What this means is your UI will need to scale to make use of extra space, with the low end limit at 4:3 and the high end limit at 16:9. How you handle that is up to you but requires a different type of fullscreen scaling than the default letterbox (I personally like Scale Outer). I handle most of the issue by spawning elements at certain %s of screen height/width rather than focus on absolute values like X: 100, Y:200. This way when the window size stretches past the layout size it won't break your game.

You can see some of this in action on my current project, working title: Dragonfly Zero. The crucial part of the screen where all the gameplay happens is 3:2, anything outside of the 3:2 aspect ratio is filled with filler art that extends the UI graphics, but not the UI functionality. All crucial functionality must fit within the core 3:2 area.

Click the banner below to launch the Dragonfly Zero main menu scaling demo and stretch your window to any size you want and watch what happens.

The game will start stretching upwards if taller than 3:2 and stretch outwards to the sides if wider than 3:2. You can use the utility from the first post to get a better idea of how this works.

Keep in mind I chose 3:2 in portrait because I'm targeting mobile and 3:2 is a good middle of the road between 4:3 and 16:9. Since you are on PC you should be targeting landscape, and if you are targeting browser with no intentions of fullscreen you may want to offset your aspect ratio range towards 16:9, because the browser address bars and things like the task bar in windows will squish the available height for your game, meaning your game will be making use of an area with a wider aspect ratio, easily passing beyond 16:9 on widescreen monitors, while not dropping down to 4:3. However, this all assumes a fullscreen browser on a 16:9 monitor, when someone could be playing in a scaled down browser window not taking up the entire screen.

I highly suggest using this window resizer plugin for chrome, not only for testing this, but for testing all of your games in the future. It's an invaluable tool.

SHORT ANSWER:

This answer only really applies if you are thinking about making a lower res html game like a flash game you might see on kongregate, which stays at a fixed smaller size that fits fully in the browser window even when the browser isn't fullscreen.

In that case you might aim for a smaller res like 480x320 (3:2), or 480x360 (4:3), where the aspect ratio doesn't matter so much because you aren't making use of the whole screen anyways.

ronval - Glad I could help! I recommend reading these 3 links by Ashley for further information, they can save you a good deal of frustration down the road.

Supporting multiple screen sizes

Remember not to waste your memory

Performance Tips

And one possible explanation without knowing any further information about your game, is that scale outer can and will render your game beyond the layout size whereas letterbox renders your game at layout size. So maybe extra GPU/CPU work relating to that?

Ashley - Good to know! Thanks for the clarification.

ronval - This is my understanding of it, there could be misinformation.

If you use the low quality scaling, it will decrease GPU load and increase overall performance to a comparable level to if you were using all the assets at that lower resolution, even if the assets have extra pixel information in the editor layout. But you will still have the RAM commitments for the original size of those assets.

For example, if your layout is 320x480, you can still have assets in your game that are 512x512, bigger than the layout itself. These assets with higher resolutions see use when using the hi quality full screen scaling, but use the same RAM regardless of render mode.

When you use hi quality scaling, it takes your 320x480 layout and scales it up to fit and render at a resolution of the device. So if you are running it on an iPad it will render at 768x1024 and on a 3GS it still renders at 320x480 because that's the native screen size. So while 512x512 is overkill for an asset on 320x480, that extra pixel information is used when scaled to fullscreen in hi quality.

Since the aspect ratio of the game is the same scaling from 320x480 to 768x1024, what IS changing along with the resolution is the ppi (pixels per inch) or how close together the pixels are. Retina displays have very high DPI displays, meaning that even though the iPhone 5S isn't much larger of a phone than the iPhone 3GS(163ppi), it has a much higher resolution (1136 x 640 pixel (326ppi), higher than the iPad2 (132ppi)!) so a game rendered at 320x480 will look great on 3GS, and pixelated on the iPhone 5S. That said, the 3GS looks more pixelated overall than the iPhone 5S due to lower ppi, because the pixels are larger.

However including higher resolution assets comes at the cost of RAM; each 256x256 square of pixels you have uses 0.25MB of RAM when loaded in the game. Meaning a 512x512 square uses 1MB by itself! This is what vtrix means when you should do both to save texture space, to modify the resolution of the original assets in the game to more closely match the intended resolution (ONLY IF USING LO QUALITY AND NOT GOING BACK) so you could potentially achieve the same effect with a 64x64 px sprite on lo quality as a 512x512 px sprite.

If you run lo quality, your game always renders at 320x480 resolution and then scales those pixels existing at the 320x480 resolution to fit the device's resolution of 768x1024. So you aren't filling each pixel with it's own unique color information, you are kind of stretching one pixel's color into like 9 pixels of information, causing it to look artifacted and pixelated.

I kind of got off a few tangents here, so if anything is unclear let me know and I'll try to explain further.

If anyone has another aspect ratio they are targeting let me know. I was going to include 17:10 and 16:10, but they just fall between 3:2 and 16:9 anyways, so it's a bit redundant.

I'm really glad you guys are finding it useful. If I knew a way to pull the device name into a text object that would be neat.

We could potentially screenshot the utility on our personal devices and post them here for reference, in order to get an exact look at the sizes/working resolutions for a bunch of different devices without having to own them.

ronval

If your game runs ok right now on the iPad 1, then you might be ok - since iPad 1 is an old device. But if your clients want you to have a game that runs really well on old hardware, the smaller resolution is usually the way to go, ESPECIALLY if they want it primarily for phones. If they want it primarily for tablets, you have to weigh the pros and cons of each to fit your situation.

I know I wouldn't want to redo all that work either! :X

I'm glad I was able to help.

The bigger your native game resolution, the bigger the rendering/performance hit!

320x480 is still a 1.33:1 (4:3) ratio, so it will fill the screen the same as your 768x1024 game would (with less pixel density/graphical fidelity), but due to the increased resolution, the draw calls are going to be much more intensive.

That is because 320x480 is 153,600 pixels, and 768x1024 is 786,432 pixels! Over 5 times as many pixels!

Thus, a game designed a 320x480 will run many times faster than the same game at 768x1024 at the cost of graphical fidelity.

I actually just made a utility to help gauge this type of thing.

Here's a link to my resolution utility

What this utility does it show you based on layout size how much your game will scale up or down from it's native, intended resolution to fit the device it is running on.

If you open the portrait version, the layout is actually already set to 768x1024 (4:3 - iPad res) so you can test with the portrait HTML5 link to get an accurate idea of how your game will scale.

matthewhxq Alrighty, landscape utility now available. I've got 3:2 included as a 3rd aspect ratio boundary in both portrait and landscape versions. Let me know how this works for you!