dorkster
commented
8 years ago But this also means that the default program config (keybindings.txt, mods.txt, settings.txt) need to be found inside the OPK and can't be altered.
I'm not exactly clear why default versions of these files need to be located on the filesystem. If they are not present in our write directory (~/.config/flare/), the engine will generate them and write them there when appropriate (config menu save or game exit).
Arbitrarily disabling menu options,,,
We have refactored the configuration menu to use a bit of polymorphism to handle separate platforms. We start with GameStateConfigBase, which only displays the Audio, Interface, and Mods tabs. Then there's GameStateConfigDesktop, which provides Video, Input, and Keybindings tabs. From what I can tell, using just GameStateConfigBase would be sufficient for the GCW-Zero (e.g. use an #ifdef)
Minicore
The minicore mod hasn't been updated for some of the new Empyrean content.
This might be a stupid idea, but I have a request. Could you try changing required_width and required_height in mods/fantasycore/engine/resolutions.txt to 320 and 240 respectively? You will also might need to change the resolution setting to 320x240 in ~/.config/flare/settings.txt for this to work, but it should scale everything down to 320x240 without needing the minicore mod. Of course, this may not perform well at all, since it'd be using the full size game assets. I'm just curious.
Navigating the inventory can be tedious, for example, as the items equipped by the player cannot be navigated in a grid pattern - pressing left or right will not switch the selection to the visually adjacent item, but rather cycle to the next node in the internal logic.
I agree that the joystick controls need some polishing. I think we could accomplish what you described for menu navigation:
- Widgets get stored in a list. Widgets themselves contain their X/Y coordinates. (this is already done)
- Instead of simply traversing the list, have a function that will find the nearest Widget in a given direction from an origin point (usually another widget X/Y)
There are some other things that could be cleaned up. For example, we shouldn't worry about widget focus to advance NPC dialog (we don't for mouse/keyboard players).
zear
Goal of this issue
This issue is meant for a general discussion/brainstorming about changes necessary to support the GCW Zero platform. It will also discuss concepts beneficial for support of other handheld and/or joystick controlled platforms. The ultimate goal is for the GCW Zero related changes to be accepted upstream.
About the platform
GCW Zero is an opensource handheld running GNU/Linux. More about this hardware and its specs can be read at: http://www.gcw-zero.com/specifications
Let me highlight just the most important details:
Current status
A preliminary build of Flare can be run on GCW Zero without any code changes required.
Build instructions:
cmake -DCMAKE_TOOLCHAIN_FILE=/opt/gcw0-toolchain/usr/share/buildroot/toolchainfile.cmake .makeTo make it run: Currently the config needs to be manually edited before Flare can launch at the 320x240 resolution mandatory for this platform. Manual config changes for button mapping are also necessary.
Game running on GCW Zero:
Issues
Config path and default settings
GCW Zero is targeting a general user base who have no knowledge or desire to hack around any config files. The software comes in form of OPK packages - read-only SquashFS images containing all the game data. Think of it as CD ISO images. More about the format at: http://wiki.gcw-zero.com/OPK
Upon selecting a game in the program list, the OPK is mounted, set as
$PWD(current directory) and the game binary executed. Because the format is read-only, any user generated data needs to be written to$HOME(Flare already supports this just fine). But this also means that the default program config (keybindings.txt,mods.txt,settings.txt) need to be found inside the OPK and can't be altered. This requires for the program logic to check for any existing user config before the default it loaded:~/.config/flarefor keybindings.txt, mods.txt and settings.txt./~/.config/flareIt is important that the config found in
./is only read as a fallback and not during regular program work. For example, users should be able to overwrite old mods with updated versions of them without any collision with the ones shipped with the game OPK.Arbitrarily disabling menu options
As GCW Zero does not utilize all the game features, such as resolution change or full screen mode (there is no window interface, game is always on the screen), there should be a way to disable access to these options. Moreover, some options can have permanent consequences, ie. changing the screen resolution to an unsupported value might prevent the user from ever launching the game again and force him to manually edit the game config.
There are several ways to implement this, such as:
Joystick-only game navigation
A lot of good work has already been done to support players who want to play exclusively with a gamepad, however game interface nagivation is still far from comfortable. Navigating the inventory can be tedious, for example, as the items equipped by the player cannot be navigated in a grid pattern - pressing left or right will not switch the selection to the visually adjacent item, but rather cycle to the next node in the internal logic. I understand this behaviour cannot be hardcoded, because flare-engine supports multiple games and each might implement the inventory menu in a different way.
This could be dealt with by implementing a way for the game developer to mark which node corresponds to the left/right/top or bottom neighbour in the layout of his choice. This would also work well in all the other sort of GUI screens.
Minicore
Being limited to 320x240, GCW Zero must depend on the Minicore mod. So far I don't see any regressions in this mod in the current build of Flare, but I just want to highlight that GCW Zero support would require to keep this mod up to date with the "big" version of the data files at all times.
Testing
I understand that at least two regular Flare developers have (or at one point had) a GCW Zero unit. If they are interested to help me out in the porting and/or testing efforts, that would be most welcome.
For people without a unit, there is a simple way to test the game in approximate conditions: 1) Launch the game in 320x240 2) Use Minicore 3) Use a gamepad
Final thoughts
I know that the main target of Flare is a computer with a large screen, mouse and keyboard and that GCW Zero might be an exotic platform for many, but nevertheless I'd like to invite others to this discussion to see your thoughts on some of the problems I have highlighted, or generally about the handheld support in Flare.