as of last year, firehauzer is postponed indefinitely. :p
It's been a while since I was last active here, huh.

Anyway, I haven't seen a bubble shooter game made for calculators yet, so I thought I'd make one.
Most of the game mechanics have been programmed in, all that needs to be implemented are the projectiles, the levels, and potential optimizations.
I will put the code up on Github soon.
I used Rembound's tutorial on making bubble shooter games as a guide.
Demo image:
Hey cool - I love Bubble Bobble etc - would be a great addition to the CE's library when done.
Some more progress, there's a bug in one of the functions where converting an X coordinate of value 0 to a grid position gives 1 instead of 0, which you can see here:

I've made a bit of progress on this in the last few days! I managed to fix most of the bugs involving the basic mechanics, and now the bubble snapping part is working! Once I have the survival part of the game finished, I'll publish the code on Github.
SomeCoolGuy wrote:
[size=7]
Anyway, I haven't seen a bubble shooter game made for calculators yet, so I thought I'd make one

https://www.ticalc.org/archives/files/fileinfo/245/24578.html
It doesn't contain the source, though, so it's probably unhelpful to your development efforts.
Hey awesome, I really enjoy these bubble shooter style games - they can be very addictive.

Love the colours too.
First, the bubbles. I tried to scale them to fit the image space given, and I think it gives the grid a more full look.
Secondly, though the bubble-snapping mostly works, I've been seeing some problems where the bubble snaps to the wrong tile. In the image, the first shot's a bit questionable, and the 2nd and 4th shots end up on the wrong tile. I have an idea on how to fix it, though. Also, I've uploaded the code here.

I found the issue! I just typed the wrong variable in the coordinate to tile index function! Now it's acting a lot more natural. I updated the code on Github to account for this.

Hey dude, looks colourful!

Is there any way to speed up the bubbles or are they supposed to be at that speed?

Anyways, keep up the good work!
Hey guys, it's been over a year, but I'm back! School and stuff has been kicking me in the a, but I hope winter break will at least give me some time to work on this project! I know I said I would upload the game once I had the survival part finished, but I've been having trouble with memory leaks, so I uploaded the current version here. I've added some code (albeit messy) to help me find the source of the memory leaks, but right now I only gathered two things:

1. As I use the program, some pointer locations keep increasing until a null-pointer error (handled with a message and exit) happens as a result of a bubble being attached to the grid.
2. If I leave the program alone, the bottom of the screen starts glitching, leaving a pattern of black and white pixels. Shooting a bubble results in a null-pointer error, same as mentioned.

If anyone's interested in helping me it would be much appreciated!

On a happier note, I added the score on the left side and a basic popping animation!

There is so much memory being leaked, here are a few examples that I found:
- printFloat leaks 10 bytes each time it is run (here for example)
- uint8_to_bin will leak 9 bytes each time it is run (although I guess it's not used)
- findCluster will leak a lot of memory every time findFloatingClusters is called, as is done here, for example
- getNeighbors has some memory allocated and assigned to its bubbles member, which is not freed in cases like this, where just the malloced bubble list is freed (here), and also means that since this is called within findCluster that that will leak even more
- and so on, I'm getting bored now...

Anyway the moral of the story is that you shouldn't use dynamic memory like this. Dynamic allocation is bad, as it's slower and more prone to bugs than just using local or static variables. Here's the toolchain's more detailed explanation why for further reading.

I'd recommend just scrapping anything that includes malloc and using statics for everything instead, you'll drive yourself crazy trying to fix every issue with these memory leaks at this point.
Why are all the files on GitHub "Added files via upload" when the toolchain has a nice page explaining how to properly use git here: https://ce-programming.github.io/toolchain/static/git.html
So a number of updates:

I got rid of all of the memory-leaking code! Granted, there's still a lot to optimize when it comes to speed, but I will get to that soon enough.

I added a proper popping animation.

I increased the speed by decreasing the number of collisions to check; the game now only checks for collisions with non-surrounded bubbles. Not a complete fix, obviously! The game only runs at almost 30 fps when the grid approaches the bottom, which is not ideal.

I added a basic game over screen. I still need to handle victories though.

I am beginning to implement some code for custom levels, as I intend to add a campaign mode in the future.

The next step is just to complete this basic implementation!

Great work on this! Everything looks like it's running quite a lot faster and smoother than it was before, and that new popping animation is very nice. What are your plans for that campaign mode and further updates (besides the optimization that you mentioned)?

Looking forward to more updates!

Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

»
» All times are UTC - 5 Hours

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum