iOS: Is there a way to have stage size in "rendered pixels" instead of points?

Taking an iPhone 6 as example: instead of getting a stage size of 667x375, is it possible to use the rendered pixels screen size (1334x750) ?

Thanks!

The OpenFL stage width/height should be in pixels, while the Lime window should have a size in points, along with a scale property.

I’ve seen on iOS, though, that sometimes it doesn’t use the “retina” resolution until after dispatching a resize

1 Like

Thanks!

Is this the behavior with version 3.6.1 too?

I’m not sure, I would watch for resize events, and make sure you are not locking a specific width/height in your XML file

Hey Josh, unfortunately no dice - regardless of any adjustments i can only detect screen size in iPhone 6 as 667x375, and it appears to affect rendering quality too. For instance, pixel fonts become unreadable at this resolution, and scaling it up won’t work because it’ll keep rendered objects as they were initially.

When starting the application it receives Event.RESIZE two times, but in both of them the resolution is the same. Tried it with different settings as suggested to no avail.

This looks like something at Lime / SDL level - any ideas where in the code i can look for a possible solution?

Thanks!

P.S.: Other HaxeFlixel users have been affected as well: https://github.com/HaxeFlixel/flixel/issues/2049#issuecomment-289697712

Could you try <window allow-high-dpi="true" /> in your project.xml?

Apparently no effect with or without the tag. Here’s my what my window tags look like:

	<window width="0" height="0" fps="30" background="#000000" hardware="true" vsync="true" />
	<window allow-shaders="true" require-shaders="true" if="cpp"/>
	<window allow-high-dpi="true" />
    <window if="mobile" orientation="landscape" fullscreen="true" width="0" height="0" />

Looks like this feature wasn’t part of OpenFL 3 (https://github.com/openfl/openfl/blob/openfl3/templates/haxe/ApplicationMain.hx)

Oh, OpenFL 3. This was improved with newer Lime releases, but is not fully supported in the older code base. There might be some workarounds (like forcing ALLOW_HIGH_DPI in the C++ window creation code), but it may be more complex than that :frowning:

How would i go about trying that (forcing ALLOW_HIGH_DPI) - I’m looking at SDLWindow.cpp and the only mention to dpi is here (lines 43…47):

if (flags & WINDOW_FLAG_ALLOW_HIGHDPI) {				
	sdlFlags |= SDL_WINDOW_ALLOW_HIGHDPI;	
}

There’s also a commented out mention to SDL_WINDOW_ALLOW_HIGHDPI in SDL2Stage.cpp line 1561:

//requestWindowFlags |= SDL_WINDOW_ALLOW_HIGHDPI;

Any ideas on how to proceed to test this out? Thanks! :slight_smile:

You could try and make these always true, and rebuild the native binary, and see whether that makes a difference. Does Event.RESIZE ever trigger from the stage?

EDIT: The problem is just that we need to use git recursive in order to get other library dependencies. Problem solved.

Hmmm, i’m not able to rebuild lime due to the following error:

Error: Could not find include file "lib/cairo/files.xml"

This is using version 2.9.1 downloaded from GitHub and simply running lime rebuild windows.

Any idea why this file is not included / how to best solve it?

Is it a clone of the GIT repository? We don’t include these files in haxelib releases due to size

Then try git submodule init && git submodule update, or --recursive on the first clone :slight_smile:

Changed cpp code to hardcode high dpi enabled and it worked! Although i’m not sure if there was something else involved (i.e. using git version vs haxelib release).

Anyway, now resize events correctly show the device high-dpi stage size (2048x1536 for iPad, gonna test iPhone 6 later, but pretty sure i’ll work there also).

Thanks for the help Josh!

1 Like