View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0023413||Runner||3D||Public||2016-08-29 10:19||2018-01-29 15:10|
|Reporter||Andrew Cay||Assigned To||Mike Dailly|
|Priority||None||Severity||C - General||Reproducibility||100%|
|Target Version||Fixed in Version|
|Summary||0023413: HTML5: surfaces are broken|
|Description||The behaviours seen in the first two cases also happen when WebGL is disabled. (surface_exists is broken)|
- The behaviour found in the third case, involving temporary surface, is only causing bugs when WebGL is active.
* surface_exists - is always returning true, although it does not
* surface_draw - impossible to check if surface exists and results in errors filling up the console (has crashed my game but doesn't seem to happen in this export)
* temporarily drawing surfaces that are freed from memory just prior to actually being drawn results in corrupt texture and many error messages.
All cases are documented in the attached file.
|Additional Information||Original helpdesk ticket: http://help.yoyogames.com/tickets/110426|
|Tags||No tags attached.|
|1.4 Found In||1.4.1757|
|2.x Runtime Found In|
|2.x Runtime Verified In||1.4.1772|
First, you should only create surfaces in the draw events. Since surfaces are just (reusable) indexes, when you create/destroy one in the create event, you're going to get the same index as the application_surface. This then causes lots of other knock on's as you think your using your old surface, but your actually using the current render target.
This also causes the odd errors of cant render to the current texture etc as your using the app surface as the texture to draw onto the app surface.
The "fix" for all these, is to set your surface variable to -1 in the create event, then test if the surface has been created in the draw event. -1 will always return false.
You should also ALWAYS set your variable to -1 when you free it.
I have changed the return from surface_exists() on HTML5 as it was returning true/false, and not 1 or 0. While this is correct, it's more consistent with the native runtimes to return a number - so that has been changed.
Lastly, the crash seems to have been fixed already.