I was going to do one for the TI-83, but then found out someone else had done it already ( http://www.cemetech.net/programs/index.php?mode=file&id=1039 )... it's getting hard to find a platform that hasn't got Flappy Birds ported to it already!
Main problem is graphics; there's no specification about that in the language, so you'd need to be writing to video memory, or do something funky with the print statements
A friend of mine back then was actually in touch with US Gold about coding it (and he was one of the few people who'd have been capable of it). But they suddenly changed their mind and said "no, we're not doing it".
Rob Buckley, Radical Software. I was going to be doing the music. But there wasn't really any point doing even homebrew CPC development after AA folded - no-one to sell it to. http://www.cpcwiki.eu/index.php/Lethal_Moves
Do you know if Rob ever released any of those unfinished things?
It looks like some work has been done recently on a port of SF2 to CPC -- I must admit, it's been a decade since I had a working CPC... I would like to get one, but maybe emulating things is best at this point.
I'm saddened that there's no kickass SID soundtrack for the game. That would have been a great way to show off the C64's technical advantages over the iPhone ;)
I think it makes more more sense as a C64 game than anything else. It just fits the era and machine so well. Made me think back to the good old days where I would spend all day playing games on my C64.
The earliest game I remember where at least one of the levels used the same game logic was Dragonsden from 1983.... But there were at least one more that I can't remember the name of...
Well, it was written in assembly anyways, so you can decompile it, but there are many macros I used, so it might be hard to read (for example scrolling is done without a loop, just 1000 separate instructions). There's so much spaghetti in there. I'll probably release that once I have some time to clean up a bit!
Beautiful work. In only 64K of RAM and probably more fun than the phone version! :) Makes me so envious of people that actually have a working C64 to try this on!
Technically yes, but the system mapped the ROM into the RAM and so only 38,911 bytes were available to the user. There were various tricks game makers used to get at the mapped, normally off-limits RAM however.
These days it is so much easier to have access to all kinds of technical information on the C64. I remember travelling half a day to the single bookshop that sold assembler books. Learning anything beyond those books was mostly a matter of figuring out other people's code (e.g. the 'sprites in the border' hack).
Pretty normal tricks for game makers. Someone writing this back in the day probably would have been able to easily use them, if they needed to. Not that this is exactly a game with a ton of art assets.
Hardcore was keeping data in the RAM normally hidden under the audio and video chips' address registers. Or the screen character color attribute RAM.
I think it is possible to get exactly 64Kb - 2 byte.
The first two byte should not be written randomly as they tell the system whether it should include the ROM or not.
If you use interrupts then the top few bytes (2 or 4 bytes, can't remember) are also occupied by a jump addresses.
Top 6, $FFFA-$FFFB and $FFFE-$FFFF were NMI and IRQ. $FFFC-$FFFD are the 'cold start' address that's run on reset, although as you point out, if you're not using them, they are free RAM.
I think that person meant the game code was actually using 38K of RAM out of the 64K. I'm assuming the system itself may be using some of the total memory?
The system itself is using a few bytes here and there if you let it. Only a couple bytes are totally off limits if you bank switch out the ROMs and turn off interrupts.
I still boot into x64 from time to time to play old games. Games that are much more playable than flappy bird. Sometimes I also like to listen to sid music while working.
Not necessarily. The word just means [trans]port to another platform. It's only relatively recently that writing automatically portable code has been possible, and even then there's usually some modification involved, otherwise we'd just call it "recompiling".
It has been used this way in relation to games for years. Game ports of the 80s and 90s very often involved complete rewrites from the arcade version, sometimes without access to even the original graphics.
I remember reading accounts of ports where the porters were not even given a spec of any sort, but were lent an arcade cabinet of the original and had to essentially test there way through everything to figure out what to implement.
I wanted to emphasise trying to stay as close as possible to the original as possible, while still being a C64 game. I didn't have access to FB source, so it's just reverse engineered. It's still in need of tweaks and fixes tho (I spent 2 days on it).
I'm probably equally rusty, but I believe ",8,1" loaded programs written in machine language, and ",8" was for BASIC programs (at least that's what I recall doing). So it looks like the port was written in BASIC.
,0 The program will be loaded to the start of BASIC memory (2049/$0801)
,1 The program will be loaded absolute, i.e. to its stored location defined by the first two bytes in the binary file. Needed for machine language programs.
Just because it doesn't have the ,1 doesn't mean it's written in BASIC; it could still be written in machine language with a BASIC stub that executes the actual code (which is loaded into the BASIC memory area but isn't necessarily BASIC) when you type RUN.
The first argument, ",8" caused the load to come from the attached disk drive, rather than the default cassette interface. The second argument, as explained by others, was to load binary files into their defined locations.
So you could also load binary programs from cassette with a LOAD "*",1,1
Probably something to do with the fact that the game was (allegedly) pulling in ~$50k/day at the top of the charts in iTunes with very little focus on monetization.
That was combined with an exceedingly simply UX anyone could understand.
And then the developer, to many people's shock, decided to pull the game. He said he didn't want the attention.
Like all popular games - especially the simple ones - there have indeed been a ton of clones pouring into the store.
If my estimations are right, we should see a CSS-only version that doesn't use any javascript next month.
ps. in case someone needs css-only ideas http://liveweave.com/wC3DB2