• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!
  • Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

HTML5 Big HTML5 adventure game: is a viable project using GMS?

Ricardo

Ricardo

Member
Hi there!

Since I discovered draw_texture_flush() is not implemented in GMS' JS engine, I have serious doubts if GMS is a viable option to make a big HTML5 adventure game. In theory, with the texture flush function working (and using audio groups), I could make a 1 GB HTML5 game without problems, as I could clean unused assets to keep the memory usage in acceptable levels.

However, without the possibility of clean the VRAM, the game will use more and more memory and ocasionally crash. This problem is even worse when we consider mobile devices. I know that JS programs are garbage-collected, but my tests shown that GMS' programs NEVER release memory, no matter what.

Has someone managed to create a really big HTML5 game using GMS and found a way to clean the VRAM without use draw_texture_flush()? I've spent a lot of time searching about this, but as GMS' JS engine is ofuscated, is hard to find a workaround by myself.

The closest I've ever gotten to a solution is through simulating a WebGL context loss using a extension with .loseContext(), but I had no luck to get the game run again properly with .restoreContext() since, apparently, GMS does not has a loss/restore context management system (or maybe I haven't found the way of call it manually).

Any thought, idea or opinion about this problem is really welcome, as well as names of big GMS's HTML5 games that managed to workaround this difficulty (I haven't found any yet).
 
Mike

Mike

nobody important
GMC Elder
The bug will get looked at - I don't think it's a huge one to fix. However.... in the meantime. If you dynamically load images, you can throw them away, and I'd think the texture page would be thrown away with them...... You could a simple test for that I guess - load lots of the same image then throw them away, see what happens.
 
Ricardo

Ricardo

Member
Hi @Mike, thanks for the advice. I created a test project in which I dynamically load some images using sprite_add and then I remove them all using sprite_delete. Unfortunately, the VRAM isn't released in HTML5 as expected. Is this a bug too? Do you want I fill a bug report with this project?
 
FrostyCat

FrostyCat

Redemption Seeker
I'd call it a bug, just file it on Mantis. You have updater-level access now, so you should be able to file directly without going through ZenDesk.

As an aside, can you show the main JS file of the extension you wrote? It's easier to diagnose that way.
 
Ricardo

Ricardo

Member
Hey @FrostyCat, I'll file a bug soon - EDIT: done.

About the JS extension I wrote trying to release the memory simulating a WebGL context loss, is nothing too sophisticated and unfortunately it didn't work (the memory is released in fact, but the game doesn't render things anymore after the context restore). You can see the code here.
EDIT: and here you can see the erros after the context restore.
 
Last edited:
FrostyCat

FrostyCat

Redemption Seeker
@Ricardo:

The problem with the straight loseContext() approach is that it throws away more than just textures allocated by sprite_add(). It throws away every texture, shader, uniform, etc. that the original context had, hence the freed memory. Restoring it without calling the initialization again would cause the drawing calls to point to blanks and throw errors.

I don't think there's anything we users can do at this point other than asking for YoYo to fix/expose it at the engine level.
 
Ricardo

Ricardo

Member
@FrostyCat: Exactly! I asked the support for a way to call manually the "initialization" after the context break, as looks like GMS JS programs doesn't has a context loss/restore management system. Anyway, Kevin from support department tell me that one of the programmers know a way to workaround this and I'm waiting for the response. I'll keep this thread updated if they give me an alternative solution.
 
Ricardo

Ricardo

Member
Hi there,
I receive a response from the support about the workaround:

"Unfortunately the developer has informed me that the workaround I have previously suggested won't work. They thought that you might have been able to get this working yourself but we have since discovered that it is something that we need to do. I am very sorry but you will have to wait until the official fix is released."

So, no workaround to draw_texture_flush(), and the new functions sprite_flush() and background_flush() are also unimplemented in HTML5. I really hope @Mike give the developers a good nudge about this, there are people trying to push the HTML5 target to a new level and get these functions work properly is essential.
 
chmod777

chmod777

Member
Actually it seems that all the *_replace and *_delete functions that deal with WebGL ressources (sprites, backgrounds and fonts) are concerned. :confused:
 
Ricardo

Ricardo

Member
chmod777 said:
Actually it seems that all the *_replace and *_delete functions that deal with WebGL ressources (sprites, backgrounds and fonts) are concerned. :confused:
Click to expand...
Ouch, so it's worse than I thought.
Correcting then: @Mike, @rwkay, please, please, fix all the damn *_replace and *_delete functions on WebGL. @chmod777 and I are gonna buy you guys a big cake if you fix that :)
 
Ricardo

Ricardo

Member
chmod777 said:
@Ricardo It seems that draw_texture_flush() is now implemented in GMS2 (and maybe soon in GM:S ?). ;)
Click to expand...
It is in GMS 1.99.525 and GMS2. However, it seems there's still something not right, at least when WebGL is on. The game take lot's of VRAM when using WebGL and draw_texture_flush() doesn't release the memory immediately (probably not GMS fault, maybe something related with the browser's garbage collector). When WebGL is off, memory consumption is almost half and it looks like draw_texture_flush() do its work faster.

I'd love to see sprite_delete working...
 
You must log in or register to reply here.
Top