MaxCoderz

Meh, got a bit distracted by Team Fortress 2.

Anyway:
Fixed all collision bugs tonight:


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).

Wow, nothing like fixing a vital part of a project/game (collisions) I know I am happy

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.

kalan_vod wrote:Wow, nothing like fixing a vital part of a project/game (collisions) I know I am happy

qft

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:


(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.

Whoo, it works


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

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

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!

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
Basically the same as described (btw, thanks for that link ) but mine trick would use less stack. If I understood correctly

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.

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.

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



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 ) (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
The table has a maximum size of 32x24 which fits nicely in AppBackupScreen (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

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!)

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?

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?

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

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

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.

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.



(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