WPR 0.1.04
Prebuilt WPR 0.1.04.
| Download | Platform |
|---|---|
WPR-Setup-0.1.04.exe |
Windows x64 — self-contained, no .NET install required |
WPR-0.1.04.apk |
Android — API 21+, arm64-v8a / x86_64 |
What's changed
Changes since v0.1.0.
Highlights
Games that used only part of your screen now fill it, and games that hung for ever on their
splash screen now start. Both had been there since the beginning, and both were silent — no
error, no warning, nothing to suggest anything had gone wrong. Doodle God, which shut
itself down a second after launch, now plays too; Fable: Coin Golf — where every course
was a black screen — plays from end to end; and Battlewagon, which drew its scenery and then
refused to put a menu on it, now gets all the way in. Feed Me Oil, which drew a perfect picture
and stopped taking taps, plays on past its first level.
And on Android, 3D characters move again. WPR now draws games there a different way, and that
one change took a family of problems with it: characters frozen mid-stride in a T-pose, games that
stopped part-way through loading and never finished, and a black screen when you came back to a
game you had left. Contre Jour, which used to die before it drew a single frame, now plays.
| 📱 | Games now fill the whole Android screen. No status bar, no navigation bar, no black borders around the game |
| Games that never got past their splash screen now start — they were waiting for a screen that could never load | |
| 🎮 | Doodle God now runs — it used to close itself a second in, back to the games list |
| ⛳ | Fable: Coin Golf now plays — its courses were a black screen, and its scenery never arrived |
| 🖼️ | The last screen no longer lingers under the new one, and fades that used to sink to black now fade |
| 🐑 | Battlewagon's menu now appears — and other games that quietly failed to find their own files on Android |
| 🕺 | 3D characters animate again on Android — they used to stand frozen in a T-pose while the world moved around them |
| ⏳ | Games that stopped part-way through loading now finish — the loading bar used to stick and never move again |
| 🌒 | Coming back to a game no longer leaves a black screen after a call or a switch to another app |
| 🔧 | Installing a game on Android no longer silently skips part of it — a game left half-converted could not start at all |
| 🌧️ | Contre Jour now plays — it died before its first frame, and again every time you looked away |
| 🛢️ | Feed Me Oil gets past its first level — it used to keep drawing beautifully and stop taking taps |
| 📦 | The Android download is about 14 MB smaller |
Upgrading on Android? Just this once, uninstall WPR first. Every release up to 0.1.03 was
signed with a throwaway key, so this APK will not install over them — Android turns it away as
"App not installed". Uninstalling clears your installed games with it, so you will need to add
them again. This is the last time: from 0.1.04 onward every release is signed with the same
key, and updates install straight over the top with your library intact.After that there is nothing to do — the first time you launch each game it says
updating patched assemblies… for a moment and sorts itself out. On Windows, press Repatch
on a game's page to pick up the splash-screen fix and the file-name fix below.
Games now fill the whole screen
Some games ran in a shrunken box: Android's clock and status icons still along one edge, the
navigation buttons still along the other, and the game squeezed into what was left with black
borders around it.
Windows Phone had no such thing as a windowed game. A game either had the whole screen or it was
not running, so the question "do you want the whole screen?" was one no game ever really had to
answer. WPR asked anyway, and took silence for a no — so a game that never got round to answering
was politely given a smaller screen, and Android kept its own bars on top.
WPR no longer asks. On a phone, the game gets the screen.
Two games show the two ways it went wrong. Final Fantasy never answers the question at all.
Fight Game: Rivals does answer, and asks for the whole screen — just a fraction of a second
too late, once the screen has already been handed out. Both now fill the display.
Of the 307 games checked, 14 were in the shrunken box, all of them XNA games:
Bubble Town 2 · Burn the Rope · Butterfly · Contre Jour · Fight Game: Rivals · Final Fantasy ·
Final Fantasy III · iBomber Defense · James Patterson's Women's Murder Club · KenKen ·
Storm in a Teacup · Tetris (both releases) · Twin Blades: The Reaping Vanguard
If one of those is a game you gave up on, it is worth another look. Every other game was already
filling the screen and is unchanged.
Windows is unaffected: games there run in a window on purpose, and that has not changed.
Games stuck on their splash screen
Fight Game: Rivals would show its studio logo and stay there for ever. Not frozen — the game
was running perfectly happily, still noticing every tap — it was simply waiting for its first menu
to arrive, and that menu was never going to load.
Many games don't build their menus in code. They describe them in data files — this button here,
that picture there — and read those files when they start. To read them, the game has to name a
few of Windows Phone's own building blocks.
When WPR installs a game, it rewrites those names so they point at its own replacements. There was
one hiding place it had never looked in, and any game that kept a name there was left pointing at
a piece of Windows Phone that no longer exists. The game then asks for its first screen, gets
nothing back, and waits.
It goes wrong quietly, which is why it took so long to find: nothing crashes and nothing is
reported. The game just never gets going.
Fight Game: Rivals is the only game in the 307 checked that used that particular hiding place, so
this is a fix for one game today — but it was never a problem specific to that game, and it
depended on how a game was built rather than on what it runs on. Windows was affected exactly as
much as Android.
Doodle God closed itself a second after you started it
Doodle God got as far as its second studio logo and then vanished, back to the games list with
Error executing application.
When a Windows Phone game starts up, the phone tells it so. When you come back to a game you had
left running — after a phone call, say — the phone tells it that instead. Two different
messages, and a game is entitled to answer each one differently.
WPR was sending both, and sending them twice, because a handful of games only ever set themselves
up in answer to the second one and sit there showing nothing without it. Most games shrug that
off. Doodle God reads "you're back" as "set yourself up again from scratch" — and it already sets
itself up on its own while the logos are showing — so it ended up doing that work three times
over. The second time round it went to add Adventurers to its list of elements, found
Adventurers already on the list, and fell over.
WPR now keeps a short list of games that should only ever be told they are starting. Doodle God is
the only game on it today. Games that depend on the other message still get it, and nothing else
about how games start has changed.
Nothing about this was specific to Android — the same thing would have happened on Windows.
Fable: Coin Golf, where every course was a black screen
Coin Golf's menus always worked. Picking a level was where it fell apart: the loading screen would
give way to a conversation with Mark, and behind that conversation the loading screen simply stayed
where it was. Then the course itself arrived as a black screen — the score, the buttons and the
wooden frame all present and correct, and nothing at all in the middle where Albion should be.
Two entirely separate faults, both of them in WPR rather than in the game, and each one enough to
ruin it on its own. Both are fixed, and the game now plays through: courses draw, the coin fires,
scores save.
The screen was never being wiped.
A game draws a new picture sixty times a second. Most start by wiping the screen and painting the
new one from scratch. Some don't bother — on a real Windows Phone the handset gave every game a
blank screen to start from, free of charge, so wiping it yourself was wasted effort.
WPR wasn't giving games a blank screen. It was handing back the last picture the game drew, still
sitting there. For almost every game that changes nothing, because they paint over every pixel
anyway. Coin Golf paints over some of them and trusts the phone for the rest.
That one difference produced all of it. The old loading screen stayed put because the new course
was, as far as the leftovers were concerned, behind it — so the course lost and was never shown.
And anything the game drew see-through, it drew on top of its own previous attempt, over and over:
a gentle fade darkened a little more every frame until it hit black and stopped, and the character
cards that slide in left a row of about ten copies of themselves smeared across the screen.
WPR now wipes the screen after every frame, exactly as the phone did.
Sixteen of the 186 Windows Phone games in the library contain no screen-wipe at all, and there will
be more like Coin Golf that have one and never reach it — so this is not a thing that can be counted
from the outside. Nearly all of them were painting over everything anyway and look identical:
Doodle Jump and Tower Bloxx New York were compared frame by frame, before and after, and are
unchanged. Coin Golf is the game where it mattered.
And the scenery never loaded.
A Coin Golf course is assembled from pieces — trees, fences, walls, bridges — and each piece names
the picture it should be painted with. Those names are written as directions rather than addresses:
go up two folders, then take this file.
WPR was following those directions but refusing to step above the top of the game's own content
folder, so every one of them arrived somewhere no file lived. 113 pictures — every tree, every
fence, every shadow — quietly failed to load.
Quietly is the problem. A picture that can't be found is treated as optional, on the grounds that a
game is usually better off missing a decoration than refusing to start. So nothing was reported and
nothing crashed; the course was simply built out of nothing, and drew as a flat white shape.
Directions that step above the content folder now work, and the course is built out of what the game
actually shipped.
Neither fix is specific to Android or to Windows, and neither needs a reinstall or a repatch —
launch the game and it is there.
Battlewagon's missing menu, and the backslash behind it
Battlewagon started, drew its castle, its tree and its sheep, animated the clouds — and never
put a menu on top of them. It sat there quite happily doing nothing, for as long as you left it.
The game was not stuck. It was throwing the same error away sixty times a second.
Somewhere in its startup Battlewagon asks to read a file called Content\Credits.xml. That file
is right there in the game, spelled exactly that way. On Windows it opens without fuss. On Android
it does not open at all — because the \ between Content and Credits.xml is only a folder
separator on Windows. Everywhere else it is just an ordinary character in a name, so Android went
looking for a single file called, in full, Content\Credits.xml, and reasonably enough did not
find one.
Battlewagon has no answer for a missing credits file. It carried on without it, one piece of its
title screen left empty, and every frame after that tripped over the gap — which is why the
background kept moving and the menu never came. Nothing was reported, because the game caught its
own error and said nothing.
WPR now understands what a game means by that kind of name. Each platform states what its own
filesystem does — Windows accepts both slashes, Android accepts only one — and WPR translates
where it has to.
This is not a Battlewagon quirk. Every one of these games was written on Windows, where the two
slashes are interchangeable, so the habit is everywhere: 7 of the 26 games checked have at
least one file written this way and one has 89 of them. Most get away with it because they reach
their files by another route, and the ones that don't fail as quietly as Battlewagon did — no
error, just something missing. If a game has been behaving oddly on Android in a way nobody could
explain, this is worth a retry.
While we were there, WPR also got better at finding a file a game names without saying where it
is. Windows Phone games could assume the game's own folder was the obvious place to look; some of
them say settings.xml and expect that to be enough. It is now.
This one needs a repatch. On Android it happens by itself the next time you open each game. On
Windows, press Repatch on the game's page.
The T-pose, and why Android draws games differently now
Mirror's Edge on Android drew its city beautifully — the lighting, the reflections, the long
white corridors — and then stood every single character in the middle of it with their arms out
sideways, frozen, sliding around the level without ever moving a limb.
A character in a game like this is a skin stretched over a skeleton. For every point on that skin,
the game stores which bone moves it — a very small number, one of a few dozen, stored in the most
compact way the game could manage. Some phone graphics chips do not accept numbers stored that
compactly for this particular job. They do not complain; they simply hand back nothing. Every point
on the skin then reads "bone zero", bone zero is the one that never moves, and the character stands
in the pose it was modelled in.
WPR now converts those numbers into a form every phone accepts, before the game is ever drawn.
Nothing the game can see has changed — it still gets the skeleton it asked for.
That fix also cleared the way for a bigger one. WPR had been avoiding the newer of the two ways
Android can draw games, because the T-pose was blamed on it. The T-pose was never its fault, and
avoiding it was costing more than it saved, so Android now uses it. Two long-standing problems
went with the switch:
- Games that stopped part-way through loading now finish. Many games load in the background
while showing you a loading screen. Under the old drawing system that background work had to
queue up and wait for the screen to be redrawn — and a game that was waiting for the loading to
finish before redrawing anything waited for ever. Neither side was broken; they were each waiting
for the other. Fable: Coin Golf stopped at the 33rd of its 602 pieces of scenery every single
time. It now loads all of them, which is how it gets as far as the courses described above. - Coming back to a game no longer leaves you with a black screen. When Android takes a game off
the screen — a call, a notification, a switch to another app — it throws away the surface the
game was drawing on. WPR now notices and builds a new one. Before, the game carried on drawing
into something that no longer existed: still running, still responding, showing nothing.
A crash that could hit a game asking the graphics chip to hand back data it had already sent is
gone as well. On a phone that request was never actually implemented, and calling it took the game
down instantly. WPR now keeps its own copy and answers from that.
This is the broadest change in this release, and it touches every Android game rather than a named
few. Windows is completely unaffected — it has always drawn games a third way, and still does. If a
game looked right on Android in 0.1.03 and looks wrong now, that is worth reporting.
Installing a game on Android could silently skip part of it
When WPR installs a game it rewrites the parts of it that reach for Windows Phone, pointing them at
its own replacements instead. On Android one step of that rewrite could fail for a reason that had
nothing to do with the game — it needed to look something up in a file that, on Android, is never
on disk in the first place. When it failed, WPR left that piece of the game exactly as it was. A
piece left alone is a piece still asking for Windows Phone, and Windows Phone is not there, so a
game that needed it stopped before it started.
The awkward part was that a game left alone looks untouched rather than half-finished, so
nothing downstream could tell anything had been skipped. It now does the lookup a different way and
no longer needs the missing file.
Across a 36-game phone this was hitting two games in the most damaging possible place — their main
file. Windows was never affected: the file it needed is always on disk there.
This one needs a repatch too — on Android it happens by itself the next time you open each
game. It removes a reason a game could fail to start; a game that still will not start is failing
for some other reason.
Contre Jour, and games that died when you looked away
Contre Jour never drew a frame. Four separate faults were stacked behind that, and each one on
its own was enough to stop it:
- It asked the phone how much memory it was allowed to use. WPR did not know, and said so in a
way a real Windows Phone never would — real hardware refuses the question outright, and games are
written to expect that refusal and carry on. WPR's polite "nothing" was the one answer the game
had no plan for, and it died in its own startup. - Its tilt-controlled menu asked the accelerometer for its current reading, and WPR had put
that reading on the wrong shelf. It was there, and the game could not reach it, and it tried
again on every frame the menu was open. - Saving your progress crashed the game. WPR's encryption of save files had never been written
— it returned nothing, and the game fell straight over when it tried to use it. Contre Jour saves
whenever it loses focus, which on a phone means every call, every notification, every switch
away. So the game did not merely fail to save; it died at the moment you were interrupted. - And it closes a file twice, in a way Windows Phone tolerated and WPR did not, which killed
the game on exactly the same path.
All four are fixed, and Contre Jour plays. None of them were really about Contre Jour: any game
that encrypts its saves was losing them the same way, any game with tilt controls was reaching for
the same missing shelf, and 56 places across the library ask the memory question that started it.
Feed Me Oil, which drew a perfect picture and stopped listening
Feed Me Oil would get you into the game and then quietly stop taking part. Everything still
drew — the scene, the oil, the whole screen, at full speed — and nothing you tapped did anything,
and nothing moved on. It looked frozen without ever actually being frozen.
That shape is worth recognising, because two completely separate faults produced it and both will
again. A game draws in one place and thinks in another. If the thinking half hits an error it
cannot handle, the drawing half carries on regardless — so the game keeps painting a flawless
picture of a world that stopped. A game that looks alive but ignores you is not hung; something is
failing once per frame somewhere you cannot see.
Two of those were fixed here.
Its levels are pictures, and WPR could not read pictures. Feed Me Oil works out what is solid in
a level by loading a PNG and looking at the pixels. WPR's picture-reading had never been written —
it handed back an image one pixel wide, with no pixels in it, and a list of pixels that was the
wrong length into the bargain. The game measured what it was given, believed it, and the first tap
sent it straight off the end of its own collision grid. It is now a real image reader, so any game
that loads an image this way gets the picture it asked for.
Changing the music. When Feed Me Oil switches tracks it asks to stop the outgoing one — but it
has already made a note of the incoming track by then, so it goes looking for the wrong thing,
does not find it, and then tries to remove the thing it did not find. That is a mistake in the game
rather than in WPR, and it lands in the worst possible place: the failure escapes through the very
routine that reads your taps, so from that moment on every frame took the same path and died in the
same spot. WPR now adjusts the game as it installs it, so that "remove the thing I did not find"
does nothing at all — which is what it meant in the first place.
Neither fault was Android's. Both were measured on a Galaxy S24 and on Windows, failing at exactly
the same moment: the story cutscene handing over to level 1.
The music fix needs a repatch — on Android that happens by itself the next time you open the
game; on Windows, press Repatch on its page. The picture fix needs nothing.
A smaller Android download
About 14 MB smaller. WPR was shipping a graphics diagnostic library that was only ever loaded on
developer emulators, never on a real phone. It is no longer included.
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
Built from commit 2df1e6e.