Beyond Castlevania...

[Godzilla]

it made a unique sound and stayed there for a while, jittering and jostling. I don't know if it would have continued to stay there as I moved the joystick to try to get it out and it eventually worked. It does the same thing at certain points down the board when I was scrolling around for the fun of it.

[+grafixbmp]

I noticed that when you go below the left triangle and go back up to it. it stops fine at it, but doesn't rebound.

[+Propane13]

Thanks for both observations.

I've fixed grafixbmp's item-- that was the easier one to find/fix.

 

The other one I have an idea about, and that's going to pick on my brain awhile.

Collision detection has 3 pieces to it, in the current implementation.

 

Phase 1 is to detect if a collision happens. This seems to be working 100%

 

Phase 2 is to act on that collision by putting the marble back in the "last known good state".

Essentially, this does an "undo" of the last movement. So, if you moved down and left, and then had a collision, the ball is repositioned up and right.

I'm pretty sure this is working as well, but it's a little harder to validate unless I turn some things off. But, I think it's probably good.

 

Phase 3 is where life gets difficult.

This is where you need to decide what to do with the marble's momentum after the collision.

It's not trivial. As I see it, there are 4 cases, and 4 reactions based on those cases.

 

Case one is if the marble bounces off of a horizontal line.

If that happens, then you keep the X-direction momentum, and swap the Y-direction momentum.

 

Case two is if the marble bounces off of a vertical line.

If that happens, then you keep the Y-direction momentum, and swap the X-direction momentum.

 

Case three is a diagonal line like a slash (/):

Here's where things get tricky. In these cases, the downward momentum swaps with the left momentum, and the right momentum swaps with upward momentum.

 

And, finally, case four is a diagonal line like a backslash (\):

In these cases, the downward momentum swaps with right, and the upward momentum swaps with left.

 

Got it? Ok, so, it's all just physics. But, the edge cases are what makes life complicated.

Let's say that the ball moves in such a way that it touches TWO pieces. Then, you have to make it smart enough to know what to do.

There are situations where you could get stuck for awhile if 2 pieces next to each other have a certain layout. These are tough to debug, and are the likely scenarios for "getting stuck".

 

The other fun one happens with horizontal/vertical hits.

Let's say you're going straight down, and hit a vertical piece.

In this case, you'll detect collision (phase 1), bump up (phase 2), and then swap left and right, continuing down.

The next time, you'll do the same thing. Pretty much you're stuck until left/right is pushed enough to get you off of this thing.

 

It's these situations I'm racking my brain around now. We'll see what I come up with.

 

-John

 

 

Regards,

-John

[GroovyBee]

The other fun one happens with horizontal/vertical hits.

 

The ball is always trying to move down the screen so you can add some forward motion (towards the player) e.g. like gravity is acting upon it. Thus when you are ping-ponging horizontally the ball's y co-ordinate will be increasing slightly on every rebound so the ball will get out of it eventually.

[+Propane13]

That's an interesting idea.

I suppose I also need to consider putting in "friction" as well, so that the ball will generally slow at a certain point if untouched.

[GroovyBee]

With friction you might have to do a ton of play testing to make sure that the ball can't get stuck in unexpected places. It all depends on the level design and the game play mechanics you implement.

[+Propane13]

@grafixbmp-- check out the pic below:

 

 

I'm a little fuzzy on where some of the collisions should happen, so I started filling them in, in yellow.

 

Would this be something you'd be interested in putting together?

 

At the moment, we can just map the whole thing in one color, or if you wish, use 2 colors (one for bumps and one for holes).

For now though, all will just be "bump" cases, to assist with programming.

 

The only restriction is that the bump/hole places need to be on the brown scanlines, not the white ones.

 

Any interest (since you are the graphics master)?

 

Regards,

-John

[+grafixbmp]

@grafixbmp-- check out the pic below:

 

 

I'm a little fuzzy on where some of the collisions should happen, so I started filling them in, in yellow.

 

Would this be something you'd be interested in putting together?

 

At the moment, we can just map the whole thing in one color, or if you wish, use 2 colors (one for bumps and one for holes).

For now though, all will just be "bump" cases, to assist with programming.

 

The only restriction is that the bump/hole places need to be on the brown scanlines, not the white ones.

 

Any interest (since you are the graphics master)?

 

Regards,

-John

I'll do it. But do ya want it just like you showed or just the yellow only. cause I could do this quick and then remove the rest leaving the yellow. Bo ya want hte collisions to be both the real ones and the holes? meaning both be the same. Or do ya want yellow for collision and say purple for holes? If this is fine then I will try to do the graphic soon.

[+Propane13]

Actually, leaving the rest there is totally fine.

It will give me a frame of reference for checking against the board when doing collision testing.

Since it's already divided up into a grid (the red lines), it's really easy for me to import data.

 

And sure, yellow and purple would work great for bumps and holes, respectively.

 

Thanks!

 

-John

[+grafixbmp]

Ok here is a test run. I have an idea about if ya want to ever use holes with collisions I will have the marble dissolve quickly so it doesn't have to go behind anything meaning no masking.

 

The one thing I'm wondering about is with the graphic that will wind up being used for the marble and its size. I tried to off set the upper boundaries. Otherwise, I suspect the collisions won't register aligned to the platform. What are your thoughts on this Propane?

 

If ya need any other changes, let me know and just tweak away at this image any way ya need.

 

[+grafixbmp]

I will do this mask again but this this time I will remove the spacing for holes. I forgot to account for the difference between the visual representation and the calculation of the numbers. Wasn't really sure if you were calculating for the start position of the marble, whole marble graphic or offsetting to the bottom edge of the marble for collisions.

Edited February 21, 2011 by grafixbmp

[+Propane13]

No worries. Thanks for the work so far!

 

Here's the way I see collisions being done:

 

The marble right now, just looks like this:

 

00011000

00111100

01122110

11111111

01122110

00111100

00011000

00000000

 

The 1's are the outside of the marble, and the 2's are places where the collision check happens.

 

It's kind of crude, but it's not a bad start.

 

-John

[toptenmaterial]

Atari 2600 is the little engine that could!! You folks amaze me.

[+Propane13]

Update for today.

 

1) It's 8k instead of 4k

2) There's a basic title screen

3) 45 and 90 degree support (45 is a little wonky when you push in 2 directions at once though)

4) A collision on the top-left triangle gives a bump condition, whereas a collision with the top-right triangle gives a hole condition. There's a difference.

 

Anyway, enjoy! Feedback welcome.

 

-John

marble_2011_02_22.zip

[Brian O]

Update for today.

 

1) It's 8k instead of 4k

2) There's a basic title screen

3) 45 and 90 degree support (45 is a little wonky when you push in 2 directions at once though)

4) A collision on the top-left triangle gives a bump condition, whereas a collision with the top-right triangle gives a hole condition. There's a difference.

 

Anyway, enjoy! Feedback welcome.

 

-John

 

 

This is amazing. Nice job.

 

-B

[Godzilla]

are you going to take into account how the ball rolls differently depending on the slope and elevation of the different areas of the maze like the arcade did? is that even possible or is that a whole different layer of collision detection (or 'area detection' ?) (for example the top left slopes up a bit, then has a level section then slopes down from there (etc.)

[+Propane13]

Yeah, that's something that I have been racking my brain around, and it's the last hurrah.

To finish the project, I need to come up with something to specify an area as a "win" condition.

So, that alone means that I'll be looking at a problem that's similar.

 

There's a way to do it that requires an insane amount of data, but that's not gonna work.

I want to ideally have the logic fit inside 2K, max. That's going to take awhile to figure out.

 

-John

[+grafixbmp]

If it would be just a matter of another array to sample for slope data for where the ball is, make the array bidirectional and use a sliding vector??

[+Propane13]

Ah, so basically, I cheat to use less data for bumps/holes.

 

What I was doing for bumps/holes right now is that horizontally, there is a maximum number of holes/bumps per scanline that I can see.

So, all I really need is a table per instance. In my first calculation, there was a max of 6 bumps/holes per line, it's 6 tables to sample.

So, I just need 6 200-byte tables. But, of course, that type of table is missing all the slope data and win conditions.

 

I *could* just have one master array (256x32), but then I wonder about scalability.

32-pixels * 256-bytes (horizontal page-boundary-aligned) = 8K.

So, let's assume the first 4K is the kernel, and then 8K is for slope data, win conditions, bumps, holes, and other things.

That would mean 12K per level. If there were, say, 5 levels, that's 60K, so a 64K chip.

 

So, that brings me to a few questions:

1) Is there a board out there that can do bank-switching for 32K, 64K, or even 128K configurations?

2) If yes, how is that done in software (LDA $FFF9)?

3) Are such boards (if they exist) expensive?

 

Just curious what the upper threshold for physical hardware is.

 

-John

[+thegoldenband]

Adding some fuel to the fire! The savestate was made with Stella 3.0 for OS X -- not sure if it can be opened on other systems, but it has all the sound data.

marble madness 2600.mp3.zip

Frame Timed Sound Effects-EM (Eckhard Stolberg).st6.zip

[+grafixbmp]

It may be possible with a little mathematical calculation to squeeze a representation of a scanline's data into 2 bytes per scanline. Since you can base a data check on the horizontal position of the ball for its column (1 of 4). If it were the second column, then the byte for 1 and 2 is split for column 2's data. This nibble can mean

0= no impact point

1= impact location 1 00000001

2= impact location 2 00000010

 

etc.

 

8= impact location 8 10000000

 

and these leftovers, 9 A B C D E F, could be fed to a special table for rare circumstances. If the math has room, it could be a possible space saver but i'm not sure. What are your thoughts?

 

 

I just noticed something else about how you sectioned off the red grid. Some areas dont have any collision checks while others do. And some have hole checks and both holes and collisions.

 

What are the chances of a 2 bit flag for each zone.

00 = no checks

01 = collision

10 = holes

11 = collision and holes

This way you will know ahead of time if you even need to check in the first place. Thats a block of unneeded collision checking and data space. But that could be the way you are already doing it.

Edited February 23, 2011 by grafixbmp

[+Propane13]

Two random out-of-nowhere questions:

 

1) What was the ROM size for marble madness for a) NES and b) arcade?

 

2) Where does it make the most sense to put the collision detection? Center of the marble, or bottom?

I'm leaning towards bottom, since I think that "feels" more correct for the isometric view.

 

-John

[+grafixbmp]

Well the NES game ROM was 128k. As for the arcade version, not sure.

 

I guess since the marble "touches" sorta speak, the terrain at the bottom and the isometric view is a representation of a 3d space, then sure, the lower portion of the ball would give accurate response with the terrain.

 

There's just got to be a better way to do all this location checking.

 

Just a collection of where it currently is, where it wants to go and maybe why.

 

Rendered PF = check

rendered marble = check

controls = implemented, fine tuning may be needed

impacts = check, possible tweaking

dropoffs = check, same as impacts

 

 

slopes = to be done

goal = to be done

 

ramp jumping = unknown

 

Ya know, there really only needs to be 2 major things to account for, direct collision and slope. anything else is a hole. If the marble isn't interacting with these 2 things it just fell off. lol with the exception of possibly jumping.

[+grafixbmp]

I just got through doodling something, killing time, just to get an idea of what's actually happening on the practice level. It isn't complete but I like how it's coming along. Thought I would share it with ya propane and everyone else too. This is what we got as far as all different scenarios. And type of drop off I left clear of anything extra.

 

[+Propane13]

I NEED this.

Keep going! Please!

 

This morning, I thought about it, and I have made a decision-- I'm going to do the 8K of data method per level.

It will be the right approach in the long run. In all honesty, I've been dreading figuring out what area maps to what slope.

 

This picture will be exactly what's needed to fill in the gaps.

 

+1 for reading my mind.

 

-John