Asteroids - 1GAM Entry

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Post Reply
UnDisbeliever
Posts: 123
Joined: Mon Mar 02, 2015 1:11 am
Location: Australia (PAL)
Contact:

Asteroids - 1GAM Entry

Post by UnDisbeliever »

This is March's entry to my 1 game per month challenge, it's a simple game of Asteroids.
Asteroids Screenshot
Asteroids Screenshot
Asteroids (v01)[HB].png (2.72 KiB) Viewed 2901 times
I spent March focusing on Object allocation, physics and collision detection.

Memory management is accomplished by two linked lists, called free and active. Creating an entity involves moving the memory out of the free list and into the active list, vica-verca for destruction. As the entities are stored in a singly linked list, destruction only occurs in the final entity pass (Render).

Collision detection is done through bounding-box collision testing. There are three types of entities, Players, NPCs, Projectiles.
For speed purposes the system will only check for collisions between:
  • The Player and NPCs
  • The NPCs and Projectiles.
Unfortunately with how I've arranged things, the system can only process 65 Asteroids, 1 Player and 3 Projectiles before hitting slowdown. That will occurs at level 6 if the player doesn't destroy all of the small asteroids, therefore I've caped the level to 7.

I tried to get the game to mirror-wrap the asteroids (where half the asteroid is on the left and the right at the same time), but I couldn't find an easy way to do bounding box-collisions for when the asteroid is wrapped. I tried twice and couldn't tighten the collision loop.

Instead I just simplified the whole problem and extended the playfield by 32 off-screen pixels. I've played the game a few times and it hasn't bothered yet. I'm not going to code another game that does this.

As usual, the same is licensed under the MIT license and the source is available at https://github.com/undisbeliever/asteroids

---
I still can't test this real SNES yet. I'm having issues interfacing my computer with the SNES. Maybe when I have more free time I'll figure it out.
Attachments
Asteroids (v01)[HB].zip
Asteroids SNES ROM
(12.75 KiB) Downloaded 131 times
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Asteroids - 1GAM Entry

Post by Drew Sebastino »

UnDisbeliever wrote:the system can only process 65 Asteroids, 1 Player and 3 Projectiles before hitting slowdown
Are you using fastrom?
UnDisbeliever
Posts: 123
Joined: Mon Mar 02, 2015 1:11 am
Location: Australia (PAL)
Contact:

Re: Asteroids - 1GAM Entry

Post by UnDisbeliever »

Espozo wrote:Are you using fastrom?
Yeah that's the first thing I did. But the screen gets crowded after level 5, so it doesn't matter, the game is fast enough.

I'm just beginning to realise tight the game loop is going to have to be in the future for my next set of games, unless I want to drop the game to 30FPS :?
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Asteroids - 1GAM Entry

Post by Drew Sebastino »

You know, how did you say you did objects? What I do is I have a table in ram and the first byte in every slot in the table is the "object identification" byte. It loads a jump table in a code and offsets it by whatever that byte was and then jumps to the code for that object. It then repeats until it reaches the end of the table, and then returns. Is that sound good? I'm a bit concerned if you only got 65 asteroids on asteroids. :? Your code doesn't even have to look for an empty spot in vram or look for a place to load a palette or anything like that.
UnDisbeliever
Posts: 123
Joined: Mon Mar 02, 2015 1:11 am
Location: Australia (PAL)
Contact:

Re: Asteroids - 1GAM Entry

Post by UnDisbeliever »

My entities are arranged in a linked list. The first word of the entity is the address of the next entity to process.

This allows me to just load the next address into direct page and avoid the whole TDC : CLC : ADC #size : TCD : CMP #end : BCC loop mess and replace it with a simple LDA z:EntityStruct::nextEntity : TCD : BNE loop

It also allows me to determine address of the next spawned entity in linear time. This is done by removing the entity from the free entities list and adding it to the active entities list.

The second word is the address of a function table that gives me a little polymorphism with the JSR (addr, X) instruction.


There is two loops. The first processes the entities physics and operates like this:

Code: Select all

dp = player
dp->functionsTable.process()
dp->functionsTable.physics()

for dp in ProjectilesActive
   dp->functionsTable.process()
   dp->functionsTable.physics()

for dp in NpcsActive:
   dp->functionsTable.process()
   dp->functionsTable.physics()

   if collision(dp, player):
       dp->functionsTable.collisionPlayer(dp)

   for y in ProjectilesActive:
       if collision(dp, y):
            dp->functionsTable.collisionProjectile(dp, y)
where collision is an inline macro for speed purposes.


The second loop renders the entities and cleans up any dead entities from the active lists.

Code: Select all

dp = player
RenderEntity(dp)

for dp in ProjectilesActive:
   if dp alive
       RenderEntity(dp)
   else
       remove dp from Projectiles Active list

for dp in NpcActiveList:
   if dp alive
       RenderEntity(dp)
   else
       remove dp from NPCs active list.
When I did the math I expected to be able to process 80 NPCs and 3 Projectiles in a single frame, so my estimation is a little off. I don't have to do a full profile of my code, so I'm not sure if there's anything I could do to speed it up.


Future games I code would probably only have 12 NPCs active on the screen, 3 player projectiles and maybe 10 enemy projectiles at any given time (~20% CPU). Easily giving me enough CPU time for tile collisions, dynanic tiles and the rest of my (currently imaginary) game engine. I'll have to add another list (off screen npcs) to correctly handle this, but I think I've got it down correctly on paper.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Asteroids - 1GAM Entry

Post by Drew Sebastino »

Wait, I just noticed something after looking at the source code on that website. Was this programmed in C? If so, that could be the reason for some of the game's slowdown. (By the way, I think it would be nice if you added a pause feature and it would be cool if you added an 8bpp space background from the internet or something. I know this was supposed to be a fun little thing though and not a "polished" game or anything.)

You could use something like this, as long as tone the amount of tiles down slightly and if you use a little less colors. Do you know if you can change the color depth in gimp, because although the picture is 256 colors, I'm not sure if some of the colors would be duplicates of each other on the SNES because of the reduced color depth.
Space Background.png
Space Background.png (36.68 KiB) Viewed 2784 times
Post Reply