 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| 0 users currently in SMW Hacking. |
| User | Post |
| BMF54123 Posts: 813/876 |
Okay, this is basically how Block Tool's SMW-side code works:
1. get block number 2. compare with table of installed custom blocks 3a. if found: get code address, run code, then go to step 4 3b. if not: increment index, go back to step 2 (repeat until end of table) 4. end code The root of the slowdown is in that loop between steps 2 and 3. That table is checked over and over again until either a match is found (the actual number of loops depends on where in the table the block number is located), or the end of the table is reached, at which point the code aborts and runs the default block behavior. This table grows in size every time a new block is added, adding another potential loop to the code. Now, add in an additional check for each on-screen sprite (double that if it's a layer 2 level), off-screen processing (Yoshi), buoyancy (if applicable), and then run the code regardless of which block type the sprite is touching...it's no wonder the poor old 65c816 can't keep up.  |
| HyperHacker Posts: 4554/5072 |
Originally posted by Someguy If you mean all 200-FFF, then yes, it'd likely be as slow as the original. However if you mean only F00-FFF, then it'll be much faster. The speedup comes from simply checking only 256 blocks for custom code instead of a whopping 3584, but obviously if you increase that amount, it'll slow down. |
| Sukasa Posts: 1966/2068 |
Ultimately the slowdown would be much less, as there is only 1/16th the number of blocks being checked. |
| Someguy Posts: 123/124 |
What happens if someone uses the full set of blocks eventually? Wouldn't that render it useless in a big hack that uses it, or is the coding fixed up in some better way anyway? |
| BMF54123 Posts: 801/876 |
Originally posted by Chaos ForceUnfortunately, no. The patch reduces slowdown by only processing block numbers within the reserved Map16 range (normally ALL blocks are processed, whether they have custom code or not, which is the root of the slowdown problem). You can have blocks with custom behavior outside this range, but their "acts like" setting must point to a block within the range. Originally posted by Stephan ReikenYes. |
| Stephan Reiken Posts: 192/200 |
Is that range the Map16 Hex?
And out of interest, how does this, in simple terms, change the Code to eliminate the problem? |
| Raccoon Sam Posts: 911/1040 |
Well, this will most likely be useless when BlockTool Omega comes out, but great job, anyway! |
| Chaos Force Posts: 1038/1056 |
Sweet. I was actually looking forward to BlockTool Omega, but this will work in the mean time. 
But since I'm lazy and don't feel like moving blocks around, can I keep the blocks I do have in its original place, and just start putting the new ones within the 0xF00 - 0xFFF range without any problems? |
| darkwitch Posts: 175/214 |
Im going to test this, and hope my hack doesn't blows up. *back ups the hack*
Yeah, you forgot to say that. Make Back ups of your hacks! |
| BMF54123 Posts: 800/876 |
Some of you might remember my attempt at fixing the Block Tool slowdown problem a few years ago. It required a customized build of the program (which ended up having a fatal glitch), couldn't really be modified, and was generally a mess. 
Now that jonwil's gone and updates to Block Tool have ceased, it's time for a more permanent solution to the problem (at least until Sukasa decides to finish Block Tool Omega ).
slowdown_fix.zip (thanks to FPI for "forcing" me to make this )
Unfortunately, this patch still requires that your custom blocks be inserted within a specific range (it's set to 0xF00-0xFFF by default), although the range can be expanded or shrunk at will. The patch can be applied to a hack at any stage of completion, as it doesn't interfere with any existing code, so those of you with hacks already in progress can still use it, provided you don't mind moving your custom blocks.
Enjoy! |
