Apps @ Burlock.org | Apps @ Burlock.org

Solar Explorer: Black screen of doom

February 20, 2013 admin No comments

Occasionally, despite the best of intentions, things can go wrong.

I released an update to Solar Explorer for all markets on the weekend, both paid and free versions.

As a special bonus, it came free with a limited edition bug that that basically caused the app to start up with a black screen and do nothing, except burn CPU cycles.

It was a really simple error – a file the app expected to exist, had accidentally been dragged and dropped into a sub-folder between the test builds and the final release.

To top it off, my mail server had crashed from a spam overload the day before the release, so although people were sending me a big “WTF?”, I wasn’t receiving any messages.

It was 24 hours before I realised there was a problem, and I released a quick fix, but it took me a further three days to notice that I wasn’t getting any email from my apps account.

I’ve now reactivated my email, so thanks to anyone who posted a query here, or sent me an email.

I’ll have to have a stern chat with the quality control department!

Blackberry Apps

Meanwhile, I’m still waiting for Blackberry to get around to testing the apps I submitted to the final port-a-thon, so long ago.

I’ve been busy submitting updates for all of them, and they’ve just been piling up – one app has actually got three versions waiting for release.

Unfortunately, Blackberry don’t provide a way for me to delete the obsolete versions, so I hope they notice the higher release numbers and don’t waste time on them. It could explain why they are so slow, if they have to slowly make their way through obsolete versions, while even more are piling up.

Because of this, I have bothered to submit the latest Solar Explorer update yet, because it’ll just slow them further. I’ll release it once they’ve cleared the backlog.

At this point, I’ve technically had only one app accepted or the $100 port-a-thon payout. I hope they don’t just ignore the other four apps because they haven’t had time to test them. Admittedly, they were rejected the first time because of screen orientation issues on the new BB phones, but that was beyond my control because hardware for testing wasn’t available at the time.

Solar Explorer 2.5.1: A whole lot of work

December 15, 2012 admin 2 Comments

I have spent a significant amount of time this week compiling and updating and testing and uploading and submitting the latest update for Solar Explorer.

Every time I got close to being able to release it I spotted some little bug or other minor issue.

Most of the problems were indirectly caused by the latest release of Shiva3D, which required updating every tool that’s used to build apps. That’s good, because it should be faster and more compatible, but it caused lots of little problems that had to be sorted out before I was finally able to run the build script and generate versions of the app for every platform and market.

Today’s release includes versions of Solar Explorer Lite for:

Google Play
SlideMe
AppsLib
Mobango

And the full version of Solar Explorer for:

Google Play
Blackberry Playbook/BB10
SlideMe
AppsLib
Samsung Market
Nook

I think that’s everyone updated…

The previous Playbook update was running a bit late – I’d had problems last month when I pushed out version 2.5.0 because I’d had to replace my ADSL router and the new one seemed to be blocking port 443 on the Playbook, so I couldn’t upload my apps to test them. I finally figured out a workaround this morning, so the latest version has just been submitted, which includes the previous update as well, which was mostly lots of new planet information.

The major new feature in the latest release is, for the first time, that I’ve added information about a non-US spacecraft, the Soviet Zond 3. There’s also various minor bug fixes and grammar corrections.

Next up, a refresh of Exoplanet Explorer…

Solar Explore 2.4.9: Catching up

October 29, 2012 admin No comments

The latest update for Solar Explorer is out, introducing a lot of minor code changes and improvements aimed at making it easier for me to port it to different markets and devices.

Probably the most noticeable change will be that when you quit the app, it’ll save what you were looking at, and put you back there when you start it next. Like the same change for Exoplanet Explorer, this was added because it was required for releasing the app on Barnes and Noble’s Nook and I thought it was useful enough that I’ve enabled it for all versions.

Speaking of which, Solar Explorer went live on B&N two days ago, a process that began back in July this year when I registered a company so that it could apply for a US tax ID which is a requirement for signing up as a Nook developer.

Although it’s technically possible for a foreign national (in certain countries) to get a US tax ID for tax treaty reasons, the process involves sending a registered copy of your passport to the US, waiting several months, and then hoping that you don’t get a rejection, which results in the whole process starting over.

While incredibly difficult for an individual, it’s dead easy for a company. All I had to do was place a long distance call to the US and answer some questions. They gave me the ID over the phone.

But enough about bureaucracy, what’s next?

I’d like to get back to my Space Race app, but there just won’t be enough time to complete it in the next six weeks, so I’m going to focus on making some more improvements to my two existing apps, particularly Solar Explorer because Exoplanet Explorer has had a heap of work done on it over the last few months.

I’ve got loads of ideas… all I need is the time to implement them!

Exoplanet Explorer V2.3.4: Tweakfest

October 27, 2012 admin 2 Comments

Another week, another update, this time with lots of little tweaks.

The biggest change is that the phantom planets that made an guest appearance in the last update have been identified and eradicated. This was caused by a few of the binary system data files from the old database sneaking into the folder for the new database, resulting in duplicates with almost identical names. It was a tough one to spot because it only affected a handful of systems out of the 650 or so. Thanks to Hernen for reporting this.

I also had another go at proof-reading the glossary, found numerous problems and fixed them. No matter how many times I read it, there’s always that needs to be corrected…. I’ve also-reworded a few of the paragraphs to hopefully make them a bit easier to read, and added “bullet points” in the text to make it simpler to pick out the headings and sections.

The missing details about the planets in our Solar System have been filled in, such as atmosphere, gravity and the discovery date for Uranus and Neptune. I’ve also tipped the Uranus model onto it’s side, so it’s a touch more accurate.

The last version was only rolled out to Google Play because I picked up on a few of the problems a couple of hours after I released it, and decided to wait till I’d fixed them before moving on. 2.3.4 is looking a lot better, so if everything is OK over the next 24 hours, then I’ll push it out to the other platforms.

I’m also expecting to release an update for Solar Explorer tomorrow which will bring across many of the same changes that have appeared in Exoplanet Explorer, and will also fix a few bugs as well.

Solar Explorer: What’s new

July 22, 2012 admin No comments

Some of you may have noticed a second Solar Explorer update rolled out following the one earlier this month.

The reason for it was a tiny little bug that caused the Moon to cease orbiting the Earth, and after all the hard work I did updating the code so that the Moon’s position would be accurate.

In truth, it wasn’t really a bug. Solar Explorer uses a library of maths functions that I’ve written in the C language. I modified this library to include the code for the Moon, and it ran just fine in the development tool.

It all went pear shaped when I exported the apps for Playbook and Android. I had thought that Shiva was building the Playbook and Android libraries at the same time as it built the Windows one, but a silent error stopped it from doing so for the portable platforms, resulting in the compiled apps having a stationary Moon and no error message to highlight the problem. Meanwhile, the version I test in Windows worked perfectly.

What’s next?

I’m currently working on an update for Exoplanet Explorer, to switch it from using the Exoplanet.eu data to Planetary Habitability Laboratory, because PHL’s data is more complete and features more information.

As part of the process, I’m rewriting the tool that builds the database to make it easier to work with. It’s been a real struggle trying to fill in the blanks because Exoplanet.eu’s data is a bit spotty, and the alternative, Simbad, has a lot of name search problems, making it a very manual process to try and gather the information to make the database as complete as possible.

The new Exoplanet database generator uses an SQL database to store the data while it’s being worked on. It begins by filling it with what’s available from PHL, then it looks to Simbad, then exoplanet.eu, before finally asking me to provide any missing information, assuming I can find it. The new structure should be a lot easier to maintain and result in fewer blank fields that I’ll have to look up myself.

Fields that have been added from PHL include information about the planet’s atmosphere (light or heavy elements), atmospheric pressure, it’s composition (rocky, iron, water or gas), it’s density and how it was discovered.

At 75% complete, and with a heavy workload at my day job, the new release is still a couple of weeks away. When it’s finally done, it will also feature the latest Shiva 3D engine which fixes the problems that Sony and Motorola afflicted their users with. It may also work around similar bugs caused by flaky code in certain custom ROMs, but as usual, custom ROMs aren’t officially supported.

Resolving difficult issues

June 17, 2012 admin 3 Comments

For some time I’ve been copping flack from people who’ve installed unsupported custom ICS ROMs on their Android devices, because sometimes the touch screen stopped working with my apps, Solar Explorer and Exoplanet Explorer, resulting in misleading comments on Android Market such as “ICS fail” which are not true as the problem only started after the unofficial ICS ROM was installed.

Despite this, I’ve done everything I can to figure out what’s wrong, but I cannot fix issues in a custom ROM, without becoming a developer on every custom ROM project, which I don’t have time for. There is the possibility of working around the problem in code, but it has to be done in the Shiva runtime engine.

Shiva is the 3rd party tool, developed by Stonetrip, that I use to write my apps. It handles all the low level code for graphics acceleration, audio, etc., and deals with a lot of the “fragmentation” issues. Because the issues have only affected custom ROM users, Stonetrip hasn’t investigated because they don’t support custom ROMs.

To be honest, I can’t blame Stonetrip. There’s loads of different custom ROMs out there with a constant barrage of patches and hacks being released to get them running on many different devices with varying levels of success. It would be impossible for a company to be able to provide support for all these projects, ones that often feature little in the way of quality control because the ROM developers themselves have few resources.

Although my apps work fine on all the ICS test devices I have access to (running official manufacturer ROMs), in the last week or so I’ve started to receive reports from Sony phone owners of a touchscreen problem present in the official ICS 4.0.4 that was released earlier this month.

Thanks to a couple of users who’ve given me the log output from their devices while running my apps, I’ve been able to report the problem to Stonetrip, and after looking into it, they think they know a way of solving it.

The plan is that they will release a new Shiva runtime engine in the next couple of weeks, after which I’ll rebuild all my apps a do a new release on Android, and Playbook, although RIM devices aren’t affected by the problem.

At the very least it will most likely fix the issue on Sony devices, and with luck it’s the same problem that is affecting custom ROM users, and it’ll be fixed too.

The next update of Solar Explorer will also includes a couple of new features that I’ve been working on. In the current version of the app, although the planets are positioned accurately based on the date, the Moon isn’t. The new release will fix that and you’ll be able to see the Moon in the right location on dates that feature a Solar eclipse. There’s also been some improvements made to the planet position calculations so they will be more accurate.

In the meantime, work continues on my Rockets app, but at a slower pace because I’ve got a full workload at the office for the next few weeks. I have however completed the Saturn V since my last update, which was a lot of work, and by far the most complex to date. As usual, the payload is included, which in this case is a model of the Apollo 11 Lunar Lander with it’s landing legs folded up, inside the final stage, below the Command Module.

Solar Explorer: How are 3D planets and moons created?

April 05, 2012 admin 2 Comments

I sometimes receive emails from Solar Explorer users with suggestions for alternate planet and moon surface images to be used in the application. These images are higher resolution than the ones I have, but they aren’t suitable for creating the illusion of a solid 3D object in the app, without a great deal of manipulation. It’s difficult to explain why in an email, because it’s a complicated process, so I’ve decided to write an article which I hope will give people who aren’t 3D artists or software developers an idea of what’s involved, and the reasons why I am grateful for the interest that’s shown, but the images will never make it into the app.

To create the illusion of a solid 3D planet or moon, an image of the surface has to be provided in a format that is suitable for a 3D engine to draw onto a sphere. The way this is done is using a mercator projection, which is basically a distorted 2D image of the body that has been flattened out into a rectangle.

Most of the mercator maps that are used in Solar Explorer were partially created by NASA, who patched them together from many different photos taken by various space probes. One photo isn’t enough because the camera can only see a part of the planet or moon when it is close, and the only sections of the image that aren’t distorted by the curve of the planet’s surface are the parts that directly face the camera. For the best results, shots of the body would need to exist that show all sides in full sunlight, with the Sun almost directly behind the camera in every shot, to minimise shadows being cast by surface features which would ruin the 3D effect.

Unfortunately, these photos don’t exist in many cases, particularly for the moons of Uranus and Neptune, which have only been visited by Voyager 1 and 2. These moons are tidally locked, meaning that one face is always turned towards the planet, so when the Voyager probes passed by, they only saw the side of the moon that was facing towards them. The planet would have been in the way of viewing the other side.

Nonetheless, NASA have done the best that they could and created maps of the parts of the moons that are visible. I’ve taken these partial images, and filled in as much detail as possible by extrapolating what is visible, then coloured them and adjusted them to make sure that they wrap around the 3D sphere model without showing a seam where the edges join.

I’m eternally grateful for the work that NASA has done creating the raw maps, because creating them myself from hundreds of photos of dozens of bodies would have taken me months.

There you have it, a basic overview of what’s involved in creating a surface map for a planet or moon. There is a lot more to it, such as dealing with hardware limitations on images sizes and creating additional specular and normal maps for adding details to the surface, but that’s topic, for another day.

Solar Explorer 2.4

March 30, 2012 admin 7 Comments

The new version of Solar Explorer has been out for about a week on Android. During that period of time, I’ve been trying to sort out bugs that are affecting the latest Motorola phones, causing the spacecraft to be invisible in the app. It’s not fixed yet, but I’ve narrowed it down to either a Motorola bug or a bug in my development tools. I’ve submitted it to Stonetrip and they’ll look into it further.

Since I can’t fix the Motorola problem any time soon, I’ve now gone ahead and built an updated version of the app for Playbook, and submitted it to AppWorld a few minutes ago. The new release it going to require Playbook’s 2.0 OS, because the latest bug-fixed Shiva engine also requires it. Hopefully you’ve all upgraded to the superior 2.0, because I can no longer build for the old 1.0 SDK.

As mentioned previously, there’s quite a few changes in this version, including a calendar to select a date on which to view the location of the Planets and Asteroids. There’s also the option to set one of four different simulation speeds so you can speed up or slow down the rate at which everything happens. The date selector is hidden when the info panel is open, so if you don’t see it, close the info panel. Screen space is limited, and I want to keep the UI as clean as possible.

The biggest improvement is a complete rewrite of the orbit calculations to allow for the accuracy needed to position the planets accurately on a given date. This was built on the changes recently made to Exoplanet Explorer that animated elliptical orbits with much better accurately.

In terms of bug fixes, the “vanishing sun” problem is now resolved, so when you zoom out to show the orbit rings, our Solar System will no longer be suitable for vampires. Another similar bug caused vanishing textures when the planets were zoomed out (far away), and that’s also been resolved. Both are related to the graphics chip used in the Playbook, and the same exact problem showed up on Android devices that also used the same chip. Cross platform development can also cause cross platform bugs.

Exoplanet Explorer: Available on App World!

March 21, 2012 admin 7 Comments

Finally, it’s arrived!

It took some time, but AppWorld finally approved Exoplanet Explorer for sale, and I’ve just flagged it as available.

Because I know there are a number of Playbook users who are waiting for the app to be released, I’ve decided to start it off at the introductory price of $1.99.

The app originally launch on Android Market at $1.99 late last year too, with the price going up to $2.99 in late December when the feature to automatically update the database was added, because those updates are maintained by me, and delivered from my server.

So, if you are Playbook user who’s interested in exploring our close galactic neighbours, then get it while it’s hot, before the introductory discount price is history.

Solar Explorer

I’m still working hard on the next Solar Explorer update and I finally got the math working for calculating planetary positions.

There’s not a lot left to do apart from some testing and minor tweaks.

I’m hoping to release it by the weekend on Android, and the update should appear on App World sometime next week.

Solar Explorer: CrackBerry’s publicity factor

March 10, 2012 admin 12 Comments

It’s certainly been an interesting start to March, after CrackBerry.com mentioned Solar Explorer, and kicked off a wave of app sales on Playbook.

Things quickly died down, which was expected, as educational apps don’t generally sit near the top of any market.

It’s all good though, as the CrackBerry feature turned into the gift that keeps on giving by raising the profile of my apps and this blog.

I’d been running apps.burlock.org for about 10 months, starting it at about the time I launched Solar Explorer on Android. In that time it had gone from a few hits a day (terrible) to about 60 (slightly less than terrible).

Most of the visitors were coming from the “Feedback” button I added to my apps in December last year. Almost nobody was linking to the site, which is probably because nobody knew it existed, and quite possibly because it was boring.

With the CrackBerry feature, in addition to the sales explosion, site traffic surged, receiving about 2,000 visitors over 24 hours. This attention later flowed on to a number of sites linking to mine, in particular the unexpectedly warm reception post which started it all, and later the favourable Playbook review I wrote after I’d received my freebie.

I even scored a mention on the Mobile Nations Monday Brief, at about the 3:00 minute mark.

Mobile Nations Monday Brief

That was my 15 seconds of fame

Android wasn’t forgotten though, as the increased publicity was obviously related to a one day jump in sales earlier in the week, equalling the previous best day I’d had on Android in early January, a total of about 50 sales.

Things had been calming down since then, Android sales were back to about 25 per day, App World sales were levelling out at about 40, and visits to the site were settling in above the 200 mark.

That was until logged into the Google Checkout console this morning and discovered that Solar Explorer had been selling at a rate of about one per minute for the past couple of hours.

At first I thought that the Market system had glitched and was sending me phantom sales. After watching it for a bit, I have come to the conclusion it is legit, and besides, nobody has been emailing me complaints.

The CrackBerry publicity must have lead to an influential Android user to downloading my app, then writing about it on a blog or forum somewhere. I’ll figure it out eventually.

Another big thank you to my mystery beneficiary.

What a month!

Update: Mystery solved, Android Central wrote a nice review of Solar Explorer.

Tag Archives: solar explorer