[Solved] How to Get Full Screen Resolution

Help
#1

Hello Everyone,
I am new in using OpenFl and I had a problem with making my game full screen.
I use the following code to set the stage size and window size

Lib.current.stage.onWindowResize(width, height);
Lib.application.window.resize(width, height);

where width and height are my intended game size in window mode. I changed the display state to full screen so the stage increased and the game is in the upper left corner. I wanted to scale up the game and center it but to do that I need to know the current device resolution to scale everything up while keeping the aspect ratio so any help how to get the fullscreen resolution?

Thanks in advance

#2

You can use Lib.current.stage.displayState = StageDisplayState.FULL_SCREEN_INTERACTIVE; to make the application fullscreen. It does it all internally so you won’t need to worry about it. Native targets have issues with scaling at the moment, so bare that in mind when toggling fullscreen mode.

#3

Yeah I know that but I want the resolution of the full screen so I can rescale my game to cover the whole screen :slight_smile:

#4

Well, when you toggle it you can query with width and height while in Fullscreen :confused:
I don’t think there is any way to actually get the native screen resolution of the current device in Haxe without creating an extern with C++ code:

And then you can make an extern in Haxe:

private static var getDesktopResolution = System.load("SomeHeaderFile.h", "GetDesktopResolution", 2);

I’m actually not 100% sure if it’s header files or not. That System.load function is a call using Lime, not OpenFL.

It would be nice to have that function in OpenFL, though.

#5

Thanks :slight_smile: the current problem is when applying full screen and my window size is 800x600 every thing is placed at the upper left corner and the rest of the screen is black (stage.color).
I wanted to get the resolution to make the game centered and scaled up at least, I am sure there is a way for that as there is lots of famous PC games created using OpenFl and sure they handle that problem well :smile:

#6

I think when you set FULL_SCREEN, it scales the resolution to the full screen dimensions. If you handle Event.RESIZE from the stage, you can get the new stage.stageWidth and stage.stageHeight, then if you want to just scale your game, put it in a Sprite that you center and scale up or down. PiratePig has some code like that:

https://github.com/openfl/openfl-samples/blob/master/demos/PiratePig/Source/piratepig/PiratePigGame.hx#L397-L431

#7

Also if you want the screen resolution, you can use :

Capabilities.screenResolutionX Capabilities.screenResolutionY Capabilities.screenDPI

For my game I’m currently using that :smile:

stage.addEventListener(Event.RESIZE, resize);
stage.displayState = StageDisplayState.FULL_SCREEN_INTERACTIVE; 
function resize(e) 
	{
	}
#8

@singmajesty Thanks a lot I was doing the same but it didn’t work as I didn’t put the resize event to the stage but to my main sprite (sound stupid sorry for that)

@loudo I tried to get these values but they are 0, 0 may be they only work on mobile not PC :slight_smile:

#9

Hey! No problem. That’s why we have the forums :wink:

(if you run into something that works differently in Flash, though, like RESIZE, let me know) :slight_smile:

#10

I’m targeting the windows -Dlegacy and I have the values of Capabilities.screenResolutionX etc.

#11

@loudo Mmmmmm… that’s weird. May be its because of the target platform as now I am testing with Neko. or may be due to using -Dlegacy.

Just for curiosity why lots of people compile using -Dlegacy??

#12

Right now, Windows has more support on legacy than on next, and for some stupid reason OpenFL/Haxe thinks HTML5 should be a first class citizen, so we’re not going to get an update any time soon until HTML5 targets are optimised. Why? I really don’t know, you have to be dumb to think HTML5 is a good target to work with. HTML is designed for making websites, not games, so yeah… You can argue NodeJS, but even that is stupid.

I don’t really want to start a language war, but come on, you’ve got to admit JavaScript is a scripting language and will therefore be slower than C or C++. Go figure.

Also: Video on JavaScript and why it’s bad.

#13

It’s not like that exactly, desktop targets aren’t hold back by the htlm5 target any more than the html5 target is hold back by desktop targets.
What’s happening is that new features are added when a cross-platform solution is found.
So it takes longer, yes, but then you don’t have to ask yourself each time you use something what targets support it.
Which is the goal of the new version.

The html5 target, which is indeed planned to be supported as much as the other targets, has three modes: dom, canvas and webgl.
You can argue that the first isn’t made for game, indeed, but it works on low powered devices like low end tv.
The second and third are clearly technologies for games, and webgl has good performances since the gpu is leveraged.

Arguing about the quality of javascript is irrelevant here, as much as discussing assembler for the c++ target, you don’t use it you compile to it through haxe, so you don’t get the problems of coding in them.

And to end on the topic of speed know that using openfl isn’t even close to be the best choice, the haxe compiled c++ isn’t as good as handwritten code, and cffi calls are expensives.
But the benefits outweigh the performance cost and that’s why we love openfl/haxe :slight_smile:

1 Like
#14

There are problems in the legacy code that could not be solved by a simple patch.

Lime 2 and OpenFL 3 is a response to the growth pains, problems and deeply-rooted issues that were tied to the older codebase.

The new codebase:

  • Is currently running on the Wii U, Xbox One and PS Vita
  • Is primed to get custom shader support
  • Has a more accurate shape renderer than ever
  • Has support for hardware blending
  • Is one codebase for all platforms

I think it’s also much easier to debug and profile, I think :wink:

To be fair, Android or iOS support were not working in fairly recent releases (without using -Dlegacy) and Android still does not have JNI support, which many extensions rely upon.

For production means, “legacy” has been a good path to getting things out the door now, but I want to keep pushing on the new codebase until we surpass the areas of immaturity that are holding it back, and we can really benefit from the new architecture.

One of the things I love about the new architecture, everyone has their own favorites. One person will tell you it’s all about desktop, and that we should go to consoles. Another says it’s all about mobile. Still another wants Flash and HTML5 support for web projects.

OpenFL is one codebase (now) so we can fix problems once, and move on with life. I’m pretty tired of rewriting classes like EventDispatcher for different backend architectures :wink:

4 Likes