(alpha) Flappy Bird X16 - finally got around to updating my code

[ZeroByte]

I've had this version of Flappy Bird done to this point for well over a year now.



Due to life reasons, I had to drop out of the X16 scene for quite a while, but I've got the bug again, and decided to dust off this old code and finish this game for the X16. It was written for R31 so a _LOT_ changed since then, and it's been quite a headache refactoring all of the various bit shifts into the various VERA registers, but it's back to the point where it compiles and runs correctly, so I should be able to start making forward progress again, and if I stick to my guns and stick to writing sloppy non-project-worthy code, I should be able to have a playable version soon.

However, if my TYPE-A self wins, I'm going to spend the next 2 weeks refactoring the code into modules and different C files, etc, and have lots of work done with no visible progress in the game. LOL.

Anyway, I wanted to go ahead and put this back out into the community that I'm working on this, and I may even do a YT video going through the code, or at least a dev vlog or something.

[Perifractic]

That looks great!

But can you call it Flappy Chickenlips. Kthxbai.


Perifractic, X16 Visual Designer
http://youtube.com/perifractic

[BruceMcF]

11 hours ago, Perifractic said:

That looks great!



But can you call it Flappy Chickenlips. Kthxbai.





Perifractic, X16 Visual Designer

http://youtube.com/perifractic

Sadly, someone recently trademarked Chickenlips in the electronic hardware/software field, so I don't think he can do that.

[ZeroByte]

Update

Looks like TYPE-A me has won out. I’ve ended up spending most of my time refactoring my code into a project and using better coding habits. I’ve almost gotten rid of all global variables that don’t absolutely need to be globals, and most modules are now moved into separate files such as bird.c/.h etc. 

The fact that it's been so long since writing the original code has ended up being a good lesson because it’s like I'm reading someone else’s code. There were plenty of What was I THINKING? moments. The plus side is: now that everything is properly contained within its own circle of functionality, it's much quicker and easier to make use of these things in the main program. For example, I was able to quickly re-task the scoreboard as a 2-byte hex debug output tool so I can see values during execution if I need to.

I have made progress in the game though. The joystick works. I was able to get the title screen knocked out in very short (for me) time last night, now that my functions don’t use global variables. Most of that time was spent implementing the "banners" - the actual title screen game loop took less than 5 minutes. The cool thing was that I was able to make the banner's position controllable by the joystick, and the scoreboard showed the X/Y coords, so I used that to choose the spot on the screen I wanted, and then just wrote the value into my code. No need to change + build + run, then go - hmm - 2 pixels up? (change build run).. no - two more pixels. (etc.)

I also stumbled upon a neat method to make sprite slots dynamic so I no longer have to think about which sprite is the bird or the scoreboard etc. Each object just uses the next available one in the order I render them. Thich let me do something cool - I made the bird leave trails of the last 6 renders by just altering which sprite it rendered to on each frame. That little 'demo' aside, the nice thing is I no longer need to keep track of which objects use which sprite slots, so it's faster and easier to add/remove things as I see fit in my main game code. I can put 8 scoreboards on the screen as debug outputs, showing various things if that's what I need to do, and I don't have to account for the sprite slots in my other objects.

Once I get the basic flow through all of the game states running (which also means I need to draw a few more sprites), I’ll upload the alpha .PRG so folks can try it out while I implement sound and other polish I'm planning.

[AndyMt]

1 hour ago, ZeroByte said:

the nice thing is I no longer need to keep track of which objects use which sprite slots, so it's faster and easier to add/remove things as I see fit in my main game code.

This sounds familiar ? . I do something similar in Brixx and Invaderz for the laser sprites and explosions. The main player sprite and some others use fixed slots, though.

I'm very much looking forward to the end result.

[ZeroByte]

The way it happened was that I had a global variable holding the shadow copies of the sprite regs.

uint8_t spregs[16][8];

The update_bird() routine knew the bird was sprite X and would go through spregs[x][0] = VRAM_ADDR_LO ; spregs[x][1] = VRAM_ADDR_HI ; etc....

While de-globalizing this array, I decided that update_bird needed a pointer to the bird struct and a pointer to the shadow registers. I realized I could pass a pointer to just the specific sprite slot index, and the bird code could just use reg[0]=VRAM_ADDR_LO etc.... and then the function returns a pointer at the next spreg[] index.

So for those reading along who aren't quite following what all this means:

My original version of update_bird() was essentially written such that calling it was like saying "hey bird, go do your thing" - and now it's like "draw THIS bird HERE" - and it's up to the main program to figure out where that might be. I could have 20 birds if I wanted, and the function wouldn't care, now. Previously, it was hard-wired to just the one bird, and it was hard-wired to a particular sprite slot.

[ZeroByte]

Update: The game is now in a basic playable state.

The main lacking feature to implement now is sound. Other main game items are the score (which should just be a few lines of code to implement) and the high score screen that displays at the end of the game. Under the hood, I'm going to convert to using a raster IRQ instead of waitvsync().

Other than that, it's all polish and some bug hunting.

As you can see, I've got a bug where the bird sprite gets cloned and the old copy doesn't get erased.



Bug tracking like that aside, I plan to add the above features plus mouse/kbd support and it should be a done deal.

I'll probably go ahead and upload the PRG to the software library tonight once I fix the ghost bird glitch.