News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: slidelljohn (a.k.a.[J]) snes projects page  (Read 10658 times)


  • Full Member
  • ***
  • Posts: 237
    • View Profile
Re: slidelljohn (a.k.a.[J]) snes projects page
« Reply #60 on: May 22, 2019, 12:49:48 pm »
Lol, thanks! :woot!:

Here is the 128x128 bubbles collision.
Code: [Select]
    00000     5
  000xxx000   14
 00xxxxxxx00  25
 0xxxxxxxxx0  36
00xxxxxxxxx00 49
0xxxxxxxxxxx0 62
0xxxxxxx0     71       //I triple checked to make sure this one was correct
0xxxxxxxxxxx0 88
00xxxxxxxxx00 101
 0xxxxxxxxx0  112
 00xxxxxxx00  123
  000xxx000   132
    00000     137

FC FC 07 00 //collision square #1
FE FC 04 00 //collision square #2
00 FD 04 00 //collision square #3
02 FD 04 00 //collision square #4
04 FD 01 00 //collision square #5
78 FD 07 00 //collision square #6
7A FD 04 00 //collision square #7
7C FD 04 00 //collision square #8
84 FD 04 00 //collision square #12
86 FD 04 00 //collision square #13
88 FD 01 00 //collision square #14
F6 FD 07 00 //collision square #15
F8 FD 07 00 //collision square #16
08 FE 01 00 //collision square #24
0A FE 01 00 //collision square #25
76 FE 02 00 //collision square #26
8A FE 02 00 //collision square #36
F4 FE 07 00 //collision square #37
F6 FE 02 00 //collision square #38
0A FF 02 00 //collision square #48
0C FF 01 00 //collision square #49
74 FF 02 00 //collision square #50
8C FF 02 00 //collision square #62
F4 FF 02 00 //collision square #63
04 00 02 00 //collision square #71 looks like it should be #75(0x0C 0x00, 0x02 0x00)
74 00 02 00 //collision square #76
8C 00 02 00 //collision square #88
F4 00 01 00 //collision square #89
F6 00 02 00 //collision square #90
0A 01 02 00 //collision square #100
0C 01 07 00 //collision square #101
76 01 02 00 //collision square #102
8A 01 02 00 //collision square #112
F6 01 01 00 //collision square #113
F8 01 01 00 //collision square #114
08 02 07 00 //collision square #122
0A 02 07 00 //collision square #123
78 02 01 00 //collision square #124
7A 02 04 00 //collision square #125
7C 02 04 00 //collision square #126
84 02 04 00 //collision square #130
86 02 04 00 //collision square #131
88 02 07 00 //collision square #132
FC 02 01 00 //collision square #133
FE 02 04 00 //collision square #134
00 03 04 00 //collision square #135
02 03 04 00 //collision square #136
04 03 07 00 //collision square #137

Here is a image of the collision grid. The red square is to show the center of the 128x128 bubble(0x00 0x00).

I now understand how most of that section of the bubbles asm works so let me know if you
need help with any of it. I'm getting ready to remove all graphics compression from the
rom so its going to speed up level loading and free up a bunch of wram that is used to store
the decompressed graphics. I'm also going to increase the rom size for the decompressed
graphics and for extra asm space. Hopefully within the next 2 weeks I should have it ready.
« Last Edit: May 22, 2019, 01:24:06 pm by slidelljohn »


  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: slidelljohn (a.k.a.[J]) snes projects page
« Reply #61 on: May 23, 2019, 09:50:20 am »
great to see you're still working on this  :woot!:


  • Jr. Member
  • **
  • Posts: 18
    • View Profile
Re: slidelljohn (a.k.a.[J]) snes projects page
« Reply #62 on: May 24, 2019, 09:24:39 pm »
I can't believe they used a grid for bubble collision.  I just assumed they used bounding box collision, followed by circlular collision like any sane programmer would do.


  • Full Member
  • ***
  • Posts: 237
    • View Profile
Re: slidelljohn (a.k.a.[J]) snes projects page
« Reply #63 on: May 26, 2019, 02:58:02 am »
I should have a new patch within the next couple of weeks ready. It will
be a updated fastrom patch combined with my new decompressed gfx/data
patch that I'm currently working on.

The grid collision for the bubbles is like a secondary collision. Its only
for bubbles having contact with other bubbles. The main collision is like the
bounding box collision that you described. If you look at the ram data for the
bubbles the ram 0x28-0x2b is the dimensions for the bubbles main collision.
This collision is for when your ship touches it, when your ships bullets hit it
and for the bounding box. 0x0b 0x00, 0x0b 0x00 is for 32x32 bubbles main
collision and 0x05 0x00, 0x05 0x00 is for 16x16 bubbles.

Here is a small tool that I'm working on to help with creating my next patch.

This tool decompresses lots gradius 3 graphics to files and puts them in their
own directory. I currently only have it decompressing the graphics and data
in bank $06 but I do already have all of the data for all of the banks. This is
just a test program and it is not optimized yet. To use the tool load a headerless
Gradius III (U) [!] rom and then push the create files button and it should create
a folder "068000" in the same directory as the tool. Do not load any other file into
this program and do not edit the data.bin file and you shouldn't run into any
problems. The decompressed .bin files that this tool creates can be loaded into your
favorite tile editor to view the decompressed graphics. I think only 1 of the
decompressed .bin files(06f57a) is data and the rest are graphics.


  • Jr. Member
  • **
  • Posts: 18
    • View Profile
Re: slidelljohn (a.k.a.[J]) snes projects page
« Reply #64 on: May 27, 2019, 10:18:00 am »
I think the whole bubble to bubble collision routine can be replaced with a more normal collision routine and people wouldn't know the difference.


  • Full Member
  • ***
  • Posts: 237
    • View Profile
Re: slidelljohn (a.k.a.[J]) snes projects page
« Reply #65 on: May 28, 2019, 03:51:51 am »
If that would speed things up that would be great.

I did some looking into vitor's sa-1 hack to see why there was still
slowdown when some bosses die and the code to make the screen fade away
was being ran on the snes cpu and the sa-1. At $00:82b2 you need to nop
the 4 bytes to stop the snes cpu from running the code so only the sa-1
will run it. So change these 22 65 92 00 to EA EA EA EA and it fixes it.
I don't know how vitor missed that. This fixes the gfx bugs and I think it
fixes the slowdown in that spot.

Here is a patch that has the bug fix plus a optimization that I did for when
the bosses die. Apply vitor's recent patch then this one.

If anyone still notices slowdowns or gfx bugs with this fix let me know and
I'll take another look at it.

« Last Edit: May 28, 2019, 04:25:16 am by slidelljohn »


  • Jr. Member
  • **
  • Posts: 92
    • View Profile
Re: slidelljohn (a.k.a.[J]) snes projects page
« Reply #66 on: May 28, 2019, 01:10:02 pm »
Very nice find, I'll test that change later and report my findings.

Update, looks good to me, the only noticable lag is the missile boss during the boss rush.
« Last Edit: May 28, 2019, 01:46:46 pm by Grego »
UltraNet SNES Network Adapter:
F-Zero Final v0.2 Teaser:
F-Zero Final Github:


  • Full Member
  • ***
  • Posts: 237
    • View Profile
Re: slidelljohn (a.k.a.[J]) snes projects page
« Reply #67 on: May 28, 2019, 08:08:58 pm »
I just now tested up to the missile boss and it looks like slight
game play slowdown but not when the boss dies. I have also noticed
some slight slowdown on the volcano stage at the top of the screen
when you are going through the sand that you shoot. I was using the
laser that charges and the 4 spinning options. Did you notice any
other slowdowns when the bosses die? I'm surprised no one has
mentioned the bug with glitchy graphics. All I see is people talking
about the boss slowdown when they die. I knew something was off when
I seen those graphics messing up. Has anyone noticed the glitchy graphics
in vitors sa-1 hack?

Here is the optimized asm code that I put in that patch:

These are the jumps to load the new code but the snes one was turned off with the 4 nop's.
Code: [Select]
$00/82B2 22 02 FE 00 JSL $00FE02[$00:FE02]   //snes
$00/FAA9 5C 02 FE 00 JMP $00FE02[$00:FE02]   //sa-1

Can anyone confirm the cycles are calculated correctly in the trace files? I'm using my new cpu
tracer to get the cycles. The cycles are calculated using the information on this page:

I found a way to record gameplay to sram and I'm going to try to add this feature when I add sram.
I'll probably have it store the gameplay every time the high score has been beaten so anyone can
replay the highest scores gameplay. Its going to take a little bit of work to pull it off but I'm
pretty sure I can do it. This is going to be a exciting new feature to play around with.

I have been slowly adding in the decompressed graphics into gradius. I was able to make a few optimizations on when certain graphics get loaded into vram. For instance the sand dragon slows the game down because it’s constantly loading new graphics into vram. These graphics are dma’d in 2 sets of 0x200 bytes. I have edited the code to load them in 1 dma at 0x400 bytes. Plus the graphics are constantly being updated into vram even if it’s the same graphics that were loaded the last time so I added a check to see if it’s the same graphics so if it is it doesn’t dma anything. I was also able to make the same modifications with your ship, power up and options gfx as well. The new asm that I’m writing for dmaing gfx to vram will be the only optimizations that I’ll add to the decompression patch. I didn’t plan on adding any optimizations to the decompression patch so these a are nice bonus. All of the new asm codes for dmaing the gfx will be uploaded after I get all of the decompressed graphics working correctly. It going to be a lot of new code.
« Last Edit: June 03, 2019, 12:11:29 pm by slidelljohn »


  • Full Member
  • ***
  • Posts: 237
    • View Profile
Re: slidelljohn (a.k.a.[J]) snes projects page
« Reply #68 on: June 12, 2019, 11:58:17 pm »
With all of this stuff that I'm working on for gradius 3 I needed a easy way
to start at any level so I made a small hack that lets you start at any level.
This patch also includes text files for the changes that I made to create the hack.

I would like to upload this new patch to Can anyone test it
to make sure that it is working without any bugs? If anyone can confirm that
it works without any bugs I'll upload it.

I'm making good progress for the decompression hack for gradius 3 but its
taking longer than expected because I have been documenting all of gradius 3's
level data as I have been inserting the decompressed graphics. I have most of
the data documented to create new levels. I have all of the data documented for
all objects placed in the levels. Its very easy to add or remove objects in all
levels. After I finish the decompression hack I will start building a gradius 3
hacking tool that includes a level editor. Hopefully soon I'll at least have a
level and object viewer working.