You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Operating System: ArchLinux
Browser/Download: Download
Demo/Full? : Demo Version
Version # : DQ1
Case 1
Steps to Reproduce:
Connect 2 (working) monitors to computer
Launch game
Open Settings > Video
Change to fullscreen
What I expected to Happen:
The game will use my primary monitor, and draw all over it, and only over it.
What happened instead:
The game used my primary monitor, hid the option to select resolution, did not scale the menu, and I had to terminate the game cause could not interact with the GUI.
Case 2
Steps to Reproduce
Connect 2 (working) monitors to computer
Launch game
Open Settings > Video
Change resolution to native resolution of primary monitor
Change to fullscreen
What I expected to Happen:
The game will use my primary monitor, and draw all over it, and only over it.
What happened instead:
The game used my primary monitor, hid the option to select resolution, had correct scaling of the GUI, but GUI was centered on the "virtual display" (both monitors as one display) - so I have basically seen only the left half of the GUI, but this time I could interact with it.
Working workaround
Disable secondary monitor before launching the game.
Okay I reproduced it as well as a bunch of other weird behavior.
I think on linux, it returns the size of the entire connected series of desktops, as the current resolution of the main window, or something. I think the game thinks two 1920x1080 monitors is 3840x1080 monitor, and so that's where the weird centering comes from. This doesn't seem to happen on mac or windows.
We're trying to verify whether it just requires the developer (ie, me) to sort out their dependencies, or whether it requires the end user to have specific libraries installed, too.
Hopefully it's just me. The way to test this is for you to try the next build after I get it out. If it's fixed for you, and you haven't messed with your libraries or anything since the last version, then we're good.
Perfect test -- try the newest version, see if it works. Try the last version before that, see if it breaks. If so, we're golden.
I'll provide you links to the newest version and the version right before the fix here in a little bit.
I think on linux, it returns the size of the entire connected series of desktops, as the current resolution of the main window, or something.
You are almost correct, here is example output from xrandr on my machine:
Screen 0: minimum 8 x 8, current 3600 x 1080, maximum 16384 x 16384
VGA-0 disconnected (normal left inverted right x axis y axis)
DVI-D-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 521mm x 293mm
1920x1080 60.00*+
1680x1050 59.95
1440x900 59.89
1280x1024 75.02 60.02
1280x960 60.00
1024x768 75.03 70.07 60.00
800x600 75.00 72.19 60.32 56.25
640x480 75.00 72.81 59.94
HDMI-0 disconnected (normal left inverted right x axis y axis)
DVI-D-1 connected 1680x1050+1920+0 (normal left inverted right x axis y axis) 474mm x 296mm
1680x1050 59.88*+ 59.95
1440x900 59.89
1280x1024 75.02 60.02
1280x960 60.00
1152x864 75.00
1024x768 75.03 60.00
800x600 75.00 60.32 56.25
640x480 75.00 59.94
Screen 0 is an X-Server "screen" - one big virtual deskop - one per each instance of X-Server. While VGA-n,DVI-n, etc. are the connected "monitors" (or "outputs") - one per physical display - each one is showing some area of the "screen".
Yep, looks like still happening in 0.3.6. Here is the result of excessive testing:
Called from ApplicationMain::main ApplicationMain.hx line 155
Called from ApplicationMain::create ApplicationMain.hx line 67
Called from lime.app.Application::exec lime/app/Application.hx line 221
Called from lime._backend.native.NativeApplication::exec lime/_backend/native/NativeApplication.hx line 129
Called from lime._backend.native.NativeApplication::handleRenderEvent lime/_backend/native/NativeApplication.hx line 346
Called from lime.app.Event_Void_Void::dispatch lime/app/Event.hx line 145
Called from *::_Function_2_1 lime/app/Application.hx line 110
Called from lime.app.Application::render lime/app/Application.hx line 750
Called from openfl.display.Stage::render openfl/display/Stage.hx line 649
Called from openfl.display.DisplayObjectContainer::__broadcast openfl/display/DisplayObjectContainer.hx line 355
Called from openfl.display.DisplayObject::__broadcast openfl/display/DisplayObject.hx line 251
Called from openfl.events.EventDispatcher::__dispatchEvent openfl/events/EventDispatcher.hx line 237
Called from flixel.FlxGame::onEnterFrame flixel/FlxGame.hx line 546
Called from flixel.FlxGame::step flixel/FlxGame.hx line 704
Called from com.leveluplabs.tdrpg.Main::update com/leveluplabs/tdrpg/Main.hx line 1538
Called from flixel.FlxGame::update flixel/FlxGame.hx line 724
Called from flixel.FlxGame::switchState flixel/FlxGame.hx line 639
Called from com.leveluplabs.tdrpg.State_OptionsHolder::create com/leveluplabs/tdrpg/State_OptionsHolder.hx line 24
Called from com.leveluplabs.tdrpg.TDRPGState::create com/leveluplabs/tdrpg/TDRPGState.hx line 68
Called from flixel.addons.ui.FlxUIState::create flixel/addons/ui/FlxUIState.hx line 115
Called from com.leveluplabs.tdrpg.TDRPGState::createCursor com/leveluplabs/tdrpg/TDRPGState.hx line 152
Called from flixel.addons.ui.U::loadMonoScaledImage flixel/addons/ui/U.hx line 1338
Error : Error! Scale must be positive & > 0! (Scale was = 0)
Activity
larsiusprime commentedon Dec 18, 2015
Thanks, I'll look into what I can do about this and see if I can reproduce.
larsiusprime commentedon Dec 23, 2015
Okay I reproduced it as well as a bunch of other weird behavior.
I think on linux, it returns the size of the entire connected series of desktops, as the current resolution of the main window, or something. I think the game thinks two 1920x1080 monitors is 3840x1080 monitor, and so that's where the weird centering comes from. This doesn't seem to happen on mac or windows.
Very strange.
larsiusprime commentedon Jan 8, 2016
Narrowed it down to issues in SDL, working on a fix:
openfl/lime#667
larsiusprime commentedon Jan 8, 2016
Found it and fixed it. Works in my build now, I'm going to put out an updated build.
All it took was this:
native-toolkit/libsdl#5
We're trying to verify whether it just requires the developer (ie, me) to sort out their dependencies, or whether it requires the end user to have specific libraries installed, too.
Hopefully it's just me. The way to test this is for you to try the next build after I get it out. If it's fixed for you, and you haven't messed with your libraries or anything since the last version, then we're good.
Perfect test -- try the newest version, see if it works. Try the last version before that, see if it breaks. If so, we're golden.
I'll provide you links to the newest version and the version right before the fix here in a little bit.
larsiusprime commentedon Jan 8, 2016
Version 0.3.7 (fixed):
https://drive.google.com/file/d/0B82nNNq_hucHZm1sZWpzRWdub2c/view?usp=sharing
Version 0.3.6 (before the fix):
https://drive.google.com/file/d/0B82nNNq_hucHU0VXRkZUeEUwWDQ/view?usp=sharing
larsiusprime commentedon Jan 8, 2016
Confirmed fixed:
https://twitter.com/earl_malmrose/status/685523330401615872
ivanpu commentedon Jan 11, 2016
You are almost correct, here is example output from
xrandron my machine:Screen 0is an X-Server "screen" - one big virtual deskop - one per each instance of X-Server. WhileVGA-n,DVI-n, etc. are the connected "monitors" (or "outputs") - one per physical display - each one is showing some area of the "screen".P.S.
Downloading archives now for the test :)
ivanpu commentedon Jan 11, 2016
Yep, looks like still happening in 0.3.6. Here is the result of excessive testing:
Works good in 0.3.7 😄
larsiusprime commentedon Jan 11, 2016
Perfect. Closing.