Jump to content

Wherigo Foundation: WF.Compiler and WF.Player


charlenni

Recommended Posts

Ok, it seems, that I am the first, who want to present his project.

 

In Autumn 2012 I thought about, what is the problem with Wherigo and what part is stopping us from developing Wherigo further. The first thing I found was the compiler, which creates GWC from GWZ files. So I started to develop such a compiler (not a difficult thing) in C (a difficult thing for me). The first trough was very buggy and the interest of the german community was poor. So I started again and ported it to Java. When I was nearly ready, I wrote to RangerFox, if he would be interested to see it. He was, but did all his work in C#, so I started again with a new language.

 

When I could compile GWZ files, I checked, what the next useful tool could be for the community. I encountered, that the biggest problem are the different players. If a cartridge works for one device, it could stop on another one. So I decided to develop a player, which acts the same way like the emulator from Groundspeak and which should have as much code as possible identically on all platforms. And we should have the code, so we could develop Wherigo further. At this time I only found the Xamarin C# and Mono implementation, which works an all major platforms: Android, iOS and Win Phone. So I started to develop a player in C# with .Net. I bought a Mac and the Xamarin licences and start to develop for iOS and Android. A realy big project for me, and I am still not at the end.

 

Meanwhile RangerFox brought together a group of people, who are very interested in creating plans to restart Wherigo again. A constant in and out of e-mails was the result. Sometimes I lost the belief, that I do the right, but I hope, all will come to a good end and RangerFox gets Groundspeak on board to support this project.

 

But enough history, now what is done and what has to be done.

 

WF.Compiler

 

The compiler was my first C# and .Net program I ever wrote. And so it looks. In the moment it is possible to compile GWZ files and to create GWC files. The formats are hard coded and there is no modularization. WF.Compiler uses SharpLua for parsing the Lua file and compiling it. WF.Compiler could handle UTF-8 files and create the correct special characters for the different devices.

 

ToDo

- Modularization of the code

- Better parser for Lua files

- New input and output file formats for the different builders and players

- Stand alone compiler with command line interface or as DLL

- Testing

- New features like resizing images for the downloading device or convert sound file formats

 

WF.Player

 

The player consists of three parts: the Wherigo library, the Core/Engine and the User Interface.

 

For the Wherigo library I took in the first step the original Groundspeak Emulator library. RangerFox talks with Groundspeak, if it is possible to use it. If not, there is an open source library from Jakuje, which did the same. Until Groundspeak decides what to do, there is only a compiled version of the library in the source. The library for the Emulator and Garmin devices is the same.

 

The Core handles all things, that are the same on all platforms. Load, save, start and stop the cartridge, changes of the position and so on. It works with the official Lua 5.1.5 implementation in C (iOS) or a port to C# (Win Phone and Android). It is possible to port the Android version also to the C code, because it is much faster. This part is ready, but should be tested. Until now, there is no ready User Interface for it. The iOS player was ready, before I redesigned the Core, so I had to change it. So it waits for testing. The main goal was to have a Groundspeak Emulator and a Garmin clone of the same behavior. So the Core loads and saves original save files from this devices. Although the log files are identically.

 

The User Interface is developed with Xamarin tools for iOS and Android. The Win Phone development is made by Mangatome. I think, he could tell you better about it. For iOS the player works, but there is nothing outside the player, so that only local stored GWZ files could be played. On Android it is vice versa: you could download cartridges via API from the website, but the player UI isn't ready. So there is much work to do for a stable player, which runs on all platforms.

 

ToDo

- Get ok from Groundspeak to use the original Wherigo library or test the new one from Jakuje

- Testing of the Core and remove bugs

- Convert for async working

- Design of the UI outside the player for iOS and Android

- Common map object for all platforms with offline maps, which could be used on all platforms. Would be a nice feature to download the cartridge and all open source maps, which you need to play the cartridge. Looked at GMap, which have the offline feature by using SQLite databases, but it only works with WinForms and WPF.

- And much more

 

The goal is to have a player environment, which works on the major platforms, behave there the same way, and we could use for further developments of the game.

 

All the code can be found on GitHub.

 

It would be nice to have some others, which could help. If you are a C# programmer or even have one of the Xamarin tools licensed, this would be perfect. If you could create good UI for iOS or Android, that would also be helpful. You don’t have to use the Xamarin tools, you could do it also with the original tools. If you are interested in any part, please contact me. Any support is appreciated.

 

Best regards,

Dirk (Charlenni)

Link to comment

I'm under the impression the compiler works with Garmin devices because the Wherigo architecture hasn't changed. The player app itself, however, is not for Garmin devices and will not be for Garmin devices. The root problem, actually, is that Garmin would have to code their own player for their GPSr operating system and come out with bug fixes. Garmin has already demonstrated they're not interested in doing that. Until Garmin comes out with a GPSr that uses an app store, Garmin is officially not in the project plan. Wherigo v1.1 cartridges will be guaranteed to work in Garmin devices just about as well as they work now (ha, ha). The site will continue to allow you to download compiled cartridges for Garmin GPS receivers and use unlock/completion codes.

 

We'll decide what we want to do about Garmin compatibility when we begin the specification process for Wherigo v2.0.

 

Don't misunderstand the timeline, though: you'll have at least until the end of 2015 to play all cartridges on a Garmin device. Everyone in the foundation is a volunteer working on their own time, so progress towards Wherigo v2.0 is going to be a little slow.

 

Personally, Wegge, I have a Colorado and iPhone. So it's not like I don't understand. When I play a cartridge, I try to use both devices just in case something happens. However, an increasing number of people are getting smartphones these days (it wasn't like that when Wherigo first came out). What do you think the smartphone percentage will be like in another three years? I see there's more to gain by going the smartphone route than keeping Wherigo compatible with Garmin's archaic GPS receivers when it's likely Garmin will cut support for Wherigo entirely unless you have an old device.

Link to comment

Personally, Wegge, I have a Colorado and iPhone. So it's not like I don't understand. When I play a cartridge, I try to use both devices just in case something happens. However, an increasing number of people are getting smartphones these days (it wasn't like that when Wherigo first came out). What do you think the smartphone percentage will be like in another three years? I see there's more to gain by going the smartphone route than keeping Wherigo compatible with Garmin's archaic GPS receivers when it's likely Garmin will cut support for Wherigo entirely unless you have an old device.

 

There are several problems with going the smartphone route. The main one being battery life. In many smartphones, GPS is a check-box capability, that isn't a core part of the product. Thus the hardware is minimal, leading to an extreme power drain, because of the heavy computational need. For instance, my phone will drain power completely in less than an hour, if the GPS is turned on at all time. On the other hand, I can have my handheld Oregon turned on for 16 hours on a set of rechargeable (and field-swappable) AA cells. So assuming that the umpteen smartphones on the market will all be usable, is not realistic.

 

Second, a dedicated outdoor GPS receiver has much better ergonomics than a phone, coming from a market where thinner is better. Try walking a mile with a phone in one hand, and a Oregon or similar in the other hand, keeping an eye on the display at all (most) times. Now, which hand is the most sore? And finally, hardly any of the smartphones available are the least rugged. I also see this as a major drawback to smartphone as a viable WIG platform.

Link to comment

Yes, that's all right, but we don't have another chance. We don't have access to GPSr software. We don't have the possibility to create programs for GPSr. We could only make improvments for devices, we have access to.

 

The power is a problem. I know. We can check this part, to see, what we can do. And you should always remember, that the development is going on. And the smartphone development is going fast.

Link to comment

While what Wegge posted below is true, I think dropping Garmin is the way to go. Battery life is an issue but there are numerous backup battery options (I have an iPhone, Oregon 550 and Oregon 600).

 

The single biggest thing that has held Wherigo back is Garmin, more specifically their extremely buggy and not-fully implemented Wherigo player. If you want to build a Wherigo that works on garmin you can't use sounds, you have to use tiny media formats, you have to design around an 8-10 zone limit tops, you will crash constantly due to less memory, and the experience will be different because the processor is much slower then smart phones. Throw in you have to download the cartridge before you leave home (can't download it in the field) and (at least on Oregons) you have a limit on the # of Wherigo cartridges on the unit (past a certain amount, I think 10, it displays them but won't let you launch them) and you have a horrible player.

 

Garmin has already dropped support for Wherigo in their last few GPS iterations (Montana and Oregon 600 and 650 do not have Wherigo support ... at all). So you are talking supporting Colorados and Oregon 450 and 550. In 3 years the number of people using those will be a much smaller number.

 

Wherigo players are available for free on Android & iPhone which makes them pretty pervasive. I still support Garmins in our wherigos (we have made/published 20 of them) but I am close to abandoning Garmins. They really limit the creativity I can do with a Wherigo and I find myself increasingly frustrated with their buggy nature.

 

So that's my (admittedly) long-winded opinion that coding for the future (smart phones, not Garmins) on a 3 year timeline is the smart place to put your efforts.

 

 

Personally, Wegge, I have a Colorado and iPhone. So it's not like I don't understand. When I play a cartridge, I try to use both devices just in case something happens. However, an increasing number of people are getting smartphones these days (it wasn't like that when Wherigo first came out). What do you think the smartphone percentage will be like in another three years? I see there's more to gain by going the smartphone route than keeping Wherigo compatible with Garmin's archaic GPS receivers when it's likely Garmin will cut support for Wherigo entirely unless you have an old device.

 

There are several problems with going the smartphone route. The main one being battery life. In many smartphones, GPS is a check-box capability, that isn't a core part of the product. Thus the hardware is minimal, leading to an extreme power drain, because of the heavy computational need. For instance, my phone will drain power completely in less than an hour, if the GPS is turned on at all time. On the other hand, I can have my handheld Oregon turned on for 16 hours on a set of rechargeable (and field-swappable) AA cells. So assuming that the umpteen smartphones on the market will all be usable, is not realistic.

 

Second, a dedicated outdoor GPS receiver has much better ergonomics than a phone, coming from a market where thinner is better. Try walking a mile with a phone in one hand, and a Oregon or similar in the other hand, keeping an eye on the display at all (most) times. Now, which hand is the most sore? And finally, hardly any of the smartphones available are the least rugged. I also see this as a major drawback to smartphone as a viable WIG platform.

Link to comment

Yes, that's all right, but we don't have another chance. We don't have access to GPSr software. We don't have the possibility to create programs for GPSr. We could only make improvments for devices, we have access to.

 

The power is a problem. I know. We can check this part, to see, what we can do. And you should always remember, that the development is going on. And the smartphone development is going fast.

 

The problem is not only Garmin. The problem is that there is no specification for Wherigo, except reverse-engineering what come from the Groundspeak builder. It's using a pretty weak subset of what's actually possible in the Wherigo lua class (most of the Wherigo interpreter is written in lua[1]). The same hold true for the 3rd-party implementations, that also had to guess a specification. And that is where a large part of the perceived Garmin issues come from: Third-party builders, generating almost-compliant code, that the other players have adapted to. It's just not Wherigo.

 

1. Both the emulator and Garmin devices have a full lua implementation that include the reflective capabilities of the Lua debug library, so I hava a pretty good idea what's going on inside.

Link to comment

There are many things not implemented in Garmin's player that do work in Emulator (such as onClick). Several other areas (zone commands, onRestore, Save & Close crashes the system, etc.).

 

I disagree that Garmin's player is a full implementation. It's not equal to the Emulator which is the closest we have to a full implementation.

 

Yes, that's all right, but we don't have another chance. We don't have access to GPSr software. We don't have the possibility to create programs for GPSr. We could only make improvments for devices, we have access to.

 

The power is a problem. I know. We can check this part, to see, what we can do. And you should always remember, that the development is going on. And the smartphone development is going fast.

 

The problem is not only Garmin. The problem is that there is no specification for Wherigo, except reverse-engineering what come from the Groundspeak builder. It's using a pretty weak subset of what's actually possible in the Wherigo lua class (most of the Wherigo interpreter is written in lua[1]). The same hold true for the 3rd-party implementations, that also had to guess a specification. And that is where a large part of the perceived Garmin issues come from: Third-party builders, generating almost-compliant code, that the other players have adapted to. It's just not Wherigo.

 

1. Both the emulator and Garmin devices have a full lua implementation that include the reflective capabilities of the Lua debug library, so I hava a pretty good idea what's going on inside.

Link to comment

Do you know, how to debug a cartridge? I want to know this all the time.

 

The WF.Player will have a complet Lua implementation, the original one, and the same Wherigo library if Groundspeak give their ok.

 

That depends on what issue you want to debug?

 

I have a background in low-level systems, so I usually fall back on adding some Wherigo.Logmessage() calls in key positions, to log the state at that point. In the case of the player crashing, I've had succes with wrapping things in pcall:

 

res, errmes = pcall (Wherigo.Showscreen(DETAILSCREEN, itemThisOrThat))

if not res then

Wherigo.Logmessage(LOGDEBUG, "Error Showing ThisOrThat: " .. errmes)

end

 

Incidentially, by wrapping the ShowScreen() in a pcall, it's actually possible to show the detailscreen of an item in the Oregon player, without the GPS crashing. It appears that the player code is trying to call a boolean value as a function, which will generate a fatal runtime error without the pcall.

Link to comment

Sorry, for this quiet time.

 

Ok, the Android and iOS player with options of Wherigo 1.0 where nearly ready, when I encountered a memory leak. After 45 minutes the Lua part used 200 MB of memory. Not all Smartphones are happy with this :blink:

 

In the last week I changed the Lua interface to a new component, which I finished this morning. Android and iOS now only use about 1 MB of memory and this size is very stable. The next step is that Mangatome will take a look on the code and check what horrible things I have done :( In contrast to me, he could make good code. :D After he had done this, we are ready for testing. I have two testers, one for Android and one for iOS. While they are testing (which I hope is a very short time B) ), I will try to do the things around the game: cartridge selection, maps, internationalization, online access for cartridges and so on.

 

For the time table of the WP7 player, you had to ask Mangatome.

 

If you want to have a look on the source code, you find it on GitHub (https://github.com/WFoundation). Not always the latest versions, but enough to get the idea. There are two parts: one is the Core, which does all the Lua handling and Wherigo related parts (WF.Player.Core), the other is the device dependent part, which is different for each device (WF.Player.Android, WF.Player.iOS, WF.Player.WinPhone). We try to move as much as possible to the Core, so that is equal on all platforms.

 

I hope this is good news for you and you see, that things are "in process". If you have further question, don't hesitate to ask.

Link to comment

Things seem to be moving well for Windows version of player, any updates for Android or iOS?

 

I splited the three things, so it is easier to follow and the threads are in the correct forums.

 

You could find any news for

- Compiler at http://forums.Groundspeak.com/GC/index.php?showtopic=320933

- WF.Player for iOS at http://forums.Groundspeak.com/GC/index.php?showtopic=320936

- WF.Player for Android at http://forums.Groundspeak.com/GC/index.php?showtopic=320938

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...