Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[HonestFlames]

From a discussion that began on Facebook, I've crawled back to this forum to talk about a Flappy Bird clone and how quickly one could be put together.

If I were in practice, I think that the basics could be put together in maybe 30 minutes with just the assets to tidy up after that.

Use a dual playfield screen and hardware scroll the pipes across the foreground. Use a sprite for Flappy Bird and the current score.

Display width of Flappy Bird looks like 176x256, just roughly judging from spacing of pipes (pipes are 32 pixels wide) . Could open a screen at 192 width and possibly use a sprite to mask 16 pixels of the screen on the right to keep things looking correct and not upset the game balance by giving the player any more advance warning than in the original game.

This is a very rambling post and I'm tired because it's late.

[KevG]

Interesting....

I'm surprised nobody has had a go at this already.

If I've got some spare time at the weekend I might have a crack at it.

[HonestFlames]

I've bumped straight into the dual-playfield bug where it wont' scroll smoothly using Screen Offset.

I guess this is what I read in another thread and I need a patched/fixed amos.library

**edit**

I managed to grab the fixed library. Phew!

What I've done today is figure out the real play area for the game (176x208) and the scrolling speed, which is approx 2 seconds for a pipe to traverse the screen, which is 1.5 pixels/sec.

Flappy himself is 17 pixels wide, which is annoying. There's also 5 colours + background for him.

To implement him as a single hardware sprite would use up 4 sprite channels. This might make it tricky for the game over score display or where he is on the same horizontal line(s) as the current score (which I was going to use hardware sprites for).

It's possible to split him in two. A top 16x7 pixels using a regular 4-colour sprite and a bottom 16x5 using a 16-colour sprite. Might have to do this, but for now I'll go with a single sprite to keep things simple.

[BooBoo]

Unknown to me of this thread I had also done a port but did not know about the dual playfield bug -Ill see what happends and maybe upload.

[HonestFlames]

I'm pretty much done, but now the sodding collision detection isn't straightforward because you can't (it seems) check sprite->playfield collision, which I was kinda relying on.

Now, because I've pretty much bodged the rest of the code together (but faithfully recreates actual Flappy Bird play), it's a lot of work to sort out the collision detection. *sigh*

**EDIT**

Aaaaand now that I've copied/redrawn the Flappy Bird background, the play area width is actually 144 pixels, not 176.

Time to make some changes!

**EDIT2**

Attached ADF of the source and assets after I made change to narrow playfield and some other tweaks.

[bruceuncle]

I'm pretty much done, but now the sodding collision detection isn't straightforward because you can't (it seems) check sprite->playfield collision, which I was kinda relying on.

Check out these posts for your collision detection.  I've pulled the AMOS code apart and finally worked out how to use those instructions.  The AMOS Pro manual's got it all wrong!

First post and Second post

Great to see someone making stuff with AMOS!  Congratulations mate.  I hope this enables you to complete it now. 

[gibs]

My version ^^

https://www.youtube.com/watch?v=fwdgKDXIjW8

[Lonewolf10]

Attached ADF of the source and assets after I made change to narrow playfield and some other tweaks.

What did you use to compress the attached archive? My version of 7zip says unknown compression method!

[HonestFlames]

So the collision detection now works and I'm starting to flesh it out a bit. Starting at the beginning, I worked on the title screen.

How to overlay the Flappy Bird floating logo? No spare palette entries in the background playfield. No spare palette entries in the foreground, either. A big, 4-colour sprite would do it. Have to use AMOS' computed sprites.

Next problem with that is there's no direct control over which hardware sprites AMOS decides to use for the computed ones, meaning a palette clash with the first couple of computed sprites and the sprite for Flappy himself...



Notice also that there's an odd corruption on the lower part of the second computed sprite (the 'ap' in 'Flappy'). This disappears and reappears depending if the Flappy sprite (a 32x16, 16-colour computed sprite) is vertically below or above the logo.

Digging back in my memory, using the Set Rainbow and related commands may let me set a separate palette for different areas of the screen, which would solve the colour problem perfectly. No clue on the strange corruption to one of the sprites.

So, I fire up a quick test project to learn how to use the Rainbow commands. It's an absolute no-go. Set Rainbow cannot assign a rainbow to a colour index beyond the number of colours assigned to the screen. It's impossible to "Set Rainbow 17..." on a 16-colour screen, which means it can't touch the sprites on a dual-playfield screen.

So, this was a dead-end and I probably should have saved myself the time and stuck the logo graphic in a separate screen displayed on top of the dual-playfield screen. So much easier. No drawbacks at all!

I'm working fairly closely to this video for my reference: https://www.youtube.com/watch?v=wmnpxUMMfu0

But... I'm using the logo from the updated version of Flappy Bird, because the original logo looks like it reads "FrappyBird".

At least I completed the background grapic.

[HonestFlames]

My version ^^

https://www.youtube.com/watch?v=fwdgKDXIjW8

Brilliant stuff! Beat me to it

[HonestFlames]

Attached ADF of the source and assets after I made change to narrow playfield and some other tweaks.

I'm using version 9.20. I've just checked and it unpacks fine here?
What did you use to compress the attached archive? My version of 7zip says unknown compression method!

[SamuraiCrow]

If you're using computed sprites, you only have to avoid sprites #0-7 because they lock the hardware sprites associated with them from being multiplexed.  Using only sprites 8-63 will allow multiplexing just fine, but one question:  Why aren't you using a separate single-playfield screen to overlap the background display for the title screen?  Amos screens will fall back to the underlying screen and palette at the bottom, unlike AmigaOS screens.  This will allow the title to have an independent palette from the background playfields anyway, it just won't be transparent.

[HonestFlames]

@SamuraiCrow

For the title screen, I have avoided sprites 0-7.

I had the large logo grabbed as a single object, to be displayed using a single computed sprite. The palette of the left-most elements of the computed sprites (using hardware sprites 0 through 3) was shared then with the computed sprite for Flappy.

First thought was to manually split up the logo into 16-wide sprites and see if I could persuade AMOS to use computed sprites but avoid using the same real hardware sprites as Flappy, so they could use separate palettes. This wasn't going to work, though.

I tried it though, and the result is the screenshot in my previous post. Weird corruption in the second computed sprite (the 'ap').

I then thought to solve the shared palette problem by using a copper-list to control the palette. 'Set Rainbow' doesn't allow it, though.

Soon as I realised that, I also realised I was a dumbass and I should just be overlaying a standard screen to display the logo, just as you say!

Why didn't I think of it first? Age. Last time I was trying to be this clever was 20 years ago.

[FOL]

I have to ask WHY.
Everyone bangs on about this game. It was a super mario rip off and thats why it got canned.

[Hungry Horace]

It's nothing like mario apart from the pipe graphics??

Been playing flappy nyan cat a lot lately, so I might do a rival ... Horace Jet Pacing sometime...

It's very addictive, but i think the reason it's so well known is because the author pulled it from distribution.