HTML5 Can't scale game canvas properly...

blossy

Member
I managed to make the canvas "responsive" via CSS/JavaScript so it looks pretty good on many screen sizes, but changing the width and height seems to mess up with the positions (x, y) of the game elements. And the result is that various interactable elements don't react on clicks/taps anymore. At least not at the locations where you'd expect them to.

Resizing the surface (surface_resize) fixes the problem but GREATLY reduces the graphic quality, even when scaling down to smaller canvas size.

Any tips?

Thanks in advance!
 

blossy

Member
Yes, I've tried that same technique and it does scale the canvas when I resize the browser window and elements are properly positioned but it degrades the image quality. It is especially noticeable if you use texts with small-ish font size - they become practically unreadable. Images (backgrounds and other sprites) look considerably worse too.

I don't have GameMaker 1.x so I can't tell if this issue is exclusive to Studio 2.

PS: Thanks for the response!
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Yes, I've tried that same technique and it does scale the canvas when I resize the browser window and elements are properly positioned but it degrades the image quality.
It may be that instead of making the app surface the size of the canvas, you want to make a magnitude larger, in effect doubling the pixel count and maintaining a clearer image? Although, if you are resizing the app surface to the canvas size then things should be okay... are you scaling the app surface at all?
 

blossy

Member
Of course, I've tried quite a few different room sizes and scaling up and down. The result is basically the same.

I've read that multiplying the canvas size by a whole number (2x, 3x, etc.) would avoid this sort of problems but I simply couldn't figure a proper base resolution that would work on mobile and desktop browsers. For the type of game I want to make (not pixel art), 360x540 looked to be a good base but it's still too large so a 2x version won't fit even the browser window of a desktop 1920x1080 screen (unless in fullscreen mode). And using a smaller base resolution like 180x270 seems too small for non-pixel-art visual style. I just don't get the needed flexibility with this approach.

For clarification, I'm trying to make a visual novel type of game with mobile browsers (in portrait mode) as main target. Clear images and texts are quite important :(
 

chmod777

Member
I've just tried this simple piece of code to compare between GMS1 and GMS2.

Step
Code:
var a = browser_width;
var b = browser_height;

if(a < room_width && b < room_height) window_set_size(a, b);
The result is much smoother in GMS1 when the window is resized if you look at the two files attached (open both and switch between tabs).


Mouse Enter
Code:
window_set_cursor(cr_handpoint);
Mouse Leave
Code:
window_set_cursor(cr_default);
OK in GMS1. Broken in GMS2.

So...
 

Attachments

blossy

Member
After quite a few more tests it's clear that scaling an HTML 5 game in GMS2 results in blurry visuals.

Even resizing down to exactly 1/2 of the original width and height produces a horrendous view that resembles a heavily compressed jpeg.

Either I am doing something wrong or the Web license is unusable and a waste of money + time as it can't meet such a basic platform requirement...
 

chmod777

Member
I've filled in a bug report that shows mouse offsets and blurry visuals when the game is scaled.
It might already be covered by this existing issue in some points: http://bugs.yoyogames.com/view.php?id=28596 ... but priority shouldn't be low at all, with web navigation on mobile devices being strong and requiring scaling.

I hope this will be fixed in the next release too.
 

blossy

Member
Thanks!

I'm not sure how a thing like this could be considered "low priority" if it makes the whole HTML export option worthless for anybody serious about releasing HTML 5 games.
 

chmod777

Member
Hello again,

The ticket has been processed and it did appear the bug was already in the database, showing the differences between GMS1 and GMS2:
0026237: HTML5: [GMS2] Calling window_set_size removes bounding box from objects (April 2017!!)

But I'm sure the following reports are duplicates too:
0028504: HTML5: Scaling with window_set_size will cause mouse to target a different point on the screen
0028596: HTML5: Attached project has mouse offset when running in HTML5


I wish @Mike could help here. ;):D
 

blossy

Member
A small update: the blurry visuals seem to be caused by the Windows 10 scaling feature (125% on my laptop).

This can be corrected by reducing the CSS width of the canvas element via JavaScript:
Code:
var canvas = document.getElementById('canvas');
var scale = window.devicePixelRatio;
canvas.style.width = canvas.width / scale + "px";
canvas.style.height = canvas.width / scale + "px";
... Which, of course, triggers the problem with the x,y coordinates so the HTML 5 export is still broken for me. The only uses I see for it are some half-assed demos/ports.
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
I'm currently happening to be helping with fixing some of the accumulated HTML5 issues (see Mantis),

0028596: HTML5: Attached project has mouse offset when running in HTML5
A fix for this is currently waiting approval - GMS2 cameras work differently to GMS1 views and weren't accounting for camera being offset inside "window" (canvas) when it came to mouse coordinate translation. This only applied when "window" aspect ratio didn't match game aspect ratio

This can be corrected by reducing the CSS width of the canvas element via JavaScript:
This is currently being looked at - DPI scaling in general is a big can of worms,
  • Automatically downscaling the canvas would have it not fill the page on mobile devices with higher dPR;
  • Automatically increasing resolution causes oddities if your code was expecting screen pixels to be evenly sized (i.e. whether things line up is at mercy of GPU/browser).
but it does make sense to detect user messing with canvas and applying coordinate scaling accordingly.

It is possible to override mouse coordinates yourself by making a script like
Code:
/// gmcallback_mouse_x()
return mouse_x;
and having the extension extract the minified JS variable name (in obj.field format) from window.gml_Script_gmcallback_mouse_x.toString() using a tiny regular expression like /return(.+);/ (so that you can then make a new Function that'd change that one variable) but that is a bit more work than people usually expect.
 
Last edited:

chmod777

Member
I'm currently happening to be helping with fixing some of the accumulated HTML5 issues (see Mantis),

A fix for this is currently waiting approval - GMS2 cameras work differently to GMS1 views and weren't accounting for camera being offset inside "window" (canvas) when it came to mouse coordinate translation. This only applied when "window" aspect ratio didn't match game aspect ratio.
Oh, these are two very good news, thanks. :)
 

Carbon

Member
So apparently https://bugs.yoyogames.com/view.php?id=26237 says it has been resolved, how is the scaling issue in HTML5 now? I just bought the HTML5 export and now very disappointed with the existing scaling bug:(

EDIT: Claire Hall said he can't reproduce the bug, wtf.. I just tried it myself and successfully rep the bug for the first time.

Oh man, waited for so long for the html5 to work at least just the core functionality like scaling, and it disappointed me so much! I wonder if I'm the only one disappointed here, not sure.

Pleaseee fix this!
 
Last edited:

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
So apparently https://bugs.yoyogames.com/view.php?id=26237 says it has been resolved, how is the scaling issue in HTML5 now? I just bought the HTML5 export and now very disappointed with the existing scaling bug:(

EDIT: Claire Hall said he can't reproduce the bug, wtf.. I just tried it myself and successfully rep the bug for the first time.

Oh man, waited for so long for the html5 to work at least just the core functionality like scaling, and it disappointed me so much! I wonder if I'm the only one disappointed here, not sure.

Pleaseee fix this!
It is fixed locally but no new GMS2 updates been out yet.
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
what do you mean with fixed locally?
That it has been fixed on YoYo's end (which is why the version number quoted on bug ticket is 9.9.1.941 instead of 2.1.x.xxx) but not yet rolled out into a public release.
 

Carbon

Member
That it has been fixed on YoYo's end (which is why the version number quoted on bug ticket is 9.9.1.941 instead of 2.1.x.xxx) but not yet rolled out into a public release.
Thank you so much for the sweet sweet slight breeze of hope.

So when can we expect yoyo to release the update?
 
C

CodeTeacher

Guest
That it has been fixed on YoYo's end (which is why the version number quoted on bug ticket is 9.9.1.941 instead of 2.1.x.xxx) but not yet rolled out into a public release.
This is very good to hear.

Any inkling of when these changes will be available for us to use?
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
Thank you so much for the sweet sweet slight breeze of hope.

So when can we expect yoyo to release the update?
This is very good to hear.

Any inkling of when these changes will be available for us to use?
Unless it was announced somewhere already, I don't imagine that there's a more precise answer than "in near future" - based on what can be seen on bugtracker alone, you can see that this update had gotten pretty big in terms of number of issues fixed, and will be have to go through QA prior to release (to reduce the chances of anything getting particularly broken).

Ideally the updates should have been per module, of course, in which case this could have been a smaller patch just for HTML5 target, but that requires some stranger infrastructure.
 
C

CodeTeacher

Guest
Thank you for the reply.

I'm teaching a coding class using GameMaker and I was hoping the students could load the project they are building up on a web server to share with the rest of the school. Would be cool if they could use the touch controls on their phones since most students do not have computers of their own.

I'll keep hoping for this to get resolved in time.
 

shmurl

Member
I'm having the same problem (4 months after the op).
Anyone news about when the update will be rolled out?
 

dhouseley

Member
Still having issues with this, when the window is centred, all my GUI elements and mouse detection go out the window. I'm wondering if any progress has been made on this.
 

bacteriaman

Member
It's been nearly 10 months since the last post in this thread, but I am experiencing the same fuzzy text issue when the HTML5 browser window is reduced from the canvas full width of 1200px. I've tried increasing the size of the font, but the legibility remains awful. My project is paid work and my reputation is on-the-line.

I guess in hindsight I could have drawn all the graphic assets at a lower resolution, but I never dreamed 1200px would be an issue with GMS2 in 2019.

It's worth noting that I am using this technique to dynamically resize the canvas: https://www.yoyogames.com/blog/67/scaling-for-html5

That article is very old though and was written for GMS1. Perhaps there's a different/newer/better method to achieve the same thing in GMS2 (?)

All comments/suggestions appreciated.
 
It's been nearly 10 months since the last post in this thread, but I am experiencing the same fuzzy text issue when the HTML5 browser window is reduced from the canvas full width of 1200px. I've tried increasing the size of the font, but the legibility remains awful. My project is paid work and my reputation is on-the-line.

I guess in hindsight I could have drawn all the graphic assets at a lower resolution, but I never dreamed 1200px would be an issue with GMS2 in 2019.

It's worth noting that I am using this technique to dynamically resize the canvas: https://www.yoyogames.com/blog/67/scaling-for-html5

That article is very old though and was written for GMS1. Perhaps there's a different/newer/better method to achieve the same thing in GMS2 (?)

All comments/suggestions appreciated.
I'd recommend The Mobility Engine personally. I use it with my HTML5 games, and I've never had any scaling problems.
 

bacteriaman

Member
@SilentxxBunny, thanks for your prompt reply.

I have been aware of Mobility Engine for awhile, but thought it was just an extension for doing certain things easier. However you're suggesting that it will actually improve the rendering of drawn elements like fonts and lines. If so, that's great news and would the asking price well worth it.

Question. Once the extension is added, how much code is required to implement scaling in an existing project? For example, the aforementioned (outdated) scaling code only requires a small snippet of code in the CREATE and STEP event of a control object.
 
Question. Once the extension is added, how much code is required to implement scaling in an existing project? For example, the aforementioned (outdated) scaling code only requires a small snippet of code in the CREATE and STEP event of a control object.
It's as simple as importing two extensions, double-checking a few global game settings, and merging the two projects. Even I managed to figure it out. ;)

@SilentxxBunny, thanks for your prompt reply.

I have been aware of Mobility Engine for awhile, but thought it was just an extension for doing certain things easier. However you're suggesting that it will actually improve the rendering of drawn elements like fonts and lines. If so, that's great news and would the asking price well worth it.
I was suggesting that I've personally never had any problems with rendering. I've always used it, so I'm not familiar with how well GameMaker handles it out "out of the box."



Edit: Sorry, everyone. I don't have a concrete answer for the question that was asked, so I shouldn't have said anything at all.
 
Last edited:

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
@SilentxxBunny, thanks for your prompt reply.

I have been aware of Mobility Engine for awhile, but thought it was just an extension for doing certain things easier. However you're suggesting that it will actually improve the rendering of drawn elements like fonts and lines. If so, that's great news and would the asking price well worth it.

Question. Once the extension is added, how much code is required to implement scaling in an existing project? For example, the aforementioned (outdated) scaling code only requires a small snippet of code in the CREATE and STEP event of a control object.
The said extension aids with scaling the canvas, primarily for mobile devices. I would say that it's unlikely to magically fix font sharpness when scaling down slightly, but it'd be nice to see before-after screenshots for a start
 

bacteriaman

Member
I ended up resizing the assets and reducing the canvas to a fixed size that's compatible with just about every modern smart phone and tablet. This was a tedious process, but in the end it was worth the effort.
 
I ended up resizing the assets and reducing the canvas to a fixed size that's compatible with just about every modern smart phone and tablet. This was a tedious process, but in the end it was worth the effort.
Thanks for sharing your solution. Glad you figured it out, my friend. :cool:
 

zbox

Member
GMC Elder
Did this ever get fixed? Downscaled games in HTML5 still look really bad compared to native exports.

Adding the CSS attribute image-rendering: pixelated; to the canvas helps some way if you don't want interpolation, and it looks like this was attempted by YYG as the attribute originally exists just with an invalid or old value. But it still isn't the same thing.
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
Did this ever get fixed? Downscaled games in HTML5 still look really bad compared to native exports.

Adding the CSS attribute image-rendering: pixelated; to the canvas helps some way if you don't want interpolation, and it looks like this was attempted by YYG as the attribute originally exists just with an invalid or old value. But it still isn't the same thing.
Should work fine after applying this tweak to rescale canvas to screen pixels - that's what usually makes things look worse than they should
https://forum.yoyogames.com/index.php?threads/cant-scale-game-canvas-properly.40830/#post-256482
 

zbox

Member
GMC Elder
Should work fine after applying this tweak to rescale canvas to screen pixels - that's what usually makes things look worse than they should
https://forum.yoyogames.com/index.php?threads/cant-scale-game-canvas-properly.40830/#post-256482
I have tried that one, doesn't seem to do too much but squash and make the game look a little weird (after the typo is fixed).

My current solution breaks all of the native clicking functionality for events etc. but I can't see another way to do this (for a fullscreen HTML5 game):

Inject JS:
Code:
document.documentElement.style.transform = "scale("+1/devicePixelRatio+")";
document.documentElement.style.transformOrigin = "top left";
document.documentElement.style.overflow = "hidden";
Extension code to get the device PX ratio:
Code:
function CustomFunc_Get_DevicePixelRatio() {
    return window.devicePixelRatio;
}
View code
Code:
var display_w = browser_width * CustomFunc_Get_DevicePixelRatio();
var display_h =  browser_height * CustomFunc_Get_DevicePixelRatio();

var asp = display_h/display_w;
var intended_h = 1080, intended_w = 2380;

var gamewindow_scale = 1.2; // Zoom out
gamewindow_w = round(intended_w * gamewindow_scale);
gamewindow_h = round(intended_w * asp * gamewindow_scale);

camera_set_view_size(view_camera[0], gamewindow_w, gamewindow_h);
view_wport[0] = gamewindow_w;
view_hport[0] = gamewindow_h;
camera_set_view_border(view_camera[0], gamewindow_w / 2, gamewindow_h / 2);

window_set_size(display_w, display_h);
application_surface_enable(true);
surface_resize(application_surface, gamewindow_w, gamewindow_h);
display_set_gui_size(gamewindow_w, gamewindow_h);
Which makes the game look really good and crisp.

vs


(You may need to open the images to see the difference, and it is exaggerated on rotated sprites. Very noticeable in-game).

But then of course that breaks all of the clicking, to which I've just done this to fix it (and replaced all of the relevant functions with these ones):
Code:
/// @func adj_device_mouse_x_to_gui
/// @param device
return device_mouse_x_to_gui(argument0) * CustomFunc_Get_DevicePixelRatio();


/// @func adj_device_mouse_y
/// @param device
var c = view_camera[0];
var view_to_gui = display_get_gui_height() / camera_get_view_height(c);
return adj_device_mouse_y_to_gui(argument0) * view_to_gui + camera_get_view_y(c)

/// etc...
I think this is the most comprehensive answer to fix it on the forums - I've tried all other answers and it really seems like none work. I hope I've not overlooked something simple to get it working. This is such a shame, because most games coming out of the HTML5 module just must look bad for no reason?!
 

Japster

Member
Well, I've built my first HTML5 game for a client, and yep, this bug has reared it's ugly head... :rolleyes: Once embedded in a page, the click locations are all out. The solution above, by @zbox sounds promising (thanks for sharing mate), but involved - not sure how much work it will be to implement, as I'm using native 'click' events everywhere, for LOADS of objects... :(

I'll study it, but seriously, is there NO easy fix for elements and hotspots not scaling properly in the HTML target?! - I love GMS2, but find it absolutely crap that the exporter I literally JUST purchased STILL has a years-old bug that is pretty much game-breaking without a load of faffing about and gaffer-taping up?! :mad:

Unlike my usual Yo-Yo fan state, today I'm NOT impressed - They were hoping to go live with it this weekend after fixing various HTML-specific smaller issues, but obv. not possible now...
 

Japster

Member
BTW - @Nocturne - I tried following the link you gave to a possible fix, but it's no longer available, nor saved on Waybackmachine... :(

Old Article

Could you perhaps enlighten me please mate? - if it's a quick fix at the cost of image quality, it would certainly do for now! :)
Cheers!
 

rIKmAN

Member
BTW - @Nocturne - I tried following the link you gave to a possible fix, but it's no longer available, nor saved on Waybackmachine... :(

Old Article

Could you perhaps enlighten me please mate? - if it's a quick fix at the cost of image quality, it would certainly do for now! :)
Cheers!
Not sure if it was another seperate guide, but I think it may have linked to the HTML5 specific part of the general "Basics of Scaling" series of articles which can be found here: https://www.yoyogames.com/en/blog/the-basics-of-scaling-html5

Might be worth a read until Nocturne can confirm.
 

Japster

Member
Hmm... no joy still - I implemented that object and code, but running the HTML5 game, previously-displaying rooms now simply display a black screen (same as I get trying to do anything similar as regards resizing the app surface)... :(

Argh...
 

Japster

Member
This really is a joke. I've exported my game, and it's useless - client is massively disappointed, missed their launch window for last week, and we still have the issue where the elements don't match up, and they can't press any buttons.

I really think I'm going to forget it, and apply for a refund for this module. I LOVE GMS2, I really do... ....but what's the point of an export module that's broken, when it comes to aligning objects with their actual on-screen / window location, without a crapload of messing about (and breaking other stuff) trying to overcome this hurdle?

I'm now beyond frustrated, not to mention incredibly embarrassed and my reputation as a deliverer is suffering - none of the solutions I've seen actually fix this, and worse, it seems an all or nothing solution as far as game canvas placement is concerned. If the game runs on it's own in an empty page, at least it *appears* correctly, if not works correctly. However, if I want to drop it below a banner / header, it all goes to crap. a sliver of game window, bottom 5th of the screen, shoved over to the right, etc...

Surely, given the ease of use and implementation of GMS2 in general, this broken functionality / module is drastically hurting the reputation of this product, and alienating users as in posts above... ...Can we not at least have some indication of how to possibly fix this if possible by amending the resultant JS, HTML or CSS to account for being embedded within an area of a page, and correctly scaled? - I mean, I've tried GUI draw, normal draw, etc, and it's not even like GUI seems affected only - it was happening WITHOUT GUI draws, so I tried those. no joy... It doesn't help that the runner doesn't seem to suffer from the issue, so I can't even troubleshoot / view the issue, by just running the HTML5 game using the local server, from the IDE?

Anyway.... enough frustration for one yet another day... ...I've had enough.... I'm calling it a night... well, morning...
 

zbox

Member
GMC Elder
As far as I know, any in-game fix (RE: scaling article) will not work because the problem actually lies outside of Gamemaker - I might be wrong, has been a while since I revisited this.

But if I'm not, @Japster as you can see the issue has been around for a bit, I would recommend biting the bullet and implementing what I did. It's not too hard!
 

Japster

Member
Well, in case anyone is wondering, I managed to resolve the HTML5 game breaking bug issue in the end (but it's a hollow victory...)

Nothing, literally NOTHING (even TrueValhalla's $64.95 'Mobility Engine', which I feel I've wasted money on at this point, as it didn't fix the issue at all, despite being a HTML5 fix all / scaling solution) - Nope, the only thing that worked was painstakingly going BACK through runtimes, until I hit v2.2.0.261...

I can 100% say that the issue was introduced in v2.2.1.287, as the above previous runtime works PERFECTLY for HTML scaling / canvas relocation, so really, isn't it just a case of YoYo's devs doing a diff and some manual investigation across these versions to FIX this issue they introduced? - it's quite obviously a bug introduced then, as it works, works, works, for every version prior to that (I know as I originally jumped back further), and suddenly STOPS working correctly after that version, getting worse across the 2 v2.2.1.x versions...

Seriously guys, this isn't that hard to investigate and fix, surely? - plus, it's the right thing to do given the exporter is a paid-for product!.... Even @Appsurd 's helpful suggestion of iFrames probably won't fix the browser magnification / zoom scaling issue, but I'll certainly try it to see if it at least fixes the OFFSET issue in later runtimes, or I'll be completely stuck on the older one...

As it stands I'm now going to have to use v2.2.0.261 for ALL of my HTML work, which as you're probably aware has issues with ASSET layer elements/placements being incorrect (a historical fix for which may be related to the broken functionality in later releases?) - So I've had to remove all assets in rooms, and create objects for each. Not ideal, but hey, it gets me working again at least...

I really would like YoYo to treat this issue with the seriousness it deserves (and their purchasers of this module deserve!), as other than this, the HTML5 module is FANTASTIC, but well, YoYo have obviously (innocently and inadvertently) broken perfectly working functionality for a module that users have paid in good faith for, so it's unacceptable to not fix it!

I love you guys, but this seemingly indifferent attitude to a long-standing, game breaking bug, that's been broken and not even touched for 2+ years, is making me lose some faith in YoYo, and sadly reminds me of that 'other' badly maintained product.... :(
 
Last edited:

Japster

Member
As far as I know, any in-game fix (RE: scaling article) will not work because the problem actually lies outside of Gamemaker - I might be wrong, has been a while since I revisited this.

But if I'm not, @Japster as you can see the issue has been around for a bit, I would recommend biting the bullet and implementing what I did. It's not too hard!
I know mate - It's a great fix for scaling issues, but my main problem is to do with the fact that the game is NOT running as the only element in it's own window (i.e. it's running in it's own div, below a banner image/links section etc)... So I get this tiny strip of it showing, as soon as ANY code fixing/adjusting the position/scale happens - ANY solution I've tried to implement (your excellent one, and several others, including Nocturne's one kindly referenced by @rIKmAN ), and including the 'Mobility Engine' from Matthew, sadly do not fix that... :(

As you've hopefully seen my newest post, sadly, the issue is DEFINITELY to do with broken GMS2 functionality introduced in v2.2.1.x - it works absolutely perfectly in every single respect, whole page, canvas in a div, SCALING (!), etc, etc, prior to the first v2.2.1.x build... :(

So yeah, would be great if YoYo just compared/DIFF'd the relevant code changes in those 2 versions of the runtime, and fixed the breakage - everyone would be over the moon = good for YoYo's relationship with us, and reputation.

Thanks again mate, really appreciate you coming back to me too!
 
Last edited:

rIKmAN

Member
So yeah, would be great if YoYo just compared/DIFF'd the relevant code changes in those 2 versions of the runtime, and fixed the breakage - everyone would be over the moon = good for YoYo's relationship with us, and reputation.
Might be a silly question, but have you reported this with the info you gave above, attached an example and linked to this thread?

Sounds like this would have a decently high priority and I would check if it’s on there already but the bug database is now private.
Good detective work though finding when it was introduced, that should help YYG a lot when attempting to fix.

I own the HTML5 module as well and although I don’t actually use it much, I also wouldn’t find it acceptable if I had to roll back to a version that old to be able to use it properly.
Rolling back also wouldn’t work if you had been using v2.3 features and syntax etc too, so it really should be fixed.
 
Last edited:

Japster

Member
Might be a silly question, but have you reported this with the info you gave above, attached an example and linked to this thread?

Sounds like this would have a decently high priority and I would check if it’s on there already but the bug database is now private.
Yeah, I will do, definitely (although I saw other instances of people already logging, but at the moment I'm chasing my tail trying to get this project live and calm down my client, after a week's delay in getting it out there for them due entirely to this issue... :(

Good detective work though finding when it was introduced, that should help YYG a lot when attempting to fix.
...Many thanks for the appreciation, it's a rare commodity these days! :) Yeah, I'd hoped that actually finding and advising the EXACT runtime release number it was introduced in, would help YoYo expedite a fix, by narrowing down to the exact point/release it started in...

I own the HTML5 module as well and although as don’t actually use it much, I also wouldn’t find it acceptable if I had to roll back to a version that old to be able to use it properly.
Rolling back also wouldn’t work if you had been using v2.3 features and syntax etc too, so it really should be fixed.
Yep, agreed mate - I've had BIG issues migrating my projects to 2.3.x too, requiring HUGE amounts of work, and ultimately giving up because too much is wrong with the imported project. On the whole, it looks a very thorough migration process, and a lot of thought has obviously gone into it - but sadly, my objects lose their preset settings / values, (resulting in a massive amount of errors due to lost pre-loaded variable settings (and actual pre-specified object variables, IIRC), and an unworkable amount of manual work for my larger projects, trying to troubleshoot and reproduce the original pre-loaded values and instance variables), every time.

Again, people MUST have been affected by this? - it's actually the only thing that's stopped me from migrating my other projects and adopting 2.3.x (which in this case proved very lucky)...

I sound very negative I guess, but to be fair, other than these two HUGE issues, I'm over the moon with GMS2 in general, and still believe it to be an amazing product - just that we really need this huge HTML5 issue fixing...
 
Last edited:

rIKmAN

Member
Yeah, I will do, definitely, but at the moment I'm chasing my tail trying to get this project live and calm down my client, after a week's delay in getting it out there for them due entirely to this issue... :(
Understandable, but please don't forget - if it doesn't get reported then it's unlikely to be fixed.

Hope you can calm the client down.
 

biyectivo

Member
Has this been fixed? I'm facing the same issues as you all are. I understand @YellowAfterlife's HDPI fix does not come into play here since I'm testing HTML% on Windows, not mobile, right?
Has the bug report been filed?
On a side note, have you experienced issues with window_get_fullscreen() on HTML5 reporting TRUE even when you have exited fullscreen (F10)?
 

Japster

Member
@biyectivo - Sorry mate, not been following this thread for a while, as I gave up - logged the issue, even had it confirmed by other users, and not even sure if it's been resolved in later runtimes.

Pretty sure it hasn't as I've not heard diddly-squat... Even if it HAS, I cannot move to a new runtime unless the mouse/touch button PRESSED state issue is fixed... (press and hold one button, press and hold another, then let GO of any button, and BOTH still show as pressed, UNTIL you let go of *BOTH* buttons.)

To be honest, these are really f****** annoying me now. My current project is in 2.3 (I bit the bullet), and yeah, tried this, as it was silly not to use some of the new features... Now I'm having to use 2.3.0.401 or something (not at home atm, so can't say which one just yet), because the HTML fails in newer ones...

NOTHING we do - webpage, iframe, etc, all options in the HTML5 Options settings dialog, puts the game correctly on screen - overlaid "get_string" prompts appear half-in the canvas (in Chrome at least), so you can't even click them etc. The game ALWAYS jumps to the left, after the loading bar is complete. It's also suffering from that crap pixelation (lost image info / lines) bug in Chrome. Interestingly, FF displays fine (and resizes the surface to 256, and the canvas is sized to EXACTLY that, or double that, whereas gamemaker resizes the game's surface to say, 256 x 225, (instead of 256 x 224, or 512 x 448 in FF) in Chrome.

The annoying thing is that we know EXACTLY which runtime introduced the original scaling bug, and this has been known about for MONTHS, so there really is NO excuse not to have fixed it and re-implemented it into a recent release?....

I'm honestly losing whatever enthusiasm I had for Gamemaker 2 development, as we've spent days on these issues....

Even Nocturne's excellent HTML5 canvas guide doesn't seem to fix this, sadly....
 
Last edited:
Top