The Void Wars Continue
Kamakaze has been hard at work fixing bugs and making improvements to Voidwars.
Voidwars is a free-to-play space combat strategy game that can be played with only your web browser. A game of Voidwars takes place in real time and generally lasts a month or so. You just need to log in a few times per day, check on your empire issue your orders etc.
It's a far cry from the basic featured game that it once was. It's been slowly evolving to a really rather cool game. Changes to the way research works mean you no longer have to wake up at some silly hour to set the next research going; the tech tree UI lets you define precisely what your scientists should do to advance your technology.
Another nice new feature is the ability to speed up construction of buildings and ships by spending money. This can help you to develop newly acquired planets into useful outposts much faster.
Endless tweaking, balancing and revamps of the combat system have made for some very strategic space battles. A collection of different weapon and armour types, along with different classes of ship hulls means that there is no one winning strategy for building your fleet. But of course focussing on building just one type of ship will leave you vulnerable to someone who notices this. A balanced fleet is often best.
I'm no expert though, as I've yet to actually win a game…
If you've played Voidwars before, now might be the time to give it another go. And if you haven't, well… what are you waiting for?
There's a trial game available (it resets once every week) to get a feel for what the game is like before you commit to a full game.
Posted: 2008-07-27 13:58:25 UTC by Xiven | Cross-references (0) | Comments (0)
Acidic
Opera Software has now released a public build of Opera that has a pixel-perfect rendering and a 100/100 score in the Acid3 test.
As stated in the linked post, it is not an Opera desktop build, but Wingogi/Lingogi, the Windows and Linux versions of the reference builds that we use internally for testing Opera's platform-independent core. It will be at least some time before you see a normal Opera desktop build that achieves this pass level.
Note also that this is still not a complete pass, as "the animation must be smooth". Top men are working on this. Top men.
Along with Safari's recent similar announcement, this impressive progress by both parties is great news for web browser interoperability.
Posted: 2008-03-28 13:37:29 UTC by Xiven | Cross-references (0) | Comments (0)
Opera on Acid
Opera internal builds have now reached a 100/100 rating on the Acid3 test!
Congratulations to the core developers, QA, and everyone else who's been working hard on this.
No publicly available build passes yet (so for now you'll just have to take our word for it), and there are still some layout issues to correct*, but Opera plans to a release technical preview version of a working build on labs.opera.com within the next week or so.
Webkit is close behind on 99/100 currently; they may well succeed in releasing a passing public build very shortly too.
* Remember that 100/100 does not mean that the browser passes the test fully, the other two requirements are that the animation has to be smooth and the final page has to look exactly, pixel for pixel, like the reference rendering.
Posted: 2008-03-27 02:18:06 UTC by Xiven | Cross-references (0) | Comments (0)
Learning Curve
Some lessons have to be learned the hard way. Today my lesson was in treating input unicode data carefully.
Last night I received an automated e-mail from my web server's control panel warning me that memory usage had been at 80% for the past 30 minutes. Somewhat worrying, so I looked at where the memory was going. The vast majority seemed to be going to Apache threads, and there seemed to be many more threads there than usual. Not really having time to look into it in-depth, and knowing that the server had been running for a long time, I restarted Apache and left it till tomorrow.
Next day, things are still working fine, and I go in to work. Checking IRC when I get in, I find not one but two messages quoting me the following message from #whatwg on Freenode:
[22:02] <Philip`> The error message on http://www.xiven.com/weblog/search/results?q=%00 seems quite peculiar
The error message in question was an out-of-memory error from PHP in my XML parsing script. The connection with the odd memory events of last night was made...
At first I thought it was just a case of a problem with null characters (%00 is the URL-encoded hex code for null, and nulls can often be problematic). But %00 (or U+0000) was not the only thing that would cause this crash: other characters included %ef%bf%bf (U+FFFF) and %ef%bf%be (U+FFFE), and invalid UTF-8 byte sequences were also causing problems. Additionally, ASCII control characters such as %01 (U+0001) to %08 (U+0008) etc, although not causing the out-of-memory error, would make the XML generated by the website be not well-formed, giving the infamous "Yellow Screen of Death" on Gecko browsers.
The following PHP code was somewhat hastily added to the main script for the website:
<?php
array_walk_recursive($_GET, 'stripInvalid');
array_walk_recursive($_POST, 'stripInvalid');
function stripInvalid(&$v, $k) {
// Strip invalid UTF-8 byte sequences
$v = mb_convert_encoding(mb_convert_encoding($v, 'UTF-16', 'UTF-8'), 'UTF-8', 'UTF-16');
// Remove various characters not allowed in XML
$v = preg_replace('/[\x{0000}-\x{0008}]/u', '', $v); // ASCII control characters
$v = preg_replace('/[\x{000B}\x{000C}]/u', '', $v); // Vertical tab & Form feed
$v = preg_replace('/[\x{000E}-\x{001F}]/u', '', $v); // ASCII control characters
$v = preg_replace('/[\x{007F}-\x{009F}]/u', '', $v); // ASCII control characters
$v = preg_replace('/[\x{2190}-\x{2BFF}]/u', '?', $v);
$v = preg_replace('/[\x{D800}-\x{DFFF}]/u', '?', $v);
$v = preg_replace('/[\x{FDD0}-\x{FDEF}]/u', '?', $v);
$v = preg_replace('/[\x{FFFE}\x{FFFF}]/u', '?', $v);
$v = preg_replace('/[\x{1FFFE}\x{1FFFF}\x{2FFFE}\x{2FFFF}\x{3FFFE}\x{3FFFF}]/u', '?', $v);
$v = preg_replace('/[\x{4FFFE}\x{4FFFF}\x{5FFFE}\x{5FFFF}\x{6FFFE}\x{6FFFF}]/u', '?', $v);
$v = preg_replace('/[\x{7FFFE}\x{7FFFF}\x{8FFFE}\x{8FFFF}\x{9FFFE}\x{9FFFF}]/u', '?', $v);
$v = preg_replace('/[\x{AFFFE}\x{AFFFF}\x{BFFFE}\x{BFFFF}\x{CFFFE}\x{CFFFF}]/u', '?', $v);
$v = preg_replace('/[\x{DFFFE}\x{DFFFF}\x{EFFFE}\x{EFFFF}\x{FFFFE}\x{FFFFF}]/u', '?', $v);
$v = preg_replace('/[\x{10FFFE}\x{10FFFF}]/u', '?', $v);
}
?>
Hopefully that covers everything (checked various docs online as to what characters in XML should be excluded). I haven't had the chance yet to look more in-depth as to why PHP was consuming all memory and apparently crashing Apache threads on certain characters; whether the exact cause is in my code or in PHP's XML parser itself, I'm not sure yet. But for now at least, sanitizing the UTF-8 characters of all input variables should keep things relatively safe. I have little doubt though that there must be a better way…
Posted: 2008-03-15 02:20:24 UTC by Xiven | Cross-references (0) | Comments (0)
WTB
I'd really like to find a trustworthy website from which I can legally purchase and download MP3s or other similar format (non-DRM encumbered of course) of anime soundtrack music.
Is that too much to ask?
Posted: 2008-03-08 21:37:56 UTC by Xiven | Cross-references (0) | Comments (0)