Just love the game and wondering this might be an interesting project?
8-bit NES can be run by various emulators on various platforms and I think 8-bit CPU is good enough for such tiny game... but unfortunately I am not good enough to make one!
There already is one. It's called Balloon Trip, and it was released soon after the launch of the Famicom.
Splashy Fish is a clone of Flappy Bird, which is a clone of Piou Piou, which is ultimately a clone of SFCave. I don't know to what extent SFCave was inspired by Balloon Fight.
I'd make something, but I'm tied up with other projects at the moment.
Since the title says "8-bit" rather than "NES" I'll just point out that there's a
Commodore 64 version and a
Vectrex version.
I may do it as a small side project. However, even though it's a simple game, making a (somewhat) faithful NES conversion isn't completely trivial. But if C64 can have two scroll layers, NES sure as hell better be able to do so as well!
(And yes, I'm aware of games like Battletoads and Bucky O' Hare that have something similar.)
With the commodore 64, the way graphics and the machine works are extremely different from the NES, despite both machine having a 6502 and being designed arround the same time.
The commodore can have 8 sprites per line, but the sprites are 24 pixels wide, and it's possible to stretch them for 48 pixels (the texture is duplicated for two consecutive columns (or 4 columns if a multi-colour sprite is used)), so it's possible to have 8*48 = 348 pixels of sprites in a line, larger than the standard 320 pixels of resolution the machine have after the borders are removed !
So it's easy to have more than 100% sprite overlay without any hardware trick, something not doable on the NES, if there is no other sprite at all on that line and if a detailed texture is not required.
thefox wrote:
I may do it as a small side project. However, even though it's a simple game, making a (somewhat) faithful NES conversion isn't completely trivial. But if C64 can have two scroll layers, NES sure as hell better be able to do so as well!
(And yes, I'm aware of games like Battletoads and Bucky O' Hare that have something similar.)The Sword Master CHR flipbook trick would easily be able to do the parallax scrolling seen in that C64 example.
rainwarrior wrote:
The Sword Master CHR flipbook trick would easily be able to do the parallax scrolling seen in that C64 example.
Yeah. Metal Storm does the same thing. But it would end up eating a fair chunk of CHR data depending on the size of the scrollable area. I guess it wouldn't too bad. It would probably be possible to use CHR-RAM for this as well, but it's probably not worth the effort.
City Connection works around it by scrolling the playfield tile-by-tile on top of the distant background graphics, but that might be too jerky.
If you think you can do it in 12 days, feel free to enter it in the compo.
I'll make one with whatever you want, but I'll only do it if you pay me
$1000 (or best offer).
Drag wrote:
I'll make one with whatever you want, but I'll only do it if you pay me
$1000 (or best offer).
That blog is funny as hell. And depressing at the same time.
Even Sesame Workshop is in on it, with the HTML5 game
Flappy Bert.
Since various people brought up CHR switching to fake parallax scrolling...
Would it be possible to design a custom board, or mapper, that makes bankswitching BG tiles much more suitable for a parallax effect? Of course it's more effort and costly than it's worth, but I wondered if you could have a custom board do stuff like that. Bee 52, which uses a UNROM clone, does that pretty well with the clouds going behind some of the scenery.
There's not much more a mapper can do to help parallax scrolling besides offering CHR bankswitching in small chunks, which most of the more complex mappers do.
Well, I guess that something MMC5-like that expanded the capabilities of the name tables and used special tile indexes to indicate the visibility of a second scroll plane, which would have its own tile map and scroll values, would help a lot with complex parallax effects. That sounds terribly complicated to implement though, and you'd still have color problems because the tile attributes would be aligned to the foreground layer.
Ah, I see. Thanks for the answer.
@Thefox: I would love to see how your hypothetical port would come out. You did a damn impressive job porting a flash game almost 1:1 to the NES, so I have faith in you.
OneCrudeDude wrote:
Would it be possible to design a custom board, or mapper, that makes bankswitching BG tiles much more suitable for a parallax effect?
Since this is a tangent, I put my reply
over here. But I believe vertical-only parallax would be surprisingly easy to add.
If I had time, I'd make Flappy Clicker 2048. But that'll have to wait until April.
or Flappy Clicker 2048 saga
Well, if your Sword Master style parallax involved a 32x32 pixel CHR flipbook, with a 1k CHR bank you're looking at 32k of CHR data for that effect, one page per parallax position.
If you had a mapper that could offset and wrap one of the 1k CHR banks on a granularity of a tile (16 bytes) or even 4 tiles (64 bytes) you could cut the data required dramatically, since now you only need 8k of CHR data (8 pages) and the rest of the parallax positions are done with the offset and wrap operation. This would work for wider and smaller flipbooks too, e.g. 128x32 is just as practical this way and still only 8 pages are required. A 64x64 pixel flipbook would also work if the granularity of the offset was 8 tiles (128 bytes).
This scheme could be used for vertical or horizontal parallax alike. The only difference is how to arrange your CHR tiles so that the offset happens in the direction of parallax.
Trying to do it in CHR-RAM would be an interesting challenge. Pushing through 256 bytes per frame could get you a 32x32 pixel scroller but it would require a sizeable blank area at the top of the screen.
rainwarrior wrote:
If you had a mapper that could offset and wrap one of the 1k CHR banks on a granularity of a tile (16 bytes) or even 4 tiles (64 bytes) you could cut the data required dramatically, since now you only need 8k of CHR data (8 pages) and the rest of the parallax positions are done with the offset and wrap operation. This would work for wider and smaller flipbooks too, e.g. 128x32 is just as practical this way and still only 8 pages are required. A 64x64 pixel flipbook would also work if the granularity of the offset was 8 tiles (128 bytes).
To make sure I'm understanding correctly, you mean dividing a 64 tile bank into eight flipbooks of eight tiles each?
Trivial, and far simpler than what I'd thought of in the other post... It's just a 3-bit latch and a 3-bit full adder. A 74'173 and a 74'283. Add the latched value to (Mapper CHR) A4..A6, to produce CHR A4..A6. And something to make it only work for one bank, such as a 74'138.
Since this only modifies address lines, it'll work fine with CHR RAM.
You could hypothetically mix a CHR flipbook with nametable updates, too.
lidnariq wrote:
rainwarrior wrote:
If you had a mapper that could offset and wrap one of the 1k CHR banks on a granularity of a tile (16 bytes) or even 4 tiles (64 bytes) you could cut the data required dramatically, since now you only need 8k of CHR data (8 pages) and the rest of the parallax positions are done with the offset and wrap operation. This would work for wider and smaller flipbooks too, e.g. 128x32 is just as practical this way and still only 8 pages are required. A 64x64 pixel flipbook would also work if the granularity of the offset was 8 tiles (128 bytes).
To make sure I'm understanding correctly, you mean dividing a 64 tile bank into eight flipbooks of eight tiles each?
Trivial, and far simpler than what I'd thought of in the other post... It's just a 3-bit latch and a 3-bit full adder. A 74'173 and a 74'283. Add the latched value to (Mapper CHR) A4..A6, to produce CHR A4..A6. And something to make it only work for one bank, such as a 74'138.
Since this only modifies address lines, it'll work fine with CHR RAM.
The idea is for a 1k window of CHR to be able to add a multiple of 16/32/64 to the incoming CHR address. This would be separate from the 1k CHR banking also needed for the 8 1k flipbook pages.
This would make a nice 64x64 pixel flipbook out of 8k of data, but you could subdivide it (probably with some duplication for wrapping) if you want to make multiple flipbooks within the same 8k of data.
rainwarrior wrote:
The idea is for a 1k window of CHR to be able to add a multiple of 16/32/64 to the incoming CHR address.
So, yes, I did understand you. It's a nifty idea.
tepples wrote:
If I had time, I'd make Flappy Clicker 2048.
Will it have kill streaks and obnoxious dubstep music? Seriously, the wubbing sound sounds like a triangle wave that's being raped and/or reading garbage data.
doctorlai wrote:
Just love the game and wondering this might be an interesting project?
8-bit NES can be run by various emulators on various platforms and I think 8-bit CPU is good enough for such tiny game... but unfortunately I am not good enough to make one!
You can't get more 8-bit than this version for the Atari 2600
http://atariage.com/forums/topic/222161 ... ased-game/It was done in batari BASIC.
Well, this won't include fancy parallax backgrounds nor bear a title of "flappy", but I intend to copy the mechanics of flappy bird for an eventual
multi-app that I'm making.
Edit: spelling errors.
Did anyone else see flappy block? It's part of Roth's 1k series.
http://slydogstudios.org/index.php/1k-series/
I wrote program for NES!
But, my assembler ability is low,so program is spaghetti ;-(
and some comment in the source are written by JAPANESE.
Still, if you like, please look and play and modify the source!!!!
http://sayonari.com/famicom/FamilyBird.zipThis game was created with plans to gift to Shoko Nakagawa is a Japanese idol.
play video on youtube
https://www.youtube.com/watch?v=UuUzPRJnNWEMy blog (written by JAPANESE language ;-( )
http://sayonari.blogspot.jp/2014/05/lv29.html
lol
great!
Looks good! There are some small glitches during screen transitions (the screen "jumps") that appear to be the result of turning the PPU on and off outside of VBlank. These could be easily fixed by waiting for VBlank before turning rendering on or off.
Does Shoko Nakagawa play Famicom games?
I know the birds in that other game are angry because the pigs stole their babies.
But where is this bird going anyway? Obviously the bird is looking for
something in a sewage treatment plant, given all the pipes.
On the other hand, perhaps I'm overthinking things. I did manage to come up with a
plot for a memory game (which resembles that of a game that Valve released a year later).
tokumaru wrote:
Looks good! There are some small glitches during screen transitions (the screen "jumps") that appear to be the result of turning the PPU on and off outside of VBlank. These could be easily fixed by waiting for VBlank before turning rendering on or off.
Does Shoko Nakagawa play Famicom games?
Thanks for your ideas!! I know very small famicom specification. So, I got some ideas from your opinion.
Recently, Shoko Nakagawa bought SuperFamicom.
her blog (May 8) is it
http://ameblo.jp/nakagawa-shoko/entry-11845215042.html