Snake Tetris

[Snake Tetris]

Looks very doable to me, bB or otherwise. It's just single colored playfield blocks and a dot, not hard to draw at all.

I do feel like the snake could use a different color than the solid Tetris blocks though, in order to avoid confusion when the playfield gets more cramped.

Being at most 4 blocks wide,the snake could easily be drawn with a stretched player object.

A stretched sprite is what I'm currently experimenting with for my own implementation. Everything is either 1, 2, 3 or 4 solid pixels.

[A Two-Player Competitive and Co-Op "Tetris" for the Atari 2600 VCS]

Sorry for another technical post (I'll have more media later.)

Code as data, data as code... This is something that jumped out at me as I was working on the game's playfield data representation.

Normally, I'm not a big fan of premature optimization, but it might be some sort of secret Holy Grail thing for the VCS...

I noticed that the PF1 (and PF2) bitmap that I was using to draw the 2 player wells (#$E0) is the opcode for the immediate addressing mode of the CPX instruction (ComPare X.) What's even better is that this bitmap for a "default clear" line state only represents only half of the well. Throwing in the other (clear) half puts "E0" into two side-by-side RAM locations, which boils down to the following instruction:

CPX #$E0

This is comparing the X register to the immediate value "E0" which is almost exactly what I want to do to check if half of a game row is clear....

 

This recursive nature of the CPX opcode definition almost allows direct execution of my data with no change. If I load the next half needing to be checked into the X register, and with a few more clever instructions, I may be able to use this method to check the next segment after that, and so on, and so forth. I can potentially use a byte after the first failure of the clearing logic to flag where the "dirty" lines start and then use this for the lion's share of the "line clear" stuff. Combine this method with dynamically self-modifying code and we can have very tight and optimized wizard shit going on...

This method may even compress my playfield data somewhat, saving a bit of RAM, since most lines (unless you suck) should be in the clear state. Since this recursively self-executing data-code will reside in RAM (as the playfield data normally would anyway), then only the lines, or the number of lines, that actually have a "dirty" flag will need to exist as a bitmap in RAM (up to a maximum of 80 bytes) and having this line clearing check "kernel" down to only a handful of bytes will help a lot for CPU usage as well.

 

I shouldn't be particularly starved of CPU in the VBLANK and OVERSCAN areas, but everything helps. I can focus more ROM and CPU on good music then.

[What the classic Konami intro would look/sound like on the Atari 2600...]

I dont think the splash screen should be *too* hard. You could even have the scrolling beam flash (whatever it's called) over a couple scanlines.

[PERIL wip game]

Chopper Hopper

[What the classic Konami intro would look/sound like on the Atari 2600...]

And shouldn't this thread be me moved to the programming sub?

[What the classic Konami intro would look/sound like on the Atari 2600...]

The jingle blows up pretty badly after one rep on my portable Stella emulator.

[New Atari Console that Ataribox?]

If he hasn't already he's going alter that picture on the far right to this:

 

Fred_clones.jpg

The image on the TV should be in a SECAM format (of 8 colors.)

[A Two-Player Competitive and Co-Op "Tetris" for the Atari 2600 VCS]

Here's one thing about VCS programming that is vastly different than what most anyone will ever come across:

 

You essentially have to look at your game's rendered image and find areas between the pixels in which you can execute your code.

 

Not all code will need to use the actual scanline because you get some free time (if you exhaust VBLANK) during each horizontal retrace period...you can kind of think of each scanline as the lines of a lined notebook, and the margins on the left are the retrace period. You can execute code within the margin notes, but if you want to fold the paper, you have to do it at one particular location...

[A Two-Player Competitive and Co-Op "Tetris" for the Atari 2600 VCS]

The way that I imagine that this works (for a reflected playfield) is that the TIA reads the PF0, PF1, and PF2 registers in one direction, and then it immediately sweeps back to read them in the reverse order. [Please correct me if I am wrong. I haven't read a developer's manual.]

 

This causes a severe contention for the PF2 register at a point directly in the middle of the screen. There is a more "standard" mode that accesses PF0, PF1, and PF2 more sequentially, and also buys you more time across the scanline to make changes to PF2. I don't want to use that mode unless I have to, so I have to work this kernel to write to PF2 (when it needs to) at an exactly perfectly-timed CPU clock cycle. No more, no less.

[A Two-Player Competitive and Co-Op "Tetris" for the Atari 2600 VCS]

So today I started working more on the playfield and ran into some interesting issues. One of them was somewhat expected, especially since I really like the aesthetics of a reflected playfield...then problem is, with an Atari 2600 game, the CPU and the television interface are in a certain lock-step with each other, so to say that timing is critical is a huge understatement.

 

The issue isn't so much of a problem though, because I'm (mostly) ignoring writes and changes PF0, so that buys me a write to each player...so...problem mostly solved...but the key issue is in timing.

 

To create an asymmetric playfield, you essentially have to cheat. The system wasn't really designed to do this, but it can be achieved by exploiting a CPU and TIA timing issue. I need to write an asymmetric playfield which is also reflected. This reflection point is the PF2 register... In order to do this, I need to write a change to the PF2 register at the exact CPU (and TIA color) clock cycle when it is possible to do so.

 

This is only on one cycle.

[A Two-Player Competitive and Co-Op "Tetris" for the Atari 2600 VCS]

Did a bit of searching, turns out there was a post/poll about PAL50 vs PAL60 5 years ago.

I didn't know that 60Hz PAL was even a thing...

 

Should I even bother with SECAM? Does anyone still even use those old French 2600s?

[A Two-Player Competitive and Co-Op "Tetris" for the Atari 2600 VCS]

I won't get too hung up on timing, but I should have clarified that I wanted to basically have the game "clock" ticking at the same rate on both 60 and 50Hz systems so that there really won't be any noticeable difference in game play or speed between regions.

 

Right now I'm moving forward on to strategies on representing the games playfield data and manipulating its bitfields.

[Proper behavior during OVERSCAN?]

Don't know if you've run across my tutorial, I cover using the timer for that purpose in step 2.

Wow, that's very similar to what I was experimenting with, but my code was not as reusable. I was also writing my timer multiplier value to VBLANK (instead of 2) to save a few bytes and cycles.

 

Thanks for the useful response!

[Proper behavior during OVERSCAN?]

I was really tempted to spinlock on a timer until the end of the overscan period, but does this cause any problems or issues on real hardware?

[New Atari Console that Ataribox?]

ataristrategy.PNG

 

No strategy is still a strategy, right?

If the football thumbnail image was any clue, I'd say its a Hail Mary.

[A Two-Player Competitive and Co-Op "Tetris" for the Atari 2600 VCS]

I don't know if you have been thinking of NTSC/PAL compatibility, but it might be good to implement that now instead of later. All you really need to change between the two is the length of vblank and overscan, plus the speed of the game. Without adjusting for speed, PAL games run at 5/6 speed, which is very noticeably different. Since you've been working on game speed, I thought I would suggest it.

I haven't implemented speed into my NyanCat project yet, but I plan on using the typical method of having an 8-bit "fractional" counter that changes your object's position when the counter rolls over. This way, you could add values that are multiples of 5 in NTSC mode, and multiples of 6 in PAL mode, and both modes would play at exactly the same speed.

Thanks for bringing that one up, because I did think about it very briefly when I was selecting palette colors. I think I can find a nice balance between the two, and I was leaning towards 50Hz as the standard difficulty speed, anyway. PAL support is definitely on the early list. It looks like the majority of it will only require different spinlock timer values and different color values (along with your list too, of course.)

[A Two-Player Competitive and Co-Op "Tetris" for the Atari 2600 VCS]

Is it just me, or does he seem really confident in the performance of his "Atari Sheers"

 

This should probably go in the Ataribox thread btw...

That was the thread I was looking for

 

It looks like the video got its own thread recently, which is even better.

 

I hope the system does well and finds its niche. Everyone I've mentioned it to has had positive opinions, and thinks it's an interesting idea.

 

 

We now return to your regularly scheduled Tetris programming...

[Atari CEO interview on Fox business channel on U-tube]

I saw this too the other day. Why not post the video?

 

[New Atari Console that Ataribox?]

As I was writing code for my shiny new Atari 2600 Tetris game just a few days ago, I heard Atari's CEO on Fox Business in the background talking about the new console (and also about stocks, of course...)

 

[A Two-Player Competitive and Co-Op "Tetris" for the Atari 2600 VCS]

This is a little off-topic, but it came up the other day as I was writing some of this code.

 

Completely out-of-the blue, Atari's current CEO appears on a television segment in the background talking about stocks and the upcoming console:

 

[A Two-Player Competitive and Co-Op "Tetris" for the Atari 2600 VCS]

I think this should be the last silly little test for this one. Here's two simultaneous orientations of the T block (with true colors) packed into one sprite:

 

[A Two-Player Competitive and Co-Op "Tetris" for the Atari 2600 VCS]

...and here's the J and Z blocks (faked) in the color of the S block:

 

[A Two-Player Competitive and Co-Op "Tetris" for the Atari 2600 VCS]

I'm taking a quick break from animation tests and going back over to the actual sprite bitmaps, and how they are going to be sized and translated on to the screen via the NUSIZx registers. As I mentioned, I wanted the sprite data to be as simple as possible, and reused as much as possible, and today I quickly realized how easy this is. I don't really even need to use more than 1, 2, 3 or 4 pixels...and this isn't even using missiles...that's just icing on an already tasty cake.

 

This is in no way how the game would actually look, because I don't have any double-piece drop options...yet...but check out the "fake" sprite replication effect by essentially doubling up on the sprite data: I can replicate this 3 times for both player sprites and get a lot of action on the screen...12 pieces? (I'm seeing how this could lead to an actual Dr. Atario game in the future...though the simultaneous colors for that one is still not an easy task without some more wizardry.)

 

This doesn't even have horizontal positioning in effect, and the result is almost correct...

[A Two-Player Competitive and Co-Op "Tetris" for the Atari 2600 VCS]

My next drawing test is going to be a bit different, I'm going to investigate "inverting" the VCS playfield and background and use black playfield blocks to draw over solid sprites (such as the "T" block) to sort of "obscure" areas of the pieces so that I can further simplify my drawing strategies. Combining a few of these techniques might let me squeeze a lot of nice detail out of things without overshooting the beam.

[A Two-Player Competitive and Co-Op "Tetris" for the Atari 2600 VCS]

Since there wasn't much to change to add the small gradient graphics effect that I plan to use in most cases for the game pieces (when possible), here it is applied to the previous animation test, and the piece is nudged over to the 2P side of the screen just for the heck of it:

 

new-anim-test3.bin