 |
| 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. |
| Acmlm's Board - I3 Archive - SMW Hacking - RELEASE: Block Tool Slowdown Fix (take 2) |
New poll |  |  |
| Add to favorites | Next newer thread | Next older thread |
| User | Post | ||
BMF54123                    Since: 11-18-05 From: MOOGLES Last post: 6287 days Last view: 6286 days |
| ||
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! (edited by BMF the Snowman on 12-27-06 08:38 AM) |
|||
darkwitch Red Cheep-cheep Since: 10-16-06 From: Puerto Rico Last post: 6286 days Last view: 6286 days |
| ||
| 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! |
|||
|
Chaos Force Just drifting by... Since: 11-17-05 Last post: 6291 days Last view: 6287 days |
| ||
| 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? |
|||
Raccoon Sam Boomerang Brother Custom Title  Since: 11-20-05 From: Correct Last post: 6287 days Last view: 6286 days |
| ||
| Well, this will most likely be useless when BlockTool Omega comes out, but great job, anyway! | |||
Stephan Reiken Blipper  Since: 11-17-05 Last post: 6294 days Last view: 6287 days |
| ||
| Is that range the Map16 Hex?
And out of interest, how does this, in simple terms, change the Code to eliminate the problem? |
|||
|
BMF54123 Since: 11-18-05 From: MOOGLES Last post: 6287 days Last view: 6286 days |
| ||
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. |
|||
Someguy Tooky Since: 11-17-05 From: West Virginia-USA Last post: 6292 days Last view: 6286 days |
| ||
| 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? | |||
Sukasa Birdo Not quite as active as before. Xkeeper supporter Xk > ||bass I IP Banned myself! Twice!  Since: 11-17-05 From: Somewhere over there Last post: 6287 days Last view: 6286 days |
| ||
| Ultimately the slowdown would be much less, as there is only 1/16th the number of blocks being checked. | |||
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6287 days Last view: 6287 days |
| ||
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. |
|||
|
BMF54123 Since: 11-18-05 From: MOOGLES Last post: 6287 days Last view: 6286 days |
| ||
| 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. |
| Add to favorites | Next newer thread | Next older thread |
| Acmlm's Board - I3 Archive - SMW Hacking - RELEASE: Block Tool Slowdown Fix (take 2) |
| |
