Forums

http://www.smspower.org/Homebrew/FlipFlap-SMS

Quote

Note: If anybody is able to test, please let me know if this works on real hardware. I have no way to check myself, and I'm eager to know if it works properly.

This game is a port of the popular mobile phone game, Flappy Bird. I assume a lot of people have already played this, but if you haven't, the game is fairly simple: You control a bird (or in this version, Opa-Opa) and tap the screen (press 1 or 2) to flap your wings and go up a bit, but gravity will quickly pull you back down. The aim of the game is to fly through the small openings in an endless stream of pipes without touching a pipe or the floor. Each set of pipes you pass gives you 1 point. The physics of the game makes it quite challenging, and it is fun to compete with others for the top score.

Source code and box art included. Beware: the source code is messy, and comments are scarce. More info in the readme.

I started working on this a year ago, but got stuck and dropped it, as I was pretty new to programming back then. This is my first Master System project, please let me know what you think of it.

I like this. :)

I tried it on my US master system 1. It works well. Only one small problem that I could see. The background on the "press start" page is bright red.

I think I've fixed the title screen background problem. All I had to do was make it load in a full palette of blacks (with one white for the text) on start up. Hopefully, it should be fine now. Other than that, I'm glad to hear that it works.

*EDIT* version 1.30 added to game page.

It plays really well (which is the most important criteria imho), and the card game cover is a really nice touch.

If you were to keep tweaking it, may I suggest possible improvements:
- better death animation
- sound effects
- perhaps move Opa Opa a little to the left ?
- retain high score
- title screen

Again I think it's really good, so being nitpicky here :) the main thing that I feel is missing is an animation frame for when Opa Opa hit an object and is falling. Good job, even more so considering it's your first game and assembly project!

I don't get why it doesn't appear in the list here: http://www.smspower.org/Homebrew/Index?q=order=$:Released

oh, wait, it says it's a 2013 game!

Oops, fixed the date on the page now!

Really cool, and VERY hard! Love the look.

Good spotting, with the year being 2013. I was wondering why it wasn't showing up!

Thanks for the feedback so far. I'll try to implement Bock's suggestions today or tomorrow. I'll add a high score counter, but it will forget the high score when turned off, because I want to keep it in a card game format, and Sega cards don't have battery backup, do they?

They don't! I think it's fine to not save the high-score, it stays in the vibe of the times.
My high-score is 16 so far.

Well done! Nicely executed, and it keeps the frustration from the original intact :) My hiscore is 10 so far.

Great idea to put Opa Opa in!

Can I ask: How is the level generated? I mean - the pipes. They are not totally random, at least so it seems to me...?

Thanks! I'm considering increasing the gap between the pipes by one tile in the next version, because I feel as though this version is a bit harder than the original.

The pipe generation was the hardest part of making this, and was the thing I got stuck on way back last year. Once I had that sorted, everything else was relatively easy.

For my random number generation, I decided to use the generator used in Phantasy Star, which uses the r register as a seed. The code can be found in the code snippets in the smspower development section. I should have tried to make my own generator, but random numbers are a bit too complicated for me, I had a deadline to meet and it just made more sense to use one that's tried and true from a commercial game.

(For this section the numbers I give are in decimal)
The generator gives a randomly-generated byte. The number I was generating was to represent the number of tiles the top pipe is in height. In order to have enough room to generate a top pipe, a bottom pipe and a 6-tile wide gap between the two, this number needed to be between 2 and 11, inclusive. I used an AND operation to effectively remove the four most significant bits of the generated byte, to give me a number between 0 and 15. In order to make this fit within the boundaries, I basically made the program check the number, and if it was 0 or 1, set it to 2, and if it is anywhere between 12 and 15, set it to 11. Hopefully that makes sense. This means that the program is a little bit more likely to spit out pipes with gaps at the top or the bottom of the screen than in the middle. It's a terrible solution, I know, since now the generation is biased. However, I can't think of any better way to set boundaries on the number generator than this. If you, or anybody else knows how to do this, I'd greatly appreciate advice.

BrambleG wrote

The generator gives a randomly-generated byte. The number I was generating was to represent the number of tiles the top pipe is in height. In order to have enough room to generate a top pipe, a bottom pipe and a 6-tile wide gap between the two, this number needed to be between 2 and 11, inclusive. I used an AND operation to effectively remove the four most significant bits of the generated byte, to give me a number between 0 and 15

.

I think it is a great solution! Simple and working. Thanks for sharing. I was imagining overly complex stuff including premade stage segments being shuffled around, when all I needed to think of was making a randomly sized top pipe and make the bottom pipe fit. Ah! :)

You could create a 256 entries table with number from 2 to 11 sequentially layed out and repeated. And when you have your 8-bit random number you should read from that table.

The bias would be smaller: 256/10 = 25.6, so 60% of the values (2 to 6?) would have a 2-3% chance of being drawn more.
You can also tweak the way the table is filled to control your bias toward some values.

Take the randomly generated byte and divide it by 26 (or use a LUT). This will give you a value in the 0-9 range. Add 2, voilà :)

edit: Bock was faster once more. Grrr!

edit again. I wrote 27 where I meant 26.

ps - like Bock I love the game card box art! Looks so slick.

The cards were very cool and ahead of their time.

Alright, I've been working on version 2. A new title screen has been added, Opa-Opa has been shifted to the left slightly, there is a death animation, and I've added a high score counter. Now I need to add sound effects and reduce the bias in the random number generation (cheers for the advice!) and version 2 will be done. Now I need to sleep though, so it'll be done in the morning.

For version 2, you can also consider: 1) Animation for Opa Opa. I think you can grab the flying animation straight from his game. 2) When you move Opa Opa to the left (as announced), keep the counter in place. That way Opa Opa and the counter are not on the same y-axis. 3) Add a little death delay.´

Anyway - it is a great game. These suggestions sprung from my attempts at the real Flappy Bird this morning :)

Version 2.0 is here! These are the changes:

-Now there is a death animation for Opa-Opa
-When Opa-Opa is falling after touching a pipe, he falls a lot more naturally now, instead of just zooming to the ground like before
-Score counter is now white instead of black
-High score counter has been added
-New title screen
-Opa-Opa has been moved slightly to the left on the screen
-Opa-Opa now visibly flaps his wings when button 1 or 2 is pressed
-Reduced the bias in the pipe generation

Unfortunately, again there's no sound. I've been trying for the past few hours, and whenever I try to use PSGLib, it just plays garbled mess constantly, and for some reason if I leave the game on the title screen with PSGLib being used, after a few seconds the game freezes and needs to be reset. Because of this, I've left sound out. Still, every other suggestion has been taken into account.

*MOD* version 2.00 added to game page.

Big improvement! Feeling nicer with the flap and the death animation. Nice work! :)

Great game!
Love the graphics but you sould hand-draw Opa-Opa rotations, it will feel more natural.

BrambleG wrote

Unfortunately, again there's no sound. I've been trying for the past few hours, and whenever I try to use PSGLib, it just plays garbled mess constantly, and for some reason if I leave the game on the title screen with PSGLib being used, after a few seconds the game freezes and needs to be reset.

Garbled mess instead of music? Freeze? It looks like you placed the PSG tune in a different ROM bank and you're not paging it in before the PSGFrame function call (PSGlib doesn't do bank switching by itself...)

I'm here to help if you need it. :)

I've only actually used one bank, so I don't think that's the problem. Also, to be clear, if I actually start the game before it freezes, it successfully plays the SFX (I had only added the flapping sound at this point) but sometimes forgets to play the SFX, and it also plays garbage in between.

Weird indeed!
Library initialized? Are you using SFX and no tunes? Calling PSGSFXFrame only?

I really love the looks of this. Shame that I'm totally useless when it comes to this kind of game. My high score so far is 3.

I tried this on my SMS II yesterday, it has some minor graphical glitches.
A screenshot is attached.

FlipFlap.png (1.24 MB)

(taken with my phone)

Hm... I'll try to figure out what the problem is. Are you using a SMS 1 or 2? Do you have the same problems on the older versions?

SMS II, fwiw. I didn't test the previous version.
I guess it's the same old problem (writing to VRAM too fast)... well, can't be sure of this, of course (and if I'm not mistaken there's still no emulator that emulates VRAM/CRAM corruption...)

I love this game, but I suck at it. Really. My score never went beyond 6.

It worked perfectly for me as far as I could play. I tested it on GenPlusDroid and SmartGear on a gaming tablet attached to a TV:

BrambleG wrote

Hm... I'll try to figure out what the problem is. Are you using a SMS 1 or 2? Do you have the same problems on the older versions?

You aren't clearing RAM before accessing it so e.g. on an Everdrive you're reading values that have been written by the Everdrive OS.

I've attached a version that clears the RAM at the start. This shouldn't be considered a proper new version yet, as I don't yet know if it fixes the problem on real hardware. sverx (and anybody else), if you can, could you try this version and let me know how it goes please?

FlipFlap-SMS-2.1.zip (3.52 KB)

Version of FlipFlap that clears RAM on startup.

FlipFlap-SMS-2.1-src.zip (1.94 MB)

Looks like it has the same problem.
I don't think this is a problem that has to do with RAM as I suppose you're copying tiles from ROM to VRAM...

Yeah, I didn't think that would work. What was that you mentioned before about writing to VRAM too fast? I'm a noob and wasn't aware of there being a "too fast". Should I space my writes out a bit? Perhaps put a push hl, pop hl between each one or something?

Long story short: when the VDP is generating the image on TV (so when it's not in vBlank phase) its timing requires that you don't push bytes to the data port too fast. That has been clocked at requiring at least 26 CPU cycles between writes. Two successive OUTIs are too fast, for instance.
So you either:
- write to VDP during vblank
- turn off screen when you want to write to VDP
- slow down
usually you would end up using two or three of this techniques.
For instance in most of my code I load VRAM contents before turning on the video and update (some) contents when in vblank during game main loop. If you need to update tilemap for the hidden column when scrolling you could do that ensuring you're not pushing data too fast :)

edit: I wish I had studied English better at high school...

sverx wrote

Long story short: when the VDP is generating the image on TV (so when it's not in vBlank phase) its timing requires that you don't push bytes to the data port too fast. That has been clocked at requiring at least 26 CPU cycles between writes. Two successive OUTIs are too fast, for instance.
So you either:
- write to VDP during vblank
- turn off screen when you want to write to VDP
- slow down
usually you would end up using two or three of this techniques.
For instance in most of my code I load VRAM contents before turning on the video and update (some) contents when in vblank during game main loop. If you need to update tilemap for the hidden column when scrolling you could do that ensuring you're not pushing data too fast :)

edit: I wish I had studied English better at high school...

He copies the affected tiles to vram using this loop:

_LABEL_279C_:
ld a, (hl) ; 7 cyc
out ($BE), a ; 11 cyc
inc hl ; 6 cyc
dec bc ; 6 cyc
ld a, b ; 4 cyc
or c ; 4 cyc
jr nz, _LABEL_279C_ ; 12 cyc
ret

So there are 11 + 6 + 6 + 4 + 4 + 12 + 7 = 50 cycles between each write. There gotta be another issue...

BrambleG wrote

Yeah, I didn't think that would work. What was that you mentioned before about writing to VRAM too fast? I'm a noob and wasn't aware of there being a "too fast". Should I space my writes out a bit? Perhaps put a push hl, pop hl between each one or something?

Still it's good to have it fixed. I filled RAM with another value than 00 before running your game and the game didn't start at all. So it seems at some point you were expecting to read 00 from uninitialized RAM. On an Everdrive you're lucky that the Everdrive already clears RAM when it initializes. So only the memory actually used by the Everdrive is non-00 when your game starts.

I also noticed that you're using bc in your interrupt handler but you're not pushing it to the stack. So bc could be overridden inside a loop for example causing the loop to stop too early.

Here's another version. This one turns off the screen when it completely rewrites the tilemap each time the game restarts. It also pushes and pops all the main register pairs in the interrupt handler.

FlipFlap-SMS-2.1.zip (3.53 KB)

FlipFlap-SMS-2.1-src.zip (1.94 MB)

Still the same. I'm starting to think that maybe you're corrupting the tiles after you load them, because it seems there's a black line over some of them but they look overall correct (which wouldn't happen if you were skipping some byte writes...)

BrambleG wrote

Here's another version. This one turns off the screen when it completely rewrites the tilemap each time the game restarts. It also pushes and pops all the main register pairs in the interrupt handler.

You made a little mistake there when you're intending to clear RAM you're actually just reading each byte:
You used

ld a,(hl)

instead of

ld (hl),a

Calindro wrote

BrambleG wrote

Here's another version. This one turns off the screen when it completely rewrites the tilemap each time the game restarts. It also pushes and pops all the main register pairs in the interrupt handler.

You made a little mistake there when you're intending to clear RAM you're actually just reading each byte:
You used

ld a,(hl)
instead of
ld (hl),a

Oops. Thanks for spotting. Here's a fixed version.

I'm getting pretty stumped now. Its times like this that I wish I had a Master System, because it's pretty difficult trying to fix this problem when I can't even test it properly...

FlipFlap-SMS-2.1.zip (3.53 KB)

FlipFlap-SMS-2.1-src.zip (1.94 MB)

Yay, that fixed it :)

Phew, what a relief! So it was a RAM issue all along. I can go ahead and consider that version the "official" v2.1 now.

Great Flappy Bird clone. My only suggestion would be to use different art instead of Mario pipes and calling it Flappy Zone!

Forums

View topic - [Coding competition 2015] Flip-Flap by BrambleG

Rate this entry!