Problem Description

I have recently purchased a Surface Pro 2 and Construct 2 has some glitches on this device, which I suspect may be related to the high-DPI screen and the fact that the OS uses a 150% DPI scaling setting to compensate and make things readable.

-While most of the interface adheres to the OS DPI scaling settings, some parts do not such as the event editor text. I can enlarge it, of course, but then if I go and work on a desktop on the same project, I will have to shrink the text back down again.

-More problematically, the animation editor appears strangely, with the tiled transparent background taking on an odd appearance and all the tool buttons appearing bunched together. In addition, I cannot do anything requiring a right click (such as adding a new animation) using the touch screen or the pen input. While it prepares to make the right click, nothing happens. This is likely to be the same on other tablets using Wacom digitizers. The only solution is to use the trackpad or an externally connected mouse to bring up right-click menus.

These issues make Construct 2 somewhat impractical to use on the Surface Pro 2.

Attach a Capx

This is not project-related, therefore no CAPX is necessary.

Steps to Reproduce Bug

• Use Construct 2 on a Surface Pro 2 device. Probably also applies to any display using non-100% DPI scaling, or a tablet input with a Wacom digitizer.
• Open the animation editor in a project.

Observed Result

Strange glitched appearance of animation editor (click here for screenshot). Right click menus do not function with pen input.

Expected Result

Animation editor should look the same as it does on other devices, though scaled up to match the screen DPI. Right click menus should work using the pen input.

Affected Browsers

N/A

Operating System and Service Pack

Windows 8.1

Construct 2 Version ID

Construct 2 r163 (64-bit)

Yeah, looks like it is something that needs to be added. The problem with OGGs is that when you play the file (as a sound effect), it loads the whole thing into memory. This causes a momentary lag in the game as it does so, which would completely mess up any player.

The solution to that was to cache the music files before the level loads, but it poses its own problem. Yes, I can load them in a "loading" layout beforehand, but there's no way to tell when it is finished! So I can set it to sit on a loading screen for an arbitrary amount of time, and if it's not finished then those files simply won't be cached and ready. If someone is playing off a slow disk or flash drive, this could be problematic. I was hoping to go back to the music playback in order to avoid all of this.

After way too much trouble playing music as OGGs through the sound effect system, I decided to bite the bullet and switch back to normal MP3s using the music system in XAudio2.

However, my music is set up with an intro file that only plays once and then a looping portion. It appears that I will not be able to replicate this using the music commands, because there is no way to check if a piece of music (in this case the intro portion) has finished playing in order to play the next part. I can't even compare the length or change the playback position of a file because the music channel is separate from the sound effect channels. Is this just a missing feature or is there another way I am overlooking?

This would be a complete godsend. I am working on a game in 320x240 and I just realized that I can't use the built-in fullscreen function because my card's drivers (Radeon 5870) won't go any lower than 640x480.

I ran Construct for a while on a midrange Dell laptop from 2002, which didn't even have a pixel-shader compatible GPU, and it worked alright. This will run Construct well.

For Chrome...

Benchmark Score: 2575

Average FPS: 54

Quite a difference! Jeez.

Benchmark Score: 816

Average FPS: 17

Core i7-930 2.8Ghz, 6GB DDR3, 1GB Radeon 5870, Windows 7 64-bit, Firefox 4.0 final.

Man, I knew Firefox wasn't so good with this, but... ouch. I actually recall trying this test on FF 3.6 and getting better results.

Behaviors only equal an unprofessional game if the behavior code itself is bad. Look at the Klik products and their platform movement. When a game uses it, you KNOW because you always get stuck in things.

On the other hand, Construct's behaviors are much better coded and it's not noticeable. They're very flexible so each game can use them uniquely; there aren't limitations that make each game using a behavior all cookie-cutter-like. If you gave me a game made with the platform behavior and a game made using events that was nearly the same, I wouldn't be able to tell you which was which. They're there to be used, so they SHOULD be used, unless they're crappy, which in Construct's case they are not.

Wow, this is cool. I'm quite taken by surprise that everything is being done in HTML5. I wouldn't have thought of it. I just hope we see good quality exporters because not all games need to be web games. I also noticed on the feature thread that apparently pixel shaders can't be used-- is there going to be some way to get equivalent effects? I like my graphical craziness and, paired with still-poor HTML5 performance across the board, I'm concerned that this whole HTML5 switchover is going to make Construct more appropriate to "toy" games (like Flash) than serious projects.

I am hoping that this bug will be addressed. Control events just aren't working right for anything but the defaults, and since it affects the built in 360 controller plugin, users would probably not appreciate it failing to work properly in a 1.0 build.

I noticed that this isn't his fault at all-- it's actually a bug in Construct as far as I can tell. The built-in Xbox 360 plugin has the exact same issues, where it works with behaviors but not events.

I did make a bug tracker entry with an example, but I don't think it's been looked at yet.

You can change the display resolution with events.

Yes, but it's so much more work than it's worth. If you change the resolution, the relative locations of everything changes, so you have to manually adjust everything to fit the other resolution. (especially in regards to background parallax and just layers in general that scroll relative to what you can see) It's a waste of events and is extremely hard to perfect.

All I'm asking is that we can center something 4:3 in a 16:9 screen or vice versa. This would really help me on my 1920x1080 screen which stretches everything, and it would also help people on older monitors that are 4:3 or 5:4 who want to play my 16:9 game in fullscreen without it being squished.