 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
1 user currently in Super Mario World hacking:  labmaster |
| Acmlm's Board - I2 Archive - Super Mario World hacking - rejoice! cure smw slowdowns. patch inside |
 |  |  |
| Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
| User | Post | ||
d4s Panser Level: 29  Posts: 142/325 EXP: 142151 For next: 5734 Since: 03-23-04 Since last post: 13 days Last activity: 1 day |
| ||
| i just created a patch that gets rid of (almost) all slowdown problems within smw. i did this by converting lots of time-consuming routines to fastrom. this results in a 33% execution speed increase. you can now put 4 and more charging chucks onscreen without any slowdowns. i wonder why fusoya didnt implement this in lunar magic. covered are nmi, startup, scrolling, sprite and enemy routines. the game now runs much more smoother with snes9x, snesgt, super sleuth and on a real snes unit. one drawback is that it doesnt run faster with zsnes. im still investigating, but i assume the problem lies within zsnes, cause it works fine everywhere else. maybe zsnes ties an internal hack to smw like it does with many other roms. i tried to maintain compatiblity with both native super mario world and lunar magic modified roms, so you can use this patch on both the original rom and released patches. if a patched rom uses asm hacks, its quite possible that the game will crash. if you want to use this fastrom patch in your own hack, i suggest you apply my fastrom patch to a fresh smw rom first, then edit it with lunar magic. however, this is not a final patch and i need your help to test it. if you experience crashes with this patch using the unmodified smw rom or slowdowns using either the original or a hacked rom, please report and attach savestates before the problem occurs. mind you, you will only see a difference in places where the game would slow down normally and you will not see any differences in zsnes, so use snes9x.i hope i can fix that soon. please apply to a rom with header only! heres the patch: http://coolboard.co.funpic.de/other.php (edited by d4s on 03-23-05 06:31 AM) (edited by d4s on 03-23-05 06:36 AM) |
|||
blackhole89 LOLSEALS Moderator of ROM hacking EmuNET IRC network admin Head GM of TwilightRO Level: 47  Posts: 596/971 EXP: 739208 For next: 26995 Since: 03-15-04 From: Dresden/Germany Since last post: 14 hours Last activity: 12 hours |
| ||
SWEET.  I have to try this out right when I get home. The only problem I see with that is that BMF's palette controlled asm hack caller system hooks to the NMI. I am more or less sure it won't work anymore with this.  Anyway, how exactly does fastrom work? I just -need- to know... |
|||
|
d4s Panser Level: 29 Posts: 143/325 EXP: 142151 For next: 5734 Since: 03-23-04 Since last post: 13 days Last activity: 1 day |
| ||
| well. fastrom is pretty easy, actually. its just much work if you add fastrom execution to a rom you dont have the sourcecode of, cause you have to modify all the jsl and jmls. you just have to set bit $01 of register $420d to enable fastrom and execute your code in the upper rom mirror.(bank $80 onwards instead of bank $00 for lorom, hirom banks $c0 onwards are fastrom aswell) so what i did was modify lots of jsl(about 100. not all, because that would be too much work and would break either lc or native smw roms, of course. maybe i'll release seperate patches later) to jump to the upper lorom mirror instead. i also patched some (only 2 or 3 related to sprite stuff) data loading routines to load from the upper mirror aswell, plus the nmi and startup routine. thankfully, most of smws routines use the current program bank as data bank most of the time, so i didnt have to interfere there. to maintain maximum compatiblity, i didnt hook into the nmi routine, but modified the nmi vector to execute my code before jumping to the original nmi routine, so if bmf patched the nmi routine, his palette stuff should still work fine. ive tested it with 3 or 4 different hacks and everything worked flawless. (edited by d4s on 03-23-05 07:24 AM) (edited by d4s on 03-23-05 07:27 AM) |
|||
|
blackhole89 LOLSEALS Moderator of ROM hacking EmuNET IRC network admin Head GM of TwilightRO Level: 47 Posts: 597/971 EXP: 739208 For next: 26995 Since: 03-15-04 From: Dresden/Germany Since last post: 14 hours Last activity: 12 hours |
| ||
| Uh... no. It didn't crash or anything, but it didn't execute BMF's code either. I guess the only thing I can do with that is upgrading my RPG code (copying about 100 tiles to VRAM using a loop every frame because of inefficient coding and my general inability to find a free DMA channel  ) with this. |
|||
HabsoluteFate Red Paratroopa Level: 23  Posts: 119/179 EXP: 58525 For next: 9198 Since: 03-15-04 From: Ottawa, Ontario, Canada Since last post: 10 days Last activity: 2 days |
| ||
| This sounds pretty cool and could help a lot....hacks can be more complex now without as much worries of slowdowns... I'll check it out when i'm home later! |
|||
gnkkwinrrul Dry Bones Level: 39  Posts: 483/647 EXP: 402054 For next: 2717 Since: 03-15-04 From: LYKEOMGIMFROMSOMEPLACE???? Since last post: 81 days Last activity: 40 days |
| ||
Sweetness  I could use this in my hack, it slows down. Alot  |
|||
|
d4s Panser Level: 29 Posts: 144/325 EXP: 142151 For next: 5734 Since: 03-23-04 Since last post: 13 days Last activity: 1 day |
| ||
Originally posted by gnkkwinrrul yeah. ~_= i usually dont play smw hacks, so i didnt know about the issue until recently. in the first place, i just wanted to help out ice man with his smw hack, but after i watched his intro wich had like 4 major slowdowns in about 10 seconds, i figured that the speed had to be fixed first.  blackhole: you know that you arent allowed to write to vram outside vblank, right? it works on emus, but doing so on a real snes crashes the system. in fact, it crashes the snes so hard that even pressing the reset switch doesnt recover it. (seems to depend on the register you are writing to, though.) opposed to hdma transfers, you can use the same channel to do several sequential dma transfers, did you know that? actually, smw does the very same thing, see here: $00/A355 BD 85 0D LDA $0D85,x[$00:0D85] A:6000 X:0000 Y:007E P:envmXdIZc $00/A358 8D 22 43 STA $4322 [$00:4322] A:0000 X:0000 Y:007E P:envmXdIZc $00/A35B A9 40 00 LDA #$0040 A:0000 X:0000 Y:007E P:envmXdIZc $00/A35E 8D 25 43 STA $4325 [$00:4325] A:0040 X:0000 Y:007E P:envmXdIzc $00/A361 A0 04 LDY #$04 A:0040 X:0000 Y:007E P:envmXdIzc $00/A363 8C 0B 42 STY $420B [$00:420B] A:0040 X:0000 Y:0004 P:envmXdIzc $00/A366 E8 INX A:0040 X:0000 Y:0004 P:envmXdIzc $00/A367 E8 INX A:0040 X:0001 Y:0004 P:envmXdIzc $00/A368 EC 84 0D CPX $0D84 [$00:0D84] A:0040 X:0002 Y:0004 P:envmXdIzc $00/A36B 90 E8 BCC $E8 [$A355] A:0040 X:0002 Y:0004 P:envmXdIzC that means you dont have to find a free dma channel, just use the same ones smw already occupies. of course youd have to temporally store your transfer parameters in some variables and then copy them to the dma regs. or am i missing the point here? but seriously, copying tiles to vram using a loop is an absolute no-no, it wastes way too much time, thats what dma is for. and time is pretty much the only thing you dont have when planning your nmi-routine. three weeks ago, i coded an intro with a primitive event handler and all the fancy stuff from scratch and tried to dma about 80000 bytes to vram each vblank(all tilemaps, oam table and palette) first, this was too much already. i then modified this so the dma transfers would only occur if the data to be transferred had actually changed.(with simple flags) i think you should do that, too, cause a textbox isnt the kind of stuff that changes shape every frame, isnt it? [edit] guys, please, its nice to hear you plan to include this in your next hack, but i need some more feedback to improve the patch. does it work fine for you/crash? do you still experience slowndowns somewhere with this patch? if yes, where? (edited by d4s on 03-23-05 01:32 PM) (edited by d4s on 03-23-05 01:40 PM) (edited by d4s on 03-23-05 01:42 PM) (edited by d4s on 03-23-05 01:42 PM) (edited by d4s on 03-23-05 01:43 PM) |
|||
|
Omega45889 Panser Level: 30  Posts: 237/335 EXP: 148978 For next: 16891 Since: 03-22-04 From: Vancouver Canada Since last post: 5 days Last activity: 6 hours |
| ||
| Could this be done for other games? Like, say, Zelda 3? I ask cause i am having a little lag trouble with some boss fights in Dark Prophecy where there is slowdown. Its not game crushing, but it would be nice to be lag free. Please PM me, or let me know somehow. Great find. |
|||
|
blackhole89 LOLSEALS Moderator of ROM hacking EmuNET IRC network admin Head GM of TwilightRO Level: 47 Posts: 598/971 EXP: 739208 For next: 26995 Since: 03-15-04 From: Dresden/Germany Since last post: 14 hours Last activity: 12 hours |
| ||
| hmm... do DMA transfers occur on vblank or right at the moment you write the control data to the registers, in other words, do I have to wait for vblank to start the transfer? I am not experienced with plain DMA, sadly And, if I want to convert the whole ROM to fastrom, is it enough to add 80h to the bank number of all 24bit jumps (using, say, a substition program which knows the length of 65c816 instructions) and hook a routine which writes $01 to $420D to the NMI or whatever is executed at the ROM's start (NMI isn't optimal, I know, since it executes every frame, though)? |
|||
|
d4s Panser Level: 29 Posts: 145/325 EXP: 142151 For next: 5734 Since: 03-23-04 Since last post: 13 days Last activity: 1 day |
| ||
Originally posted by blackhole89 dma transfers occur right after youve written the appropriate bit to $420b. you can chain many transfers using the same channel, just execute them using 420b before you set up another, of course. basically, you could try to make a program that automatically patches all jsls/jmls, but the problem here is that you really only have one single byte to detect a jsl, $22. if the rom isnt bigger than 16 lorom banks aka 4mbit, then you'll also know that the high nibble of the third byte after the $22 is 0, but youre out of luck otherwise. if your program just ORs every third byte after a $22 with $80, you'll most likely mess up more than youll fix. or do you have something else in mind? omega: dude, this aint a find, this is pure asmz0r l3333333333eeeeeeee33333333tness. >  seriously, this can be done with every other slowrom game (zelda 3 and rtype came to my mind aswell), its just a tremendous amount of work. (edited by d4s on 03-23-05 04:02 PM) |
|||
|
HyperLamer <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 3873/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
NICE. Does this fix the slow custom block code too? (Particularly with layer 3 water enabled.  )I dunno about making a program to change all the jumps though. It'd have to be able to tell code from data. |
|||
|
blackhole89 LOLSEALS Moderator of ROM hacking EmuNET IRC network admin Head GM of TwilightRO Level: 47 Posts: 600/971 EXP: 739208 For next: 26995 Since: 03-15-04 From: Dresden/Germany Since last post: 14 hours Last activity: 12 hours |
| ||
Originally posted by blackhole89 What I meant by that is some sort of internal "disassemble, modify 24 bit jumps, reassemble" stuff. Hmm... so there isn't any delay with the DMA transfers? That means I have to spend one frame (in the worst case) waiting for vblank whenever uploading message box data to the screen? (ok, one frame isn't -that- bad, but I am not quite sure whether this might mess up with the original SMW code) |
|||
|
d4s Panser Level: 29 Posts: 146/325 EXP: 142151 For next: 5734 Since: 03-23-04 Since last post: 13 days Last activity: 1 day |
| ||
Originally posted by HyperHacker thanks =) thats what i want you to try out. seriously, guys: i have NO idea what smw hacks with what features are already out there, so youll have to test that yourself. all i can tell you is that i only modified the jumps of the original smw rom, thatd mean that custom block remains untouched. its quite likely that it will be faster than before, however, because everything else is faster now and that leaves more time for other code to execute. Originally posted by HyperHacker oh ok, im sure this is very well possible. a program that reads out all jsls basing on a tracelog would be very cool. could you do this? that'd rock for sure. =) [edit] just tried out bmfs odyssey and wanted to play it on a snes, but no such luck. looks like his nmi routine is way too long and reaches into the next frame. his normal patch crashes right away on the title screen. what i found interesting is that odyssey works fine when my fastrom patch is applied to it afterwards. however, it crashes when you try to collect a coin. its a shame hacks are designed for emulators and fail to work on the actual system. oh well... (edited by d4s on 03-23-05 04:24 PM) (edited by d4s on 03-24-05 03:27 AM) |
| Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
| Acmlm's Board - I2 Archive - Super Mario World hacking - rejoice! cure smw slowdowns. patch inside |
| | |
