WIP - potential head-to-head block slider/tile matching game

[ZackAttack]

I've been playing around with the idea of a simple game that puts two players in competition with each other. I'd like to get some ideas on how I could enhance the game play. Here is what I have so far.

The screen is divided into left/right regions with each region comprised of an 8x16 grid. Each block in the grid can be one of 3 colors or no block. Each player will move their sprite to push/pull blocks into position. Grouping enough like colored blocks would clear them from the grid. New blocks will appear at random in unoccupied spaces. Whoever goes the longest without their grid being filled is the winner.

 

[+Al_Nafuur]

4 hours ago, ZackAttack said:

I've been playing around with the idea of a simple game that puts two players in competition with each other. I'd like to get some ideas on how I could enhance the game play. Here is what I have so far.

The screen is divided into left/right regions with each region comprised of an 8x16 grid. Each block in the grid can be one of 3 colors or no block. Each player will move their sprite to push/pull blocks into position. Grouping enough like colored blocks would clear them from the grid. New blocks will appear at random in unoccupied spaces. Whoever goes the longest without their grid being filled is the winner.

 

Are the blocks playfield?

 

[ZackAttack]

1 hour ago, Al_Nafuur said:

Are the blocks playfield?

No, the border is playfield. The blocks are drawn by a series of writes to COLUBK. The colors were carefully chosen so SAX results in black. STA, STX, and STY give the three different colors for the blocks.

[+SpiceWare]

Clever! Was wondering how you'd pulled it off when I saw the screenshot last night.

 

Looking at it closer the rightmost column of blocks gives it away as they're slightly narrower than the others.

 

Lots of combinations of the store commands. Are you using lots of prebuilt kernels in ROM like Galaxian, or a RAM based kernel that's modified as the blocks are moved?

[+SpiceWare]

Thinking on that rightmost column, perhaps invert the PFx registers and change the playfield color instead of the background. That would let you use the ball to extend the width of the rightmost column.

 

Of course if you plan to use the ball for something else the minor tradeoff of that one column's width would be worth it.

[JeremiahK]

Awesome game concept!  I love the SAX trick, I thought of something similar awhile back when I was studying the illegal opcodes, but I couldn't find a real use for it.

5 hours ago, SpiceWare said:

Thinking on that rightmost column, perhaps invert the PFx registers and change the playfield color instead of the background. That would let you use the ball to extend the width of the rightmost column.

 

Of course if you plan to use the ball for something else the minor tradeoff of that one column's width would be worth it.

I was thinking the same thing.  Another option could be to use the PF to draw the center line using SCORE mode, and use one or both missiles to draw the left/right borders, giving each player their own border color (assuming everything can be aligned).  Unless you plan on using the missiles for something else, of course!

Edited September 23, 2022 by JeremiahK

[ZackAttack]

12 hours ago, SpiceWare said:

Looking at it closer the rightmost column of blocks gives it away as they're slightly narrower than the others.

Well now that you pointed it out, it's very annoying. Ball is already used to widen the center border to 9 pixels. Otherwise, the 1st column for the right grid would be a pixel too big. But you got me thinking, why not fill in the other side with M0. P0 won't ever cross the center border and there's a 3 cycle gap between the sides that's just enough to write COLUP0 with the color of the last column's block. The right most border is now 3 pixels though.

 

12 hours ago, SpiceWare said:

Lots of combinations of the store commands. Are you using lots of prebuilt kernels in ROM like Galaxian, or a RAM based kernel that's modified as the blocks are moved?

Dynamically generated by ARM.

6 hours ago, JeremiahK said:

Awesome game concept!  I love the SAX trick, I thought of something similar awhile back when I was studying the illegal opcodes, but I couldn't find a real use for it.

I was thinking the same thing.  Another option could be to use the PF to draw the center line using SCORE mode, and use one or both missiles to draw the left/right borders, giving each player their own border color (assuming everything can be aligned).  Unless you plan on using the missiles for something else, of course!

Thanks. I'm afraid there aren't any cycles left to do much more.

 

16 COLUBK stores = 48 cycles

2 COLUP0 writes = 8 cycles (save a lda# because registers already have the block colors loaded)

GRP0/1 writes = 10 cycles

AUDV0 write = 5 cycles (sampled audio)

LDA block color = 2 cycles

 

That leaves 3 cycles to write ENAM1. M1 could be serve as an object that can only be used by one player at a time. The other option would be to truncate that rightmost column and have missiles available for both players simultaneously. I think I prefer the first option because the blocks are the most important aspect of the gameplay, and it would be much cleaner to have them all the same size. If there's a good reason to need multiple missiles, that could always be done with flicker.

 

Here's what it looks like with the column size fixed, and blocks randomly added. I'll post a playable bin once P0 controls are fully functional.

 

[JeremiahK]

17 hours ago, ZackAttack said:

Ball is already used to widen the center border to 9 pixels.

Aha, I was wondering why the 8-pixel center line didn't make any blocks look stretched.

 

17 hours ago, ZackAttack said:

...M1 could be serve as an object that can only be used by one player at a time. The other option would be to truncate that rightmost column and have missiles available for both players simultaneously. I think I prefer the first option because the blocks are the most important aspect of the gameplay, and it would be much cleaner to have them all the same size. If there's a good reason to need multiple missiles, that could always be done with flicker.

I agree, and if you don't like the look of fast flicker, you could always go for a quick flashing effect that alternates between both boards.

[ZackAttack]

On 9/23/2022 at 10:04 AM, SpiceWare said:

perhaps invert the PFx registers and change the playfield color instead of the background

This turned out to be just what I needed. I had to jump through some hoops to make it all fit. The kernel is exactly 76 cycles now. To free up the missiles I replaced the center border with a PHP, using the status register as the border color. There's not enough time to use ldx/txs/ldx to reset the stack pointer to the COLUPF register. Since AUDV0 only uses D3:D0 and TIA Read registers only drive D7:D6 a PLA can be used to fix SP and put the next audio sample in the A register. This saves 2 cycles. Here's the pseudo code for the kernel as well as the results in Gopher2600.

 

pla		;4 4 Resets SP back to COLUPF and loads a 4-bit audio sample
sta AUDV0	;3 7
lda #		;2 9
sta GRP0	;3 12 When the row doesn't contain P0, replace this with a JMP to keep the PC in the ROM region.
lda #		;2 14
sta GRP1	;3 17
lda #ColorA 	;2 19
st? ENAM0	;3 22 A and X colors have opposite bit values, so use one or the other to enable/disable respectively
st? ENAM1	;3 25 Same as M0
st? COLUPF	;3 28 store A,X, or Y depending on which color the blocks should be
st? COLUPF	;3 31
st? COLUPF	;3 34
st? COLUPF	;3 37
st? COLUPF	;3 40
st? COLUPF	;3 43
st? COLUPF	;3 46
st? COLUPF	;3 49
php		;3 52 P=BorderColor and SP=COLUPF
st? COLUPF	;3 55
st? COLUPF	;3 58
st? COLUPF	;3 61
st? COLUPF	;3 64
st? COLUPF	;3 67
st? COLUPF	;3 70
st? COLUPF	;3 73
st? COLUPF	;3 76

 

Now I just need a good use for those Missiles!

[JeremiahK]

Awesome!  That looks perfect.

 

I was actually going to suggest using PHA as a 1-byte 3-cycle NOP for the timing reason, but I figured the overhead to keep the stack from overflowing would cost too much.  I was assuming you were doing some sort of RAM kernel (hence why I was trying to save you a byte), but it looks like that isn't the case.  This definitely looks like it could be some sort of bus stuffing routine?  Very cool!

Edited September 25, 2022 by JeremiahK

[Dionoid]

Very clever usage of SAX! I remember reading about SAX a while back and having no idea on how to make good use of that opcode. Cool trick!

On 9/24/2022 at 9:34 AM, ZackAttack said:

On 9/23/2022 at 8:58 PM, SpiceWare said:

Lots of combinations of the store commands. Are you using lots of prebuilt kernels in ROM like Galaxian, or a RAM based kernel that's modified as the blocks are moved?

Dynamically generated by ARM.

I'm not sure what you mean by "dynamically generated by ARM" as answer to SpiceWare's question. Could you elaborate a bit?

Edited September 26, 2022 by Dionoid

[+SpiceWare]

3 hours ago, Dionoid said:

I'm not sure what you mean by "dynamically generated by ARM" as answer to SpiceWare's question. Could you elaborate a bit?

 

In reading the Kernel, specifically this bit:

 

sta GRP0	;3 12 When the row doesn't contain P0, replace this with a JMP to keep the PC in the ROM region.

 

 

I think the 6507 code for the Kernel is being generating scanline-by-scanline in real time by the ARM.

[ZackAttack]

Yes, it's basically a variation of the Strong-ARM Framework I posted a while back. It's targeting a much weaker ARM chip though to make a cart release feasible. There will be more details on that later when I release the source code for this game.

 

On 9/25/2022 at 1:11 AM, JeremiahK said:

This definitely looks like it could be some sort of bus stuffing routine? 

No, I don't think this would count as bus-stuffing since there is no intentional conflict. At no point is the ARM stuffing its own value over an existing value placed on the bus by TIA/6507.

 

 

I implemented controls for P0 last night, but it felt very awkward trying to push around blocks when P0 movement has 1pixel resolution. Then I tried limiting P0 to moving one block at a time. Pushed blocks instantly move to their new positions for obvious technical reasons. However, P0 will move smoothly and animated to the next block position. Almost ready to post a build. Just need to handle removing blocks when 3 are lined up and it will qualify as a playable game.

 

If anyone has any suggestions for the missiles, that would be great. I'm thinking they could serve as a power up, but not sure what or how.

[Dionoid]

16 hours ago, ZackAttack said:

Yes, it's basically a variation of the Strong-ARM Framework I posted a while back. It's targeting a much weaker ARM chip though to make a cart release feasible. There will be more details on that later when I release the source code for this game.

Ah, interesting. I'm reading that your ARM framework is basically emitting a dynamic 6507 instruction stream. Very clever.

[Ecernosoft]

On 9/23/2022 at 7:08 AM, ZackAttack said:

No, the border is playfield. The blocks are drawn by a series of writes to COLUBK. The colors were carefully chosen so SAX results in black. STA, STX, and STY give the three different colors for the blocks.

Question: Does SAX store (A and X) to a location?

 

And what does LAX do?

[JetSetIlly]

1 minute ago, Ecernosoft said:

Question: Does SAX store (A and X) to a location?

 

And what does LAX do?

The SAX instruction ANDs the A and X registers together and stores the result at the address

 

LAX loads a value into both the A and X registers.

 

[Ecernosoft]

33 minutes ago, JetSetIlly said:

The SAX instruction ANDs the A and X registers together and stores the result at the address

 

LAX loads a value into both the A and X registers.

 

That’s what I thought. Thanks for the info!