Yeah after sleeping on it, version specifics would be overkill. So I'd just
stick to the "families"
On Thu, Feb 12, 2015 at 9:26 AM, James Paige <b...@hamsterrepublic.com>
wrote:
> Having a single platform function that returns a constant doesn't sound
> bad, but it really isn't much less work, and we already have a few "running
> on *" commands, so I would prefer to stick to that.
>
> I would never want to get so specific as to return specific linux distros
> or specific windows versions. I think "runing on linux" and "running on
> windows" are more than adequate.
>
> The idea of different controllers being synced is worth remembering when
> we get around to improving gamepad support on WIndows/Mac/Linux but right
> now gamepad support on all those platforms lags miles behind the gamepad
> support on Android.
>
> ---
> James
>
>
>
> On Thu, Feb 12, 2015 at 2:26 AM, Michael Kidder <mkid...@gmail.com> wrote:
>
>>
>> How about something like running_on_platform and it returns an integer.
>> then make a bunch of constants you can add like os:Ubuntu12 os:SuseLinux3
>> os:Windows7 os:Windows8 os:Android4 etc . This would let you easily add
>> constants make a bit less cumbersome down the road when new platforms are
>> added.
>>
>> It may also be prudent to split out control options the same way and not
>> specifically tie them to the platform since 360 controllers can be used on
>> Linux, PS4 controllers can be used on Android, PS3 controllers can be used
>> on PS4, etc etc.
>>
>> And yes, it would nice to only have to make one game that auto changes
>> internally for the platform, for "Exit to Windows" type stuff.
>>
>> this is just a starting point, you'd have to hammer it a bit to make sure
>> it wouldn't get convoluted down the road.
>>
>> On Mon, Feb 2, 2015 at 3:42 PM, James Paige <b...@hamsterrepublic.com>
>> wrote:
>>
>>>
>>> On Fri, Jan 30, 2015 at 4:35 PM, Ralph Versteegen <teeem...@gmail.com>
>>> wrote:
>>>
>>>> Cool! What are the differences between those platforms that affect the
>>>> FreeBasic/C/Java code?
>>>>
>>>
>>> The main differences between the different android microconsoles is that
>>> the each have their own store. OUYA's is the only store we report right
>>> now, but at the very minimum I want to make the others disable the
>>> "Purchasing" feature, rather than incorrectly falling back on the Paypal
>>> store backend.
>>>
>>> The other big difference is button labelling. OUYA has buttons labelled
>>>
>>> (Y)
>>> (U) (A)
>>> (O)
>>>
>>> But Gamestick and FireTV label them
>>>
>>> (Y)
>>> (X) (B)
>>> (A)
>>>
>>> And Xperia Play labels them
>>>
>>> (□)
>>> (△) (O)
>>> (X)
>>>
>>> So I will want to update the ${B#} buttonnames feature to support each
>>> of those consoles.
>>>
>>>
>>> Then there are some controller variations to deal with.
>>>
>>> OUYA and Gamestick both handle the controller the same way, which
>>> appears to be the "Correct" way.
>>>
>>> Fire TV Controller (but not remote) does everything correct except for
>>> the D-Pad, which apparently works as arrow keys in a fake keyboard rather
>>> than joystick buttons. This causes the Fire-TV controller D-pad to be
>>> completely ignored by sdl_android.
>>>
>>> The Fire-TV remote, on the other hand, has a round d-pad that works
>>> perfectly with sdl_android. It has buttons that map to confirm and cancel,
>>> so all simple ohrrpgce games with default controls are playable, but
>>> anything like Tim-Tim or Vorpal Florist that needs more buttons is mostly
>>> out-of-luck.
>>>
>>> Xperia play does most of the controller normally, except for the X and O
>>> buttons. Instead behaving like gamepad buttons, they behave like android
>>> buttons. X maps to "D-Pad center" and O maps to "Back"
>>>
>>> For OHRRPGCE games, this works out pretty well, since the default
>>> actions for those buttons happen to be the same as the default gamepad
>>> button mappings for the buttons in the same positions.
>>>
>>> Also, Xperia Play has L1 and R1 shoulder buttons, but not L2 and R2.
>>>
>>> Yes, we should have all of those commands, including ones for checking
>>>> for Windows, Mac, and Linux, partially because of differences in
>>>> control schemes. Not all Mac users have a two-button mouse for example
>>>> (I don't), so right clicking shouldn't be used, and they have
>>>> different keyboards. (Of course this isn't ideal, as you might be
>>>> running Linux or Windows on a Mac, but I think figuring out how to do
>>>> keyboard detection for a remote possibility is not worth the effort.)
>>>> Differences between Linux and Windows are subtler but do exist. We
>>>> shouldn't assume to know every 'valid' reason to want to know the OS.
>>>> For example you might want to write "Exit back to Windows"
>>>>
>>>
>>> Yeah, that sounds good. I will go ahead and implement those. I think I
>>> would like them to *only* return true when "running on desktop" is true.
>>> For example, Android is technically mostly linux, but I don't think I would
>>> want "running on linux" to return true there.
>>>
>>>
>>>>
>>>> It would be nice to distribute some images (or slice collections) of the
>>>> various controller/keyboards for people to use. It might make people
>>>> at least think about whether their game could work on another
>>>> platform.
>>>>
>>>
>>> That is a good idea. I'll be making such images anyway for Baconthulhu,
>>> so I will dump them somewhere in the "Import" directory.
>>>
>>>
>>>> zzo38 suggested a commandline switch to change the OS the engine is
>>>> claiming to run on, which sounds useful. It's also easy to find out
>>>> which games actually use these commands using scanscripts.py.
>>>>
>>>
>>> That sounds fine. Making the engine lie to the "running on *" family of
>>> commands could be handy for testing and debugging scripts.
>>>
>>> ---
>>> James
>>>
>>>
>>>
>>>> On 31 January 2015 at 07:57, James Paige <b...@hamsterrepublic.com>
>>>> wrote:
>>>> > I am still pretty opposed to any type of external resource access.
>>>> >
>>>> > Also, I am not familiar with "SSI Gold Box games", but if by
>>>> "continuing
>>>> > sagas" you are talking about the ability to import save data from
>>>> one game
>>>> > into another, for things like keeping the same characters in a
>>>> sequel, I am
>>>> > open to that, but it would be totally unrelated to platform detection.
>>>> >
>>>> > On Fri, Jan 30, 2015 at 10:49 AM, Timothy Bell <raek...@gmail.com>
>>>> wrote:
>>>> >>
>>>> >> I can see this being useful for when we evolve to a point where
>>>> games need
>>>> >> more external resources than can reasonably fit in the rpg format.
>>>> Plus,
>>>> >> it'd be another step closer to supporting continuing sagas (think
>>>> the old
>>>> >> SSI Gold Box games)
>>>> >>
>>>> >> On Jan 30, 2015 11:23 AM, "James Paige" <b...@hamsterrepublic.com>
>>>> wrote:
>>>> >>>
>>>> >>> So we currently have some platform detection plotscripting commands
>>>> >>> "running on desktop" "running on mobile" "running on console"
>>>> >>>
>>>> >>> These are needed because of the differing control schemes.
>>>> >>>
>>>> >>> Now that I have been working on making the OHRRPGCE compatible with
>>>> other
>>>> >>> consoles besides OUYA (GameStick, FireTV, Xperia Play) I know I am
>>>> going to
>>>> >>> need more detailed console platform detection in the freebasic code.
>>>> >>>
>>>> >>> I am wondering if I should also expose these more detailed platform
>>>> >>> detection commands to plotscripting?
>>>> >>>
>>>> >>> For example, in Crypt of Baconthulhu, I have a help screen that
>>>> shows up
>>>> >>> when "running on console" is true, and it shows an actual sprite of
>>>> an OUYA
>>>> >>> controller.
>>>> >>>
>>>> >>> I would love to have the game show an image of the correct
>>>> controller for
>>>> >>> whatever system it is running on. If you google images of an OUYA
>>>> >>> controller, and a Gamestick controller, and a FireTV remote, you
>>>> will see
>>>> >>> the big differences (FireTV supports a real controller, but most
>>>> users only
>>>> >>> have the remote, which is very minimal)
>>>> >>>
>>>> >>> Is there a downside to having a "running on gamestick" command?
>>>> >>>
>>>> >>> And that leads me back to something I argued strongly against a few
>>>> years
>>>> >>> ago, but now I am rethinking. Is there any real harm to having
>>>> "running on
>>>> >>> windows" "running on mac" "running on linux" commands? I really
>>>> don't see
>>>> >>> them being useful to any games in any way I can think of, but is
>>>> that enough
>>>> >>> reason to leave them out?
>>>> >>>
>>>> >>> Just thinking out loud, and hoping for some feedback.
>>>> >>>
>>>> >>> ---
>>>> >>> James
>>>> >>>
>>>> >>> _______________________________________________
>>>> >>> Ohrrpgce mailing list
>>>> >>> ohrrpgce@lists.motherhamster.org
>>>> >>>
>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>> >>>
>>>> >>
>>>> >> _______________________________________________
>>>> >> Ohrrpgce mailing list
>>>> >> ohrrpgce@lists.motherhamster.org
>>>> >>
>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>> >>
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Ohrrpgce mailing list
>>>> > ohrrpgce@lists.motherhamster.org
>>>> >
>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>> >
>>>> _______________________________________________
>>>> Ohrrpgce mailing list
>>>> ohrrpgce@lists.motherhamster.org
>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>
>>>
>>>
>>> _______________________________________________
>>> Ohrrpgce mailing list
>>> ohrrpgce@lists.motherhamster.org
>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>
>>>
>>
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce@lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>
>>
>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce@lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
>
_______________________________________________
Ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
