Porting Aquaria To the PSP 25
Apple Prophet writes "Just a few short weeks after BitBlot released the source to Aquaria as part of the Humble Indie Bundle, Andrew Church hacked up an ambitious homebrew port of the game to the PSP. He wrote a detailed synopsis of the technical challenges in an article on the Wolfire Blog, and of course, contributed all of the patches back to the project so anyone with a homebrew-equipped PSP can try it out. Check out the mercurial repository for the source."
Re: (Score:2)
Yea. For the first 10 minutes.
I'm guessing your attention span was too short.
Speaking from experience (Score:3, Informative)
Don't post mercurial repositories to slashdot. Its a fantastic version control system and I use it for all my personal work and a lot of my professional stuff, but exposing a python runtime to slashdotting is not going to work very well.
If I did it again I would just point directly to the source files and let anybody who really needs to see the revision history search for it.
And people: please go light on this server.
It's protected (hopefully!) (Score:4, Informative)
I wasn't the one who posted the story, but I added a Coral Cache redirect for Slashdot referrers after the Wolfire column went live (just in case -- even though we all know Slashdotters never RTFA). People who actually want to clone the repository will presumably know not to use the Coral Cache URL, people who are just browsing shouldn't notice a difference, and hopefully my server will survive the onslaught. (:
Potential Wii/console ports (Score:5, Informative)
From the game's website, screenshots, and hardware requirements it seems possible that this game could be ported to the Wii. The simplistic control scheme (mouse only, keyboard can just be used for starting/exiting game) could easily have it work on pretty much any gamepad for any system. The technical hurdles the dev went through just to get it to the PSP (a platform of much less popularity than several others) suggests he possesses the resolution to get Aquaria on other systems.
The size (200MB) is within Wiiware limits, although I've become skeptical of Wiiware because of the massive price discrepancy between that store and the prices indie developers charge online. Obviously Nintendo wants a worthwhile profit, but when one can get PC versions for a tiny fraction of the Wiiware cost which are largely fixed for a long time, sometimes not going down ever...tends to make you wonder if Nintendo would even be willing to sacrifice anything at all for a much higher exposure of indie titles. But, that's expected of most corporations obviously.
Twenty years ago, games were not far off what many indie titles are today - made by between one and five people with the costs minescule compared to the development houses of today, and involving simple but entertaining and addictive concepts. The difference is that these games circa 1990 sold for $30-50, even some simpler titles that required much less work than certain more elaborate games of the day (Monkey Island, Mercenary series etc) . Considering one can pick up some of the best indie titles for under $5, and get much more hours of entertainment than if that 5 bucks went on a movie ticket or an exorbitant hour using Starbucks wifi...it's pretty damn good value.
Re: (Score:1, Informative)
The size (200MB) is within Wiiware limits
That's far, far over the WiiWare limits. There's only 512 MB storage built into the Wii, and about half of that is reserved for various purposes. There'd be very little space left over if games that large were allowed.
Re: (Score:2)
That's completely correct; apologies for my error. Given that one can purchase a cheap SD card of at least 2GB to insert to the front slot, it seems the actual size limit of about 40MB for Wiiware indie titles is restrictive.
Towards the end of the Nintendo 64's life cycle, Nintendo promoted a chip that allowed more demanding games (Donkey Kong 64 etc) to work. Things like the MotionPlus are sort of echoing this, being designed for a later and somewhat narrow group of titles (thusfar).
Why they can't push SD
Re: (Score:3, Insightful)
<media-exec style="intelligence: low; paranoia: high; pockets: deep">Cause the dirty pirates can use them!!!</media-exec>
Re: (Score:2)
Until a recent (late last year?) update you couldn't *do* anything useful with the SD card. You could put music or pictures on it, and you could put games on it if you didn't want to play them. Anything you actually wanted to run had to be moved back into main storage (moved, not copied, due to piracy paranoia), and then moved back when you were done with it (it couldn't just be quickly deleted because you had to move it the first time, due to piracy paranoia). So the existence of more than one app over 150
Re: (Score:2)
This would be a crown jewel in the Wii Homebrew scene. Not that there aren't plenty of amazing titles already there - this game was [unintentionally] designed to be played with a nunchuck and wiimote.
Re: (Score:3, Informative)
I don't know what Aquaria uses for graphics, but if it's SDL, running it on the Wii should be trivial.
Re:Potential Wii/console ports (Score:4, Interesting)
From the game's website, screenshots, and hardware requirements it seems possible that this game could be ported to the Wii. The simplistic control scheme (mouse only, keyboard can just be used for starting/exiting game) could easily have it work on pretty much any gamepad for any system. The technical hurdles the dev went through just to get it to the PSP (a platform of much less popularity than several others) suggests he possesses the resolution to get Aquaria on other systems.
Just for the record, this PSP port is totally unofficial -- I did it mainly for the challenge of porting (and because I enjoyed the heck out of the game). That said, judging from the Wii's specs, I don't think a Wii port would be too difficult as long as you don't have to copy textures into GPU RAM for drawing. The Linux port uses SDL and OpenGL, so if there's a functional SDL/GL port for the Wii, that could save a lot of time.
Re: (Score:2)
SDL/GL is available on Wii Linux, but running a game under Wii Linux means mediocre performance and only running on "hacked" Wiis. Going the "official" route would require a much more thorough port of BBGL into Nintendo-approved bits. And lots of direct cooperation from Bit-Blot. And a few grand and some legal hassles. :)
Re: (Score:1)
Generation clash. (Score:2, Insightful)
This is an excellent article, showing how many things are often taken for granted by modern software developers. Mr Church did a great job not only porting the game, but also taking time to write about all these things.
For anyone who started programming in "ye good ol' times", techniques used by Mr Church are fairly obvious and were in everyday use. Memory manager, optimizing file speed access - all of that has been used in many games written in 80s/90s. Games had "resource files" with their own index table
More of a progression, I think. (Score:2)
I wouldn't call it a generation "clash" so much as a "progression" from one generation to the next. As one who's been programming for a fair number of years, I certainly advocate knowing the details of what's going on at the lowest levels; if you're not familiar with how caches work, for example, you might have trouble figuring out why a loop over a 2-D array is running so slowly (answer: you have the loops inverted, so every array access is missing the cache). For those who have learned programming in mo
Yup, not the best English here. (Score:1)
Agree that "clash" is not the best expression - I meant a difference, not fight. You are right correcting that.
Knowledge is the key, absolutely. In programming just like in many others areas it became more and more complicated to know and understand all past details - there is just too many of them. People working longer time (like you) have a certain advantage as soon as development is done on something else than the most current generation of hardware and tools (that take care of some details).
I did not g
Re: (Score:2)
Why the hell is there nothing like this in a modern OS?
You can use SDL and get at least reasonably close to what it was in DOS with a bit more comfort and flexibility.
Anyway, the reason you don't get pixel putting in your average OS API is simply that hardware doesn't support it properly. Directly accessing graphics memory is slow and thus instead of accessing the pixels directly, you tell your graphics card to draw a polygon or if thats to high level, you prepare a piece of system memory by pixel-putting and then upload it the the gfx card in one go. Moved mem
Amazing (Score:1)
Where do I download? (Score:1)