Jump to content

JeremiahK

Members
  • Content Count

    275
  • Joined

  • Last visited

Community Reputation

201 Excellent

About JeremiahK

  • Rank
    Moonsweeper
  • Birthday 05/18/1996

Profile Information

  • Gender
    Male
  • Location
    Indiana, USA
  • Interests
    I was born in 1996, and played on my dad's Atari 2600 a bit as a kid. I enjoy making 3D graphics, running, working on my custom computer, and programming.
  • Currently Playing
    Insurgency

Recent Profile Visitors

4,214 profile views
  1. The low bit of colors can be used this way, too. After performing an ASL, it is ready to be used for one of the ENAxx registers.
  2. For larger snippets of code, I have started simply saving it to a file, and uploading as an attachment.
  3. In my nyancat kernel, I also split the screen into zones (7 rows, each 14 lines high, and separated by 5 lines, 128 lines for the whole display). I wanted the cat to be able to move "smoothly" from row to row (it can be drawn halfway between rows). For this reason, the cat kernel uses 2 rows. The other 5 don't try to draw the cat at all, so I was able to significantly decrease the amount of padding needed in the graphics. In the most complex part of the kernel, I am reading graphics values 8 times, and writing to TIA registers 11 times, per line, if I recall. I used every one of the 76 cycles per line, and all the registers. The stack pointer was used to hold a color value for one of the sprites, since it can be loaded into X faster than RAM. Note that the time-sensitive areas of the kernel must not cross page boundaries, unless the extra cycle is accounted for.
  4. Haha, I noticed the same thing myself! For debugging, I like to set the level to 99 to make it last forever, no reshuffles
  5. Let me know when you need the final bin for the stream. I am going to try and get the scoreboard functioning by then
  6. Thanks Omegamatrix! I had thought of that, but there isn't really a way to do that. The ball wouldn't be wide enough, and we are already using all the other objects/colors. I think the flashing block is fine, although we can always tweak the way it flashes. Yes, that is not final. We are definitely going for a steady 262 line 60hz display. Also, if anyone loads the game up on a Harmony cart, note that I am aware that the colors need to be improved. Some are fine, but green is especially icky.
  7. I like that! Another name idea I had was Block Party. Or we could call it Forty-Niner, and have some sort of classic bogus Atari story about being a California miner in 1849.
  8. Thanks Andrew! I actually did know that, if I'm honest, I just wanted the first reply
  9. Adding a reply so I get notifications. It's been a very productive week! Just Jeff and I have been brainstorming and hammering out the code this past week or so, starting from a static kernel display. These past two days have been the biggest breakthrough, everything fell into place. It's still very rough, but all the Bejeweled gameplay functionality is there, and in just under 1K of code!
  10. Agreed, I only mention it because it might affect how we implement certain things. I would recommend always checking all 16 rows/columns. This way, we can use the same routine to check after spawning in new blocks. You can only make 1 or 2 matches on a single move, but after gravity and random spawns, a chain reaction could start, and there would be no way of knowing where they are on the board without checking everything. The coordinates may not need to be kept, simply the cursor position and move direction. I made a comment on the commit, and I will copy it here in case anybody wants to respond:
  11. I am planning out how the game states/logic should flow. This is what I've got, let me know what you think. Attract Mode: Show game board with some fun colorful effects, just randomly changing colors for a placeholder (easter egg potential later). The previous game's score(s) should be shown. (Top for P1, bottom for P2? We can always decide on this later.) Pressing Game Reset or P1's fire button will start a new game with the same settings as the last game (or default settings on startup). Pressing Game Select or P1's up/down will enter Game Select Mode. Game Select Mode: Pressing Game Select or P1's up/down changes the game mode number, which is displayed in place of the score. If we end up wanting a Space Invaders style 112 game modes, this might not work well. Pressing Game Reset or P1's fire button starts the game by entering Game Init Mode. Waiting for some period of time without an input will preserve the selected game mode, but switch back to Attract Mode. Game Init Mode: All game variables are initialized here, level, score, cursor position, etc. The game board is cleared, and the game enters Shuffle Mode. Shuffle Mode: Blocks are randomly spawned into the top of the grid, falling down until the grid is full. They are spawned in such a way that no matches/runs of colors are formed. Once the grid is full, switch to Play Mode. Play Mode: This is the "normal" mode of the game, where the cursor is drawn, and moves can be made. If a player moves the joystick while holding the fire button, switch to Move Mode. Otherwise, move the cursor. Move Mode: Here a move is attempted. The gems being moved are swapped, and a bit in RAM is checked, the "undo" bit. If it is set, switch to Play Mode, otherwise Match Mode. This is because if a match isn't found (an illegal move was made), the move will have to be made again to swap the gems back. So basically, there are two Move Modes, Attempt Move Mode, and Undo Move Mode. Match Mode: Every row and column is checked for runs of 3 or more same-colored gems. If none are found, check the "recheck matches" bit. If it is set, we have already taken care of the matches and gravity, so clear the bit and switch to Play Mode. Otherwise, set the "undo" bit, and switch back to Move Mode. If matches are found (there might be more than one in the case of chain reactions), every matching gem is removed from the board, and the game enters Gravity Mode. Gravity Mode: Each column is checked from the bottom up for empty holes. When one is found, every block above it (including other holes) is moved down 1 step, and a new block is spawned at the top. If no holes are found, set the "recheck matches" bit (can probably be the same as the "undo" bit), and switch back to Match Mode, since the new gem locations may have formed new matches. As far as I know, this should cover everything in the game, except for knowing when the game is lost. In order to do this, it needs to be somehow determined that there are no moves left. Note that the game modes that change the state of the board will also take care of animating the moves.
  12. I just wrote a quick gravity routine! It handles every column in the same frame, but only takes 1 step per frame, so we can animate the fall over time. Here is a BIN with all white blocks. Use the debugger to change some to black and see what happens. Keep in mind I am ignoring the top row issue, so the top row actually is the bottom. Also, this is currently inserted into vblank, so it always runs every frame. I can add a gravity mode to handle the animation/logic, but skip the whole routine when we don't need gravity. BBlocks.bin Gravity.asm
  13. I don't think it will be possible to do any fancy gravity effects of blocks falling through the black bars between rows. I can't think of a way to do this without splitting the entire kernel up into 4-line sections, which would greatly complicate everything.
  14. I thought of an algorithm for checking the matches: Matches are only checked when the game enters "match mode", which is triggered when a move is made. Loop through all the rows. Step through each block in the current row, starting at the 2nd one. Compare each block to the previous one, and if they are the same, increment a counter to keep track of the run. If they are not the same, or if the end of the row is reached, check the run counter. If it is a run of 3 or more, step back through the row, setting the match bits on the matching blocks. Reset the run counter, and finish the row. Then do the same thing for the columns. I doubt there will be enough time to do this all in one frame, so the work can be split up across multiple frames. Use a RAM counter to keep track of which logic frame we are on. Checking 1-2 rows and columns per frame should suffice. After the matches are found, the next step is taken. Maybe play a color animation to show the matches flash quickly, then remove the blocks, add to the score, and switch to "gravity mode". If no matches are found (an illegal move was made), move the blocks back, and go back to normal/move-making mode. In gravity mode, the highest black block, or hole, in each column is found. All blocks above the hole are moved down, and a random block is spawned at the top. After all holes are filled, switch back to move-making mode.
×
×
  • Create New...