Romhacking.net

Romhacking => Personal Projects => Topic started by: slidelljohn on January 01, 2019, 10:46:14 pm

Title: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on January 01, 2019, 10:46:14 pm
Welcome To My Projects Page!

I currently have 2 important projects that need to be finished and released.

Project #1 Gradius 3 (fast rom about 99% complete, sram support work in progress)

I have a near complete Gradius 3 fast rom. All assembly is complete there is just some data that still needs
to be changed to fast rom locations but it shouldn't really affect the speed much. There is definitely a noticeable
amount of decreased slowdowns but it still doesn't remove all slowdowns. Here is the patch:

http://www.mediafire.com/file/cg9yg9tpce03ytk/Gradius_III_%2528U%2529_%255B%2521%255D_%257BFast_Rom%257D.rar/file (http://www.mediafire.com/file/cg9yg9tpce03ytk/Gradius_III_%2528U%2529_%255B%2521%255D_%257BFast_Rom%257D.rar/file)

I also added extra difficulties that you can unlock by holding L, R, Y, and B buttons at the same time when you go into the
option menu. There are 4 new difficulties which are elite, master, expert and pro. Normal, hard and arcade are slightly easier.
Elite difficulty is the same as the original arcade difficulty but master, expert, and pro are gradually harder with pro as the
hardest.

(https://i.imgur.com/ZX6zJiO.png)

The lastdual helped me with this patch by checking for bugs that I might have missed. There could still be some bugs so let me
know if you find any. I really need someone to try and beat the hardest level to see if there are any bugs in the gameplay.

My main goal for gradius 3 is to remove all slowdown, add sram and make it feel like a competition cart. I also want to add
a new system for calculating your score after each boss kind of similar to super punch out. Now fast rom will never remove all
of the slowdowns so I have been learning about the sa-1 chip. I do have a gradius 3 rom that is updated to use the sa-1 chip but it
does not load gradius 3's assembly yet. I have been gradually changing the assembly code to store all wram data into bw-ram for
the sa-1 chip to work properly, this is near complete. When I complete the wram to bw-ram change I'll start working on getting
the sa-1 to load most of the assembly. I plan on having the snes cpu live in wram so the cpu's don't collide so I can get the full
speed out of the sa-1 chip. I have no clue how long this is going to take but I chose gradius 3 for this because it is a small rom.
I hope everyone enjoys the fast rom patch and the extra difficulties.





Project #2 New snes mod chip called Super V-Power! (v = vram) (100% working but could still be improved)

This mod chip is for adding extra vram to the snes. The snes has 64kb of vram but the ppu is capable of using 128kb of vram.
Creating this mod chip kind of just fell in my lap. I did not figure out the ppu can use the extra vram and I'm not really sure who
did but byuu made higan v1.00 and up capable of using the extra vram because he said it should be possible. You can see how I ended
up creating this mod chip on byuu's forum. Byuu's forum is gone but it has been completely archived here:

http://helmet.kafuka.org/byuubackup2/viewtopic.php@f=16&t=1559.html (http://helmet.kafuka.org/byuubackup2/viewtopic.php@f=16&t=1559.html)

All of the mod chip stuff is at the end of that page but you can see how it ended up getting made from reading everything from the
beginning. I also modified a snes debugger to show the extra vram in the vram viewer so there is a debugger that's supports the extra
graphics. The link to the debugger is on that 1st page. Qwertymodo was a really big help in showing me how to create the castellated
holes to mount the pcb to the snes and he helped me in how/who to send the pcb to to get made. The entire pcb I designed myself and
created in eagle cad. Im getting ready to create a updated version of the super v-power mod chip and when its finished I'll upload
all of my schematics. Im not interested in making any money off of the mod chip it will be fully open source for anyone to make it if
they want to. I do have a few mod chips that Im willing to give away for free to people that have the skills and want to create hacks
that use the extra vram. If anyone has a fully working level editor for a snes game and would like to add this feature to their editor
I would be willing to modify the game that uses their editor to use the 128kb of vram. I already have a mmx v1.1 rom that fully supports
the extra vram but I need to write a editor from scratch to be able to use it. As far as all my searching online I am the only person
to try and get 128kb of vram to work on the snes. I was trying to get analog to get their super nt to support the extra vram but I
didn't have any luck probably because nothing uses the extra vram yet. One day they might add support for it.

Here is my mod chip installed on the snes motherboard:

(https://i.imgur.com/lk6pD66.png)

If I can get the sa-1 hack completed it would set me up for a project that will blow all other projects that I have worked on away,
which is, mega man x with sa-1, 128kb vram and a new engine to have game play like super metroid.



Moderators:
Hopefully it was/is ok for me to talk about this chip here because it could be a game changer for future snes rom hacks. If I broke any
rules let me know and it wont happen again and I'll delete the Project #2 post.




Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: niuus on January 04, 2019, 02:37:53 pm
Wow. I find your mod chip project one of the most interesting things i've seen for a long time on the SNES scene (since the MSU-1, for me). Please, more info! I've read the thread, it does sound really amazing.  :beer:
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: darkmoon2321 on January 04, 2019, 08:54:24 pm
Interesting.  Gradius III is a fun game that I played through a few times back in the day.  The game would slow to a crawl every time one of those big serpent creatures was on-screen though.  Out of curiosity, have you done any kind of analysis on the code to figure out why it is lagging so badly in the first place?  I haven't looked into the game's code myself, though I might take a look now.  My guess is that it would be significantly easier to correct some inefficient code rather than try to convert over to SA-1.  If it's an issue of graphics decompression, there is also the route of placing decompressed graphics directly in the ROM and bypassing the decompression routine, particularly for commonly used images.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on January 04, 2019, 09:20:17 pm
More info you got it 8)

I have some more pcb components on the way from China as soon as these come in(about 2 weeks) I’ll be able to see if I’ll be able make the upgrade that I would like to do. I’m going to try to split the pcb into 2 pcb’s. One pcb I’m going to try and put header pins on it to mount it around the cpu and the ppu1 and it will have all of the resistors, transistors, status leds, a couple switches and a connector for a flat ribbon cable on it. The other pcb will only have the two ram chips and a connector for a flat ribbon cable. The second pcb I will also drop the castellated holes for a bga setup. I think this setup will make everything a lot cleaner and professional looking. Now this 2 pcb setup probably won’t work on the 1st released motherboard that has the vertical ram chips because you have to solder directly to the pins on the cpu and ppu but I might be able to figure something out for that one.

With my current setup for the pcb using the cpu unused i/o ports I haven’t found any games that don’t work properly. Without using those ports from the cpu there are games that don’t work properly with the major one being super mario world 2.

All of the major details are in the link to byuu’s archived forum. I have good pictures for mega man x1 showing what the original 64kb of vram looks like and what the upgraded 128kb of vram looks like and it has the patch for mmx1 and the nSide debugger to create hacks for it.

Currently the only games I plan on hacking with the extra vram are mega man x1 and the 7th saga. The only other games I’ll probably add the 128kb of vram to is one that someone has a level editor for that they are willing to add support for the extra vram.

darkmoon2321:
Yes I looked into some of it but I still need to do more research on that. From what I was seeing the slowdown is caused by the algorithm for the sprites. Yes removing compression does speed things up but not really during gameplay mostly when levels are loading. I have mmx1 and 7th saga that I have removed all graphics compression and gameplay still slows down but level loading is way faster. I already have 100% of gradius 3 asm disassembled and most of the data mapped out so interesting things are being worked on to improve the game.

I could release the disassembled asm for gradius 3 but I’m not really sure what the right way is to release it. Can I release a text file with all of the asm on romhacking.net without getting in trouble or do I need to write a program that rips it out of the game?
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: darkmoon2321 on January 04, 2019, 10:30:19 pm
I could release the disassembled asm for gradius 3 but I’m not really sure what the right way is to release it. Can I release a text file with all of the asm on romhacking.net without getting in trouble or do I need to write a program that rips it out of the game?

I'm pretty sure you can release it here.  There are a few complete disassembly documents on the site already.  I don't see any for SNES titles yet though, so that could be a first.  I did go ahead and get a trace log on some of the lag, and I can see where it happens, but you're probably miles ahead of me if you already have a full disassembly.

Edit: I did a little more research into this.  The sprite drawing code does consume a lot of processing time, and I think it is possible to make it run more efficiently.  However, that's not the only issue.  On the lag trace that I got, the game didn't even reach the sprite drawing routine before it was interrupted by the next NMI.  It appears that collision detection is occupying the largest chunk of time, in my test case approximately half of an entire frame.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: lastdual on January 05, 2019, 07:36:22 pm
Good luck with that vram project! It sounds really ambitious :beer:

I've done a number of side-by-side tests with the Gradius 3 fastrom hack and the improvement is noticeable, though as slidelljohn stated there is still slowdown. However, when combining the hack with an emulator that allows for overclocking (such as the Snes9X 2010 Libretro core for RetroArch), the game is virtually slowdown-free. It's pretty awesome after all these years to play one of the first 16-bit shmups the way it was meant to be played. Gradius 3 is a personal favorite of mine (I prefer the SNES version--that soundtrack is gold), and seeing it running so smooth (also flicker-free using the above emulator) is a real treat.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on January 07, 2019, 10:05:27 pm
I'm pretty sure you can release it here.  There are a few complete disassembly documents on the site already.  I don't see any for SNES titles yet though, so that could be a first.  I did go ahead and get a trace log on some of the lag, and I can see where it happens, but you're probably miles ahead of me if you already have a full disassembly.

Edit: I did a little more research into this.  The sprite drawing code does consume a lot of processing time, and I think it is possible to make it run more efficiently.  However, that's not the only issue.  On the lag trace that I got, the game didn't even reach the sprite drawing routine before it was interrupted by the next NMI.  It appears that collision detection is occupying the largest chunk of time, in my test case approximately half of an entire frame.

I'm still not sure about the rules for releasing the full disassembly but Ill probably end up writing a program that can extract it. I do have the main function for gradius 3 that I used to pinpoint the slowdown that I found.
Here is a text file of the main function:
http://www.mediafire.com/file/36ld5ftx8tq24b5/gradius_3_main_function.txt/file (http://www.mediafire.com/file/36ld5ftx8tq24b5/gradius_3_main_function.txt/file)

In the main function if this line ($80/82A2 22 F1 8E 80 JSL $808EF1[$80:8EF1]) is nop'ed reload the cart from the begging and
just let the game play until the ship crashes. It should crash around 2 minutes and 31 seconds. Now if you let the game play
without removing that line the game will crash around 2 minutes and 46 seconds. So just that one line of code eats up 15 seconds.
Not sure if the collision detection is loaded from that line but I recall 2 or 3 sections of code that shows the slowdown.

I definitely wouldn't mind teaming up and try to make the code more efficient. I would think there is room for improvement especially when the programmers do stuff like this
Code: [Select]
$80/8223 C2 20       REP #$20
$80/8225 C2 10       REP #$10

instead of this
Code: [Select]
$00/0000 C2 30       REP #$30
I do have a lot of stuff that I am working on right now so I am not sure when I'll have a chance to look at the code again
but improving the code is definitely something that I would like to do.

Good luck with that vram project! It sounds really ambitious :beer:

I've done a number of side-by-side tests with the Gradius 3 fastrom hack and the improvement is noticeable, though as slidelljohn stated there is still slowdown. However, when combining the hack with an emulator that allows for overclocking (such as the Snes9X 2010 Libretro core for RetroArch), the game is virtually slowdown-free. It's pretty awesome after all these years to play one of the first 16-bit shmups the way it was meant to be played. Gradius 3 is a personal favorite of mine (I prefer the SNES version--that soundtrack is gold), and seeing it running so smooth (also flicker-free using the above emulator) is a real treat.
Thanks! I still never tried RetroArch. I guess all the hacking I do eats up all of my free time. :D

I got one of the parts that I was waiting on to see if I can improve the super v-power mod chip and I came up with something even better. I wanted to split the chip into 2 chips so I wouldn't solder wires directly to the board but as I was testing everything I came up with the idea of having one pcb wrapping around the cpu and the ppu so there would be no wires and no ribbon cables. This will only be possible by getting a custom injection molded header pin that connects to the cpu pins, ppu pin, and all of the vram pins. I found a company that can make the custom header pin for me but its going to take some time to get all of the correct measurements for the holes. If I can get this done I can add a bonus to the super v-power mod chip. I can add the super cic chip to the super v-power as well because it also has a hole for every pin for the cic chip. Imagine a all in on 128kb vram and super cic. This is turning out way better than I expected.

Here is a image showing all of the holes for all of the pins for the 2 vram chips and the cic chip. url image is large:
https://imgur.com/ONDw8XG (https://imgur.com/ONDw8XG)

Here is a paper cutout to give everyone a idea of the shape of the new pcb design with the super cic added:
https://imgur.com/KCgeDEM (https://imgur.com/KCgeDEM)

After I get the pcb shape and the holes correctly mapped out in eagle cad I'll see about getting the custom header pins made.
My schematics and custom header pins will all be open source when they are ready.

One of the bsnes plus developers is currently working on adding the super v-power capabilities to the bsnes plus debugger so
hopefully soon we will all have a really good debugger for future rom hacks that can use this new unused hidden feature for the original snes console. :woot!:

Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: darkmoon2321 on January 08, 2019, 11:48:05 am
In the main function if this line ($80/82A2 22 F1 8E 80 JSL $808EF1[$80:8EF1]) is nop'ed reload the cart from the begging and
just let the game play until the ship crashes. It should crash around 2 minutes and 31 seconds. Now if you let the game play
without removing that line the game will crash around 2 minutes and 46 seconds. So just that one line of code eats up 15 seconds.
Not sure if the collision detection is loaded from that line but I recall 2 or 3 sections of code that shows the slowdown.

That function does indeed call the sprite handling code.  I wrote a simple program that parses through Geiger's trace logs and counts the number of times each line of code executes so that I can find good targets for optimizing code.  The collision detection code that I identified before spans 80/EA7A to 80/EC3C.  From the main function, it is reached the line before the sprites, so ($80/829E 22 8E 87 80 JSL $80878E).  I'm not entirely sure if collision detection is all this code does, but it appears to be a significant part of it.  If you're interested in the short program I made, source is here: https://www.dropbox.com/s/0x3p0p9hsp3dmcm/geiger_trace_frequency_counter.cpp?dl=0 (https://www.dropbox.com/s/0x3p0p9hsp3dmcm/geiger_trace_frequency_counter.cpp?dl=0)

I can take a quick look at optimizing the sprite display code a bit, I have a better understanding of that than the collision code at the moment.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on January 08, 2019, 07:13:45 pm
I cant seem to download that file from dropbox. The web page just shows a white screen. It says
the server is encrypted.

I think this is all of the assembly that is used for the sprites at $80:8EF1:
http://www.mediafire.com/file/h444w9o6k5vm64d/gradius_3_sprite_assembly_0x008ef1.txt/file (http://www.mediafire.com/file/h444w9o6k5vm64d/gradius_3_sprite_assembly_0x008ef1.txt/file)

I have some notes on some lines in the text file but they are not complete as I was still in the process
of documenting them before I took a break on this project.

Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: ExL on January 10, 2019, 01:00:25 am
Use this link instead - https://www.dropbox.com/s/0x3p0p9hsp3dmcm/geiger_trace_frequency_counter.cpp?dl=1
"dl=0" prevented you from downloading. But just in case I've reuploaded it here: https://mega.nz/#!7V0hUIpB!BfP0jc1Hx2qDfP0ivSh6JGblVSHSMEvgSRcAwNjuMOk
I'm just passing by, with no knowledge on subject, but that looks very interesting ::) I hope snes9x and other emulators will add support for Super V-Power and that'll lead to lagless hacks comfortably played everywhere :thumbsup:
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on January 10, 2019, 07:31:37 am
Thanks ExL! I didn’t know what was going on with that link. ;D
The Super V-Power mod chip isn’t actually for helping with lag but a creative programmer could speed up some things with it.

I sent the new pcb design for the Super V-Power mod chip to the manufacturer but I’m going to have to do a few test before it’s ready to show off the new version of it. Hopefully within the next 2 months I’ll have something ready to show. The new design is gonna be crazy! :o
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: darkmoon2321 on January 10, 2019, 02:23:35 pm
Sorry about the link, never had that issue with dropbox before.  I did some work on optimizing the sprite routine:

https://www.mediafire.com/file/6ec2cavwn9vuvd3/Gradius3_spriteOptimization.ips/file

Apply this patch on top of your fastROM patch.  It reduces the amount of time spent computing individual sprite tiles by about 10% or so.  Further optimization is possible, but it would likely be at the expense of rom space and provide benefit mainly for large sprites containing lots of tiles.  In other words, creating separate routines for sprites that are vertically flipped, horizontally flipped, both, or neither.  This would eliminate the branch checking for these conditions that occurs for individual tiles right now.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on January 10, 2019, 04:32:42 pm
About 10%, that’s great!  :thumbsup:
I don’t have time to look at it today but I’ll definitely look at it tomorrow. I may have to put some of my other projects on hold and work on this one some more. I’ll look more into optimizing the asm code, expanding the rom, and remove all compression this weekend. Im also going to submit the complete disassembled assembly tomorrow.

I was able to test your patch right before I left to go to work and it looks like it’s around a .7 second speed up from when the ship first crashes if you let the game play on its own. So yea, definitely around a 10% speed up on top of the fastrom patch. Good work! I am interested in what you did to speed it up but I would probably hold off on the details just in case I can come up with something different to add to it.

Update 1-12-19:
I just now submitted 2 complete gradius 3 assembly documents and they can be seen in the Submission Queue Status Page. Hopefully within 24-48 hours they are accepted. The 2 gradius 3 assembly documents are for banks $00 and $02. Those 2 banks have the assembly for the whole game.  If these get accepted I may start uploading more assembly documents that I have for mega man x v1.1 and the 7th saga.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Aaendi on March 06, 2019, 01:20:15 pm
Can I see the before and after of the original sprite ASM code, and the improved sprite ASM code?  I'm interested in this project.

I checked the "collision code" and it doesn't look like collision code to me.  It looks more like a general physics engine. It might have collision somewhere but I didn't find it.

edit:

Here's more optimizations to add to it:

Code: [Select]
arch snes.cpu

macro seek(n) {
origin (({n} & 0x7f0000) >> 1) | ({n} & 0x7fff)
base {n}
}
seek($8096d5)
-;
ldx $00
ldy $0000,x
inx
inx
stx $00
jsl $808ea0
lda $f6
beq +
sty $f2
+;
stz $02
ldx $00

-;
lda $0000,x
inx
and #$00ff
cmp #$00ff
beq label_0
cmp #$00fe
beq label_1
cmp #$00fd
beq label_2
ldy $f0
beq +
lda #$0000
+;
ora $04
stx $00
jsl $808ed8
ldx $00
lda $f6
beq -
stx $f4
lda $04
sta $f8
inc $f2
lda $0000,x
and #$00ff
cmp #$00ff
bne +
label_0:
stz $f0
stz $f6
+;
stx $00
jml $808ee3


label_2:
lda $0000,x
sta $05
inx
bra -

label_1:
stx $00
jsl $808ee3
bra --





seek($808f6e)
lda $0000,x
-;
lsr
lsr
bcc -
sta $0000,x


inx
inx
cpx #$3e20
beq +
-;
stz $0000,x
inx
inx
cpx #$3e20
bne -
+;

cpy #$3d80
bcs +
sep #$20
lda #$f0
-;
sta $0001,y
iny
iny
iny
iny
cpy #$3d80
bcc -
+;
rep #$20
lda $92
ora $66
ora $12f8
sta $18

-;
tya
lsr
and #$0006
tax
lda $8180ca,x
cmp $0002,y
beq +
sta $0002,y
tya
lsr
lsr
and #$001f
tax
sep #$20
lda $8180d2,x
xba
tya
asl
eor #$50
rep #$20
sta $0000,y
+;


lda $18
bne big_jump

tya
and #$001c
tax
lda $8180aa,x
and $1e
bne +
sep #$20
lda $0000,y
dec
bra ++
+;
sep #$20
lda $0000,y
+;
clc
adc $8180ac,x
sta $0000,y
rep #$20
big_jump:

iny
iny
iny
iny
cpy #$3e00
bcc -
sep #$20
lda #$01
pha
plb
rep #$20
rtl
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Samus12345 on March 11, 2019, 11:52:23 pm
Some info on darkmoon's sprite routine hack: It introduces glitchy graphics on the fire stage boss (the two-headed dragon) that isn't in the original fastrom hack.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Aaendi on March 12, 2019, 03:34:18 pm
I noticed that this loop happens pretty often, and I wonder if there is any way to remove the loads and stores from $fc and just keep it in the X register.  I would optimize this code myself, but I found out that this is in the middle of Darkmoon's code.

Code: [Select]
8090a4 lda $fc       [0000fc] A:0000 X:0700 Y:3c18 S:1de9 D:0000 DB:7e nvmxdIZc V:165 H: 312
8090a6 clc                    A:0700 X:0700 Y:3c18 S:1de9 D:0000 DB:7e nvmxdIzc V:165 H: 340
8090a7 adc #$0040             A:0700 X:0700 Y:3c18 S:1de9 D:0000 DB:7e nvmxdIzc V:165 H: 352
8090aa tax                    A:0740 X:0700 Y:3c18 S:1de9 D:0000 DB:7e nvmxdIzc V:165 H: 370
8090ab cpx $18       [000018] A:0740 X:0740 Y:3c18 S:1de9 D:0000 DB:7e nvmxdIzc V:165 H: 382
8090ad bcc $9082     [809082] A:0740 X:0740 Y:3c18 S:1de9 D:0000 DB:7e NvmxdIzc V:165 H: 410
809082 stx $fc       [0000fc] A:0740 X:0740 Y:3c18 S:1de9 D:0000 DB:7e NvmxdIzc V:165 H: 428
809084 lda $00,x     [000740] A:0740 X:0740 Y:3c18 S:1de9 D:0000 DB:7e NvmxdIzc V:165 H: 456
809086 beq $90a4     [8090a4] A:0000 X:0740 Y:3c18 S:1de9 D:0000 DB:7e nvmxdIZc V:165 H: 490
8090a4 lda $fc       [0000fc] A:0000 X:0740 Y:3c18 S:1de9 D:0000 DB:7e nvmxdIZc V:165 H: 508
8090a6 clc                    A:0740 X:0740 Y:3c18 S:1de9 D:0000 DB:7e nvmxdIzc V:165 H: 536
8090a7 adc #$0040             A:0740 X:0740 Y:3c18 S:1de9 D:0000 DB:7e nvmxdIzc V:165 H: 588
8090aa tax                    A:0780 X:0740 Y:3c18 S:1de9 D:0000 DB:7e nvmxdIzc V:165 H: 606
8090ab cpx $18       [000018] A:0780 X:0780 Y:3c18 S:1de9 D:0000 DB:7e nvmxdIzc V:165 H: 618
8090ad bcc $9082     [809082] A:0780 X:0780 Y:3c18 S:1de9 D:0000 DB:7e NvmxdIzc V:165 H: 646
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: KingMike on March 12, 2019, 07:24:05 pm
Only the A register can be used for math instructions (such as adc).
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Aaendi on March 12, 2019, 11:55:43 pm
I'm talking about the loading and storing.  It can just use TXA and TAX and not load and store from $FC until it's out of the loop.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on March 14, 2019, 04:17:07 pm
I still haven't done anything else with gradius 3 but I plan to start working on this project again
soon.

@darkmoon2321
Maybe it would be a good idea to post your asm code. If enough of us put our ideas together we could
probable optimize the code more.

I have been gone for a little while but I'm back with some good news on something that I have been working on for the past few weeks. devinacker who has been updating bsnes plus created a branch of the bsnes-plus-v04 that uses the 128kb of vram mod. The branch is called vramexpand https://github.com/devinacker/bsnes-plus/tree/vramexpand (https://github.com/devinacker/bsnes-plus/tree/vramexpand). The games appear to be working correctly with the extra vram but some of the debugging features don't work correctly for the extra vram. I decided to play around with the source code for the branch to get some of the debugging features working for the extra vram and I'm having good success in modifying the code. Not only do I have some of the extra vram data loading but I'm also adding new features. Here is a image showing the original tile viewer and the one I modified.

(https://i.imgur.com/YuilVgS.png)
I added some new buttons and a height scroll box. I also changed how the tile viewer screen gets updated. It now updates almost instantly. Everything still doesn't work %100 in the tile viewer but vram 4bb settings are mostly correct.

I added a feature that lets you control what debugging windows are opened when you open bsnes plus.

(https://i.imgur.com/C9L4iQ9.png)
You can ether choose what window to have open at start up or you can have it to where the last windows that were opened when you closed bsnes open the next time you open bsnes. I plain on adding more windows to the list and starting options for each window.

Now the modification that I made that took the most time is the new cpu tracer. I created a multi threaded, multi buffer near lag free cpu tracer with slightly new text format in trace files. The tracer allows for up to ~2gb trace files and it has a progress bar to see the size of the file being generated. The cpu step and breakpoints are also displayed differently in the console. I also added a clear console button.

(https://i.imgur.com/svfyvAw.png)
The new algorithm to generate the trace file still has room for improvement. I should have the new algorithm finished soon.

Here is a link to the vramexpand and the modified vramexpand with the changes that I made.
http://www.mediafire.com/file/jve2buz9iqnzg6o/bsnes_plus_files.zip/file (http://www.mediafire.com/file/jve2buz9iqnzg6o/bsnes_plus_files.zip/file)

This is how you change the vram settings.

(https://i.imgur.com/8wwgrDA.png)

64kb is what is in a original snes, 128kb is how much the snes was actually capable of using and 256kb uses a mod that lets you switch between 2 different sets of 128kb of vram. I haven't test the 256kb yet but I will soon.

As far as I can tell there are no major bugs or memory leaks from the modifications that I made. Nothing ever crashes. You do need at least 2 gb of ram for the tracer. I hope you all like the modifications that I made. I definitely wouldn't mind helping contribute to the official source that devinacker maintains.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: darkmoon2321 on March 16, 2019, 01:46:50 am
@darkmoon2321
Maybe it would be a good idea to post your asm code. If enough of us put our ideas together we could
probable optimize the code more.

Here is a commented disassembly of the optimized code I did for sprite handling:

Code: [Select]
$80/9020 LDX #$0200 ;Initial address of object data
$80/9023 LDA #$08C0 ;final address
$80/9026 BRA $58    [$9080] ;process all objects between initial and final
$80/9028 LDA $000ED0
$80/902C CMP #$008F
$80/902F BEQ $11    [$9042]
$80/9031 LDA $0011D0
$80/9035 CMP #$0095
$80/9038 BEQ $34    [$906E]
$80/903A LDX #$08C0 ;Initial address of object data
$80/903D LDA #$1200 ;final address
$80/9040 BRA $3E    [$9080] ;process all objects between initial and final
$80/9042 LDX #$08C0 ;Initial address of object data
$80/9045 LDA #$0E40 ;final address
$80/9048 JSL $809080[$80:9080] ;process all objects between initial and final
$80/904C BCS $62    [$90B0] ;exit if no more room for sprites
$80/904E LDX #$0EC0 ;Initial address
$80/9051 LDA #$0F00 ;final address of object data
$80/9054 JSL $809080[$80:9080] ;process all objects between initial and final
$80/9058 BCS $56    [$90B0] ;exit if no more room for sprites
$80/905A LDX #$0E40 ;Initial address of object data
$80/905D LDA #$0EC0 ;final address
$80/9060 JSL $809080[$80:9080] ;process all objects between initial and final
$80/9064 BCS $4A    [$90B0] ;exit if no more room for sprites
$80/9066 LDX #$0F00 ;Initial address of object data
$80/9069 LDA #$1200 ;final address
$80/906C BRA $12    [$9080] ;process all objects between initial and final
$80/906E LDX #$0900 ;Initial address of object data
$80/9071 LDA #$1200 ;final address
$80/9074 JSL $809080[$80:9080] ;process all objects between initial and final
$80/9078 BCS $36    [$90B0] ;exit if no more room for sprites
$80/907A LDX #$08C0 ;Initial address of object data
$80/907D LDA #$0900 ;final address
$80/9080 STA $18 ;Store final address for object data (terminator)
$80/9082 STX $FC ;store address of object data
$80/9084 LDA $00,x ;Object word 0, offset to 03:0000 array that determines the sprite data
$80/9086 BEQ $1C    [$90A4]
$80/9088 STA $04 ;store the offset to the sprite data in ROM
$80/908A LDA $0A,x ;Object X position
$80/908C STA $08
$80/908E LDA $0E,x;Object Y position
$80/9090 STA $0A
$80/9092 LDA $02,x ;Object alternate attributes
$80/9094 STA $14 ;"Alternate attributes/palette" flag stored in top bit
$80/9096 ASL A
$80/9097 XBA
$80/9098 STA $13 ;store alternate attributes/palette
$80/909A LDA $04,x ;Object attributes
$80/909C STA $06
$80/909E LDX $04 ;Load relative offset of ROM sprite data into X
$80/90A0 BRA $0F    [$90B1]
$80/90A2 BCS $0C    [$90B0]
$80/90A4 LDA $FC ;Load address of object data
$80/90A6 CLC
$80/90A7 ADC #$0040 ;increment to the next object address
$80/90AA TAX
$80/90AB CPX $18 ;check for final address
$80/90AD BCC $D3    [$9082] ;loop until we reach the final address
$80/90AF CLC ;return carry clear, we still have room for more sprites
$80/90B0 RTL ;end sprite tile processing for the current set of objects
$80/90B1 LDA $030000,x ;get # of tiles in the sprite
$80/90B5 AND #$00FF
$80/90B8 STA $16 ;store num_tiles
$80/90BA INX
$80/90BB LDA $030002,x
$80/90BF XBA
$80/90C0 CMP #$FF00 ;check for FF value in last byte of sprite tile's data
$80/90C3 BCC $07    [$90CC]
$80/90C5 LDA $030000,x ;if last byte was FF, get new ROM offset for sprite data
$80/90C9 TAX
$80/90CA BRA $EF    [$90BB]
$80/90CC AND #$0010 ;check sprite size
$80/90CF BNE $07    [$90D8]
$80/90D1 STZ $0E ;store the sprite size toggle bit
$80/90D3 LDA #$FFFC ;load amount to offset the tile based on its size
$80/90D6 BRA $08    [$90E0]
$80/90D8 LDA #$0011
$80/90DB STA $0E ;store the sprite size toggle bit
$80/90DD LDA #$FFF8
$80/90E0 STA $0C ;store tile offset modifier based on sprite size
$80/90E2 STZ $11 ;Initialize upper byte of tile X position (16 bit) to zero
$80/90E4 LDA $02FFFF,x ;get tile's relative X position
$80/90E8 BPL $02    [$90EC]
$80/90EA DEC $11 ;if relative X is negative, set upper byte to FF
$80/90EC STA $10 ;store lower byte of relative X position
$80/90EE BIT $06 ;check object's attributes
$80/90F0 BVC $07    [$90F9] ;check if tile is horizontally flipped
$80/90F2 SEC
$80/90F3 LDA $08
$80/90F5 SBC $11 ;subtract tile relative X from object X if hflip
$80/90F7 BRA $05    [$90FE]
$80/90F9 CLC
$80/90FA LDA $08
$80/90FC ADC $11 ;if not flipped, add tile relative X to Object X
$80/90FE CMP #$0110 ;right boundary check
$80/9101 BMI $03
$80/9103 JMP $917B ;If we get here, do not draw tile
$80/9106 CMP #$FFF0 ;left boundary check
$80/9109 BPL $03    [$910E]
$80/910B JMP $917B  [$80:917B] ;If we get here, do not draw tile
$80/910E CLC
$80/910F ADC $0C ;Add relative offset based on sprite size toggle bit
$80/9111 STA $0000,y ;store final tile X to be transmitted to OAM
$80/9114 XBA
$80/9115 LSR A
$80/9116 ROR $00 ;rotate X most significant bit into extended OAM table temp variable
$80/9118 STZ $11 ;Initialize upper byte of tile Y position (16 bit) to zero
$80/911A LDA $030000,x ;get tile's relative Y position
$80/911E BPL $02    [$9122]
$80/9120 DEC $11 ;if relative Y is negative, set upper byte to FF
$80/9122 STA $10 ;store lower byte of relative Y position
$80/9124 BIT $06 ;check object's attributes
$80/9126 BPL $07    [$912F] ;check if tile is vertically flipped
$80/9128 SEC
$80/9129 LDA $0A
$80/912B SBC $11 ;if vflip, subtract relative Y from object Y
$80/912D BRA $05    [$9134]
$80/912F CLC
$80/9130 LDA $0A
$80/9132 ADC $11 ;if not flipped, add relative Y to object Y
$80/9134 BIT #$FF00 ;Make sure the upper byte of tile Y position is 0 at this point
$80/9137 BEQ $04    [$913D]
$80/9139 ASL $00 ;if upper byte of Y was not 0, pop the X MSB for this tile off the temp variable
$80/913B BRA $3E    [$917B] ;if we get here, do not draw tile
$80/913D SEC
$80/913E SBC #$0010 ;subtract 10 from tile Y position
$80/9141 CLC
$80/9142 ADC $0C ;add relative offset based on sprite size toggle bit
$80/9144 STA $0001,y ;Store final tile Y to be transmitted to OAM
$80/9147 LDA $030002,x ;get tile's relative attributes and tile #
$80/914B AND #$EFFF ;clear vflip flag?
$80/914E EOR $06 ;toggle bits from the object's attributes
$80/9150 BIT $14 ;check "alternate attributes/palette" flag
$80/9152 BPL $05    [$9159]
$80/9154 AND #$F1FF ;clear palette bits
$80/9157 ORA $13 ;set alternate attributes/palette
$80/9159 STA $0002,y ;store tile's final attributes and tile # to be transmitted to OAM
$80/915C INY ;update write offset for next tile's data
$80/915D INY
$80/915E INY
$80/915F INY
$80/9160 LSR $0E ;rotate the size toggle bit into our temp extended OAM variable
$80/9162 ROR $00
$80/9164 BCC $15    [$917B] ;check if we have filled our temp variable
$80/9166 CPY #$3E00 ;check if we have used up all available OAM space
$80/9169 BCS $1C    [$9187] ;if so, end sprite tile processing
$80/916B LDA $00 ;load our temp extended OAM variable
$80/916D STA ($02) ;indirect store the extended OAM table
$80/916F LDA $02
$80/9171 ADC #$0002 ;update the write address for extended OAM data
$80/9174 STA $02
$80/9176 LDA #$8000
$80/9179 STA $00 ;reset our temp extended OAM variable
$80/917B INX ;update the read offset for the next tile's data from ROM
$80/917C INX
$80/917D INX
$80/917E INX
$80/917F DEC $16 ;countdown until all tiles in the object have been processed
$80/9181 BEQ $03    [$9186]
$80/9183 JMP $90BB  [$80:90BB] ;loop over all tiles in the object
$80/9186 CLC
$80/9187 JMP $90A2  [$80:90A2] ;start on the next object

For the most part, it's pretty similar to the original, with a few exceptions.  In the original, the ROM location where tile data was located was loaded and stored into the X register a few times for every tile because the X register was re-used to hold the location of the extended OAM table in RAM.  Similarly, the address of the write location for tile data needed to be loaded for every tile because they also temporarily used the Y register to hold the value for the size-toggle dependent position offset.  They also checked for vertical/horizontal flips by doing:
Code: [Select]
LDA $06
BIT #$8000  ;#$4000 for hflip
BEQ $07    [$9135]

I simplified this using BIT $06 and either BVC or BPL.  There were several other minor modifications as well.  As for speeding up the math with $FC by using TAX/TXA, it's doable, but the value in the X register will need to be restored to the address of the object's data as soon as the object's sprites are finished being drawn.  In other words, this will only save processing time for the case where there is no active object in a slot.

Some info on darkmoon's sprite routine hack: It introduces glitchy graphics on the fire stage boss (the two-headed dragon) that isn't in the original fastrom hack.

I didn't know this.  I'll have to take a look and see if I can find out what's happening.  I must have missed something.
Edit: I'm not convinced this is from me.  I just ran both versions up to this boss using an invincibility cheat to test, and both showed some pretty glitchy graphics.  I think there are just too many overlapping sprites trying to be displayed at once.  The way the boss curls around on itself makes it particularly prone to glitchy sprites.  However, I did find a potential bug.  At $80/9166, it should be changed to:

Code: [Select]
LDA $00
STA ($02)
CPY #$3E00
BCS $18

In other words, extended OAM data needs to be saved prior to checking whether there are too many sprites on-screen. Otherwise the extended OAM data (size toggle, X MSB) might not be saved for the last few sprite tiles in the event that there are too many sprites on-screen at once.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on April 01, 2019, 02:30:34 am
@darkmoon2321
Cool, thanks for uploading your modifications. I’m going to try to start working on some more of the gradius 3 stuff this week or next week. I have been putting most of my free time into much needed snes c++ tools but I get burned out working on the same thing so it’s almost time to work on something other than my c++ projects.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Aaendi on April 02, 2019, 01:42:37 pm
Here's some more optimizations:

Code: [Select]
arch snes.cpu

macro seek(n) {
origin (({n} & 0x7f0000) >> 1) | ({n} & 0x7fff)
base {n}
}

seek($809d7e)

rep #$30
lda $66
bne ++
ldx #$1200
-;
lda $00,x
beq +
stx $fc
jsl $809da0
ldx $fc
+;
txa
clc
adc #$0010
tax
cpx #$1280
bcc -
+;
rtl


seek($80ed75)
jml collision_a

seek($80ebeb)
jsl collision_b

seek($80ed7e)
jml collision_b

seek($80edd4)
jml collision_c

seek($8df100)
collision_a:
clc
lda $10
adc #$0003
sta $0c
sec
lda $000a,y
sbc $08
bpl +
eor #$ffff
inc
+;
cmp $0c
bcs ++
clc
lda $12
adc #$0003
sta $0e
sec
lda $000e,y
sbc $0a
bpl +
eor #$ffff
inc
+;
cmp $0e
+;
rtl



collision_b:
clc
lda $10
adc $0028,y
sta $0c
sec
lda $000a,y
sbc $08
bpl +
eor #$ffff
inc
+;
cmp $0c
bcs ++
clc
lda $12
adc $002a,y
sta $0e
sec
lda $000e,y
sbc $0a
bpl +
eor #$ffff
inc
+;
cmp $0e
+;
rtl

collision_c:

clc
lda $10
adc #$000b
sta $0c
clc
lda $0028,y
adc $000a,y
sec
sbc #$000b
sec
sbc $08
bpl +
eor #$ffff
inc
+;
cmp $0c
bcc +
jml $80eb57
+;
lda $12
adc #$0003
sta $0e
sec
lda $000e,y
sbc $0a
bpl +
eor #$ffff
inc
+;
cmp $0e
bcc +
jml $80eb57
+;
jml $80eb2f


sprite_processing:
lda $0000,x
-;
lsr
lsr
bcc -
sta $0000,x


inx
inx
cpx #$3e19
bcs +
txa
-;
stz $0000,x
stz $0002,x
stz $0004,x
stz $0006,x
adc #$0008
tax
cpx #$3e1a
bcc -
+;

cpx #$3e20
bcs +
-;
stz $0000,x
inx
inx
cpx #$3e20
bcc -
+;


cpy #$3d64
bcs +

-;
sep #$20
lda #$f0
sta $0001,y
sta $0005,y
sta $0009,y
sta $000d,y
sta $0011,y
sta $0015,y
sta $0019,y
sta $001d,y
rep #$21
tya
adc #$0020
tay
cpy #$3d64
bcc -

+;

cpy #$3d74
bcs +

lda #$00f0
sta $0001,y
sta $0005,y
sta $0009,y
sta $000d,y
tya
adc #$0010
tay

+;


cpy #$3d80
bcs +

sep #$20
lda #$f0
-;
sta $0001,y
iny #4
cpy #$3d80
bcc -
rep #$20

+;
lda $92
ora $66
ora $12f8
sta $18

tya
lsr
and #$003e
tax

-;
lda lut_b,x
cmp $0002,y
beq +
sta $0002,y

lda lut_c,x
sta $0000,y
+;


lda $18
bne big_jump


lda lut_a,x
and $1e
bne +
sep #$20
lda $0000,y
dec
sta $0000,y
rep #$20
+;


big_jump:

inx
inx
iny
iny
iny
iny
cpy #$3e00
bcc -
sep #$20
lda #$01
pha
plb
rep #$20
rtl

lut_a:
dw $000f,$0007,$0007,$0007,$0003,$0003,$0001,$0000,$000f,$0007,$0007,$0007,$0003,$0003,$0001,$0000
dw $000f,$0007,$0007,$0007,$0003,$0003,$0001,$0000,$000f,$0007,$0007,$0007,$0003,$0003,$0001,$0000


lut_b:
dw $08ff,$02ef,$04fe,$02ef,$08ff,$02ef,$04fe,$02ef,$08ff,$02ef,$04fe,$02ef,$08ff,$02ef,$04fe,$02ef
dw $08ff,$02ef,$04fe,$02ef,$08ff,$02ef,$04fe,$02ef,$08ff,$02ef,$04fe,$02ef,$08ff,$02ef,$04fe,$02ef


lut_c:
dw $a850,$0858,$4040,$c848,$2070,$9878,$7060,$b468,$6810,$0018,$b800,$5808,$3030,$8838,$6020,$9028
dw $28d0,$d8d8,$48c0,$a0c8,$38f0,$b0f8,$80e0,$48e8,$1890,$9498,$7880,$1088,$50b0,$c0b8,$d0a0,$6ca8




seek($8281f5)

ldy #$1280
phx
tyx
clc
lda $00,x
adc $0a
sta $10

and #$01f8
bit #$0100
beq +
eor #$2100
+;
lsr
lsr

sta $00
clc
lda $18,x
adc $0e
sec
sbc #$0010
and $90
sta $12

and #$01fc
asl
asl
asl
adc #$0800

and #$17e0

bit #$0020
beq +
eor #$0021
+;
ora $00


sta $14
eor #$8000
tax
stx $16
lda $7dffff,x
plx
and #$c000
rtl



seek($829903)
phy
lda $18,x
ldy $1c,x
sty $18,x
sta $1c,x

lda $1a,x
ldy $1e,x
sty $1a,x
sta $1e,x

ply

bra +
+;


seek($829819)
lda $18
clc
adc #$0004
sta $18

seek($8096d5)
-;
ldx $00
ldy $0000,x
inx
inx
stx $00
jsl $808ea0
lda $f6
beq +
sty $f2
+;
stz $02
ldx $00

-;
lda $0000,x
inx
and #$00ff
cmp #$00ff
beq label_0
cmp #$00fe
beq label_1
cmp #$00fd
beq label_2
ldy $f0
beq +
lda #$0000
+;
ora $04
stx $00
jsl $808ed8
ldx $00
lda $f6
beq -
stx $f4
lda $04
sta $f8
inc $f2
lda $0000,x
and #$00ff
cmp #$00ff
bne +
label_0:
stz $f0
stz $f6
+;
stx $00
jml $808ee3


label_2:
lda $0000,x
sta $05
inx
bra -

label_1:
stx $00
jsl $808ee3
bra --


seek($808f6e)
jml sprite_processing
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on April 02, 2019, 03:49:30 pm
The way I do my hacking I’m not able to use your codes. Do you have any patches that I can use to test and compare with the fastrom mod I did and the improvements darkmoon did? I have been trying to get in touch with you. I tried responding to your email and I tried messaging you on here but no reply.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Aaendi on April 02, 2019, 08:26:45 pm
I'm not home right now so I'll make an IPS file when I get home.


http://www.mediafire.com/file/g1ql7oqmo99qud3/Gradius_III_optimization.ips/file

Quote
Do you have any patches that I can use to test and compare with the fastrom mod I did and the improvements darkmoon did?


Well this patch includes your patch and darkmoon's patch, since I was modifying a rom that already had both of your patches applied.

Edit:

I think it will be easy to optimize code if I take your disassembly and modify it to be reassembleable. That way I don't have to worry about alignment.

Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on April 03, 2019, 06:41:09 pm
Wow! That’s a nice little speed up! About 3 seconds. I did a timing test and it looks like you nearly removed the rest of the slowdown from that one function(JSL 80/8EF1). I think there is only about a .75 second slowdown left in it but the code has to use up some time so might not be too much more that could be done to optimize that function. I haven’t played through the whole game yet to make sure everything is still working properly but the first demo stage is.

I think I’ve found out something interesting but to be sure I would need you and darkmoon to create your patches without using my fastrom patch. Would you two be willing to do that so I can run some more tests?

There is some minor slowdown coming from this function as well:  80/9F19 // updates graphics for your ship and boss

It’s only about a 2.5 second slowdown compared to the 15 second slowdown for the other sprite function 80/8EF1.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on April 11, 2019, 02:35:31 am
[quote author=darkmoon2321 link=topic

I didn't know this.  I'll have to take a look and see if I can find out what's happening.  I must have missed something.
Edit: I'm not convinced this is from me.  I just ran both versions up to this boss using an invincibility cheat to test, and both showed some pretty glitchy graphics.  I think there are just too many overlapping sprites trying to be displayed at once.  The way the boss curls around on itself makes it particularly prone to glitchy sprites.  However, I did find a potential bug.  At $80/9166, it should be changed to:

Code: [Select]
LDA $00
STA ($02)
CPY #$3E00
BCS $18

In other words, extended OAM data needs to be saved prior to checking whether there are too many sprites on-screen. Otherwise the extended OAM data (size toggle, X MSB) might not be saved for the last few sprite tiles in the event that there are too many sprites on-screen at once.
[/quote]

There actually was glitchy graphics in the fire stage while fighting the boss but the 4 lines of code you posted fixed it.

@darkmoon2321 and Aaendi
The optimizations that you two have done so far are great! Not sure if you two can optimize anymore of the code but there are still significant slowdowns on the 2nd level with all the big bubbles. The slowdown looks like it’s coming from the function before the sprites function at 00:878E.

I played around a little bit with the assembly and I was able to optimize some of the code but it’s not better than the optimizations that have already been done. I’ll probably look into optimizations at a later time if there are still slowdowns. Right now I’m currently rewriting all of the assembly for gradius 3. Gradius 3 uses a lot of long jumps (JSL’s) instead of using JSR’s and the assembly has a lot of rep 10, rep 20 when it should be rep 30. I’m also finding a lot of spots where they are using too many reps and seps by not organizing the code inside of the functions. So yea I’m doing a complete rewrite. It’s probably going to take several weeks to complete.
Wish me luck :crazy:
Hopefully this will give a minor speed up. I’m not really expecting much of a speed up if any but it is possible to get some speed up. After the assembly rewrite is completed, I’ll complete the fastrom hack, and then I’ll rip out all of the compression and expand the rom. I’ll probably start getting some of the sram features implemented after all of that.

Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Aaendi on April 13, 2019, 10:20:38 pm
They also NEVER used the direct page register.

http://www.mediafire.com/file/pipd3v1t4pkillc/Gradius_III_optimization.ips/file

Here is an update.  I think I'm getting close to eliminating slowdown for good.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Zimgief on April 20, 2019, 06:07:51 pm
I tried it (first two stages). The game is so much better, even if the bubbles still slow down (but much more less).

For me, the game had three majors flaws:

- slowdowns

- flickering (especially when the four options are on the same horizontal line as the player) which makes some bullets or enemies invisible

- the ramping of difficulty on the same difficulty level. Proportional to the upgrades I think, or maybe the longer we progress without dying. They abandoned this in later Gradius/Parodius console games, and for a good reason. As someone who doesn't have very good reflexes, having much more bullets, moving a a much faster pace, just because I am playing successfully, makes it difficult for me to finish the game on normal (when I can with the last Snes Parodius game, or Gradius Advance for example).
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on April 29, 2019, 02:12:56 pm
@Aaendi
Yea, I also noticed that they didn’t use the direct page register much. They changed the direct page register a few times in the asm in bank $00 but they never change it in bank $02. Definitely noticed less slowdown in your latest patch. I’m still not even close to finishing cleaning up gradius’s asm but I’m making good progress and I’m noticing less slowdown but not a lot.

@Zimgief
All slowdowns will hopefully be removed. Most of the flickering can be removed if you use a super nt or a emulator that supports no sprite per line limit. There is still some flickering left after using that feature but I’m hoping I can remove all of the flickering by increasing the vram size to 128kb. Yes, the difficulty does change. I believe each level has its own difficulty. The difficulty that you choose plus the levels difficulty gets added together to create the difficulty for the level. I could probably put together something that shows you how to change the difficulty for each level if you want.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Zimgief on April 30, 2019, 01:54:46 pm
Quote
I could probably put together something that shows you how to change the difficulty for each level if you want.
Yes, I would be interested! :)
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Aaendi on May 05, 2019, 05:57:01 pm
I have some bad news.  I completely wrecked the source code for my optimization hack trying to fit code inside what little free ROM I have left, and I can't get it to work at all. :banghead:

I guess I'll have to start over but with a larger ROM this time.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on May 06, 2019, 05:27:52 am
@Zimgief
I tried looking for the files that had the information but I cant seem to find them right now.
I have them somewhere. Its with the same docs for my fastrom hack that I added 4 new difficulties to.
Whenever I find them I'll let you know.

@Aaendi
That's unfortunate. I hope you didn't loose any valuable information on what you have already done.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Aaendi on May 06, 2019, 10:04:16 am
I got it to work again.  Expanding the ROM size did help.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on May 08, 2019, 12:12:23 am
Awesome! Glad the work you did wasn't lost. The extra rom space is definitely going to help.

Well, I just found out someone created a sa-1 hack for gradius 3:
https://www.youtube.com/watch?time_continue=152&v=pmJyQiL9wYg (https://www.youtube.com/watch?time_continue=152&v=pmJyQiL9wYg)

Its kinda funny that person started working on it after I posted my stuff about gradius 3.
It makes me not want to release anymore docs until I finish my projects first. It took a
long time to write that assembly doc and the sa-1 stuff I did already. How can I write and
release docs if I have to worry about someone 1uping something that I'm currently working on?
I don't know if I should throw my gradius 3 work in the trash or continue with it. I guess
on the bright side we all now have a sa-1 gradius 3.

@Aaendi @darkmoon2321
You both did some good work optimizing the gradius 3 code and maybe it might be best to try
and get your new optimizations inserted into that new sa-1 hack. The sa-1 hack is definitely
going to be faster than the fastrom hack.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: niuus on May 08, 2019, 02:07:02 am
Awesome! Glad the work you did wasn't lost. The extra rom space is definitely going to help.

Well, I just found out someone created a sa-1 hack for gradius 3:
https://www.youtube.com/watch?time_continue=152&v=pmJyQiL9wYg (https://www.youtube.com/watch?time_continue=152&v=pmJyQiL9wYg)

Its kinda funny that person started working on it after I posted my stuff about gradius 3.
It makes me not want to release anymore docs until I finish my projects first. It took a
long time to write that assembly doc and the sa-1 stuff I did already. How can I write and
release docs if I have to worry about someone 1uping something that I'm currently working on?
I don't know if I should throw my gradius 3 work in the trash or continue with it. I guess
on the bright side we all now have a sa-1 gradius 3.

@Aaendi @darkmoon2321
You both did some good work optimizing the gradius 3 code and maybe it might be best to try
and get your new optimizations inserted into that new sa-1 hack. The sa-1 hack is definitely
going to be faster than the fastrom hack.
Please don't abandon your work. An SA-1 hack sounds nice, but it would increase the power requirements for playing on low powered devices at full speed, doesn't play nice on SNES Classic canoe emulator, it's unusable on flash carts not compatible with special chips, etc.

I'd rather have a plain Gradius III optimized, than a special chip assisted game (that didn't required it on the first place) any day.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Zimgief on May 08, 2019, 08:09:42 am
Moreover, the guy insists, on his twitter, that the game is "impossblu", because it is running so fast with this method.
Even "I just found out that with SA-1 the game runs so fast that it's impossible right now to unlock arcade mode because in options the game expects you to alternatively press the A button at 120 Hz which is impossible on hardware. Used to be 60 Hz alternate presses, which is viable".

So, as you can guess considering my latest comments, I am absolutely not a fan of. :p I would expect a game running at same speed but without slowdowns, faithful to the original difficulty.
You and Aaendi have done an impressive work. I hope you will continue, if you find it still meaningful.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Samus12345 on May 08, 2019, 10:47:52 am
Please don't abandon your work. An SA-1 hack sounds nice, but it would increase the power requirements for playing on low powered devices at full speed, doesn't play nice on SNES Classic canoe emulator, it's unusable on flash carts not compatible with special chips, etc.

I second this. There is still a place for a non-SA-1 speedup hack.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: snesfanboi on May 08, 2019, 12:27:00 pm
Hi, I just tried your fastrom patch for gradius III and the difference is incredible.

Like the above post, please continue your work if have the time and motivation!
 
The Sa-1 patch just speeds the game up far too much, whereas your one just reduces the slowdown in bad spots. It still plays like the original.

Great work once again, and it's a shame Konami didn't release this game later as they fixed most of the slowdown issues in Parodius da!.

Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on May 08, 2019, 03:28:36 pm
Unfortunately I'm probably not going to be doing much more gradius 3 stuff.
I mainly starting playing around with gradius 3 so I could learn how to make
a snes game use the sa-1 chip. Vitor Vilela's sa-1 work is really amazing and
hats off to him for everything he has done. sa-1 is the future of snes rom
hacking. I think anyone that was interested in the gradius 3 fastrom hack should
be more interested in Vitor Vilela's gradius 3 sa-1 hack. The sa-1 hack may not
be perfect now due to no slowdowns but the gameplay could be modified to make it
right just like how Vitor Vilela modified the unlock arcade mode button presses.
I'm going to continue learning the sa-1 so I could one day add to the list of
sa-1 hacks. Hopefully Vitor saves mmx for me to do. :laugh:
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Samus12345 on May 08, 2019, 10:31:32 pm
Unfortunately I'm probably not going to be doing much more gradius 3 stuff.

That's a shame. :( The SA-1 version is no good to me since I use Canoe on my SNES Classic and it doesn't load the graphics properly. Is there any chance you could upload the most recent version you've done, at least? I'm still using the first version you uploaded.

Thanks for your hard work, everyone who's worked on the fastrom patch!
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: niuus on May 09, 2019, 01:11:15 am
Unfortunately I'm probably not going to be doing much more gradius 3 stuff.
I mainly starting playing around with gradius 3 so I could learn how to make
a snes game use the sa-1 chip. Vitor Vilela's sa-1 work is really amazing and
hats off to him for everything he has done. sa-1 is the future of snes rom
hacking. I think anyone that was interested in the gradius 3 fastrom hack should
be more interested in Vitor Vilela's gradius 3 sa-1 hack. The sa-1 hack may not
be perfect now due to no slowdowns but the gameplay could be modified to make it
right just like how Vitor Vilela modified the unlock arcade mode button presses.
I'm going to continue learning the sa-1 so I could one day add to the list of
sa-1 hacks. Hopefully Vitor saves mmx for me to do. :laugh:
Oh well, i respect your decision! You could maybe make an official release of your last patch here on romhacking, the work you have done is STILL amazing and perfectly playable.

So, are you pursuing Super V-Power! now? That could be a game changer for many future romhacks and games.  :beer:
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on May 09, 2019, 02:11:54 am
I guess I could upload what I have with the fastrom patch. Yea, I’m going to do some more stuff with the super v-power mod chip. I have a new design for the mod chip. The mod chip is going to be 3 pcb’s. 1 through hole pcb for the ppu/cpu connections and 2 bga pcb’s for the vram chips. I’m also going to do some more research on creating sa-1 hacks so I could get the mmx + sa-1 + 128kb of vram going. I guess I could also finish updating the bsnes plus vram expand debugger to show the extra vram. I was making good progress editing that new debugger.  Has anyone tested out that new bsnes plus vram expand debugger that I made some modifications to? I know it’s still buggy but I was able to make a few improvements to it.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Aaendi on May 09, 2019, 01:28:19 pm
http://www.mediafire.com/file/3d00sa1ndp2n79q/Gradius_III_optimization.ips/file

Here is what I've done so far.  I think I'll take a break with this, because it's dominating all my time.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on May 09, 2019, 02:45:49 pm
I may upload whats already done to the fastrom patch. Do you want me to include your
optimizations if I upload it?

Here is how far I got in my sa-1 that hack I was making:
http://www.mediafire.com/file/4y0yb44mcvhhyas/Gradius_III_%2528U%2529_%255B%2521%255D_sa-1_test.ips/file (http://www.mediafire.com/file/4y0yb44mcvhhyas/Gradius_III_%2528U%2529_%255B%2521%255D_sa-1_test.ips/file)

I'm still going to finish it because I still need to earn how to get the sa-1
working in a snes game. It doesnt use the sa-1 for the asm yet but most ram
is already loading in bw-ram. The sa-1 is up and running its main loop and I did
test out graphics decompression routine and it seemed to be working fine. The main
thing is finishing the transfer of the rest of wram to bw-ram. It was a lot of work.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Aaendi on May 09, 2019, 05:40:27 pm
Yeah, sure if you want to.

I'm wondering will an optimized SA-1 hack have any improvements over a non-optimized SA-1 hack?  I don't think the original game ever went slower than 30fps.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on May 09, 2019, 06:54:21 pm
I guess it depends on if there are any slowdowns left but I don't think there
are any.

Did you have any other plans for gradius 3 or did you just want to optimize the
code? I do still have other things that I could possibly do. Fastrom and sa-1
wasn't the only things.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Grego on May 09, 2019, 10:40:37 pm
There is still slight slowdown in the sa1 hack, so optimization might fix some of that. It runs great tho, super hard.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Aaendi on May 10, 2019, 12:45:57 am
How is that possible?  Does the game not run entirely on the SA-1 side?  Or is the S-CPU and SA-1 accessing memory at the same time?
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on May 10, 2019, 01:31:42 am
I played up to the bubble stage and I didn’t notice any slowdowns with 4 options and the charging lasers. I think but I’m not sure both of the cpu’s are always running at the same time after you activate the sa-1. I haven’t look at the code yet but I don’t think vitor would have them acces memory at the same time because it would slowdown the sa-1. He has written some really good docs on taking full advantage of the sa-1 chip.

@Grego
Which level(s) have you noticed slowdown in on vitors sa-1 hack?
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Grego on May 10, 2019, 02:20:23 am
The boss at the end of level 3 with full upgrades slows down slightly. And the missile boss on the boss run.

Just a thought, a flicker algorithm would be nice, invisible bullets when too much stuff on the screen is unfair.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on May 10, 2019, 07:09:03 pm
Interesting, I didn’t think there would be any slowdowns left.
I guess maybe I should continue rewriting all of the asm to help remove slowdowns. I have something that could possibly remove some flickering in certain situations but for the most part I don’t think all of the flickering can be removed unless you use a emulator or super nt that supports the no sprite limit.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Grego on May 10, 2019, 09:17:49 pm
If you continue optimizing the game make sure to take into consideration his ram remapping.

A prioritized flicker system would be best, player shots flickering first, then items, etc. Not sure how hard that would be to achieve.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on May 10, 2019, 11:40:23 pm
I’m going to continue but not with his hack. I had my own sa-1 hack that I was doing before he started his so I’m familiar with sa-1 bw-ram mapping. I only had about 0x2000 wram left to remap to bw-ram in my sa-1 hack.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Aaendi on May 11, 2019, 02:22:51 pm
The hard part about optimizing Gradius 3 is a lot of it has to do with the way tables were arranged.  It stores metasprite coordinates as signed 8-bit values that have to be sign extended to 16-bit.

There's also a routine that I have no idea what it does, but it somehow effects bubble movement, and involves changing bytes in an array.  I have no clue why a routine changing bytes in an array would effect bubble movement.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on May 11, 2019, 03:39:23 pm
Which routine? I can take look at it if you want me to. The array might be for a dma of bg2 data. The bubbles are sprites and bubbles are on bg layer 2.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Aaendi on May 11, 2019, 06:13:24 pm
The routine at $82980e.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on May 13, 2019, 07:22:07 am
Is this the array that is located at $01:E2BD?

Code: [Select]
7E FF 07 00
80 FF 04 00
82 FF 01 00
FE FF 02 00
02 00 02 00
7E 00 01 00
80 00 04 00
82 00 07 00
FF FF

I can take at look at it later tonight when I get more time.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: snesfanboi on May 14, 2019, 06:25:01 pm
I may upload whats already done to the fastrom patch. Do you want me to include your
optimizations if I upload it?




Would love this, to me it's a far more natural solution to gradius 3's problems on the snes. I'm the dev balanced stuff out with slowdowns, some of the bosses on the sa-1 version are too hard now and the hardest difficulties aren't worth trying.

Keep up the great work. Unrelated but one game that has awful slowdown is final fight 3 co-op, its pretty much unplayable. That game is fastrom though
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on May 17, 2019, 09:04:01 pm
@snesfanboi
Maybe it might be best to do 2 separate patches. A fastrom and a
fastrom plus optimizations. The goal is to remove all slowdowns
so the further we progress the more the game is going to play like
the sa-1 patch. When we get all of the slowdowns out I'll see about
balancing out the game play so its not too hard. I don't really have
any interest in the final fight series but if someone gets a disassembly
dump of it similar to the disassembly I did for gradius 3 then someone
might consider making some optimizations to the code. The disassembled
code is very important to making these kinds of modifications. It took
awhile to do gradius 3 disassembly but it was well worth it.

@Aaendi
I'm currently working on dissecting the whole function $02/96DF-$02/99E2.
Not sure if you made any progress on figuring out exactly how that array
works yet but I'm making progress on it and I should have it fully figured
out soon. While I was dissecting the function $02/96DF-$02/99E2 I couldn't
help but try out a few optimizations. Let me know if any of these
optimizations are useful.

This code looked like it could use a optimization.
Code: [Select]
$82/9819 E6 18       INC $18         [$00:0018] A:08E8 X:0C00 Y:08E8 D:0000 DB:7E S:1DE6 P:nvmbdIzc V:011 H:0504 F:12 C:07
$82/981B E6 18       INC $18         [$00:0018] A:08E8 X:0C00 Y:08E8 D:0000 DB:7E S:1DE6 P:NvmbdIzc V:011 H:0594 F:12 C:07
$82/981D E6 18       INC $18         [$00:0018] A:08E8 X:0C00 Y:08E8 D:0000 DB:7E S:1DE6 P:NvmbdIzc V:011 H:0644 F:12 C:07
$82/981F E6 18       INC $18         [$00:0018] A:08E8 X:0C00 Y:08E8 D:0000 DB:7E S:1DE6 P:NvmbdIzc V:011 H:0694 F:12 C:07

I wrote this in its place.
Code: [Select]
$82/9819 A9 04 00    LDA #$0004                 A:0AA4 X:0C00 Y:0AA4 D:0000 DB:7E S:1DE1 P:nvmbdIzC V:008 H:0068 F:25 C:03
$82/981C 18          CLC                        A:0004 X:0C00 Y:0AA4 D:0000 DB:7E S:1DE1 P:nvmbdIzC V:008 H:0086 F:25 C:02
$82/981D 65 18       ADC $18         [$00:0018] A:0004 X:0C00 Y:0AA4 D:0000 DB:7E S:1DE1 P:nvmbdIzc V:008 H:0098 F:25 C:04
$82/981F 85 18       STA $18         [$00:0018] A:E2C1 X:0C00 Y:0AA4 D:0000 DB:7E S:1DE1 P:NvmbdIzc V:008 H:0126 F:25 C:04
The original is 28 cycles and the new is 13 cycles.

You can also use the same optimization for this code as well and save 1 cycle. Just change the value of the lda to 0x0002.
Code: [Select]
$82/98AA E6 18       INC $18         [$00:0018] A:08D6 X:0C00 Y:08D6 D:0000 DB:7E S:1DE3 P:nvmbdIzC V:055 H:0108 F:30 C:07
$82/98AC E6 18       INC $18         [$00:0018] A:08D6 X:0C00 Y:08D6 D:0000 DB:7E S:1DE3 P:NvmbdIzC V:055 H:0158 F:30 C:07

Here is another one that can be optimized.
Code: [Select]
$02/9771 B5 12       LDA $12,x  [$00:7C00]   A:0300 X:61AE Y:004E D:1A40 DB:01 S:1DF3 P:eNvmxdIzcHC:21150 VC:000 00 FL:00
$02/9773 DA          PHX                     A:0300 X:61AE Y:004E D:1A40 DB:01 S:1DF3 P:eNvmxdIzcHC:21158 VC:000 00 FL:00
$02/9774 0A          ASL A                   A:0300 X:61AE Y:004E D:1A40 DB:01 S:1DF3 P:eNvmxdIzcHC:21166 VC:000 00 FL:00
$02/9775 AA          TAX                     A:0300 X:61AE Y:004E D:1A40 DB:01 S:1DF3 P:eNvmxdIzcHC:21174 VC:000 00 FL:00
$02/9776 BF 80 97 02 LDA $029780,x[$02:F92E] A:0300 X:61AE Y:004E D:1A40 DB:01 S:1DF3 P:eNvmxdIzcHC:21182 VC:000 00 FL:00
$02/977A FA          PLX                     A:0300 X:61AE Y:004E D:1A40 DB:01 S:1DF3 P:eNvmxdIzcHC:21190 VC:000 00 FL:00
$02/977B 85 00       STA $00    [$00:1A40]   A:0300 X:61AE Y:004E D:1A40 DB:01 S:1DF3 P:eNvmxdIzcHC:21198 VC:000 00 FL:00
$02/977D 6C 00 00    JMP ($0000)[$00:0000]   A:0300 X:61AE Y:004E D:1A40 DB:01 S:1DF3 P:eNvmxdIzcHC:21206 VC:000 00 FL:00

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
This is data not ASM. This is data for the jump above

$02/9780-$02/9787 data location
88 97
F7 97
32 99
BC 99
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

I wrote this in its place.
Code: [Select]
$82/9771 B5 12       LDA $12,x  [$00:2C5A]   A:0003 X:2C48 Y:1F3F D:0000 DB:81 S:1DE3 P:envmxdIzCHC:0016 VC:000 00 FL:41148
$82/9773 F0 13       BEQ $13    [$9788]      A:0003 X:2C48 Y:1F3F D:0000 DB:81 S:1DE3 P:envmxdIzCHC:0022 VC:000 00 FL:41148
$82/9775 3A          DEC A                   A:0003 X:2C48 Y:1F3F D:0000 DB:81 S:1DE3 P:envmxdIzCHC:0028 VC:000 00 FL:41148
$82/9776 F0 09       BEQ $09    [$9781]      A:0003 X:2C48 Y:1F3F D:0000 DB:81 S:1DE3 P:envmxdIzCHC:0034 VC:000 00 FL:41148
$82/9778 3A          DEC A                   A:0003 X:2C48 Y:1F3F D:0000 DB:81 S:1DE3 P:envmxdIzCHC:0040 VC:000 00 FL:41148
$82/9779 F0 03       BEQ $03    [$977E]      A:0003 X:2C48 Y:1F3F D:0000 DB:81 S:1DE3 P:envmxdIzCHC:0046 VC:000 00 FL:41148
$82/977B 4C BC 99    JMP $99BC  [$81:99BC]   A:0003 X:2C48 Y:1F3F D:0000 DB:81 S:1DE3 P:envmxdIzCHC:0052 VC:000 00 FL:41148
$82/977E 4C 32 99    JMP $9932  [$81:9932]   A:0003 X:2C48 Y:1F3F D:0000 DB:81 S:1DE3 P:envmxdIzCHC:0058 VC:000 00 FL:41148
$82/9781 4C F7 97    JMP $97F7  [$81:97F7]   A:0003 X:2C48 Y:1F3F D:0000 DB:81 S:1DE3 P:envmxdIzCHC:0064 VC:000 00 FL:41148
$82/9784 EA          NOP                     A:0003 X:2C48 Y:1F3F D:0000 DB:81 S:1DE3 P:envmxdIzCHC:0070 VC:000 00 FL:41148
$82/9785 EA          NOP                     A:0003 X:2C48 Y:1F3F D:0000 DB:81 S:1DE3 P:envmxdIzCHC:0076 VC:000 00 FL:41148
$82/9786 EA          NOP                     A:0003 X:2C48 Y:1F3F D:0000 DB:81 S:1DE3 P:envmxdIzCHC:0082 VC:000 00 FL:41148
$82/9787 EA          NOP                     A:0003 X:2C48 Y:1F3F D:0000 DB:81 S:1DE3 P:envmxdIzCHC:0088 VC:000 00 FL:41148

Here is how many cycles for each jump.
Code: [Select]
$82/9771 B5 12       LDA $12, X      [$00:0CD2] A:9771 X:0CC0 Y:0070 D:0000 DB:81 S:1DE3 P:NvmbdIzc V:020 H:1006 F:44 C:05
$82/9773 F0 13       BEQ $13         [$9788]    A:0000 X:0CC0 Y:0070 D:0000 DB:81 S:1DE3 P:nvmbdIZc V:020 H:1040 F:44 C:03 = 8  //$82:9788

$82/9771 B5 12       LDA $12, X      [$00:0C12] A:9771 X:0C00 Y:0070 D:0000 DB:81 S:1DE3 P:NvmbdIzc V:009 H:0212 F:45 C:05
$82/9773 F0 13       BEQ $13         [$9788]    A:0001 X:0C00 Y:0070 D:0000 DB:81 S:1DE3 P:nvmbdIzc V:009 H:0246 F:45 C:02
$82/9775 3A          DEC A                      A:0001 X:0C00 Y:0070 D:0000 DB:81 S:1DE3 P:nvmbdIzc V:009 H:0258 F:45 C:02
$82/9776 F0 09       BEQ $09         [$9781]    A:0000 X:0C00 Y:0070 D:0000 DB:81 S:1DE3 P:nvmbdIZc V:009 H:0270 F:45 C:03
$82/9781 4C F7 97    JMP $97F7       [$81:97F7] A:0000 X:0C00 Y:0070 D:0000 DB:81 S:1DE3 P:nvmbdIZc V:009 H:0288 F:45 C:03 = 15 //$82:97f7

$82/9771 B5 12       LDA $12, X      [$00:0C12] A:9771 X:0C00 Y:0070 D:0000 DB:81 S:1DE3 P:NvmbdIzc V:027 H:0278 F:13 C:05
$82/9773 F0 13       BEQ $13         [$9788]    A:0002 X:0C00 Y:0070 D:0000 DB:81 S:1DE3 P:nvmbdIzc V:027 H:0312 F:13 C:02
$82/9775 3A          DEC A                      A:0002 X:0C00 Y:0070 D:0000 DB:81 S:1DE3 P:nvmbdIzc V:027 H:0324 F:13 C:02
$82/9776 F0 09       BEQ $09         [$9781]    A:0001 X:0C00 Y:0070 D:0000 DB:81 S:1DE3 P:nvmbdIzc V:027 H:0336 F:13 C:02
$82/9778 3A          DEC A                      A:0001 X:0C00 Y:0070 D:0000 DB:81 S:1DE3 P:nvmbdIzc V:027 H:0348 F:13 C:02
$82/9779 F0 03       BEQ $03         [$977E]    A:0000 X:0C00 Y:0070 D:0000 DB:81 S:1DE3 P:nvmbdIZc V:027 H:0360 F:13 C:03
$82/977E 4C 32 99    JMP $9932       [$81:9932] A:0000 X:0C00 Y:0070 D:0000 DB:81 S:1DE3 P:nvmbdIZc V:027 H:0378 F:13 C:03 = 19 //$82:9932

$82/9771 B5 12       LDA $12, X      [$00:0C12] A:9771 X:0C00 Y:0070 D:0000 DB:81 S:1DE3 P:NvmbdIzc V:011 H:0458 F:11 C:05
$82/9773 F0 13       BEQ $13         [$9788]    A:0003 X:0C00 Y:0070 D:0000 DB:81 S:1DE3 P:nvmbdIzc V:011 H:0492 F:11 C:02
$82/9775 3A          DEC A                      A:0003 X:0C00 Y:0070 D:0000 DB:81 S:1DE3 P:nvmbdIzc V:011 H:0504 F:11 C:02
$82/9776 F0 09       BEQ $09         [$9781]    A:0002 X:0C00 Y:0070 D:0000 DB:81 S:1DE3 P:nvmbdIzc V:011 H:0516 F:11 C:02
$82/9778 3A          DEC A                      A:0002 X:0C00 Y:0070 D:0000 DB:81 S:1DE3 P:nvmbdIzc V:011 H:0528 F:11 C:02
$82/9779 F0 03       BEQ $03         [$977E]    A:0001 X:0C00 Y:0070 D:0000 DB:81 S:1DE3 P:nvmbdIzc V:011 H:0580 F:11 C:02
$82/977B 4C BC 99    JMP $99BC       [$81:99BC] A:0001 X:0C00 Y:0070 D:0000 DB:81 S:1DE3 P:nvmbdIzc V:011 H:0592 F:11 C:03 = 18 //$82:99bc
This code can be further optimized by moving the most used jump to the spot where the least
cycles are used. These($02/977D 6C 00 00    JMP ($0000)[$00:0000]) jumps are used in a lot of places and if they have 8 or less jumps they can be optimized with this new code. So far I tested this new jump code at these locations.
Code: [Select]
$82/9728 //function for 128x128 bubbles
$82/9754 //function for 64x64   bubbles
$82/9771 //function for 32x32   bubbles
$82/978E //function for 16x16   bubbles

Here is another one that I optimized but I maxed out the character limit for this post
so I cant show the new codes. There was a lot of them to change.
Code: [Select]
$82/815D A5 03       LDA $03    [$00:0003]   A:00ED X:0C00 Y:0030 D:0000 DB:81 S:1DD9 P:envmxdIzcHC:1138 VC:008 00 FL:42835
$82/815F 8D 02 42    STA $4202  [$81:4202]   A:ED10 X:0C00 Y:0030 D:0000 DB:81 S:1DD9 P:eNvmxdIzcHC:1166 VC:008 00 FL:42835
$82/8162 EA          NOP                     A:ED10 X:0C00 Y:0030 D:0000 DB:81 S:1DD9 P:eNvmxdIzcHC:1196 VC:008 00 FL:42835
$82/8163 EA          NOP                     A:ED10 X:0C00 Y:0030 D:0000 DB:81 S:1DD9 P:eNvmxdIzcHC:1208 VC:008 00 FL:42835
$82/8164 EA          NOP                     A:ED10 X:0C00 Y:0030 D:0000 DB:81 S:1DD9 P:eNvmxdIzcHC:1220 VC:008 00 FL:42835
$82/8165 EA          NOP                     A:ED10 X:0C00 Y:0030 D:0000 DB:81 S:1DD9 P:eNvmxdIzcHC:1232 VC:008 00 FL:42835
$82/8166 AD 16 42    LDA $4216  [$81:4216]   A:ED10 X:0C00 Y:0030 D:0000 DB:81 S:1DD9 P:eNvmxdIzcHC:1244 VC:008 00 FL:42835
There are at least 2 different STZ's that could be used instead of using these 4 nops
to wait the 8 cycles to get your results.

I laughed when I seen this code. There is no way someone wrote this by hand is there?
And no, the code isn't trying to use up cycles to get results like the multiplication code.
Code: [Select]
$02/97A8 4C AB 97    JMP $97AB  [$02:97AB]

May 22, 2019, 12:29:49 am - (Auto Merged - Double Posts are not allowed before 7 days.)
@Aaendi
I have most of that array figured out. This is for 32x32 size bubbles collision data.
This data appears to be for only bubbles colliding with bubbles.

Code: [Select]
3x3 8 pixel squares(24x24 pixel) minus a center square(square #5)
example:
ooo
oxo
ooo

7E FF 07 00 //1st 2 bytes = collision square #1 location, 2nd 2 bytes is for direction to bounce off of bubble
80 FF 04 00 //1st 2 bytes = collision square #2 location
82 FF 01 00 //1st 2 bytes = collision square #3 location
FE FF 02 00 //1st 2 bytes = collision square #4 location
02 00 02 00 //1st 2 bytes = collision square #6 location, 0x02 0x00 = left, right, opposite
7E 00 01 00 //1st 2 bytes = collision square #7 location, 0x01 0x00 = upper/right, lower/left, opposite   
80 00 04 00 //1st 2 bytes = collision square #8 location, 0x04 0x00 = up, down, opposite
82 00 07 00 //1st 2 bytes = collision square #9 location, 0x07 0x00 = upper/left, lower/right, opposite
FF FF       //end of collision size and direction
Also if you set the 2nd 2 bytes to bounce off of bubble to 0x00 0x00 then
the 32x32 bubbles wont collide with each other. It appears the 2nd 2 bytes
have a max of 0x7 and that's not looking at the data that is looking at the asm.

Here is the 16x16 bubble collision data
Code: [Select]
$81:E2df
00 00 06 00 //collision square #1 location, 0x06 00 = up/down, left/right, opposite
FF FF

Ram used for colliding bubbles is 7E:C000-7E:CFFF. 64x32 8x8 square collision array. 2 bytes per square

Here is the 64x64 bubble collision.
Code: [Select]
64x64 bubble collision

 00000
00xxx00
0xxxxx0
0xxxxx0
0xxxxx0
00xxx00
 00000

$01:E25B
7C FE 07 00 //collision square #1
7E FE 04 00 //collision square #2
80 FE 04 00 //collision square #3
82 FE 04 00 //collision square #4
84 FE 01 00 //collision square #5
FA FE 07 00 //collision square #6
FC FE 07 00 //collision square #7
04 FF 01 00 //collision square #11
06 FF 01 00 //collision square #12
7A FF 02 00 //collision square #13
86 FF 02 00 //collision square #19
FA FF 02 00 //collision square #20
06 00 02 00 //collision square #26
7A 00 02 00 //collision square #27
86 00 02 00 //collision square #33
FA 00 01 00 //collision square #34
FC 00 01 00 //collision square #35
04 01 07 00 //collision square #38
06 01 07 00 //collision square #39
7C 01 01 00 //collision square #40
7E 01 04 00 //collision square #41
80 01 04 00 //collision square #42
82 01 04 00 //collision square #43
84 01 07 00 //collision square #44
FF FF

I also have the 128x128 bubble collision data mapped but my posts text is maxed out so
I cant post it yet. :D
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Zimgief on May 22, 2019, 12:02:35 pm
Here an answer if you can't double post. :p
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn 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



$01:E199
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
FF FF

Here is a image of the collision grid. The red square is to show the center of the 128x128 bubble(0x00 0x00).
(https://i.imgur.com/8776ekC.png)

@Aaendi
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.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: snesfanboi on May 23, 2019, 09:50:20 am
great to see you're still working on this  :woot!:
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Aaendi 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.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on May 26, 2019, 02:58:02 am
@snesfanboi
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.

@Aaendi
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.
http://www.mediafire.com/file/23np4ja4dzd4pua/gradius_3_data_decomp.zip/file (http://www.mediafire.com/file/23np4ja4dzd4pua/gradius_3_data_decomp.zip/file)

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.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Aaendi 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.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn 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.
http://www.mediafire.com/file/9snjopq80afdb22/Gradius-III-%255Bsa-1%255DUSAv1.04_bug_fix.bps/file (http://www.mediafire.com/file/9snjopq80afdb22/Gradius-III-%255Bsa-1%255DUSAv1.04_bug_fix.bps/file)

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


Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Grego 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.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn 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:
http://www.mediafire.com/file/sho7adgcm4htrjj/New_asm_code_when_boss_dies.zip/file (http://www.mediafire.com/file/sho7adgcm4htrjj/New_asm_code_when_boss_dies.zip/file)

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:
https://wiki.superfamicom.org/65816-reference (https://wiki.superfamicom.org/65816-reference)

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.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn 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.
http://www.mediafire.com/file/8u90hm9ay5fakxq/Start_at_any_level_gradius_3_snes.zip/file (http://www.mediafire.com/file/8u90hm9ay5fakxq/Start_at_any_level_gradius_3_snes.zip/file)

I would like to upload this new patch to romhacking.net. 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.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: niuus on June 20, 2019, 01:59:29 am
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.
http://www.mediafire.com/file/8u90hm9ay5fakxq/Start_at_any_level_gradius_3_snes.zip/file (http://www.mediafire.com/file/8u90hm9ay5fakxq/Start_at_any_level_gradius_3_snes.zip/file)

I would like to upload this new patch to romhacking.net. 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.
So, i pressed start+b at the 1 player screen, but nothing else showed up afterwards, even held it up to the game start point. I tried again pressing and holding b+start in succession, but no dice.

Patched rom CRC32 is 3C3C11C1
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on June 20, 2019, 05:55:55 pm
When you start a new game try holding start + B + A and when the weapon select screen shows up you can release the buttons and it should start you on level 2 after selecting your weapons. Start + B activates the new asm for the stage select but you still need to hold the other buttons as well to choose the level. If you only hold start + B it will load the new asm but since no other buttons are pressed and held it will load level 1. No new screens pop up to choose a level. Holding the correct button combinations is what chooses the level. Hope that gets it working for you. Let me know how that works.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: niuus on June 21, 2019, 06:11:43 am
When you start a new game try holding start + B + A and when the weapon select screen shows up you can release the buttons and it should start you on level 2 after selecting your weapons. Start + B activates the new asm for the stage select but you still need to hold the other buttons as well to choose the level. If you only hold start + B it will load the new asm but since no other buttons are pressed and held it will load level 1. No new screens pop up to choose a level. Holding the correct button combinations is what chooses the level. Hope that gets it working for you. Let me know how that works.
Sorry, nothing  :-[

At the 1-2 player screen, i pressed the buttons at the same time (and held them until the weapon screen), also tried b+a+start (in succession, holding them all), nothing.

I tried in Snes9x RX (Wii), and also on Snes9x 1.58 (PC).
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on June 24, 2019, 06:16:18 am
Only thing that I can think of for why it isn't working for
you is you might not be patching it correctly. I checked everything
including the link that I posted and it works every time for me.

Here are a few images that might help. I'm using geiger's snes debugger.

(https://i.imgur.com/C87zoKo.png)
At the ram address 7e0020 you see 00 00. Those 2 bytes are the controller 1
inputs. 00 00 means nothing is pressed. At the ram address 7e0086 you see 00.
That is going to be the current level that you start at.



(https://i.imgur.com/er8vYM5.png)
In this image I have just pressed and started holding start + A + B. If you
look at the ram address 7e0020 you will see 80 90. Those 2 bytes means I'm
holding only start + A + B buttons. If you look at 7e0086 it is still 00.



(https://i.imgur.com/QAebD9y.png)
Now we are at the weapon select screen. 7e0020 is still being held (80 90)
and now 7e0086 has changed to 01. 01 = level 2 which is the bubble level.
If 7e0086 was still 00 it would load level 1. When you get to this screen
that is when its safe to let go of the buttons.



(https://i.imgur.com/gpA6TsO.png)
If you don't see this highlighted hex in your rom then you definitely did
not patch it correctly. If you do see that hex in your rom then you may
not be holding the correct buttons.

Is anyone else having issues getting this patch to work?









Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: niuus on June 24, 2019, 01:48:56 pm
Only thing that I can think of for why it isn't working for
you is you might not be patching it correctly. I checked everything
including the link that I posted and it works every time for me.

Here are a few images that might help. I'm using geiger's snes debugger.
I am using LunarIPS as usual. Can you give me the CRC32 and MD5 of the patched rom?
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on June 24, 2019, 03:58:51 pm
Here is the patched rom hashes.
(https://i.imgur.com/IgadJlQ.png)

CRC32 looks the same as your patched one. When you are holding
the start + B + A buttons what are the 2 bytes in ram at 7e0020
and 7e0021?
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Zimgief on June 24, 2019, 04:23:09 pm
It works, no problem. Tried (start + b) +a, got to bubble stage.

niuus, maybe make sure you press a + b, THEN (without releasing  a + b) press start?
Note: got the game file on "wow****".
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: snesfanboi on June 27, 2019, 03:54:48 pm
Does the patch above include the optimizations? I'm not being lazy, my PC is has been dead for 2 weeks but should have it back over the weekend.

Keep up the great work  :beer:
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on June 29, 2019, 11:15:09 am
@niuus
Did you get it to work yet?

@Zimgeif
Thanks! I found those difficulty settings data that I said I had.
http://www.mediafire.com/file/wv2votm41jgqo3i/Gradius_3_difficulty.txt/file (http://www.mediafire.com/file/wv2votm41jgqo3i/Gradius_3_difficulty.txt/file)

@snesfanboi
No it does not include anything but the level selection. The next optimization patch
that I will have ready is going to be awhile longer before its ready. I have a lot of
new optimizations to do to add to the optimizations that have already been created. I
think with these new optimizations the game will run faster than the current sa-1 that
vitor created. The assembly looks like it was ether written to cause a lot of slowdowns
(which is the most likely thing) or the programmers were not that smart (I don't think
that's why the game slows down so much).

Here is another example of how the assembly throughout the rom was programmed that could
cause slowdown.

This asm is traced from gameplay when a enemy is killed.
Code: [Select]
$02/8502 F0 01       BEQ $01    [$8505]      A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIZCHC:1072 VC:017 00 FL:454
$02/8505 74 02       STZ $02,x  [$00:0902]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIZCHC:1094 VC:017 00 FL:454
$02/8507 B5 14       LDA $14,x  [$00:0914]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIZCHC:1132 VC:017 00 FL:454
$02/8509 30 06       BMI $06    [$8511]      A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIZCHC:1170 VC:017 00 FL:454
$02/850B A6 FC       LDX $FC    [$00:00FC]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIZCHC:1186 VC:017 00 FL:454
$02/850D 5C B4 8D 00 JMP $008DB4[$00:8DB4]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:1218 VC:017 00 FL:454
$00/8DB4 74 04       STZ $04,x  [$00:0904]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:1250 VC:017 00 FL:454
$00/8DB6 74 08       STZ $08,x  [$00:0908]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:1288 VC:017 00 FL:454
$00/8DB8 74 0A       STZ $0A,x  [$00:090A]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:1326 VC:017 00 FL:454
$00/8DBA 74 0C       STZ $0C,x  [$00:090C]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:1364 VC:017 00 FL:454
$00/8DBC 74 0E       STZ $0E,x  [$00:090E]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:0034 VC:018 00 FL:454
$00/8DBE 74 00       STZ $00,x  [$00:0900]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:0072 VC:018 00 FL:454
$00/8DC0 74 02       STZ $02,x  [$00:0902]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:0110 VC:018 00 FL:454
$00/8DC2 74 14       STZ $14,x  [$00:0914]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:0148 VC:018 00 FL:454
$00/8DC4 74 06       STZ $06,x  [$00:0906]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:0186 VC:018 00 FL:454
$00/8DC6 74 10       STZ $10,x  [$00:0910]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:0224 VC:018 00 FL:454
$00/8DC8 74 12       STZ $12,x  [$00:0912]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:0262 VC:018 00 FL:454
$00/8DCA 74 16       STZ $16,x  [$00:0916]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:0300 VC:018 00 FL:454
$00/8DCC 74 18       STZ $18,x  [$00:0918]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:0338 VC:018 00 FL:454
$00/8DCE 74 1A       STZ $1A,x  [$00:091A]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:0376 VC:018 00 FL:454
$00/8DD0 74 1C       STZ $1C,x  [$00:091C]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:0414 VC:018 00 FL:454
$00/8DD2 74 1E       STZ $1E,x  [$00:091E]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:0452 VC:018 00 FL:454
$00/8DD4 74 20       STZ $20,x  [$00:0920]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:0490 VC:018 00 FL:454
$00/8DD6 74 22       STZ $22,x  [$00:0922]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:0528 VC:018 00 FL:454
$00/8DD8 74 24       STZ $24,x  [$00:0924]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:0566 VC:018 00 FL:454
$00/8DDA 74 26       STZ $26,x  [$00:0926]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:0604 VC:018 00 FL:454
$00/8DDC 74 28       STZ $28,x  [$00:0928]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:0642 VC:018 00 FL:454
$00/8DDE 74 2A       STZ $2A,x  [$00:092A]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:0680 VC:018 00 FL:454
$00/8DE0 74 2C       STZ $2C,x  [$00:092C]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:0718 VC:018 00 FL:454
$00/8DE2 74 2E       STZ $2E,x  [$00:092E]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:0756 VC:018 00 FL:454
$00/8DE4 74 30       STZ $30,x  [$00:0930]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:0794 VC:018 00 FL:454
$00/8DE6 74 32       STZ $32,x  [$00:0932]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:0832 VC:018 00 FL:454
$00/8DE8 74 34       STZ $34,x  [$00:0934]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:0870 VC:018 00 FL:454
$00/8DEA 74 36       STZ $36,x  [$00:0936]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:0908 VC:018 00 FL:454
$00/8DEC 74 38       STZ $38,x  [$00:0938]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:0946 VC:018 00 FL:454
$00/8DEE 74 3A       STZ $3A,x  [$00:093A]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:0984 VC:018 00 FL:454
$00/8DF0 74 3C       STZ $3C,x  [$00:093C]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:1022 VC:018 00 FL:454
$00/8DF2 74 3E       STZ $3E,x  [$00:093E]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:1060 VC:018 00 FL:454
$00/8DF4 6B          RTL                     A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE3 P:envmxdIzCHC:1098 VC:018 00 FL:454

$00/F425 B5 2E       LDA $2E,x  [$00:092E]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE6 P:envmxdIzCHC:1142 VC:018 00 FL:453
$00/F427 89 00 04    BIT #$0400              A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE6 P:envmxdIZCHC:1180 VC:018 00 FL:453
$00/F42A F0 06       BEQ $06    [$F432]      A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE6 P:envmxdIZCHC:1204 VC:018 00 FL:453
$00/F432 89 02 00    BIT #$0002              A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE6 P:envmxdIZCHC:1226 VC:018 00 FL:453
$00/F435 D0 18       BNE $18    [$F44F]      A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE6 P:envmxdIZCHC:1250 VC:018 00 FL:453
$00/F437 B4 0A       LDY $0A,x  [$00:090A]   A:0000 X:0900 Y:DD2A D:0000 DB:01 S:1DE6 P:envmxdIZCHC:1266 VC:018 00 FL:453
$00/F439 C0 C0 FF    CPY #$FFC0              A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE6 P:envmxdIZCHC:1304 VC:018 00 FL:453
$00/F43C 30 05       BMI $05    [$F443]      A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE6 P:envmxdIzcHC:1328 VC:018 00 FL:453
$00/F43E C0 40 01    CPY #$0140              A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE6 P:envmxdIzcHC:1344 VC:018 00 FL:453
$00/F441 30 0C       BMI $0C    [$F44F]      A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE6 P:eNvmxdIzcHC:0000 VC:019 00 FL:453
$00/F44F B5 2E       LDA $2E,x  [$00:092E]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE6 P:eNvmxdIzcHC:0022 VC:019 00 FL:453
$00/F451 89 08 00    BIT #$0008              A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE6 P:envmxdIZcHC:0060 VC:019 00 FL:453
$00/F454 D0 57       BNE $57    [$F4AD]      A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE6 P:envmxdIZcHC:0084 VC:019 00 FL:453
$00/F456 AD B4 12    LDA $12B4  [$01:12B4]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE6 P:envmxdIZcHC:0100 VC:019 00 FL:453
$00/F459 0D B8 12    ORA $12B8  [$01:12B8]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE6 P:envmxdIZcHC:0140 VC:019 00 FL:453
$00/F45C F0 07       BEQ $07    [$F465]      A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE6 P:envmxdIZcHC:0180 VC:019 00 FL:453
$00/F465 B5 0E       LDA $0E,x  [$00:090E]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE6 P:envmxdIZcHC:0202 VC:019 00 FL:453
$00/F467 C5 D8       CMP $D8    [$00:00D8]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE6 P:envmxdIZcHC:0240 VC:019 00 FL:453
$00/F469 10 04       BPL $04    [$F46F]      A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE6 P:eNvmxdIzcHC:0272 VC:019 00 FL:453
$00/F46B C5 D6       CMP $D6    [$00:00D6]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE6 P:eNvmxdIzcHC:0288 VC:019 00 FL:453
$00/F46D 10 3E       BPL $3E    [$F4AD]      A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE6 P:eNvmxdIzcHC:0320 VC:019 00 FL:453
$00/F46F B5 14       LDA $14,x  [$00:0914]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE6 P:eNvmxdIzcHC:0336 VC:019 00 FL:453
$00/F471 89 FF 7F    BIT #$7FFF              A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE6 P:envmxdIZcHC:0374 VC:019 00 FL:453
$00/F474 F0 33       BEQ $33    [$F4A9]      A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE6 P:envmxdIZcHC:0398 VC:019 00 FL:453
$00/F4A9 22 B4 8D 00 JSL $008DB4[$00:8DB4]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE6 P:envmxdIZcHC:0420 VC:019 00 FL:453

$00/8DB4 74 04       STZ $04,x  [$00:0904]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:0476 VC:019 00 FL:454
$00/8DB6 74 08       STZ $08,x  [$00:0908]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:0514 VC:019 00 FL:454
$00/8DB8 74 0A       STZ $0A,x  [$00:090A]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:0552 VC:019 00 FL:454
$00/8DBA 74 0C       STZ $0C,x  [$00:090C]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:0590 VC:019 00 FL:454
$00/8DBC 74 0E       STZ $0E,x  [$00:090E]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:0628 VC:019 00 FL:454
$00/8DBE 74 00       STZ $00,x  [$00:0900]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:0666 VC:019 00 FL:454
$00/8DC0 74 02       STZ $02,x  [$00:0902]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:0704 VC:019 00 FL:454
$00/8DC2 74 14       STZ $14,x  [$00:0914]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:0742 VC:019 00 FL:454
$00/8DC4 74 06       STZ $06,x  [$00:0906]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:0780 VC:019 00 FL:454
$00/8DC6 74 10       STZ $10,x  [$00:0910]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:0818 VC:019 00 FL:454
$00/8DC8 74 12       STZ $12,x  [$00:0912]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:0856 VC:019 00 FL:454
$00/8DCA 74 16       STZ $16,x  [$00:0916]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:0894 VC:019 00 FL:454
$00/8DCC 74 18       STZ $18,x  [$00:0918]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:0932 VC:019 00 FL:454
$00/8DCE 74 1A       STZ $1A,x  [$00:091A]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:0970 VC:019 00 FL:454
$00/8DD0 74 1C       STZ $1C,x  [$00:091C]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:1008 VC:019 00 FL:454
$00/8DD2 74 1E       STZ $1E,x  [$00:091E]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:1046 VC:019 00 FL:454
$00/8DD4 74 20       STZ $20,x  [$00:0920]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:1084 VC:019 00 FL:454
$00/8DD6 74 22       STZ $22,x  [$00:0922]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:1122 VC:019 00 FL:454
$00/8DD8 74 24       STZ $24,x  [$00:0924]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:1160 VC:019 00 FL:454
$00/8DDA 74 26       STZ $26,x  [$00:0926]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:1198 VC:019 00 FL:454
$00/8DDC 74 28       STZ $28,x  [$00:0928]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:1236 VC:019 00 FL:454
$00/8DDE 74 2A       STZ $2A,x  [$00:092A]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:1274 VC:019 00 FL:454
$00/8DE0 74 2C       STZ $2C,x  [$00:092C]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:1312 VC:019 00 FL:454
$00/8DE2 74 2E       STZ $2E,x  [$00:092E]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:1350 VC:019 00 FL:454
$00/8DE4 74 30       STZ $30,x  [$00:0930]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:0020 VC:020 00 FL:454
$00/8DE6 74 32       STZ $32,x  [$00:0932]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:0058 VC:020 00 FL:454
$00/8DE8 74 34       STZ $34,x  [$00:0934]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:0096 VC:020 00 FL:454
$00/8DEA 74 36       STZ $36,x  [$00:0936]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:0134 VC:020 00 FL:454
$00/8DEC 74 38       STZ $38,x  [$00:0938]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:0172 VC:020 00 FL:454
$00/8DEE 74 3A       STZ $3A,x  [$00:093A]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:0210 VC:020 00 FL:454
$00/8DF0 74 3C       STZ $3C,x  [$00:093C]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:0248 VC:020 00 FL:454
$00/8DF2 74 3E       STZ $3E,x  [$00:093E]   A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:0286 VC:020 00 FL:454
$00/8DF4 6B          RTL                     A:0000 X:0900 Y:0000 D:0000 DB:01 S:1DE3 P:envmxdIZcHC:0324 VC:020 00 FL:454

Does anyone see whats wrong with this asm? I found 4 different occasions that
this happens and there could be more. This also happens with each of your bullets
when they disappear.

The game also uses MVN's to clear large sections of ram when it could be using dma.
It going to be very interesting to see how the next optimization patch compares to
the sa-1 hack in slowdowns.

I haven't been able to do as much as I would like on my projects lately and the gradius 3
decompression is taking more time than expected to complete so its going to be a little
while longer before the decompression is complete. I do have 7f:0000-7f:f800 of ram
completely free from compression. That ram was used for compressed gfx and compressed bg
data. That ram is no longer used in the game and is completey free to use for other things.
The next ram to free up from compression is 7e:a000-7e:bfff and 7e:e000-7e:ffff. When that
compression is removed that ram will be completely free. After that I will move the ram
data at 7f:f800-7f:ffff to 7e:3000-7e:37ff so all of ram bank $7F will be completely
unused in the entire rom. This decompression hack could be used in vitors sa-1 hack
to decrease ram size needed by half but I'm not really sure if that is something that he
would add to it but he is more than welcome to add this decompression hack to it if he
would like to. It could also possibly add a slight speedup in some locations in the sa-1
hack. The decompression hack does increase rom size but I don't really think that should be
a issue.

Some of the ram that the decompression hack is freeing up I'm going to use to remove some
slowdowns in this function $80/829E 22 8E 87 80 JSL $80878E[$80:878E] and this function
$80/82A2 22 F1 8E 80 JSL $808EF1[$80:8EF1]. Those are the 2 most used functions that cause
most of the slowdowns during gameplay so the ram trick should add a nice speedup when those
2 functions are used.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Zimgief on July 01, 2019, 11:25:13 am
Thanks a lot for the documentation!
I changed all the level difficulty values to 0, and played extensively the base game, and the hacked game, and it's a world of difference. Normal difficulty is much more enjoyable for me now, while still being harder than the old Easy.
I uploaded the hack as I feel it can be interesting for other players. Obviously I credited you. :p

I tried to change the values of the Game Level (for exemple, put 08 on easy), it didn't seem to make a difference? Unsure about how the usefulness of the values.

I was wondering:
- do you think you could release a optional "no flickering" hack, without slowdowns being removed? As I feel slowdowns can arguably be considered as a feature rather than a bug (a kind of "bullet time"), while flickering are unarguably flaws
- if it was easy for you, do you think you could find where to apply the same changes in Parodius(the SNES game also released in Europe)?

Anyway, thanks a lot!

EDIT
The read-me reads like this:
Spoiler:
NO STAGE DIFFICULTY SCALING

            By Zimgief


* PRESENTATION *

Difficulty in Gradius III depends on multiple factors.
The first and most obvious one is the Game Level in the Option Mode. Easy, Normal, Hard (and the unlockable Arcade).
It affects speed of ennemies and bullets, as well as the frequency ennemies shoot at you. Also, the number of minor ennemies generated during boss fights, and the number of "option-eating" ennemies that chase you during stages.

But the speed of ennemies and bullets as well as the frequency ennemies shoot at you are also affected by the stage you are in. The farther you go, the harder it gets.
Which is bad game design, especially in a Gradius game:
- different humans, at different ages, do not have the same reactivity. Everyone should be able to choose just the right amount of speed he or she is confortable with. This is not possible in the base game, as the speed increases multiple times during a single playthrough.
- when you are decently upgraded, this increase in speed is barely noticable because ennemies die as soon as they appear. But if YOU die, recovery is next to impossible even in Normal. At this rate, why have any lives and credits at all?

Knowing all this, the purpose of this hack is to remove stage difficulty scaling. So you can choose a Game Level (easy, normal, hard, arcade) that does not subreticiously overwhelmes you, and does give you better chances of recovering when you die.


* HOW TO PLAY *
Apply the patch to a US rom (maybe works with EU and J? Didn't try, sorry!).


* ACKNOWLEDGMENT *
slidelljohn (a.k.a. [J]), who provided the hex editing documentation


* VERSION HISTORY *
1.0 - First public release (01/07/2019)
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on July 02, 2019, 04:02:48 am
Your welcome! 8)

Awesome! :thumbsup:

Not sure why changing easy to 0x08 is not working for you. I just double checked and it work the 1st time for me so the data is accurate. Maybe you changed the wrong byte or you never changed the difficulty to easy. The game does start on normal mode.

Unfortunately I don’t think a no flickering hack is possible. Now I do think it’s possible for less flickering. %25 of your sprites in gradius 3 are for backgrounds. Most of the stars in the background are sprites and that’s going to cause more chances to hit the sprites per line limit. On the plant level when fighting the boss the upper background tiles and the lower background tiles are all sprites and you can see those flashing a lot. I could probably make those stop flashing by doubling the vram and have those sprites on one of the background layers. I also found the algorithm that causes the flashing of sprites when the game is paused. The game rotates some of the last sprites in oam to the 1st sprites in oam and it might be possible to change that up a little bit. It’s going to be some time before I get to make any modifications for the flashing of sprites but I have definitely been looking at the causes. There are emulators that have mods for the sprite limit to help with flashing and the super nt also has that feature but both of those mods I don’t think can work on original hardware.

I may or may not look into the parodius. I never played it and I don’t really have any interest in it plus it’s been hard to work on my own projects lately. But who knows I might look into it one day. You could probably find that data yourself if you look at your ram while changing the difficulty settings. Somewhere in the ram a value is changing. That’s how I find stuff like that. After I find the ram address for the difficulty I just run a trace and find how that value gets there.

Your welcome! Sorry it took so long to get that doc for you. I should probably better organize the information I find on the games that I like to hack. And thanks for the credit! :)
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: SCO on July 02, 2019, 05:47:16 am
retroarch snes9x has a flicker reduction option. I don't know if it works here.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Zimgief on July 02, 2019, 07:09:11 am
Yeah, but i'm more interested in playing the game on official hardware, whether the original system, or Snes Mini (CANOE emulator). :)

No problem for Parodius. The fact is I'm not too fond of it either. I'll see if I manage to track down the value (in fact, I am able, using Snes9x, to know which ram adress is affected when changing the difficulty in the options ($1FB8), but from there, I don't know what to do).

Looking at the arcade version, I'm thinking of another improvement. In arcade, during the boss fight in Plant Stage, bullets are displayed ABOVE the boss, which means they are always visible. Whereas on SNES, they are displayed UNDER, which means they become invisible when he's nearing you. That is unfair. Could it be changed?
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on July 02, 2019, 08:19:53 am
Well I guess since you took the initiative to find the ram location I
can help you figure parodius out.

Not sure if you know how to run a trace or not with geigers snes debugger
but just check cpu under logging in the debug console and it will start
tracing the cpu asm code to a file where your rom is with .log extension.
When you check the cpu box you also have to ether hit run or click on the
emulators screen so the snes will play. Uncheck the cpu when you are ready
to stop tracing code.

(https://i.imgur.com/OZ5nPc6.png)

This is the line of code that stores the value in ram at 7e:1fa8
$82/8281 99 A4 1F    STA $1FA4,y[$81:1FA8]

$81:1FA8 = $7e:1FA8 in snes lorom memory mapping


Code: [Select]
Disassembly:
$82/824F A9 07 00    LDA #$0007              //max difficulty
$82/8252 85 12       STA $12    [$00:0012]   //


Disassembly:
$82/8262 B5 24       LDA $24,x  [$00:9A60]   //
$82/8264 89 D0 01    BIT #$01D0              //
$82/8267 D0 0F       BNE $0F    [$8278]      //
$82/8269 89 20 C2    BIT #$C220              //
$82/826C F0 19       BEQ $19    [$8287]      //
$82/826E B9 A4 1F    LDA $1FA4,y[$81:B0D2]   //load
$82/8271 3A          DEC A                   //difficulty down
$82/8272 10 0D       BPL $0D    [$8281]      //
$82/8274 A5 10       LDA $10    [$00:0010]   //
$82/8276 80 09       BRA $09    [$8281]      //
$82/8278 B9 A4 1F    LDA $1FA4,y[$81:B0D2]   //load
$82/827B 1A          INC A                   //difficulty up
$82/827C C5 12       CMP $12    [$00:0012]   //
$82/827E D0 01       BNE $01    [$8281]      //
$82/8280 7B          TDC                     //
$82/8281 99 A4 1F    STA $1FA4,y[$81:B0D2]   //store
$82/8284 20 39 85    JSR $8539  [$80:8539]   //


If you want to learn how to find this stuff you can create a page
and I'm sure you would get help from me or some of the other members.
Its really not hard to learn and the more you do the better you get.

I assume you are saying the arcade system and not the arcade difficulty.
Correct me if I'm wrong with that assumption. But yea I hate that those
bullets are behind the boss. That's a good idea and I think it should be
possible.



Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Zimgief on July 02, 2019, 10:59:42 am
Ok, I think I understand the idea (I tried Geiger's Snes9x Debugger earlier today, and didn't even know where to start :D). I will try (and ask help in a new topic if needed)!

Yes, I was talking about Gradius III on the arcade system. :)

About the difficulty settings in the first draft of your fast rom patch.
"Elite, master, expert and pro" are not very explicit, don't you think? The names could be switched, no one would tell the difference.
Here are some ideas (maybe good, maybe not):
With 8 levels of difficulty : "easy 3, easy 2, easy 1, normal, hard 1, hard 2, hard 3, arcade".
Or with only 5 levels : "novice, easy, normal, hard, arcade", with novice being the original easy, and easy something between the original easy and normal.
In any case, I feel everything should be unlocked by default, except "arcade", the hardest (keeping the same way to unlock as in the non-modded game).
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on July 02, 2019, 03:41:35 pm
I usually use geigers debugger for when I want to trace code.
For graphics hacking I use vsnes to look at snes9x(geigers)
save states and for in game I use bsnes plus. You could pm me
too if you ever have any questions with snes hacking but it
is good to post in the forum just so other people can learn
as well.

The difficulties that I added I just did for fun and I haven't
decided yet if it is something that I want to keep. If I do
decide to keep the new difficulties I would definitely be open
to suggestions of what could be best for it. It doesn't have to be
"Elite, master, expert and pro". That was just the best option
that I could come up with at the time that I made the hack.
I'm not sure about how to set up unlocking the difficulties
but I was leaning towards having the extra 5 difficulties unlock
as you beat the current hardest level.

I do like hearing other peoples suggestions on stuff like this.
2 heads will always be better than 1 and 3 better than 2. ;D
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: niuus on July 02, 2019, 08:05:47 pm
It works, no problem. Tried (start + b) +a, got to bubble stage.

niuus, maybe make sure you press a + b, THEN (without releasing  a + b) press start?

@niuus
Did you get it to work yet?
Sorry for the late reply, finally returned to my computer today. So! It works! The test led me to the Bubble Stage. Does this patch include the optimization or can i just stack it against one of your previous patches? (Optimization only, or SA-1 Optimization)
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: slidelljohn on July 03, 2019, 12:17:19 pm
I made it to work on a non modified gradius 3 but I think it should work on the
fastrom hack I made. I don't have a working SA-1 Optimization, vitor does. I don't
think the patch is compatible with vitor's SA-1 Optimization but my source is
included with the patch so anyone could very easily make it compatible with any
gradius 3 hack.

I'm trying to submit the level selection patch with a updated readme but I'm having
a little bit of trouble submitting it. Hopefully I can get it figured out soon.

Just now submitted the patch.
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Zimgief on July 10, 2019, 03:47:36 am
Playing Gradius III on Gradius Collection for PSP, I tried Beginner Mode and noticed a really good idea for improving accessibility (so, for a patch separate from the fast-rom hack):

- each time you die, you do not lose ALL your power-ups, only the higher one, probably in this order : option (one at a time), double/laser, missile, speed (one at a time). Maybe losing options all at a time would be better (same for speed)
- plus, dying does not reset your position on the power-up bar. If you are on laser and die, you will still be on it, so if you lost it you can get it asap, or if you lost option, you can get to it faster.
 
If these changes are feasible, maybe you (or maybe Aaendi  or darkmoon2321), would be interested in implmenting them?
Title: Re: slidelljohn (a.k.a.[J]) snes projects page
Post by: Red X on July 10, 2019, 08:37:43 pm
Wow John, a few years pass and you go from graphics hacking to making mod chips, as well as advancing SNES Emulation in general. Well done. :thumbsup: