[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 16/01/12 10:38, paul sutton wrote: > > That explains why the .deb file for head over heels (linux version ) is > 15mb where as the original 8 bit game was about 32 k That'll be the 30MB of game data compressed inside the deb. Since the WAV file for the sound of a trumpet is larger than the RAM I had in my ZX Spectrum I'm guessing the game is no longer comparable to the original at least in terms of sampled sound quality ;) Although I note the "ay" 2,404 bytes and the "mp3" version of the music 4MB, whilst audible different is definitely not worth the extra 3.9998 MB of disk space. No really those retro games really are mostly dreadful, and those fond memories are often disappointed by the reality when you fire up your ZX Spectrum simulator and see what the original was like (rather than what you remember, or reworked versions of same). ZX Spectrum http://www.youtube.com/watch?v=Z_5V6LxFNQc Amiga http://www.youtube.com/watch?v=ornJoqJD1Ks Remake 2009 http://www.youtube.com/watch?v=pXCVcEIHSP8 http://retrospec.sgn.net/games/hoh/screenshot17.html I know which I'd rather play. Really the complaint shouldn't be that the modern stuff is bigger, the complaint should be it is insanely bigger, and that we have insanely more choice, things are insanely more complex, and that as a result things often aren't actually much quicker (although the spectrum game would have taken minutes to load off audio tape) or more reliable even if the hardware is insanely faster and more reliable. Games are the least of our worries here. I tried to track down a character set problem on a web application once, and you would not believe how many times a simple string was converted into, out of, or checked for validity as a UTF-8 or Latin-1 string in one POST request to a web server. Some of that was tacky programming by the author, some of it was just poor choices of defaults in databases, but ultimately too many layers, too many languages, and too much complexity. After all that the performance drag was one regular expression in a Perl module eating MOST of the CPU for various reasons, which hints at how stunningly fast it could be if we did it in a simpler cleaner fashion. To an extent the time taken bloats to fill acceptable human experience, but the boot time on my box is no doubt influenced by all the start-up scripts being interpreted, and some of them using different interpreters. All the sorts of things Steve Jobs moaned about in some letter or other... The other day I fired up top, and saw I was using 500MB of RAM before I was doing anything useful. Stopping nagios, Apache, mysql, postfix, ..... etc to get me a stripped down desktop sort of experience reduced memory usage rather less than one would hope, and I still had a zillion processes running some of which I have zero idea of their purpose despite using this distro for a LONG time. I could hazard a guess at "bluetoothd" except there aren't any bluetooth devices in this box as far as I know.... And something seems to have caused the kernel to try and treat my USB hub for keyboard and joystick as a USB2 hub (I can't type that fast), so I had to do some deep magic poking in the kernel to tell it to stop when really this sort of thing should be automatic now. Sometimes a lot of programming complexity to get a simple user experience is justified, but these days a lot of it is programming around other bits of programming because you don't feel empowered to junk the whole boot mechanism for something faster, or throw out entire daemons in pursuit of simplicity. Or realising if you do change the infrastructure you'll break compatibility and thus potential market share. As such if "Linux" survives it might well be by ditching a lot of Unix legacy, and forking off an Android or similar. I think Android proves the idea that "make it profitable and they'll write the apps" is still fine, you don't need everything on day one. Although they have vast resource and a lot of developers I think as much could be done with less. -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq