WPR 0.1.05

Prebuilt WPR 0.1.05.

Download	Platform
WPR-Setup-0.1.05.exe	Windows x64 — self-contained, no .NET install required
WPR-0.1.05.apk	Android — API 21+, arm64-v8a / x86_64

What's changed

Changes since v0.1.0.

Highlights

If a game never starts on your phone, you can now do something about it. 0.1.04 changed the
way Android draws games, and that fixed a great deal — but on a small number of phones the phone's
own graphics driver cannot cope with it, and there was no way back short of a PC and a cable.
There is now a switch in settings, WPR notices a game that died before it drew anything and moves
you off that driver by itself, and the error you get when a game fails finally tells you which
driver it was using. That switch also had a trap waiting behind it, and it is gone: games that draw
any part of the scene as wireframe used to close themselves on the opengl setting, DoDonPachi
Maximum among them.

The biggest fix in this release is for games that looked perfect and would not respond. On
Android, WPR could run a game at full speed, with every picture in the right place and every
animation playing, while the game quietly ignored everything you did. Brain Challenge HD was
the clearest case: its coach appeared and never said a word, and there was no way past the
introduction. The cause was not in any of these games — it was in the protection tool their
publishers ran them through before release, which produces a shape of code that Android refuses
to run and Windows has never minded. It turns up in a third of the games installed here. If an
Android game has ever seemed to run beautifully while ignoring you, try it again.

And four rendering faults are gone, three of which were never about one game. Brain
Challenge HD's coach had blue skin, because red and blue were swapped on a whole class of
Android textures. Kinectimals drew black boxes around its foliage, because one model's
settings were leaking into every other model in the game. 3D Brick Breaker Revolution played
for a few minutes on Android and then vanished, because a leak nothing could clean up eventually
starved the graphics chip. And Fast and the Furious: Adrenaline showed a white screen and
nothing else, because of two small pieces of Windows Phone that WPR had never built.

One more, and this one was about touch rather than drawing. Gravity Guy's menu looked
perfect and ignored every tap. WPR had been telling games the size of the window they were running
in, where a Windows Phone would have told them the size of its screen — and a game that uses that
number to work out where your finger is put every tap off the edge of the world. Three more games
are built on the same engine and did the same sum.

And Chickens Can't Fly now starts. It used to close itself the instant you opened it on
Windows, and behind that were four separate faults stacked one behind another — each one only
visible once the one in front of it was gone. The first of them was a missing piece of Windows that
five of the games here would have hit sooner or later. While testing it, one more thing turned up
that is not about that game at all: the mouse wheel now scrolls lists inside games on Windows,
which it never did, and a short drag with the mouse no longer opens whatever it was pointing at.

🎛️	A graphics switch in Android settings — for phones where games never start at all
🛟	WPR switches graphics driver by itself after a launch that dies before its first frame
💬	A failed game now tells you which graphics driver it used, and where to change it
🕹️	Games that draw wireframe no longer close themselves on the opengl setting — DoDonPachi Maximum starts its stages
🗣️	Games that drew perfectly on Android and ignored you now respond — the pattern behind it appears in 11 of the 36 games here
🧪	Brain Challenge HD's coach is the right colour — and so is any Android game whose art looked oddly tinted
💭	Brain Challenge HD talks, and reaches its menu — it used to stop at a silent coach with no way past
🌿	Kinectimals' leaves no longer sit in black boxes — and other games' see-through parts are fixed with them
🧱	3D Brick Breaker Revolution no longer dies a few minutes in on Android
🧹	Games that draw in a loop no longer leak graphics memory — a quarter of a megabyte a time, never reclaimed
🏎️	Fast and the Furious: Adrenaline now races — it used to load to a white screen and stop
👆	Gravity Guy's menu takes taps again — and Fragger, iStunt 2 and Monster Island with it
🐔	Chickens Can't Fly starts and plays — it used to close itself the moment you opened it
🖱️	The mouse wheel scrolls lists inside games on Windows, and a short drag no longer opens the wrong thing
🌐	Games that talk to online services no longer close themselves on Windows — five of them here
🏆	Achievements you already have no longer pop up again every time you start a game
🔍	A graphics page on each game's info screen, so a bug report can say what the phone can actually do

Upgrading is normal this time. Install the new APK straight over the top on Android, or run
the installer on Windows; your games and progress stay where they are. The 0.1.04 notes warned
that it was the last release you would have to uninstall for, and that still holds.

One thing to expect afterwards: every game needs to be repatched once. The fix for games that
drew perfectly and ignored you is made by rewriting part of the game as it is patched, so a game
patched by an older WPR keeps the old behaviour until that is done again.

On Android this is automatic. The first launch of each game says updating patched
assemblies… for a moment and then carries on. It happens once per game and you do not have to
do anything.

On Windows it is not. Nothing repatches by itself, and a game that has not been repatched
simply carries on behaving as it did before — it will still start. Press Repatch on a game's
page to do it one at a time, or start WPR with --repatch-installed to do the whole library in
one go and exit. Most games are repatched to no effect, so if you only care about one of the
games named below, repatching that one is enough.

---

When a game will not start at all, there is now a way out

0.1.04 switched Android over to Vulkan, the newer of the two ways a phone can draw games. That was
the right call and it is still the right call: it is what fixed characters frozen in a T-pose, and
games that stopped part-way through loading, and the black screen when you came back to a game you
had left.

But which of the two works is not really up to WPR. It depends on the graphics driver inside the
phone, written by whoever made the chip, and some of them do not do what they say they do. When
one of those fails, it fails in the worst possible way: the game shows a black screen, throws up an
error, and closes — and then does exactly the same thing next time, and the time after that.
Nothing you can do in the app changes anything.

There has always been a way out of that, but it involved plugging the phone into a PC and writing a
file into the app's storage by hand. If all you have is the phone, you had nothing.

Three things change that.

There is a switch. Settings → graphics has two buttons, vulkan and opengl. If a game has
never once started on your phone, try the other one. It takes effect straight away — the choice is
live from the moment you tap it, and the next game you start uses it. Nothing to restart, and the
rest of WPR agrees with you immediately: the driver named on a game's info page, and in the error
you get when a game fails, is the one you just picked.

This is not a setting to fiddle with. Vulkan is the right answer on nearly every phone, and the
reason it is the default was measured rather than assumed — the other option makes some games stop
part-way through loading and never finish, which is a worse problem than the one it solves. The
page says as much underneath the buttons. It is there for people who cannot play anything at all.

WPR also notices on its own. Every time a game starts, WPR writes down that it is about to use
the graphics driver, and crosses that note out the moment the game puts its first picture on the
screen. If it finds the note still standing next time — meaning the last attempt never got as far
as a single frame — it quietly moves you to the other driver and tries that instead. The window
this covers is about a second, from just before the driver is touched to the first thing you see,
so it takes a real failure to trigger it rather than you changing your mind and closing the game.

If you then pick a driver yourself, your choice wins and WPR forgets whatever it had concluded.

And the error tells you what happened. Until now, a game that failed to start gave you a page
of technical detail with no mention of the one thing most likely to be responsible. The message now
opens with the driver that was in use and a pointer to the setting, before any of the detail. It
says it every time, including when there is no error to go on at all — a driver that takes the
whole game process down with it leaves nothing behind to describe.

What this does not do. It does not fix any particular phone. The report that prompted it is
Zuma's Revenge on a Realme Note 60x, and that combination cannot be reproduced on any hardware
available here — the game plays through, level 1 included, on Windows, on the emulator, and on both
drivers. That phone's own Vulkan driver is the one variable none of those can stand in for. So this
release makes no claim to have fixed that game on that phone. What it does is make sure somebody in
that position has a button to press.

Android only. Windows picks its graphics driver automatically and has never had this trap.

Games that draw wireframe no longer close themselves on the opengl setting

DoDonPachi Maximum played its menus, started a stage, and died there — every time, with an
error saying only that the game had closed unexpectedly.

Some games draw parts of the scene as wireframe: outlines rather than solid surfaces. DoDonPachi
Maximum draws the structures sliding past behind its stages that way, which is why it got through
everything before a stage and never through a stage itself.

Asking for that is a single instruction, and on the opengl setting that instruction is not there.
It belongs to desktop graphics and was never part of what phones do. WPR reached for it anyway,
without checking — and reaching for something that does not exist does not produce a normal error,
it takes the whole game down where it stands. Nothing useful is written anywhere, which is why the
only thing left behind was a message saying the game had closed and to go and look elsewhere.

WPR now checks first, and draws those parts solid on a phone that cannot draw outlines. A wireframe
background rendered as solid shapes is not what the artist intended; a game that closes itself is
not anything at all.

This only ever affected the opengl setting, and that is exactly why it was worth fixing now.
Vulkan — the default, and what nearly every phone will be running — draws wireframe perfectly well,
which is why DoDonPachi Maximum plays through its stages there. But 0.1.05 is the release that puts
an opengl button in front of people for the first time. Somebody pressing it to rescue one stubborn
game would have traded that problem for this one, in a different game, with nothing to connect the
two.

It was never about one game either. Any Windows Phone game that uses wireframe anywhere was doing
the same thing on that setting.

Android only, and only on the opengl setting. Windows draws games a third way that has always had
the instruction available. Needs nothing beyond installing this release.

Blue people: red and blue were swapped on Android

Brain Challenge HD's scientist coach stood at the side of the screen with blue skin, while their
white lab coat stayed perfectly white.

Pictures in these games are stored in several different formats, and one of the older, smaller ones
packs a colour into half the usual space. WPR was reading that format with its red and blue the
wrong way round on Android, so anything stored that way came out with those two colours exchanged.

That is a strange thing to spot, which is why it lasted. Grey is unaffected, because grey is equal
parts red and blue to begin with, and so is everything a game stored in one of the other formats.
In Brain Challenge HD exactly two pictures in the whole game use it — the two sprite sheets the
coach is drawn from. Everything else on screen was correct. The result does not look like a fault
in the display; it looks like one character was coloured in wrong.

None of this was specific to that game. Any Windows Phone game with one of these smaller pictures
in it has been drawing it with red and blue exchanged on Android since 0.1.04, when Android moved
to Vulkan. If you have seen art in a game that looked oddly tinted, or a character that seemed
the wrong colour, it is worth another look now.

Android only. Windows draws games a third way that always read the format correctly.

Games that drew perfectly on Android and would not respond

This is the largest single fix in the release, and it had been quietly affecting about a third of
the games here.

Brain Challenge HD is the clearest example. Its coach appeared, blinked, breathed — and never
said anything. The speech bubbles the coach talks in simply did not arrive, the arrow that
moves the conversation along did nothing, and there was no way past the introduction. Nothing
looked broken. The game ran at full speed, the artwork was correct, the animation played. It just
would not go anywhere.

Underneath, Android was refusing to run one function out of the game. Not failing to run it —
refusing, before it ever started, and then quietly carrying on with the rest of the game. That
one function happened to be the one that decides what the coach says and when to move on.

The reason it happens at all is a disagreement about a piece of code that is perfectly legal.
Windows Phone games were built fifteen years ago and more, and most commercial ones were put through
a protection tool before release that deliberately scrambles the shape of the code to make it hard
to read. One of the shapes those tools produce is one that Android's runtime examines, decides it
cannot make sense of, and throws away the whole function rather than the part it objected to. The
same code runs without complaint on Windows, which is why none of this has ever been visible there.

Because it comes from the protection tools rather than from anything a particular studio did, it is
everywhere. Across the 36 games installed here it appears 6,195 times, in 32 different files
belonging to 11 games — Brain Challenge, Chickens Can't Fly, Crimson Dragon: Side Story,
Earthworm Jim, Fragger, Minesweeper, Monster Island, More Brain Exercise by Namco, PAC-MAN,
i Love Katamari and iStunt 2.

WPR now rearranges those pieces of code when it patches a game, in a way that changes nothing about
what the game does but leaves Android with nothing to object to.

Two things worth knowing. Only Brain Challenge is confirmed to have been visibly broken by
this — the other ten contained the same shape, but whether a given game ever reached it in play is
another matter, so this is not a promise that ten more games were fixed. And on some phones it
leaves nothing behind in the error log at all: on a Galaxy S24 the game went wrong in complete
silence. So if an Android game has ever seemed to run beautifully while ignoring you, it is worth
trying again after this release.

A correction made before release, and worth being honest about. A second, wider form of this
repair went in during development and broke two games that had been fine since 0.1.03 —
Earthworm Jim stopped on its Gameloft logo for ever, and Final Fantasy III was caught by
the same change. That wider form has been switched off again; the narrower one above stays, and
Brain Challenge still talks. The same investigation found that on Android a game re-prepared by a
WPR update could quietly lose its untouched original copy, so each later update was building on
the previous one's output. That is fixed too, and WPR now says so in its log when it meets a game
whose original has already been lost — for those, reinstalling the game from its package is the
only way back. If Earthworm Jim or Final Fantasy III still fail to start for you after this
release, that is the reason, and a reinstall is the cure.

Android only in effect, but the repair is made when the game is patched, so it travels with the
game. This one needs a repatch — see the note at the top.

Brain Challenge's main menu, and a player name that was empty rather than absent

With the speech bubbles working, Brain Challenge got as far as its main menu and hit something
else: the date that belongs in the header was missing, and the game was failing once for every
frame it drew.

WPR gives games a player name, and uses a stand-in when you have not set one. The two versions
disagreed about what "not set" looks like — Windows left the setting out altogether, Android wrote
it down as empty — so the stand-in was used on one and not the other, and Android handed games a
name with no letters in it. Brain Challenge takes the player's name apart letter by letter to draw
it, and asking it for the first letter of nothing is what went wrong.

An empty name is now treated as no name, which is what it always meant.

Both platforms, though only Android ever produced the empty value. Needs nothing beyond installing
this release.

3D Brick Breaker Revolution, and a leak in every game that draws in a loop

3D Brick Breaker Revolution played happily on Android for two or three minutes and then
disappeared, with nothing to say beyond the game process exited unexpectedly.

The game was running out of a particular kind of room on the graphics chip. What makes it worth
explaining is that it was not being greedy — it was leaking, and the thing it leaked could never be
cleaned up by anything.

Whenever a game wants to draw a batch of flat images — text, buttons, sprites, most of what you see
in a 2D game — it makes a small object to do it with. That object is cheap in the ordinary sense, a
few bytes, but it quietly claims about a quarter of a megabyte of graphics memory and a slot in a
fixed-size list on the chip. A game is meant to make one and keep it.

3D Brick Breaker Revolution is a conversion of an old Java phone game, and its conversion layer
makes a brand new one every single frame and throws it away — sixty times a second, for as long as
you play. Because the discarded object looks tiny to the part of the system that tidies up after
games, nothing ever felt any pressure to reclaim it, so nothing ever did. It measured out at about
thirty-six a second, none of them released. After a few minutes the graphics chip had nothing left
to give and the game died.

WPR now shares those resources instead of handing out a fresh set each time. There is one set
per game, made the first time anything draws and kept for as long as the game runs, so a game that
asks for a thousand gets the same one a thousand times. Failures went from around two and a half
thousand in a session to zero, and the game is playable — verified in-game at level 3 of 99.

This is not a fix for one game. Anything making these objects in a loop was leaking graphics memory
the same way, on Android and on Windows alike; most games simply were not doing it fast enough to
run out before you stopped playing. All of them are lighter now.

Two smaller repairs went in underneath it, in the graphics layer itself. When the chip ran out of
room, the code there was not checking whether it had been refused — it carried on as though it had
been given what it asked for, which is why the game kept running for thousands of frames after the
first failure and then died somewhere unrelated to it. It now notices, asks for less, and if there
is genuinely nothing left it reuses what it already had rather than something meaningless. That was
a real fault in its own right and is kept as a backstop, but it is no longer what makes this game
work.

Needs nothing — launch the game.

Kinectimals, and one model's settings leaking into all the others

Kinectimals drew its world beautifully and then put a hard black box around every leaf on every
tree.

A game tells the graphics chip how to draw each part of a model: whether it is solid or see-through,
whether it sits in front of or behind other things. Those instructions travel in small bundles, and
a game usually starts from one of a handful of ready-made ones — solid, normal depth, and so on
— then takes a copy of it if it wants something different.

Taking a copy is the important part, and the way a game decides whether it needs to is to ask
whether the bundle it is holding has already been handed to the graphics chip. If it has, it
belongs to the chip now and must not be edited. Under WPR that question had never been given an
answer: nothing was ever marked as handed over, so every game that asked was told no, this one is
yours, go ahead and change it — and what it then changed was the shared ready-made bundle that
everything else in the game was also using.

Kinectimals is unusually exposed to that, because it decides how to draw things from a list of rules
in a data file and the first rule in the list applies to everything. So the rule saying "leaves are
see-through" was written into the shared bundle, and then overwritten by the rule saying "everything
is solid" for the next model along. The leaves were drawn solid — and since the transparent part of
a leaf texture is stored as pure black, drawing it solid paints exactly that.

WPR now marks a bundle as belonging to the graphics chip when it is handed over, so the question
gets its true answer and the copy actually gets made.

Expect this to have fixed more than one game. Checking before copying is a standard habit rather
than a Kinectimals quirk, and every game with that habit had been writing over the shared bundles.
If something has looked wrong about a game's transparency, its shadows, or what is drawn in front of
what, it is worth trying again.

It was reported as an Android problem and it was never an Android problem — it happened identically
on Windows, and that is how it was found. A fault that looks exactly the same on two completely
different graphics systems is not coming from either of them.

Fast and the Furious: Adrenaline, and a white screen with nothing behind it

Fast and the Furious: Adrenaline loaded to a white screen and stayed there.

Somewhere in its startup the game asks the phone how many music playlists you have. It is a
throwaway question — the answer is none, there is no Zune music library here, and every Windows
Phone game had to cope with a user who had no playlists anyway. But WPR had never built the two
small pieces needed to answer it, and a question with nothing behind it does not come back with
"none". It fails outright.

Where the damage landed is the instructive part. That question is asked from inside a chain of
fourteen objects being built one within another, and the failure took the whole chain down with it.
The game was left holding no application at all, and then spent every frame afterwards failing to
draw the thing that was not there. The player saw a white screen. The music library was never on
screen and was never a suspect; the one useful line in the log sat buried under nearly eight
thousand identical complaints about the white screen itself.

The two missing pieces are now there, and permanently empty — which is the correct answer. There is
no music library on this phone, and the game's Music: Zune option simply finds nothing. What it
needed was for the question to be answerable at all.

The game now plays: main menu, Quick Play, track select, and a live 3D race, on Windows and on
Android.

This is the one thing in this release that needs a repatch — on Android it happens by itself the
next time you open the game; on Windows, press Repatch on its page.

Gravity Guy, and a menu that would not take a tap

Gravity Guy drew its menu perfectly, animated the background, played its music — and did
nothing at all when you tapped PLAY. Or ACHIEVEMENTS, or OPTIONS, or anywhere else on the screen.

A Windows Phone screen is 480 across and 800 tall, and in the phone's own reckoning it stays that
way even when you turn the phone sideways to play. A game played sideways draws into a picture that
is 800 across and 480 tall and receives your taps in those same sideways numbers, while the screen
it is being drawn on goes on being 480 by 800. That sounds like a mistake and it is not — it is
simply how the phone described itself, and games were written knowing it.

WPR was answering that question with something else entirely: the size of the window the game
happened to be running in. On a PC that is whatever size the window is; on a phone it is the whole
panel, which on a modern handset is nothing like a Windows Phone's. Gravity Guy takes that number
and uses it to turn your tap into a position inside its own world. Fed the real one, every tap on
the screen lands somewhere in the game. Fed the window's, every tap on the screen lands off the
edge of it — not near a button, not slightly off, but outside the world entirely. So no part of the
menu could ever respond.

That all-or-nothing quality is what made it so hard to place. Nothing failed, nothing was reported,
and the taps themselves were arriving and being handed over correctly the whole time; it was the
game's own arithmetic, given one wrong number, that threw them away. From the outside it looked
like touch was simply not working, which is the one thing it was doing properly.

WPR now answers with the phone's screen, as a Windows Phone did. Gravity Guy's menus work
throughout — title screen, PLAY, OPTIONS, and back out again. Fragger is fixed with it, and
iStunt 2 and Monster Island are built on the same Miniclip engine and do the identical sum.

Of the 307 games checked, fourteen ask this question at all, so this was a small change with a
precisely known reach. Both platforms; Android was affected in exactly the same way. Needs nothing
— just open the game.

Chickens Can't Fly, and four faults standing in a queue

Chickens Can't Fly closed itself on Windows the moment you opened it. It now starts, and plays.

It took four unrelated repairs to get there, and the useful thing to say about them is that they
were in a queue. Fixing the first one did not make the game work — it made the game get further and
fail differently. That is the normal shape of this kind of work rather than a sign of going
backwards, and it is worth saying plainly, because from the outside "it still doesn't work" looks
the same either way.

First: a missing piece of Windows, and this one was never about this game. Windows Phone games
that talk to online services — leaderboards, high score tables, the anonymous usage reporting
Microsoft bundled into the phone development kit — need a particular piece of the .NET framework
to do it. WPR has always shipped that piece on Android and, it turns out, never on Windows. The
same game worked on a phone and killed the app on a PC, which is about as clean a split as you can
get. Chickens Can't Fly starts its usage reporting on a background task a second or two in, and
when that piece is missing the failure is not something the game can catch: it takes the whole
process down without ceremony. Five of the games installed here need it — Minesweeper, Cro-Mag
Rally, geoDefense Swarm, Crimson Dragon: Side Story, and this one.

Second: WPR told it that it had just come back, and it believed it. When a game starts, WPR
sends it the signal a phone would send when you return to a game you had put aside. That is there
on purpose and several games need it. Chickens Can't Fly reads it and concludes the opposite of
what most games do: it decides everything it needs is still in memory from before, and skips
loading its saved state off disk. A moment later it asks that state a question and there is nothing
there to ask. It now doesn't get that signal, which is what a phone would actually have done on a
fresh start. The list of games treated this way is a list of names rather than a rule, because
nothing about a game tells you in advance which way it will read it — Doodle God is on it for
the opposite reason, and the flag this game trips over is one Battlewagon positively needs.

Third: a folder Windows Phone always had. Games can put a picture on their tile on the phone's
home screen, and the phone kept a folder ready for them to write it into. WPR's storage starts
empty and nothing ever made that folder, so the write failed — and it failed on the line directly
before the one that says finished loading. The game sat on its title screen for ever, still
animating, with its loading animation running on a thread that was never told to stop. A live tile
means nothing here and nobody would miss it; failing a game's whole startup over one is another
matter. The folder is now created on demand.

Fourth: an empty leaderboard could not say it was empty. When you finish a level the game
submits your score, and part of submitting it is asking the leaderboard for somewhere to put the
details. There is no leaderboard service behind WPR and there never will be — but "there is nothing
here" has to be an answer, and instead the question failed. Because it is asked from the code that
runs while the results screen is up, it failed again on every single frame: the game drew perfectly,
at full speed, and the results screen simply never moved on.

Three of those four looked identical from the player's seat — a screen that renders beautifully
and does nothing. None of them produced a crash or an error message. Verified end to end in the
app: menu, level select, a played level with its score screen, and the back button returning you to
the list.

The remaining complaints in the log are the game trying to reach online services that shut down
over a decade ago. It copes with all of them, as it was written to.

Windows was where this showed up; the last three repairs apply to Android equally. Needs nothing —
just open the game.

The mouse wheel scrolls now, and short drags stop opening the wrong thing

This one is not about a particular game.

Scrolling a list inside a game on Windows meant holding the mouse button and dragging, exactly as
you would drag a finger on a phone — and doing that in Chickens Can't Fly's laboratory list kept
opening whichever laboratory was under the pointer instead of scrolling past it.

The reason is a gap that a finger never falls into and a mouse falls into every time. A game
decides for itself whether what you just did was a tap or a drag, and it does that by measuring how
far you moved before letting go. This one calls anything under about forty pixels a tap, and starts
scrolling at fifteen. Between those two it is both, and the tap wins. On a phone that overlap is
unreachable: a finger flick travels hundreds of pixels and there is no such thing as a careful
two-millimetre swipe. With a mouse, a short precise movement is the natural thing to do, and it
lands in the overlap on nearly every attempt.

Rather than guess at each game's idea of a tap, WPR now makes the mouse wheel scroll. A notch
moves the list by a comfortable step, rolling the wheel several times runs the notches together
into one continuous movement, and the whole thing is deliberately far too big to be mistaken for a
tap. Nothing had to be taken away to do it: the wheel previously did nothing at all on these
screens.

Worth knowing why it needed doing this way. Games can either ask the system to recognise gestures
for them, or read the raw positions and work it out themselves — and Windows Phone lists mostly do
the second, because they were written before anyone trusted the first. Chickens Can't Fly never
asks about gestures at all, so a synthesised swipe would have gone straight past it. What actually
reaches such a game is a finger, so that is what WPR now provides.

A real fault came out of building it. WPR's ability to act out a touch — which also backs the
keyboard-to-touch controls you can set up per game — was never telling games when the finger came
off. Nothing else clears it, so after the first gesture the game believed a finger was still
pressed against the screen for the rest of the session. It shows as a game that behaves as though
you never let go: a list dragged past its end stays stuck past its end instead of springing back,
which is exactly what the lab list did. That is fixed, and it improves the custom touch controls
along with the wheel.

Windows only in effect — a phone has no wheel, and a phone's own scrolling was never affected.
Needs nothing.

Achievements you already have no longer pop up again

Starting a game you had played before could set off a run of achievement notifications for things
you unlocked days ago.

The achievements themselves were never wrong. They were correctly recorded, and correctly recognised
as already yours — it was only the pop-up that escaped the check. WPR skipped over each achievement
you already held, and then showed a notification anyway.

Games re-award achievements constantly and there is nothing wrong with that. Loading a save usually
means telling the system about every achievement you hold, and plenty of games check their progress
by awarding the achievement again on every evaluation rather than only at the moment you earn it.
WPR now tells you about one only when it has genuinely just flipped, and describes that one rather
than whichever happened to be first in the list.

Both platforms. Needs nothing.

A graphics page on each game's info screen

Android's game info screen has a new graphics section: which driver was chosen and why, whether
WPR has stepped in after a failed launch, and a short list of what the phone was actually measured
to be capable of the last time a game drew a frame — compressed texture support, hardware
instancing, how many textures it can use at once.

Everything on it is measured rather than assumed. Where WPR genuinely cannot find something out the
row is absent, rather than filled in with a plausible-looking number that would read as a
measurement; and until a game has drawn at least one frame, the list says so instead of guessing.

It is there so a screenshot attached to a bug report carries the facts that were missing from every
"black screen then crash" report so far — in particular whether a phone is on OpenGL because
somebody chose it, or because WPR moved them there after a failure. From inside a game those two
look identical.

All changes

Features

• arm native research
• keyboard input emulation, module architecture, and game fixes
• android vibration support with a global on/off setting
• pin a game to the android home screen
• recover achievement keys for 190 games from embedded XLAST config
• curate achievements for four playable games
• curate eleven more catalogues from their resource tables
• curate Doodle God Blitz and Picnic Wars from their content XML
• real gamerscores for six games from their own score tables
• recover eleven catalogues whose XLAST pair table would not parse
• names, gamerscores and descriptions for 169 catalogues
• gamerscores for fifteen catalogues curated from their own packages
• a game description for every catalogue
• achievement icons for 200 more games
• fixing games

Fixes

• Mirror's Edge on Android - animation, music and driver selection
• populate TouchPanel.DisplayOrientation so tilt games get their readings
• read the Android accelerometer directly, not through Xamarin.Essentials
• keep a game's icon after uninstall so achievements keep their artwork
• keys were filed under Tentacles' stale ProductID
• repair catalogue text mangled by an ANSI round trip

Chores

• open release notes for 0.1.03 and mark it unreleased
• rename WPR.Input.XamarinEssentials to WPR.Input.AndroidSensor
• add the tilt fix to the 0.1.03 notes
• add the game icon fix to the 0.1.03 notes
• turn the 0.1.03 notes into a release document

Other changes

• plans native
• fable coin golf fix
• 0.1.04
• version 0.1.05 release

Built from commit a4037f9.