[TI-Z80 APP] A puzzle collection games pack

A forum where you can announce your awesome project(s).

Moderator: MaxCoderz Staff

User avatar
driesguldolf
Extreme Poster
Posts: 395
Joined: Thu 17 May, 2007 4:49 pm
Location: $4080
Contact:

Post by driesguldolf »

Meh, got a bit distracted by Team Fortress 2.

Anyway:
Fixed all collision bugs tonight:
Image

Splitter works partially (which is why I carefully placed the cursor then failed the 3rd time resulting in slightly wrong collisions)
The numbers in the end are for debugging.
First one is the number of times the main loop was executed
second is the number of interrupts that have occurred
and the third is the number of 'events' that have been fired. (ball, cursor, splitter movement are all events).
User avatar
kalan_vod
Calc King
Posts: 2932
Joined: Sat 18 Dec, 2004 6:46 am
Contact:

Post by kalan_vod »

Wow, nothing like fixing a vital part of a project/game (collisions) I know I am happy :P
cjgone
Regular Member
Posts: 83
Joined: Tue 18 Apr, 2006 5:33 am
Location: Washington->UC Berkeley '15

Post by cjgone »

Are you using a pixel based collision? Or are the line actually objects, as in, they can be deleted sepereately, not everything at once?

Pretty sweet man.
User avatar
driesguldolf
Extreme Poster
Posts: 395
Joined: Thu 17 May, 2007 4:49 pm
Location: $4080
Contact:

Post by driesguldolf »

kalan_vod wrote:Wow, nothing like fixing a vital part of a project/game (collisions) I know I am happy :P
qft :mrgreen:
cjgone wrote:Are you using a pixel based collision? Or are the line actually objects, as in, they can be deleted sepereately, not everything at once?

Pretty sweet man.
It uses a table to store the level.
Each cell has certain properties (ball bounces on top, bottom, left or right cell border)

The previous level actually looks like this:
Image

(the reason why the balls move into the lower left 'cage' is because the cells on the right allow the ball to move left, while the cells on the left have a solid border on the right. Bugged out after I fixed the collisions)

Therefore, to split a 'cage' (defined as a group of cells which seal a certain area) I have to split the table as well (which is almost done).
As long as I splitted the cages on the light grey lines, most would work fine already.

I considered pixel based levels but that made certain things hard, if not impossible.
1) How do you keep the balls from colliding with other balls (you can use double buffer to avoid bouncing of the cursor, but that wouldn't work for the balls)
2) Scoring. I was thinking of some formula based on the size of the area left. I've no idea how to do that...
3) Outside the level. In a real game, the total area the balls have shrink. How do you know what's inside and what's outside the level?
4) You cannot start to split an area if the cursor isn't inside a level... How do you check for that?

Those are the main reasons for not going for pixel based levels. :)
User avatar
driesguldolf
Extreme Poster
Posts: 395
Joined: Thu 17 May, 2007 4:49 pm
Location: $4080
Contact:

Post by driesguldolf »

Whoo, it works :D
Image

Don't you just love it when your code runs after the first try? 8)

notes:
Speeds of every moving thing are fully configurable. Currently (slowest interrupt, 108 Hz) everything is updated every 4 ints.
At the end, it now displays the table behind the level. It has more use then the numbers now.
The ball didn't move at the beginning. No idea why, it also seems my random ball spawner is broken and tends to spawn the balls on a grid (to avoid spawning them into each other)...

Next up:
Erasing the areas with no balls in it. Time to google a good floodfill algorithm to implement :)
Last edited by driesguldolf on Fri 18 Jul, 2008 2:10 pm, edited 1 time in total.
User avatar
benryves
Maxcoderz Staff
Posts: 3087
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

Post by benryves »

Looks good. :) I need to write a flood fill algorithm myself, so will be interested to see which you pick. Lode documents a few techniques that might give you some ideas. The most intuitive flood-fill algorithms are unfortunately rather stack hungry!
User avatar
driesguldolf
Extreme Poster
Posts: 395
Joined: Thu 17 May, 2007 4:49 pm
Location: $4080
Contact:

Post by driesguldolf »

Yup, stack is a problem. Worst case scenario it would use 768*2 bytes.

Ideas that have been developing themselves in my head:

Based on 4-level floodfill with managed stack:
Instead of a 2 byte return address, you can use a return direction. With 4 directions (left, right, up and down) you can store 4 'directions' in a byte.
Basically you save the direction in which you went flooding, and use that to return to the previous pixel.
Worst case, it would use 192 bytes. You could even use unused hw stack space for that.

Idea based on 4-level scanline floodfill still needs some tinkering :P
Basically the same as described (btw, thanks for that link :)) but mine trick would use less stack. If I understood correctly :P
User avatar
benryves
Maxcoderz Staff
Posts: 3087
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

Post by benryves »

driesguldolf wrote:Yup, stack is a problem. Worst case scenario it would use 768*2 bytes.
If you assume a call per pixel, that's actually 12,288 bytes for the coordinates alone, or 24,576 if you include pushing the return address! Wikipedia also provides some hints. :)
User avatar
DigiTan
Calc Master
Posts: 1069
Joined: Fri 04 Mar, 2005 12:52 am
Location: NW Wisconsin
Contact:

Post by DigiTan »

It really looks like the game is starting to take off! I always suspected floodfill was the reason we never see many jezzball-type games in the community.
My diet consists of nails, code-stealers, and HP fans.
Projects:

Robot War [TI-82, TI Flash App]
Sonic the Hedgehog [Multiplatform]
User avatar
driesguldolf
Extreme Poster
Posts: 395
Joined: Thu 17 May, 2007 4:49 pm
Location: $4080
Contact:

Post by driesguldolf »

Just for fun I coded the simple floodfiller:
This is sooo exciting :D, I coded my first recursive procedure. *joy*
Image
:mrgreen:

Hehe, unfortunately there's a bug in the splitter. It sometimes goes straight through the borders of an area. Like so.
Btw, the imprint of the cursor is the result of lazy coding, the fact that it gets erased is even more lazy coding :)

So next thing is bug fixing, organizing the code and optimization (the embedded screenshot is NOT optimized AT ALL :P) (including writing a better floodfiller).
benryves wrote:
driesguldolf wrote:Yup, stack is a problem. Worst case scenario it would use 768*2 bytes.
If you assume a call per pixel, that's actually 12,288 bytes for the coordinates alone, or 24,576 if you include pushing the return address! Wikipedia also provides some hints. :)
Yeah, add that to the reasons why I'm not using pixel based levels :P
The table has a maximum size of 32x24 which fits nicely in AppBackupScreen :P (each cell takes one byte, widths and heights are stored elsewhere).
DigiTan wrote:It really looks like the game is starting to take off! I always suspected floodfill was the reason we never see many jezzball-type games in the community.
Yeah, this is a lot more complicated then I first foresaw... Currently the code alone for this game is ~2460 bytes... "engine.inc" has over 2000 lines. :S
User avatar
benryves
Maxcoderz Staff
Posts: 3087
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

Post by benryves »

Wow, that looks really good. :)

I didn't know of Jezzball until seeing the calculator version(s) -- I always assumed they were based on a simplified version of Qix. (Simplified from a gameplay perspective -- not a programming perspective!)
cjgone
Regular Member
Posts: 83
Joined: Tue 18 Apr, 2006 5:33 am
Location: Washington->UC Berkeley '15

Post by cjgone »

I'm assuming only a simplified version of flood fill will be needed because I think you can only make rectangles, or simple 90 degree angled polygons with the line thing?
User avatar
DigiTan
Calc Master
Posts: 1069
Joined: Fri 04 Mar, 2005 12:52 am
Location: NW Wisconsin
Contact:

Post by DigiTan »

Now there's an idea. Driesguldolf, I know this might go outside what you had planned, but would you be willing to consider multi-directional Jezzball? Like with diagonals and stuff?
My diet consists of nails, code-stealers, and HP fans.
Projects:

Robot War [TI-82, TI Flash App]
Sonic the Hedgehog [Multiplatform]
User avatar
driesguldolf
Extreme Poster
Posts: 395
Joined: Thu 17 May, 2007 4:49 pm
Location: $4080
Contact:

Post by driesguldolf »

benryves wrote:Wow, that looks really good. :)

I didn't know of Jezzball until seeing the calculator version(s) -- I always assumed they were based on a simplified version of Qix. (Simplified from a gameplay perspective -- not a programming perspective!)
That looks horribly complicated to code D:
cjgone wrote:I'm assuming only a simplified version of flood fill will be needed because I think you can only make rectangles, or simple 90 degree angled polygons with the line thing?
Not really, since the splitter can be cut in half creating a 'complex' pattern.
I actually already have a version where the splitter as a whole will dissapear when a ball hits it. But to be honest, that's quite boring :P

Though I'm not sure what you mean by 'simplified floodfill', afaik there are several variations on how to achieve a similar effect but I've never heard of a simplified version :P
DigiTan wrote:Now there's an idea. Driesguldolf, I know this might go outside what you had planned, but would you be willing to consider multi-directional Jezzball? Like with diagonals and stuff?
Wha? You want diagonal splitter? That would imply areas with diagonal borders. Which completely breaks with the current data structure.
Balls moving in diagonal directions would be a lot easier. And actually be possible.
User avatar
driesguldolf
Extreme Poster
Posts: 395
Joined: Thu 17 May, 2007 4:49 pm
Location: $4080
Contact:

Post by driesguldolf »

Guess what?

All bugs fixed, all relevant code optimized (including the scanline floodfill) and some reorganization that will come in handy later.
Though there might be one bug left... It caused some areas with a ball in it not being recognized as inside the level. I hope that with the new floodfiller this is fixed.
I also prevented trying to use the splitter when the cursor was on an invalid position.

:mrgreen:

(no screeny because graphically nothing has changed)

While playing, the level data gets more and more complicated and redundancies are appearing. Next thing is to find those redundancies and fix them.

That's also the final step in the development of the engine :D
Post Reply