I made a thing, please help me break it!

[BPzeBanshee]

I'm a bit behind the times on getting this working but I think some of my fellow GM devs will understand the significance of this.



Needless to say I want to be sure it works on other people's machines consistently before actually using it anywhere. I'd really appreciate it if folks with some spare time could test this and try to break it.

Download test file here

[eebrozgi]

Semi-old Windows 7 laptop here, all systems normal.

[Rozyrg]

Works fine on my weak but somewhat capable Win8.1 machine. Only anomaly I've seen is a 1px high white line appearing under the black border above the 'button' text when rotated to 180 degrees, nothing unusual for doing TATE stuff.

I'll test it on my other PCs later.

[wgogh]

It works normally. Windows 7 on an old Sony Vaio laptop.

[BPzeBanshee]

Thanks for the assist so far guys. It's been quite the help! If you need more information being shown as to what it's actually doing I can update the build to show window resolutions, etc. Better to break it somehow now rather than later down the track.

Works fine on my weak but somewhat capable Win8.1 machine. Only anomaly I've seen is a 1px high white line appearing under the black border above the 'button' text when rotated to 180 degrees, nothing unusual for doing TATE stuff.

I'll test it on my other PCs later.

The 1px white line happens when the x/y position of the renderer is at a decimal point, I spotted it a few nights ago and rounded that off so shouldn't be an issue. I've fixed some other stuff with the "old" renderer method (which is what you get when you hit "No" to the question popup box) since that's also a new refactor and I broke a few things there.

How was the performance? I've not noticed a drastic difference but I'm worried about the new renderer's performance on exactly your kind of machine, and neither GMS nor its apps run on my legacy PC anymore .

[Rozyrg]

It does work on my legacy machine (ASUS Eee PC/Netbook with WinXP) but it freaks out if you try maximize the window. Basically, everything turns to weird blocks like sometimes when I fiddle with GMS' "force software vertex processing" option.

The only noticeable impact on FPS I get is if I use the key that changes the window size/resolution - it goes from ~59 to 30. Not really unexpected for this PC, though.

[BPzeBanshee]

Most peculiar. It might be related to that option or could be related to the vertex buffer mode that recently got changed in Studio (the default for which older cards have some trouble with) - we got a few bug reports for that with Zenohell which fortunately I was able to replicate on a Intel HD card when working on Zenodyne R.

If you've got time tomorrow and still willing I'll make an updated build with a bit of ini-configurable options, hopefully one of those settings will fix it. Otherwise I can give you the source code if you feel like tinkering with it?

[Ikazu-san]

What exactly is in need of testing?
The only issue I found is that pause button doesn't actually pause anything.

[BPzeBanshee]

Basically anything with the screen controls that may or may not cause it to break - going to fullscreen and back, unusual resolutions you might have for your monitor, any weird artifacts that don't otherwise happen when saying "no" to the popup question, etc. I want it to be robust as possible so I don't make an embarassment of myself next week.

Pausing works as far as controlling the black box in the room (a very crude player object I admit), it should show a pause notice in the center of the game window when pressing ENTER.

[S20-TBL]

Everything A-OK on my end (i5 Win10 laptop), nothing much to report on the crucial parts except...

Pausing works as far as controlling the black box in the room (a very crude player object I admit), it should show a pause notice in the center of the game window when pressing ENTER.

Pausing doesn't seem to stop movement, I can still control the black box with the arrow keys and it will be displaced when I un-pause. But that's all I found.

[BPzeBanshee]

Ah, yes I see what you mean: I slacked off and made the "player" (the black box) also handle pausing, so when using instance_deactivate_all(1) it isn't deactivating itself but the "pause" image is otherwise being generated fine so it appears elsewhere if you move it around and unpause. Not a render-related issue nor will it show up in GMOSSE-related projects, I assure you.

Took a bit longer than a week given rl and time spent on other things but I think I've nailed the remaining render issues. GMOSSE already has it up and running and the fallback render object is also working nicely. Since the fixes and improved pause script code is there I won't be releasing the source for this project file (cause it's awful) but anyone interested can look at obj_ctrl_render and obj_ctrl_render_old in GMOSSE MK-IX when I release.

Thanks again for all the support - I've experimented with this a few times over the years and the performance losses on people's machines was too great to justify the overhaul, but now with the possibility to control when and how the application surface is drawn that clearly isn't an issue anymore.