Jump to content

triggthediscovery

New Members
  • Posts

    4
  • Joined

  • Last visited

About triggthediscovery

  • Birthday 09/29/1996

Profile Information

  • Gender
    Male

Recent Profile Visitors

776 profile views

triggthediscovery's Achievements

Combat Commando

Combat Commando (1/9)

19

Reputation

  1. I'm not exactly sure what the limitations of Batari basic are (I've heard it leverages the ARM), but I'm writing this for a stock 4k cart in assembly, so I was very particular (read:overcomplicated) with how I handled it. Apologies if this is a little hard to follow, please let me know if I need to clarify something. Background info: The enemies are drawn using a rotating 16 byte buffer, each byte applying to a 4 kernel line subroutine (move, move+4, draw, ect.) and NUSIZ instructions (1 copy, two close, ect.) which is updated every 4 kernel lines (the subroutine is in the top 4 bits, NUZIO in the bottom 3). The play area is 64 kernel lines tall, so the 16 byte buffer covers the screen. The player is drawn with the ball in a rotating 64 byte buffer, updated every kernel line. I make sure to track the player and enemy positions every kernel line so I know their absolute positions on screen. For collision: In the enemy update cycle (once every 4 scanlines), there is a collision check. This uses the (player position - enemy position) (which ever one you collided with) and references a 256-bit array (covering all possible relative positions) to determine which enemy was hit (#%10000000 is the leftmost, #%01000000 is the middle, #%00100000 is the rightmost). This is then XORed with the 16 byte enemy buffer pointer (I only need the lowest 4 bits, as it's only 16 bytes long) to store which enemy the player collided with. This is then stored in memory to be referenced later (as this was already too much logic in the kernel) Outside the kernel, I used the enemy pointer to determine which byte in the enemy table the player collided with, and the surrounding bytes to determine which enemies were present on the line, updating the enemy buffer to "remove" that enemy so it won't appear next frame. So, I'm actually only doing one collision check every 4 kernel lines (once for each set on enemies).
  2. Well, it's been **checks calendar** a while, but I have been working on this in fits and starts for a bit now. I had some issues, namely losing the source code, but I've managed a more game like demonstration of what this is supposed to be. This version adds collision detection, which ended up requiring a lot of the kernel to be rewritten. When in P0 difficulty B it only applies collision detection to the enemies, with difficulty A applying it to them and the player. The player collision is rough (it causes image scrolling issues on real hardware.) It's there because I had already done the work before I realized it would take some work to get right, and figured putting it behind an option would be possible. This version also adds color to the enemies, and gives each set different graphics. I realized I could add this more or less for free to the kernel, and figured "why not?" I also added an enemies killed counter at the bottom. For the purposes of this it only goes up to 99, but that will serve as the basis of the score counter once that gets in. I've tried testing in emulator and real hardware, but there might still be bad boot states remaining. The collision itself is also kinda funky, there's definitely room for improvement there, but I'm planning on leaving it until I get further into development. But that's more or less it. Fingers crossed, I can get this to a satisfactory place without too much more work, but honestly I didn't think I would still be on this 18 months after starting. vsshooter.bin
  3. I apologize, I accidentally uploaded an outdated bin file! Thanks SpiceWare, I'm realizing I'm going to need a flashcart if I want to make sure it works properly on a real system. In regards to all my WSYNCs I might use the timer in the final version, but right now they were just the easiest way to get a stable game in Stella, I intend to hopefully use all that free CPU time for something fun. But here's my current beta, and I know it works as a demo in Stella, but it doesn't have any added features, again sorry for the outdated bin vparallax_01.bin
  4. Update: Check my comment below for more details, but I've added the current version as vsshooter.bin on this post -- Original post -- Hello, I've been working on my first major 2600 project, and decided to post about it here just to see what people think about it. It's a vertically scrolling shooter for the 2600 running on a stock 4k cart. I don't have a harmony cart, so I've only had the opportunity to test it in an emulator, so apologies if it's not stable on real hardware. The kernel should theoretically support ~30 enemies on screen at a time. The current version technically supports this, but it can cause some bad artifacts with scrolling enemies. Currently it's more of a tech demonstration than a game, since I need to rewrite the kernel to allow for collision detection (I was planning on doing collision detection separately, but after calculating the timing it would take 30+ scanlines for all the math) but I figured before I gutted my code I would record the state things are in right now. Luckily, I won't have to remove any functionality shown in the current demo, so it should be representative of the game if I get the time to finish it vparallax_01.bin vsshooter.bin
×
×
  • Create New...