View Issue Details

IDProjectCategoryView StatusLast Update
0023413Runner3DPublic2018-01-29 15:10
ReporterAndrew CayAssigned ToMike Dailly 
PriorityNoneSeverityC - GeneralReproducibility100%
Status ClosedResolutionFixed 
PlatformHTML5OS OS Version
Product Version 
Target VersionFixed in Version 
Summary0023413: HTML5: surfaces are broken
DescriptionThe 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 InformationOriginal helpdesk ticket:
TagsNo tags attached.
1.4 Found In1.4.1757
2.x Runtime Found In
2.x Runtime Verified In1.4.1772


Mike Dailly

2017-07-26 11:47

Developer   ~0054578

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.