Hello all,
I am currently working on my first NES homebrew game, and I've just added in the scrolling and column drawing code. The object of the game is to avoid asteroids that scroll across the screen, which are randomly placed within the new columns. If the player collides with an asteroid, the game is over. I have written the code to draw the next column and scroll the screen, though this code currently just copies the data from a .bin file containing the level data. I want to write the asteroids to the background because they do not move independently of it, and I want to avoid issues with the 8-sprites-per-scanline limit.
I currently have a very rudimentary PRNG to determine the Y-coordinate of a given asteroid (I intend on expanding it to determine how many asteroids should be drawn on a given column, but would like to get this problem worked out first and expand later). I am looking for some advice from the more experienced NES developers here as to how to go about further development of the object placement. My current plan for the routine is:
1. Determine the Y coordnate of the asteroid to be drawn
2. Copy the nametable data to be drawn from the data file into a memory buffer; the buffer really only needs to contain data for the next column to be drawn.
3. Overwrite the data in the buffer at the Y coordinate of the asteroid to contain the asteroid image
4. Use buffer as data source when drawing the next column, rather than the .bin file
5. Track objects so that if they ever come into contact with the player sprite, the game ends.
The first question I have is regarding the memory buffer; I read in another thread that an easy way to create a buffer is to use the stack and set up a secondary stack pointer for the buffer. However, if I am going to be modifying the data in the buffer to draw the asteroids, I will either need to write directly into the stack (which seems like it defeats the purpose of the stack) or write something very long and convoluted to draw an asteroid instead of the regular background.
The second question I have is a little more broad, and it is regarding tracking these objects to determine whether they collide with the player. Should I track objects individually? Another idea I had was to check the value of the background at the boundaries of the player each frame to determine whether they have collided with anything. I'm wondering how feasible this is, considering VRAM can only be accessed in vblank. Any tips on doing collision tracking?
Edit: I also know some people include whether a cell is solid or not in their ma data, but I'm not quite sure how this works in practice/how to determine it.
Note that I'm not necessarily looking for code, though examples are always appreciated
Thank you all for your help, I really appreciate it!
Edit: to clarify, I'm only wondering about routines for placing the randomly generated position in the memory buffer and how to detect a collision with the player once it is there. I also do not need to worry about ejection as colliding with an object won't require this--colliding with an asteroid will trigger the game over sequence, so I really only need to worry about detecting the collision.
I am currently working on my first NES homebrew game, and I've just added in the scrolling and column drawing code. The object of the game is to avoid asteroids that scroll across the screen, which are randomly placed within the new columns. If the player collides with an asteroid, the game is over. I have written the code to draw the next column and scroll the screen, though this code currently just copies the data from a .bin file containing the level data. I want to write the asteroids to the background because they do not move independently of it, and I want to avoid issues with the 8-sprites-per-scanline limit.
I currently have a very rudimentary PRNG to determine the Y-coordinate of a given asteroid (I intend on expanding it to determine how many asteroids should be drawn on a given column, but would like to get this problem worked out first and expand later). I am looking for some advice from the more experienced NES developers here as to how to go about further development of the object placement. My current plan for the routine is:
1. Determine the Y coordnate of the asteroid to be drawn
2. Copy the nametable data to be drawn from the data file into a memory buffer; the buffer really only needs to contain data for the next column to be drawn.
3. Overwrite the data in the buffer at the Y coordinate of the asteroid to contain the asteroid image
4. Use buffer as data source when drawing the next column, rather than the .bin file
5. Track objects so that if they ever come into contact with the player sprite, the game ends.
The first question I have is regarding the memory buffer; I read in another thread that an easy way to create a buffer is to use the stack and set up a secondary stack pointer for the buffer. However, if I am going to be modifying the data in the buffer to draw the asteroids, I will either need to write directly into the stack (which seems like it defeats the purpose of the stack) or write something very long and convoluted to draw an asteroid instead of the regular background.
The second question I have is a little more broad, and it is regarding tracking these objects to determine whether they collide with the player. Should I track objects individually? Another idea I had was to check the value of the background at the boundaries of the player each frame to determine whether they have collided with anything. I'm wondering how feasible this is, considering VRAM can only be accessed in vblank. Any tips on doing collision tracking?
Edit: I also know some people include whether a cell is solid or not in their ma data, but I'm not quite sure how this works in practice/how to determine it.
Note that I'm not necessarily looking for code, though examples are always appreciated
Thank you all for your help, I really appreciate it!
Edit: to clarify, I'm only wondering about routines for placing the randomly generated position in the memory buffer and how to detect a collision with the player once it is there. I also do not need to worry about ejection as colliding with an object won't require this--colliding with an asteroid will trigger the game over sequence, so I really only need to worry about detecting the collision.