Fixing memory leak in Surface

[LordEidi]

This is an ugly hack but fixes the memory leak in Surface for now. A refactoring would be the better option.

[Daft-Freak]

Hmm, another one in load_from_bmp:

32blit-sdk/32blit/graphics/surface.cpp

Lines 822 to 825 in 946baad

	if(!data)
	data = new uint8_t[header.image_size];
	auto ret = new Surface(data, format, bounds);

Also, tooManyCamels, not_enough_snakes 😄

[Gadgetoid]

Quite amazed this hasn't been conflicted yet. I guess the engine doesn't get quite the TLC the ports do!

Seems the reason this failed for Emscripten has been lost to the sands of time. Could use a rebase and some gentle nudging into snake_case as suggested.

@LordEidi got any time/interest in doing this, or should we grab and tidy up?

[Daft-Freak]

Until recently (in uh, "SDK time") changing the layout of Surface would break the firmware API. That's possibly why nothing much has changed here.

As an additional comment, the new variables should probably be up with the other variables.

(This was on my list of things to look at, which I should probably be less secretive about...)

[LordEidi]

Sorry, wasn't on Github lately (Codeberg is a nice place to be :) ).

Re your question regarding tidying up. We moved away from loading our data through blit::Surface and implemented an Aseprite exporter which generates code (two arrays: one image, one palette and a struct for the rest) which is then directly compiled into the binary. We feed that data structure into the Surface during execution and haven't had any trouble with that so far.

Long story short: I could help you brushing up this pull request. But I haven't followed the 32blit SDK changes lately as closely as I used to. I would need a bit of guidance what you need to accept the change.