AkashicRecord Posted October 27, 2018 Author Share Posted October 27, 2018 (edited) ...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.) Edited October 27, 2018 by AkashicRecord Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 27, 2018 Author Share Posted October 27, 2018 (edited) ...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.) Edited October 27, 2018 by AkashicRecord Quote Link to comment Share on other sites More sharing options...
OldSlabSides Posted October 27, 2018 Share Posted October 27, 2018 Love the look of the game so far! The color scheme is looking pretty slick as well... 3 Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 27, 2018 Author Share Posted October 27, 2018 (edited) Love the look of the game so far! The color scheme is looking pretty slick as well... 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.) Edited October 27, 2018 by AkashicRecord Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 27, 2018 Author Share Posted October 27, 2018 I added horizontal positioning today to the VBLANK period and it seems to work perfectly down to the pixel! I'll post .bins later. Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 27, 2018 Author Share Posted October 27, 2018 (edited) 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. Edited October 27, 2018 by AkashicRecord 1 Quote Link to comment Share on other sites More sharing options...
NostAlgae37 Posted October 28, 2018 Share Posted October 28, 2018 (edited) Hey Akashic, the blocks shown in the below image had more of a 3D appearance than the screenshots that you've been posting lately: Was this something that was achievable on actual hardware or was it also a mockup of some sort? I guess that I'm a bit confused. Edited October 28, 2018 by NostAlgae37 1 Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 28, 2018 Author Share Posted October 28, 2018 Hey Akashic, the blocks shown in the below image had more of a 3D appearance than the screenshots that you've been posting lately: Was this something that was achievable on actual hardware or was it also a mockup of some sort? I guess that I'm a bit confused. 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... Quote Link to comment Share on other sites More sharing options...
NostAlgae37 Posted October 28, 2018 Share Posted October 28, 2018 Oh, so the recent screenshots are with scanlines enabled, that's what the difference was... I didn't realize it would have that much of an impact on how the pieces would appear to the eye, that's interesting. 1 Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 28, 2018 Author Share Posted October 28, 2018 Oh, so the recent screenshots are with scanlines enabled, that's what the difference was... I didn't realize it would have that much of an impact on how the pieces would appear to the eye, that's interesting. 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 Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 28, 2018 Author Share Posted October 28, 2018 Oh, so the recent screenshots are with scanlines enabled, that's what the difference was... I didn't realize it would have that much of an impact on how the pieces would appear to the eye, that's interesting. 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! Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 28, 2018 Author Share Posted October 28, 2018 Oh, so the recent screenshots are with scanlines enabled, that's what the difference was... I didn't realize it would have that much of an impact on how the pieces would appear to the eye, that's interesting. 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... 1 Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 28, 2018 Author Share Posted October 28, 2018 Hey Akashic, the blocks shown in the below image had more of a 3D appearance than the screenshots that you've been posting lately: 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... Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 28, 2018 Author Share Posted October 28, 2018 (edited) Oh, so the recent screenshots are with scanlines enabled, that's what the difference was... I didn't realize it would have that much of an impact on how the pieces would appear to the eye, that's interesting. This is also one reason why I would really love to see actual hardware test output of my code. Edited October 28, 2018 by AkashicRecord Quote Link to comment Share on other sites More sharing options...
NostAlgae37 Posted October 28, 2018 Share Posted October 28, 2018 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! Maybe less is more in this case? Is it possible that fewer gradient changes over the surface of the pieces results in a more 3D appearance? I am a pixel artist so I understand that subtle changes can have huge impacts on how the human mind interprets the images that it receives from the eyes. Believe or not, a lot of the success in what we do results from trial and error; just testing different iterations to see what works best. You might find that same sort of approach will pay dividends for you also in this instance. 1 Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 28, 2018 Author Share Posted October 28, 2018 (edited) Maybe less is more in this case? Is it possible that fewer gradient changes over the surface of the pieces results in a more 3D appearance? I am a pixel artist so I understand that subtle changes can have huge impacts on how the human mind interprets the images that it receives from the eyes. Believe or not, a lot of the success in what we do results from trial and error; just testing different iterations to see what works best. You might find that same sort of approach will pay dividends for you also in this instance. 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! Edited October 28, 2018 by AkashicRecord Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted October 28, 2018 Share Posted October 28, 2018 Two player tetris?? Are you kidding me?! Looking forward to following the development. I think the pictures with scanlines looks perfect, and cool effect without to. 2 Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 28, 2018 Author Share Posted October 28, 2018 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... Quote Link to comment Share on other sites More sharing options...
JeremiahK Posted October 29, 2018 Share Posted October 29, 2018 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.) If you time it right, you can do HMOVE's without comb lines, but it's a pain. (Also, I believe it doesn't always work correctly on all systems.) If you look at the bottom of this page, there is a table that shows how many clocks each HMxx value corresponds to at each cycle for strobing HMOVE. Otherwise you can leave the two outer bits of PF0 cleared, and this would draw a black bar on the right side of the screen as well. 1 Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 29, 2018 Author Share Posted October 29, 2018 (edited) 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! Edited October 29, 2018 by AkashicRecord Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 29, 2018 Author Share Posted October 29, 2018 (edited) If you time it right, you can do HMOVE's without comb lines, but it's a pain. (Also, I believe it doesn't always work correctly on all systems.) If you look at the bottom of this page, there is a table that shows how many clocks each HMxx value corresponds to at each cycle for strobing HMOVE. Otherwise you can leave the two outer bits of PF0 cleared, and this would draw a black bar on the right side of the screen as well. 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. Edited October 29, 2018 by AkashicRecord Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 29, 2018 Author Share Posted October 29, 2018 (edited) 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??? Edited October 29, 2018 by AkashicRecord 2 Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 29, 2018 Author Share Posted October 29, 2018 (edited) 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... Edited October 29, 2018 by AkashicRecord Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 30, 2018 Author Share Posted October 30, 2018 (edited) 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.) Edited October 30, 2018 by AkashicRecord Quote Link to comment Share on other sites More sharing options...
AkashicRecord Posted October 31, 2018 Author Share Posted October 31, 2018 (edited) 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 Edited October 31, 2018 by AkashicRecord 2 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.