I am trying to lay some groundwork for a game, such that, no matter what a window is resized to on desktop, or the orientation is set to on mobile, I make the most use of all the available screen real estate. I.e. no black bars, but also no stretch-resizing.
This is obviously not a unique problem, and despite reading and trying everything I could think of, I do not seem to be able to accomplish this simple task on resize:
- set a background sprite to cover the whole visible area with a certain colour
- resize a logo sprite to the width of the visible area, and align it with the top edge
I am working with StageSizeScaleMode based on suggestions on this forum and/or the haxeflixel github issues, but have also tried a custom scaleMode. The problem is that I can’t see where exactly the problem lies in the existing StageSizeScaleMode.
I have sample code and screenshots detailing several problems I’m experiencing with up-to-date release versions of haxe, haxeflixel, and openfl: https://github.com/GimmickyApps/ScaleHuh
Thanks for any help/tips, and your patience, in advance.
(I have my eye on player-03’s advanced-layout, but seeing as I couldn’t get this simple thing to work first, I haven’t tried it yet.)
We currently do not support automatic stage resize modes, the stage stageWidth and stageHeight will increase when a window is resized. If your code (or a framework you rely upon) handles the Event.RESIZE events, it can use the updated stage size to render at the new size 
Let me know if you need help figuring it out!
There are some other options, though. You can simulate StageScaleMode.SHOW_ALL, there’s Joshua’s old Layout library, and HaxeUI seems to offer scaling as an option too.
I think I didn’t explain quite well enough. I want manual resizing, and HaxeFlixel seems to force some amount of automatic resizing, but not in the way I would like. I think if you have a look at the github link I posted and look at the screenshots in the issue it should be a bit more clear, hopefully
Thanks for the offer! 
Is SHOW_ALL something that can be used with HaxeFlixel in particular, though? I had already read that thread, but it seemed to be if one were using OpenFL directly and not with HF on top. I’ll look into the other two links too, but meanwhile, I heard back on a few issues I posted on the HF github, and it sounds like they were already solved in the latest dev branch of HF, which I hadn’t tried yet. I’m just waiting to hear back on a couple questions about switching to the dev branch and then I’ll try it out…if that irons out these problems then advanced-layout is my next stop.
I looked at what Flixel provides, and it turns out “SHOW_ALL” is equivalent to Flixel’s RatioScaleMode (which happens to be the default). Never mind that then.
Question: what exactly are you looking for here? Would you be happy with RatioScaleMode if you could make the background fill the screen? The catch would be that the UI elements would still be confined to a smaller rectangle. So if you put the pause button in the top-left corner, it would move away from the edge depending on the window dimensions.
The reason I ask is because there may be a simple way to handle this, if that catch is acceptable. But if you want your UI to expand to fill the screen, the individual elements are going to have to move independently of one another, so you’re going to have to specify what you want each object to do.
My library is designed to make this easier, but you could do it yourself without too much trouble. Add a listener to FlxG.signals.gameResized, and position your UI elements based on the new dimensions.
I want to be able to make use of the space with a custom layout, just what your library is designed for.
E.g. on a typical phone in portrait mode, my default-resized landscape game would be very small, to the point of being unplayable. I’d like my game to be intelligent enough (and I know I have to add this intelligence manually, because it’s very game-specific) to split the screen into two (one very small landscape showing everything and the rest a zoomed-in FlxCamera showing what the player is currently working on and would need finer control over.) This would make the difference between an immersive experience that adapts to the player’s preference at any given moment vs something that wastes screen real estate even in landscape mode just because I happened to develop for a different aspect ratio.
I.e. when you said, “you’re going to have to specify what you want each object to do,” that is precisely what I want to be able to do. So, what scale mode do you normally use with your library? With StageSizeScaleMode I am experiencing this particular bug which makes layout very difficult:
Unfortunately, upgrading to the dev branch of HaxeFlixel does not solve this particular one.
Thanks for your help player-03!
(The solution was to call updateHitbox() on any sprites after a resize, as you can see in the linked-to issue.)
