Kernel Advice

[+Karl G]

I am trying my hand at making a 3D Pong game, and I thought I had a workable plan for the kernel. Here's what I have so far, with the issue I am having readily apparent:

 

 

As you can see, I am using each of the missiles to draw the edges of the arena. I'm using the player0 object for the player's paddle, and player1 for the game ball. I wanted to use a player object for the ball so that it could smoothly size up and down as the ball got closer or further away. I've not drawn the remote paddle yet, but I was planning to use the ball object for that.

 

My issue is obvious from the screenshot: missile0 takes priority over player1, so it is drawn on top of the game ball.

 

Now, I could presumably use the ball instead of missile0 to draw one side of the arena, but this causes a few problems: it would have to be the same color as the playfield, which would make the other side look strange having a different color. also, I couldn't fade the color of the playfield lines to indicate distance as I do now without the ball also matching, which again would clash with the other side of the arena. Finally, I would have to use a missile instead of the ball object for the remote paddle, which would eliminate my ability to use another color just for that section, since there are no playfield lines drawn there.

 

It occurs to me as I write this that I could make player0 and player1 the same color, so the game ball, the target, and the arena edges would share that color and the object priority issue would go away. Does anyone see any more clever solutions for this issue, however?

 

Thanks in advance for any help!

[ZackAttack]

Do you have time to enable/disable m0 on each line? If you don't draw it then it won't cover p1.

[+Karl G]

I would have to check. I would do that conditionally each line where there's a collision between p1 and m0, presumably?

 

Edit: I guess it would be too late if there was a collision, since it will have already been drawn. Would it be conditional based on p1 position, then?

[+Karl G]

Edit: I can't think of any way to know whether or not to disable the m0 on a particular scanline without calculating if it would intersect with m0. Maybe a lookup table?

[ZackAttack]

The paddle has much less area than the ball. It might make the collision detection easier and faster if you draw the pong-ball with P0 and the paddle with P1

[RevEng]

Yeah, if you want it pixel perfect it will be a pain to selectively disable the missiles. I guess use a LUT and then check it against a mask of the ball. Meh.

 

Your first solution of identical colors sounds workable, but would make the game less colorful.

 

If you flipped which objects were drawn by P0/P1 and M0/M1 every other frame (along with swapping postions, colors, etc) the ball and cursor would look translucent, rather than being covered up.

 

It's also worth looking at Wall Ball, since it's in the same game category...

 

 

...it uses background color changes for the top and bottom color fade, PF to coarsely create the black side walls, M1+Ball to smoothen the black side walls, uses P1 for the back-wall blocks, and flickers P0 for double-duty.

 

I don't like the flicker, but the setup does allow for more color in the display.

[+Karl G]

I hadn't heard of Wall Ball, so it's interesting to see how someone else designed a similar arena. I want to avoid flickering if I can, but I also don't want it to be too monochrome. I'm wondering now if I might want to consider not using the missiles to draw my arena as it limits my other options.

 

Anyway, thanks!

[Omegamatrix]

Hello Karl,

 

This comes up quite a bit. You can minimize the impact by doing some game logic:

 

;paddle (P0) on leftside of screen

left border = M1 = blue

right border = M0 = pink

ball = P0 = pink

paddle = P1 = blue

;paddle (P0) on rightside of screen

left border = M0 = blue

right border = M1 = pink

ball = P1 = pink

paddle = P0 = blue

The problem then becomes the paddle will hide behind the arena border depending on the outcome. This is probably better than the ball being hidden, but it can also be improved with even more game logic to see if either the paddle or ball is over either border. In the scenario that just one object is on a border give it priority. If both objects are over different borders than that will naturally work out. If both objects are over the same border give the ball priority. The paddle will be behind the border in this case but hopefully not for long.

[Omegamatrix]

Also if my colors seem off it's because I am colorblind.

[+Karl G]

Thanks - that would indeed reduce the amount of overlapping. I ended up deciding to scrap using the missiles for arena borders entirely, and just use the playfield. This makes the arena more "zen", but I think the color fading, the diminishing of line width and ball size, etc. will give illusion of depth. I'm also having the kernel "highlight" the line above and below the game ball (P1) to show the current depth of the ball.

 

Thanks to everyone for the advice so far. I also wanted to mention that the source code for SpiceWare's Collect Tutorial has been handy for me as a guide, so thanks for that, too. :-)

[+Karl G]

Here's the current version. I'm updating the game ball (P1) every line, and everything else every other line. I'm hoping that I have enough kernel time left to read a Trakball, so long as reading those every other scanline is sufficient.

 

[ZackAttack]

It would look more 3D if you space the lines more as they get closer to you. That may be easier to accomplish if you draw the lines with COLUBK instead of PF since you can get a 3 pixel resolution instead of 4.

[+Karl G]

The line spacing thing did occur to me, but I hadn't come up with a good way to do it.

 

This is showing how green I am, but I assume that you mean a 3-pixel resolution because 1 cycle == 3 color clocks?

 

So, are you meaning something like:

 

(wait variable number of cycles)

change COLUBK to begin line

(wait variable number of cycles)

change COLUBK to end line

 

Doing that in a loop would have a resolution of 5 cycles, or 15 color clocks. I suppose I could unroll the loop and have a bunch of nearly identical kernel lines that sleeps for an exact number of cycles to start and end the line with COLUBK?

 

Let me know if I'm missing something obvious here.

[ZackAttack]

That's pretty much what I was getting at.

 

Regarding the line spacing I was thinking you'd just skip ever 2nd line, then 2/3 lines, then 3/4 lines etc. Which is why having 3 pixel resolution, aka more lines, would potentially be helpful.

 

Drawing the lines with COLUBK also makes it cheaper to fade the color as the lines go further away since either way you're setting COLUBK.