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

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - slidelljohn

Pages: 1 2 3 4 5 [6] 7 8 9 10 11 ... 15
101
Don't press save gfx that just saves the graphics not compressed to a file. Press save as to
compress the graphics. I could possibly be using a different rom version but idk. Im using
bsnes plus v04.

I looked at it and the editor seems like its working correctly. The reason
why #27 is causing the error for you is because you are probably not
putting the new compressed data in empty space and you are writing over
#27 compressed data. You cant put the compressed data in the same spot
as the original data unless the new compressed data is smaller than
the original data. The graphics pointer to graphics #0 is $1B:CB2C
and for #27 is $1B:CBE9. This image shows the graphics #0 highlighted
and #27 is the next graphics after #00.
http://www.mediafire.com/view/h5jc1ud8k3b41uj/persia2.png

102
Everything that I'm able to edit seems like its working correctly.
Sprite #0 and sprite #14 every edit shows perfect in game. After
you make your edit try to load those edited graphics in the editor
and see if it shows that they were edited correctly instead of doing
the in game test. If the edited graphics don't show up some what correctly
then you may be putting the wrong offset for the pointer. If it does show
up correctly in the editor and messed up in game then the sprites could
be doing something like what the backgrounds are doing. I tried using the
save states that you sent me but I couldn't get them to load.

Here is a image showing sprite #473 edited and loaded as sprite #14 in the editor
and bsnes plus. The hex editor in blue shows the location of the new graphics and
the green box shows the new pointer to load the compressed graphics. Its a large
image so the image is a download.
http://www.mediafire.com/view/ke9r2nsnwehli9d/persia.png

103
I'm not really sure why it was doing that because that was the last thing that
I had to fix for it to work correctly. It wasn't even working on my end anymore.
I think I was able to fix it so try this one out and let me know.
http://www.mediafire.com/file/jasifm4w8214202/New_SNES_Paint.zip/file

A new file called window2 gets created but that is just the image in the viewer
converted to snes 4bpp data. That file is just to make sure the conversion to
snes 4bpp is correct.

Here is another one to test. I did as many tests as I could. Hopefully its 100% working now.
http://www.mediafire.com/file/nnag9hk3tboeiqi/SNES_Paint_test_%25231.zip/file



104
Personal Projects / Re: UltraNet SNES Network Adapter Preview
« on: June 09, 2019, 12:42:34 am »
Is that the one that has multiple files used? I could possibly create a multi file patching system if that would help for patching f-zero with multiple files. I don’t really like metal warriors and I don’t know anything about it so it would be better for me to test the f-zero one if I can.

105
Personal Projects / Re: UltraNet SNES Network Adapter Preview
« on: June 08, 2019, 01:37:43 am »
I could test out f-zero. Is the f-zero hack that you made for it working without any bugs?

106
I think I have the sprite compression algorithm working correctly.
http://www.mediafire.com/file/vlnd83qmnh6fj77/SNES_Paint_compress.rar/file

This algorithm should produce the same exact bytes as the original compressor that Konami used.

You can edit and save the compressed sprite data only to a file called compressed_gfx_bytes.bin.
You cant save it to the rom yet in the editor but you can test out the compression by using a hex
editor to store the compressed data to the rom. If you load the 1st sprite the F8000 next to the
decompress push button is the location of the pointer for the compressed graphics that were loaded
from the rom. The next hex number to the right of that is the location of the compressed graphics
that were loaded from the rom. The save as button is the button that will compress the graphics in
the canvas to the file called compressed_gfx_bytes.bin. When you compress these graphics they use
the same 3 byte header as the graphics that were loaded from the rom. byte 1, byte 2 and byte 3 is
the bytes for the header. byte 3 = size 1 and size 2. size 1 and size 2 is multiplied together to
get the number of 16 x 16 tiles to decompress. Let me know if any of these don't compress correctly.
Its going to take more time before the bg tiles and the palettes are ready but sooner or later these
will be editable as well.

107
Personal Projects / Re: UltraNet SNES Network Adapter Preview
« on: May 30, 2019, 12:32:59 am »
This is awesome! I want one so I can make some stuff for it. :woot!:

108
Personal Projects / Re: slidelljohn (a.k.a.[J]) snes projects page
« 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

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

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.

109
Personal Projects / Re: slidelljohn (a.k.a.[J]) snes projects page
« 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

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



110
Personal Projects / Re: slidelljohn (a.k.a.[J]) snes projects page
« 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

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.

111
Personal Projects / Re: slidelljohn (a.k.a.[J]) snes projects page
« 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).


@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.

112
ROM Hacking Discussion / Re: Widescreen SNES needs hackers
« on: May 18, 2019, 02:10:40 pm »
@DerKoun
We need a debugger that supports this feature.
Is there a debugger? If not, I recommend trying to
add this feature to the bsnes plus vram expand
branch that added support for the 128kb of vram.
With double the screen and double the vram we
could make some really nice looking hacks. I
already created a fully working 128kb vram hack
for mmx1 and I would like to add the extra screen
space to it to see how it plays.

Is it possible for this to work on original hardware?

113
Personal Projects / Re: slidelljohn (a.k.a.[J]) snes projects page
« 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

114
Can you get me a savestate for when those graphics appear in game? Ether giegers snes or bsnes plus savestate would do. I never played the game before so I don’t know where to find the gfx when playing it. I need to make sure there isn’t another compression algorithm that is used for the gfx.

With QT I recommend following some of the tutorials on YouTube to help get you familiar with how the program works and when I get some free time I can show you how to write some code for editing snes games.

115
The palettes start at the princes I just need to set the pointer at the beginning. Gfx that have 0x0000 as thier 1st 2 bytes in the 3 byte header and the gfx # around 1200-1400 started to display messed up gfx. Are the platforms and traps gfx in the 1200-1400 range of the pointers?

I’m not 100% sure if this is the QT that I have but I think it is.
http://download.qt.io/archive/qt/5.6/5.6.3/qt-opensource-windows-x86-mingw492-5.6.3.exe

116
Personal Projects / Re: slidelljohn (a.k.a.[J]) snes projects page
« 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.

117
I have a new update:
https://www.mediafire.com/file/93cg9kcifv4kiwk/SNES_Paint2.zip/file

I still need to do a few more tests before I add in the compression. Might take
a few more days. Install QT if you want to learn some coding. I'm currently using
QT 5.6.3 with mingw but there are newer versions.

118
Personal Projects / Re: slidelljohn (a.k.a.[J]) snes projects page
« 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.

119
Personal Projects / Re: slidelljohn (a.k.a.[J]) snes projects page
« 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.

120
Personal Projects / Re: slidelljohn (a.k.a.[J]) snes projects page
« 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.

Pages: 1 2 3 4 5 [6] 7 8 9 10 11 ... 15