Can I do these things? draw() with Tilemaps, sound loading progress, etc


#1

Hi there, I’ve been working on porting a game project I’ve been working on for a few years over from AIR to OpenFL, and at this point I am very frustrated and tempted to revert all my changes. My previous system for drawing levels used copyPixels() to render the level tilemaps onto a bitmap, and then drew that bitmap onto a main rendering bitmap – I thought I could just rewrite my system so that I instead create a tilemap and then use that to render to the main bitmap, but using draw() on a BitmapData with a tilemap parameter seems to fail to draw anything at all. I’ve tried putting the same Tilemap on the display list and it seems to display just fine there, but that’s unsuitable to my purposes since I need access to the screen buffer so I can do reflection effects and such… using DisplacementMapFilter, which seems to be currently unimplemented in OpenFL but I can write my own if necessary.

I’ve also run into a lot of problems with loading in sounds, where I had it set up to load in sound effects/music and fire only proceed when these were fully loaded, I find that with the bytesLoaded parameter of the Sound class apparently essentially unimplemented I can no longer do so, and if I try to play a sound before it’s fully loaded then it returns a null SoundChannel which causes errors further down the line.

Are there solutions to these problems? Am I missing something?


#2

you may want to load sounds using Assets.loadSound, as described in the docs of the method:

Assets.loadSound ("sound.wav").onComplete (handleSound);

don’t think you need to check bytesLoaded for that.

i have the same “architecture” for most of my games (draw to an offscreen bitmap), but, tbh this is pushing to the limit, as far as i know/noticed, this is software rendering. i’m not drawing Tilemaps, though, just plain BitmapDatas and do so using BitmapData#draw as copyPixels is painfully slow (if you export to html5, that is). however, using BitmapData#draw with color transform is also slow. i had reflections/alpha stuff rendered using this method in some of my games and i’ve removed them :slight_smile:

i’m yet to test everything openfl offers, but i believe the fastest solution is display list and a “mega-texture” for the tileset, containing all the ingame assets. it might be necessary though to re-think the whole game architecture…


#3

Hi!

Thank you – this is something we just had not tested, I think it would be good for us to support this, it’s just different than how it’s normally used.

Normally you use BitmapData with your Tilemap, and let that do the rendering. This allows to use copyPixels on Flash, and a batch OpenGL render on other targets, giving you (hopefully) the best of both worlds, depending on the target.

As for effects, for performance you’re going to want to use a shader. You could use Tilemap with bitmapData.draw on Flash Player (as it’s a flash.display.Bitmap under the hood on that platform) but on others, you can apply a tilemap.shader or tile.shader to your tiles, for a different effect when drawing each one. If it must be a post-process effect, then using filters should work, though we might not have a GL version of DisplacementMapFilter written yet.

Are you still able to target Flash and AIR with your code? openfl test air, openfl test flash, etc?


#4

Ahh, I was under the impression that Assets was just a way to handle embedded media, knowing that it has a set of methods for handling loading at runtime is useful. I’ll have to see if that helps me rewrite my sound handling code

I’ve already created a system to load all the tiles into one big tileset as needed – right now I’m just using that for level tiles, but maybe I can fit all the tile and animation assets in there even if it’s limited to 8192x8192, as it seems to be on at least AIR/Flash platforms. It may be a problem to fit the background paintings in as well, though… Also, it seems to be very difficult to modify tilesets once they’re loaded in, which seems like it could be a problem if I need to update the game’s animation data without restarting it, say while I’m editing and reloading an asset.

I’ve been testing on AIR and Windows targets – Flash isn’t a viable target because I’m using a lot of file IO stuff that isn’t allowed by the Flash sandbox. In neither Windows nor AIR does BitmapData.draw work on a Tilemap, as best as I can tell. I might be able to do it with a shader, I’ll have to look into that – is there an overview somewhere of how to approach shaders in OpenFL, or a sample somewhere in the code base that I could look at? I tried the HerokuShaders demo and it didn’t seem to work under AIR or Flash targets, so I wasn’t sure how much I should base my work around it. I suppose I don’t strictly need to be able to target AIR, but it’s very useful to be able to use the Flash debugger when I run into a sticky problem.


#5

maybe you’re already doing this, there’s this tool called texture packer (https://www.codeandweb.com/texturepacker). the result of packing together the assets is a big image file and plist with definitions. you might be able base your animations on this plist.

not sure about the backgrounds, it could be that it works just as fast with a background and a tilesheet on top of it in the display list. should be easy to see by modifying the bunnymark sample.


#6

You can use multiple Tileset instances with a Tilemap, it just slows down rendering a bit on hardware targets.

bitmapData.draw for Tilemap is now on the TODO list

Another approach would be trying to implement the displacement map filter in shaders, if we figure that out, we could make it work using .filters


#7

For the time being, I’m going to defer getting a Tilemap-based draw system working in my game and just run it as an AIR project, though I’m trying to maintain compatibility across OpenFL/AIR and OpenFL/Windows while I do it so that it will be an easy transition if and when I want to do that.

In the meanwhile, there’s a couple of odd things I’m running into. First, the OpenFL/AIR version seems to run quite a bit slower than the normal AIR version (around 23fps instead of 50). I’m not sure why that would be the case, and I can’t find any individual function that seems to be causing it yet. Also, I have a system set up to run a separate worker to render non-interactive details and particle effects, and in the OpenFL version of the project that seems to produce glitchy results:

Also, I’m unclear on whether mp3 is currently supported in OpenFL/Windows, and if not that would certainly explain many of the issues I’ve had trying to get audio to work. If not, it puts me in a bit of a tricky situation, since ogg isn’t natively supported in AIR either, so I don’t really know what format to keep my audio assets in.


#8

Have you tried running Scout, to see if anything seems unusual, comparing the two versions?

Is there any way to (maybe?) get code I could use to compare, and see the issues you’re talking about? Happy to sign NDA, etc.

We haven’t supported MP3 due to the costly licensing, but just this year, the license expired, so adding MP3 is on our TODO list. In the meantime, HTML5 requires multiple file formats, usually, so keeping both OGG and MP3 might be a good idea


#9

Okay, I made the toolkit project that contains all of my particle code available for viewing:


It’s a bit byzantine because of the way I had to structure it to work with the AIR worker system (I didn’t originally have multithreading in mind when I wrote the class).

I didn’t want to make my entire main game project open, so I just pastebinned the relevant sections of code. Hopefully this will be sufficient: https://pastebin.com/sQLsw6Lp

I haven’t tried running scout, but I will next time I’m testing to see if anything interesting comes up. I’d heard mp3 was becoming more open so I assumed support would be forthcoming at some point, so I’ll probably just wait for that to happen, since writing a bunch of special-case code to either load ogg/mp3 depending on platform or manually decoding whichever isn’t supported on the platform that’s running seems like overkill, especially when OpenFL will probably see these changes long before I finish my project. I’m not really interested in releasing for HTML5, just trying to make a standalone game project.