AkashicRecord

So, Whitesnake comes on the damn radio as I'm reading Nukey Shay's comment. I guess that means I'm going to have to add some form of this stupid game mode to my cartridge. Just...wonderful... Probably going to need feedback when that time comes, because I just don't see this as being a very fun version of Tetris!

Pitfall! was one of my all time favorites. I never owned the cartridge as a child, but I always spent a lot of time at friends' houses that had it! ...that, and Berzerk. You should give David Crane's Pitfall! panel sessions a watch, they are worth every second. Oh, and did you know that Jack Black (yes, that Jack Black) was in the Pitfall! TV commercial? https://www.youtube.com/watch?v=wfLgSdAAHMA

Huge indeed. You have about a 40 x 24 grid using the playfield if you aim for 8 scanlines of vertical resolution per "block"....it's *mostly* square-ish at that point. But here's the kicker: A bitmap representation of a playfield of that resolution would use exactly 120 bytes of RAM... Have fun with only ~6 variables for your game!

Today, I had some fun with the Missile objects, but the positioning for those was a bit...off. I think I'll set the missile decorations aside for the time being and move on to the playfield bitmap and writing the PlayerCanMove / PlayerCanRotate / PlayerCanAdvance functions which comprise the bulk of the game logic... While working on the horizontal positioning for this game I had an idea for a horizontal and vertical side-scrolling shooter (somewhat like "Life Force" for the NES...or "Salamander" for the arcade), but it doesn't have a name yet; that, and "Dr. Atario" will be the next titles in my VCS lineup, but not necessarily in that order...

Here's a more "realtime" example. This one adds some very crude joystick movement code, but there is one HUGE factor here....it moves the object only one pixel at a time, per frame... Z-BLOCK-HPOS-JS-test.bin The standard Tetris game field is divided into much larger chunks of pixels (and scanlines) so the pieces will move over a far more coarse grid than these examples currently demonstrate. I may add smooth pixel-precise animation at a later date, but for all intents and purposes, the game is going to adhere to a more coarse and "fixed" grid. Anything else is just for looks and show. This example does NOT perform any sort of bounds checking, so it will behave very oddly beyond the left and right screen edges. The playfield is also set to take priority, and the bounds for the playfield edges are not checked, so the object will (unrealistically) move behind the playfield... Pressing the joystick button will reset the game piece to its default position. These issues will NOT be in the finished product, of course... After all, this is what game protoyping and testing is all about, isn't it???

Yes, thanks for that link! It's incredibly handy. After my initial implementation of HMOVE positioning, I don't think I'm going to have to worry too much about the black line artifacts. The PF0 solution to trim the field a bit almost crossed my mind, though. That method would definitely work well for this game, should it be necessary. I'm aware of the techniques to strobe HMOVE every line (overkill) and also the cycle 73 / 74 HMOVE latch "trick" but I don't think I need to go that far. Since I'm positioning the objects so early, I don't think there will be anything to worry about (for this game, anyway.) I could even position the objects in the Overscan period...doesn't really matter either way I think, since the player objects move so infrequently anyway.

Well, I didn't get much accomplished today...my Netbook's A/C adapter is on the fritz today. I did have two hardcoded tests of the horizontal positioning. One positions the object at position 26, which aligns nicely with the left edge of Player 1's game field. The second .bin has a hardcoded position of of 54, placing the object flush with the right side. This is pixel-precise with regard to the game field, so this will do quite nicely, and I can sort of forget about horizontal positioning from now on. (I've removed the hardcoded horizontal positioning test .bins and am replacing them with a more interactive version): J-BLOCK-HPOS-test.bin Since the positioning for both players will need to happen only once during VBLANK, I'll have plenty of CPU to spare for calculating the positions rather than hardcoding ROM lookup tables... I'll work on adding some crude joystick positioning in a few minutes, but it is probably going to all over the place, so don't say I didn't warn you!

You can't think of programming the VCS in this way. There is no "drawing something after a nop." You have to think of the TIA and 6507 as being in lock step with each other. You have 76 CPU cycles across each scanline. Whatever CPU cycle *at that moment* along a particular scanline is what is going to determine where on the screen a particular change will take place. The TIA always does what it was last doing until it is told otherwise...the CPU clock cycle timing is what determines just about everything.

The first reminds me of Haunted House a little bit.

The next tests that I'm currently working on are crude joystick movement tests where you can slew game pieces left and right. I need to put the horizontal positioning function through its paces. (For anyone interested, it's the somewhat magical "subtract 15" loop of twenty-something bytes.) After these tests, it's on to the playfield and getting pieces to lock in to place, etc. It will start to feel like a real game at that point. The graphics kernel is still largely unfinished, as I'm still working out the dispatch strategy for the different combinations of game objects on the critical scanlines. Look forward to some more test code later today...

I think that might be the case, but look at that double "T" block .bin (with CRT emulation) first. It may be that a certain level of "crispness" to the graphics simply isn't possible... It's certainly possible to change everything now, though; I'm still technically in a strong design phase right now....some of the best graphics effects are still a ways off... I absolutely value your criticism!

This is also one reason why I would really love to see actual hardware test output of my code.

I had some idea to use the Ball and other objects (as available) to decorate things as much as possible. One of my unpublished mockups involved some "3D" shading which was very convincing... I've not shared either the mockups or test code (yet) because it is much more complicated. This will be the future icing on the cake, provided that the cake can even withstand it...

This is one of the small reasons why Activision's games were the best... They developed their games on actual consumer hardware (e.g.; shitty CRTs), where other developers used monitors; entirely unrealistic equipment for the general consumer...

Well, recently I've been using as many color changes and gradients as possible in my tests... Some of the previous examples only had a handful of color changes. Most of these recent tests are showing every possible luminance value across the full spectrum afforded to the VCS... Just wait until I have to figure out a PAL color scheme!

Yes, I'm trying to simulate badly adjusted televisions so that the picture is as universally good as possible. Here's that double T-Block .bin (...there are code issues within): two-T-block-test.bin

Oh, I still have that .bin... It was a Stella screenshot, but without the CRT / phosphor simulation. I'll post it in a few minutes if I can...

What's nice about this horizontal positioning code is that I'm strobing HMOVE during VBLANK, so there isn't the infamous "black bar" or combing on the left screen edge. Perfect!!! (It's nice not having to waste the Ball object to smear it down the left edge to hide HMOVE artifacts...) I may even have plenty of spare time to use the player Missile objects for playfield decorations. Let's see what we can do.

I added horizontal positioning today to the VBLANK period and it seems to work perfectly down to the pixel! I'll post .bins later.

Thanks! I can't wait until the playfield+game piece protoypes are finished. I think they are going to look very nice together. I should be able to get these pieces to snap into a horizontal grid pretty soon, and then I can move on to some joystick movement tests. I'm worried about having black bar combing artifacts on the left side of the screen once I start touching the HMOVE register...so I may have to settle with a slightly off-centered display...maybe. This means that there might have to be a black bar on the left side of the display, making it look off-center.)

...so my only real graphics issue with the game pieces is the "L" block. There isn't a very good orange color in the VCS' palette. So contrast this "orange" piece to the yellow or gold Square block above. L-BLOCK-anim.bin I suppose it will have to do! (I haven't experimented with alternating colors on different frames or scanlines. That might be something else that can be done to improve the graphics later.)

...who could forget the Square or "O" block? O-BLOCK-anim.bin I'm kind of digging the colors as they are so far. What does everyone else think? (The playfield area outside is plain and unfinished in these examples. There are more examples at the bottom of page 4.)

Here's another dump of some (rather obsolete) graphics tests using the gradient shading: Z-BLOCK-anim.bin S-BLOCK-anim.bin J-BLOCK-anim.bin Again, it isn't much, but it gives a gist of what this might look like. This code is NOT tested on real hardware, so I have no idea what it looks like on a real television and console. The joystick is still enabled for these. Use the left and right stick inputs to randomize the playfield color every ~30 frame ticks, and use the up and down inputs for fine-tuning the color gradient. It's good for testing to see what the game pieces look like against other playfield colors...

This isn't exactly what I had in mind for the finished product, but it gets kind of close. I'm still cranking hard on this stuff, but I don't feel bad about tossing out crude examples in the meantime. This one chunks a purple T block down the screen, and looks a bit better than the previous: T-BLOCK-anim2.bin Here's a simulated screen image: And here's a "badly adjusted" simulated TV image (running under Stella): (I know it isn't much....because I'm not showing everything just yet...)

Thanks for the comment! I know it is a lot of technical mumjo-jumbo, but this works really well for me as a detailed note-taking system. I won't miss anything if its well-documented. I think I'll absolutely be able to hit my target...it's getting to be within sight already. I hope to have an animated example with that gradient shading added back in later. (I took it out to simplify testing for now, but I have some test files that still have it in.) One of the upcoming protoypes will have more pieces that will change in response to button presses. I'd like to move on to that before rotations and the game coordinate system.