Do you work with width/height or scaleX/Y when resizing it in the event callback? The reason I am asking is to figure out the best way. Do I have to worrry about other transformations when scaling for the new stae size?
Btw stage.scaleMode produces emtpy screen on Android, but works on Linux.
Assuming your app has a hard-coded native resolution:
Listen for the screen resize event
Measure the aspect ratio of the current device window (stageWidth/stageHeight).
create a new container that has the dimensions of your native resolution, but stretch the height or width to match the same aspect ratio as the device window. Note that we are just matching the aspect ratio for now, not blowing up to the full screen size.
fill the container with an empty black bitmap
center your entire game inside of this container (this also assumes that your game is contained within its own sub-container).
THEN, just scale that container upward/downward to match exact width and height of the device’s window. because your game is nested inside of the container, it will maintain your native aspect ratio while expanding to fit the device window.
I am targeting Android and at this point I feel like probably the best way is to create the sprites and images with the proper aspect ratio and the placements from the get go. This resizing afterwards sounds more like a desktop way. Am I wrong on this when it comes to mobile? Get the aspect ratio and use it as a leverage to place things properly in the beginning (working with percentages rather than absolute coords) unless one does a bitmap scale as @afroninjadotcom described, at least that is what I understood from his post.
@afroninjadotcom
Please correct me if I misunderstood your points.
Create a new bitmap in the main sprite, copy the scaled current bitmap rendered in the current sprite to the new empty bitmap. And remove the old bitmap.
I implement the above logic on all major targets- flash, desktop, android, and ios.
Don’t get me wrong there are certainly advantages to targeting different resolutions in a dynamic fashion but it’s always been a complete headache for me. I think it applies to functional apps, but for games it’s usually easier to just scale your entire output accordingly (just my opinion though)
I don’t copy any bitmaps- I place my entire game inside of a sprite, then place that sprite into an adjustment container. I then scale the adjustment container to fit the desired resolution.
AfroNinja: what’s the difference between your implementation and StageScaleMode.SHOW_ALL? The only difference I can find is that your implementation would let you center it. And even then it would be easier to make a workaround to center it:
I guess nothing, I didn’t realize it would be that easy to center with the SHOW_ALL value
also didn’t realize you could move the stage itself with Lib.current.x/y.
It’s not the actual stage. Lib.current is a movie clip created and managed by OpenFL, and your Main class is automatically added as a child of it (except in Flash).
So unless you add children directly to the stage, Lib.current can serve as a parent of everything in the display list.
@player_03
I tried using StageScaleMode for Android but it gives me a blank screen, but it works on Linux Desktop. Maybe not supported on Android?
@afroninjadotcom
Do you have a basic code to show how you do it? I have just started using OpenFL (and no prior as experience), so I do not know all the nitty gritty details of OFL at the moment.
progress: I have some actual text on the images, so removing them stopped the segfault which is weird. But now changing the size turns the window into an empty screen.
progress_2:
ok now it seems like all the values are returning inf
Main.hx:115: 1,1
Main.hx:157: resizing,inf,inf,inf (stageScale, stageScaleX,stageScaleY)
bizarre I will infestigate more
Sorry about the fuss, I had 2 issues. I had to initiate the nominals and then cleaning and making a fresh build of linux target solved the segfault. No idea I seem to get segs here here there and clean build solves that issue.
Your solution is perfect for me for now, Thanks again for your dedicated solution.
So the resizing seem to work with Android with couple issues. But the biggest issue to me is that the mouse touch event (mousedown moving) moves in an bizarre fashion. For example I click on an image then start moving it but the image moves fast to its left or right as in it is accelarating when it moves from the click center. Linux build has the same issue`.
This was not the case when I was using a non resized Window. It is peculiar.
You’re probably handling the mouse event incorrectly. I assume you’re checking either e.mouseX and e.mouseY or stage.mouseX and stage.mouseY, right? Instead of that, you want to use image.parent.mouseX and image.parent.mouseY.
It’s not in the documentation, but in Flash, you can center the stage by setting stageAlign = "". However, Haxe wants you to use an enum value, so you have to use untyped to make it ignore that.
onResize(null) is to resize the stage instantly. On Android, the stage will start at a different width and height, but you won’t get a RESIZE event until they rotate the device.