Ashley Yep. Every engine I've used uses "Window" instead of "Viewport" here and it never works the first time lol.

Anyway, just to clarify, we can now simply subtract Window Inner from Window Outer to get the border sizes, then add the border sizes to the desired window size?

Jaydon export works fine here. Are yours exceptionally large or anything odd?

r3 is awaiting approval.

-Includes all assets in a separate folder.

-Fixes a bug where previously collected items would reappear in some situations.

I'm currently using an HP Omen. I think they've been reduced to ~$1000 by now.

15.6" IPS panel, 1920x1080, touch-enabled

Intel core i7 4710HQ

Nvidia GTX 860m

256gb PCIe SSD

Pretty damn nice considering the price. I'd prefer a 17" screen though. Also it doesn't have a numpad so that can be troublesome at times.

Without a dedicated GPU...hm...maybe something like the HP Envy, Asus zenbook, Dell Inspiron, or Lenovo thinkpad. There are so many out there..

Problem Description

I use NWjs.WindowWidth - WindowWidth to calculate the width of a window border so I can properly resize a window. Same for height. This has worked fine for all of my projects. However, if I set my project's window size to 1920x1080 or higher (my screen's resolution), this expression returns the wrong numbers.

It looks like the window is automatically resized if the game is launched at a resolution that matches or exceeds the device's screen resolution. This might be part of the problem somehow.

Attach a Capx

https://dl.dropboxusercontent.com/u/105 ... e_Bug.capx

Description of Capx

Calculates the size of the window borders and prints them out to a text object.

Steps to Reproduce Bug

• Preview the layout. Note the border sizes printed to the text object.
• Close the window.
• Set the window size in the project properties your device's screen resolution or higher.
• Preview the layout again. Note the border sizes are not the same as they were, and the window size is not exactly what you set it to.

Observed Result

Border size results are wrong and window is resized.

Expected Result

Border size results should be the same as when you first previewed the layout.

Affected Browsers

• NWjs

Operating System and Service Pack

Windows 10

Construct 2 Version ID

211

jbconstruct82 I made some updates to the store page which broke the original post here. Doesn't look like I can modify it - clicking edit just shows a block of text with no bbcode or anything...oy. Tom is there any way to, like, 'refresh' this auto-generated thread to reflect the latest updates on the store page?

Ashley

I use NWjs.WindowWidth - WindowWidth to calculate the width of the window border so I can properly resize a window. Same for height. This has worked fine for all of my projects. However, my latest project that starts with a window size of 1920x1080 is giving me the wrong numbers; usually I get 16x39 but now I'm getting 123x39. It looks like the window is automatically resized if the game is launched at a resolution that matches or exceeds the screen's resolution, thus screwing up the borders somehow.

I'm not sure if this is a problem with C2, NWjs, or Windows...so I figured I'd post here before submitting a bug report. Thoughts?

You can see for yourself by using the .capx in this forum thread. Just run it and see what the border size text says. Then set the window size in the project properties to 1920x1080 (or your screen's resolution if it's larger) and run the layout again.

DurandalCorp I thought about including a video but didn't know if it was really necessary with such heavy commenting already. I even included references to where some functions are called and executed. If there is no reference then I deemed it easy enough to figure out i.e. "Menu_Select" is obviously called from eMenus, "Room_Load" is obviously from eRoomSystem, all dictionary keys can be found in eSaveData, and so on. It's all organized that way. If you have any specific questions I'll be happy to answer them via the support email or private message.

jojoe The first 2 Metroids and a lot of other metroidvanias only have 4 directional aiming. Seemed more suitable for this kit. Anyway, I'll consider including 8 directional aiming but the code is nearly identical already...you just need to replace "Up, Down" etc. at the end of the animations with numbers (0,1,2,3,4), change the aim variable from a string to an int, and add the additional inputs.

Well the idea is to export the game via NW.js or whatever and post the .exe...not the .capx.

Updated to r2. Fixes a bug where the player engine group is not deactivated when opening the subscreen (small oversight when refactoring), removes left-over door triggers, and fixes up some door trigger placements. Also includes a readme with default controls and extra details.

Yeah it's best to have a good machine for developing and a crappy laptop or something for testing. I am currently developing on an HP Omen laptop (got it for 30% off...retailmenot.com is awesome.)

If you want a desktop you should build your own. It's not as complicated as it seems and will save you a lot of money. I usually get my parts from Newegg and Amazon.

If you insist on buying pre-built, I've heard to avoid those cheapo "gaming" brands like ibuypower and cyberpower or whatever. Check out Digital Storm or Origin.

Hmm...alright I think I'm getting the idea now. Most of the confusion came from the art that I was given. It's about 4x the size it needs to be even for a 1080p game, and not all of it was drawn "to-scale". For example, the source image for the player is almost 1/4th the size of an entire level image. He'll need to be scaled down roughly 70% just to fit! Looks like we need to spend some time scaling all the source images so they are closer to the final product, and minimize in-editor scaling so we can still use object types that don't allow it like tiled backgrounds and 9-patches. Hoorah for batch processing.

Thanks for all the input everyone!