AkashicRecord

Absolutely love it.

I ran into something interesting last night...by accidentally "frying" one of my prototype programs. Luckily, the volume was off, because oh boy, if it is turned up loud... Anyway, this quickly showed me how many uninitialized and unused registers that I've been ignoring, and some that I'd almost completely overlooked. So, I completely gutted my program down to it's barest of bones and essentially rewrote the whole thing from scratch. Doing this, I fixed quite a few things in the process (...and back to a proper 262 lines of NTSC again). After everything was done, I wired up the joystick button to a sort of "soft reset" function and tested frying the program quite a bit (the Backspace key in Stella), checking to see if the program would essentially restore itself to a working state. (It did.) There's probably not any *real* need to do this, but I don't like loose ends like what I had discovered...it was also time to start refactoring and cleaning up the program anyway before moving too far forward...I've also taken the David Crane approach to graphics and have started placing black lines in areas to reduce blooming and color artifacts. One strange thing I noticed while frying my test program was that the playfield priority in CTRLPF seemed to be ignored, or at least handled differently, between Missile and Player objects when VDELPx is enabled?

I'm *almost* finished with the rotation system, but right now it kind of flips the game piece about....60 times per second. It should be relatively easy and quick to add the rest of the game pieces once the full behavior of just one piece is completely finalized. (The entire thing is mostly just a data driven loop with indexed loads and such based on the current piece rotation.) The gradient shading will be a lot more flexible now, as I was just previously decrementing the color value every single time.

Like Grand Prix. (A technical marvel)

Yeah, I'm kind of drawing a blank myself on which versions had this particular rotation "standard" in place. I'm guessing that some of the newest versions do...but I'm not even sure if TetrisDS had it. (That was my most recently owned version that was worth a shit.) Either way, I'm going to have more than just one way to skin this cat, so let's collectively make the best Tetris title to ever exist.

Ok, so I've started some serious coding for the block rotations, and I've added an assemble-time constant to enable or disable the peculiarities of the SRS system. This way, I'll be able to roll out some prototypes that have the feature, and some that don't, without having to code a detailed options system (yet), and I can still work from the same source file without having to maintain multiple versions...because that is how the nastiest bugs are born. Most of this stuff is just a bunch of onerous pointer preinitialization to facilitate fast loading within the display kernel(s), and handling the application of horizontal and vertical grid position "kludges" to tweak the sprite placement. (The only reason that is necessary, is that the VCS doesn't really have a screen coordinate system, per se, so you have to perform extra bookkeeping to know which particular scanlines to "hit" on, or not... Vertical positioning is rather ad-hoc on the 2600.)

Well, it seems that this kind of information is a bit easier to come by these days. This is the "SRS" or Super Rotation Standard for the game. It gives each piece 4 unique rotations...except the square. This causes some minor horizontal and vertical translations for the Z, S and Line pieces which are absent from many Tetris variations... If there are any that object to this rotation behavior, I could have this as an "SRS On / Off" game option toggle before the start of a game.

Any objections to the game pieces coming into play with the "flattest" side down? (Sometimes this can make it possible to put pieces into play with hardly any rotations required.) I kind of forget what the "standard" method is for this aspect of the game. I kind of always just made my own rules here.

If I can test it, I can code for it.

You're on my level for sure... I thought about exactly that, but I was concerned about "over complicating" the controls a bit... I had an idea for the single-button control that will help with certain time-critical rotations...but only under certain circumstances. (I'll explain this one later because it is something that hasn't existed in any "Tetris" game, even to this date.) I might be able to squeeze in a few different control methods that will just "work" based on play style. I don't see too much of a problem with only having one button on the standard joystick... (I did want to code in some auto-detection for the Sega Genesis controller if possible, though.) On another note... How willing are you to pass the Castlevania 2600 torch to another programmer?

Yes, Tengen Tetris is my primary model for this title. It will definitely have all of those modes in the finished product. (I originally had a 12x20 well for the Co-Op mode, just never posted a screenshot or .bin.) I'll have some "brick" test protos coming soon. I have a few ideas that I think will look pretty good, especially with this new minimalist approach to the playfield walls and decorations.

Before I temporarily say goodbye to missiles, I'll have a look at drawing the edges of a single-player playfield using the second player sprite and missile. This might lead to the quickest way to get out a playable prototype.

Absolutely. I had a 1P centered playfield in earlier test programs, but I wanted to focus on 2P from the start. Trying to add a second player later in development would be a major PITA, though the first playable prototypes will probably only have 1P...

I won't have a .bin for this one because it is completely *not* exciting, but it demonstrates the fine positioning of the Player 1 and 2 Missile objects so as to form one side of each player's Well. This example has each Missile object placed to within 1 pixel of the flush edge of the game playfield... HPOS-JS-TEST3.bin You can easily see how the missile objects take the current color of the player on a scanline. This makes it a bit difficult to use them for decoration without things looking a bit...weird. (Press UP to cycle the background colors and see how the colors clash against each other.) I'll play around with some different ideas later, but for now I'm going to ignore the missiles. I'm pleased that they are finally being positioned properly, as only one single function is positioning every game object in under 30 bytes.

I added the gradient shading to the second player and it worked, but it was starting to "do too much work" on a scanline which causes a loss of some pixels on the left side. (I completely expected this.) I had already planned on a complete redesign for the actual rendering process anyway, so right now I'm going to back those changes out and work on a joystick handler rewrite (it doesn't handle both players simultaneously very well) and need to work on input smoothing. I may move on over to preliminary piece rotations soon. That's where it starts to get exciting.

Alright, so I managed to fix a few of the issues. There is still an occasional scanline glitch at the bottom that I'm not terribly concerned with at the moment... HPOS-JS-TEST2.bin This update adds 2P joystick movement. The first stick moves the piece on the left, and the second stick controls the right side. Right now, they are in lock-step with each other on the vertical axis because that is one of the next things to tackle. Right now, the pieces move horizontally (independently) but share the same downward movement....this prototype test kind of gives me an idea for a strange game mode... The fire button on P1 resets the vertical location. As you can also see, the 2P piece is just a solid color. I haven't moved on to independent shading yet.

Yuck! Today's issue is with positioning of both sprites. I'm definitely missing something minor, and it hasn't jumped out at me yet. I had started to add the second player to the test program, so that the second joystick would independently move a game piece on the appropriate side of the screen...and it was very close to working.

As you could see, the control is *too* responsive in the above test. This is actually a good thing. It means that with only some minor smoothing, it will be incredibly responsive and fluid. This one is going to knock it out of the park for playability and control...

I'll fix the glitch in this one when I have time later, but this sort of demonstrates the playfield grid that I was mentioning earlier, though the left and right movements certainly need to be tamed. This is the first test of the "soft drop," but the condition at the bottom of the screen isn't handled properly because the PieceCanAdvance code hasn't been written yet. Use the button to reset the piece position if/when it bugs out... HPOS-JS-PF-test.bin (still a little bugged, but better than before)

This morning, I managed to greatly simplify the horizontal and vertical positioning of the game pieces, reducing the majority of the calculations down to 2 or 3 bitshifts, plus one addition. This is great because it's only a few bytes and a few CPU cycles, it could almost even be applied within the joystick handler... The technical details about this is that I can use a default vertical positioning value of 22, shifted left 3 times which multiplies it by 8, giving the exact scanline in which to start drawing...after adding 16 to take into account the floor of the game playfield, of course. The horizontal positioning value has to be multiplied by 4, so that gives a value range between 0 and 9, which when shifted left 2 times multiplies the value by 4. Adding 26 (for Player 1) equates to the left edge of Player 1's game field; Player 2 simply has a larger offset value to position at the left edge of their side of the screen. The most difficult thing about the game playfield is handling the bitmap representation...that is to say, figuring out which parts are empty or not. I want to simplify everything and use exactly the same data representation that will be expected by the TIA (...it's PF registers) if possible, but this complicates things quite nicely...while simultaneously simplifying one part of the problem.

So this old (but better) shading scheme looks great for the pieces and rotations that are 2 game blocks high...but I haven't applied this method to the vertical orientations yet, so I'll have to do some testing there and ask for opinions... Oh, and for the record, everyone who is submitting ideas and opinions; you are basically helping to develop the game... I have no objections to list others in the credits for the finished product..

I'll go back to that shading method in some upcoming tests for sure. Thanks for the input After all, it may be required. When two players are on the same scanlines (like at the start of a new game) there might not even be enough CPU time to make all of those color changes! Every color change is about 5 CPU cycles, that means that the electron beam advances 15 pixels across the screen...out of 160 visibile pixels. You quickly run out of time to do anything before the next line is drawn on the screen!

Yeah, too bad the only DC game was the completely horrid, childhood-scarring, pile of trash that was Superman... (Hilariously, the Nintendo 64 title was somehow worse.) I think I'd rather see something like this:

This is a very minor update of the previous test program. It adds some simple bounds checking for the left and right movements, so it should constrain the Player 1 game piece to within its normal boundaries..though there is no game grid just yet. There is a little bit of a staging area at the top that you'll have to temporarily nudge the piece down from before it will advance down the screen... The vertical playfield is still currently chopped off at the bottom, as that's my primary focus (....getting pieces to properly lock into place at the bottom.) I'm also adding the second player's joystick handling and will have a "2 player" joystick demo soon... T-BLOCK-HPOS-JS-test2.bin

I started thinking about fixed-point math the other day, and while it might be a bit overkill for "Tetris," I figured I'd add this to my toolkit / arsenal since it will be almost required for a side-scrolling shooter, or anything involving jumping or gravity, etc... What this can do, is allow for essentially sub-pixel positioning by virtue of using a rather extended mathematical "canvas" for all game operations. Rather than constraining everything to 0-255 (or -127 to +128) and simple increments / decrements...which is all the 6502/6507 can really do), then 16-bits can be subdivided amongst a fixed-point (scaled) number representation, allowing for much finer-grained control...like sub-pixel positioning as I mentioned. Trigonometric functions would still benefit from using a lookup table method; but for a CPU that can't even multiply or divide (and hardly add or subtract, either)...fixed-point is definitely the way to go. The more I think about it, fixed-point might actually be a good fit for the joystick control... If I use a "canvas" of either 1024 (or 2048) units...maybe more if necessary...then I can allocate the remaining bits to the fractional (i.e.; "decimal" portion) and use different acceleration values for slewing the game pieces left and right over a much larger virtual "space." A simple function would shift and round the fixed-point values and translate them into "screen coordinates."** (**The VCS most certainly does NOT have screen coordinates.)