| Name: | GPS V1.4.4 - Gopher Popcorn Stew |
| Authors: | TheBiob, p4plus2 |
| Added: | |
| Version History: | View |
| Operating System: | Windows, Mac OS X, Linux |
| Platforms: | SNES |
| Games: | SMW |
| Source Available: | Yes |
| Featured: | Essential |
| Website: | None |
| Description: | This tool, as the name clearly doesn't imply, is a block inserter designed to replace the dated BTSD. It is backwards compatible with BTSD and will upgrade your ROM when using the tool. The readme has full details on benefits. A GUI is not included in this version. If you want one download it from an older version of GPS. The GUI does not support the features of the current list and has not been kept up to date. Use the GUI at your own risk. Simple blocks, for example Mario-only, can be created with Blockreator. |
| Tags: | block blocktool btsd gps sa-1 |
| Comments: | 97 (jump to comments) |
| Rating: |
Download
338.76 KiB | 10,445 downloads
Comments (97)
I did try and compile the source myself (for Linux) but was unsuccessful, but it's entirely possible I did it wrong though as no instructions for compilation were provided.
yes i Know i close LM but it still dosent show up.
Tested with:
Windows 10 22H2 (OS Build 19045.2075)
Updates (dd/mm/yyyy):
no they aren't
Oh, then my format on the lower updates must've be different.
16/07/2022 (V1.4.4) (TheBiob) - GPS now prints asar warnings instead of ignoring them. - Fixed shared routine glitter.asm from crashing the game in case it runs out of smoke sprite slots. (Vitor Vilela) - Fixed custom routine paths not allowing spaces.The month and day numbers are swapped.
Updates (dd/mm/yyyy):
no they aren't
It works as fine as the last version, with the updates. So, accepted. However, as pointed by MarkAlarm and passing through the routines, fixed the %glitter() routine by adding a RTL at the end of the main loop in order to avoid a minor extended sprite overwrite.
The whole issue with fullsa1 ROMs is resolved. The minor edits done are in perfect order, so, pending on the last rejection log, I can safely approve this. Nice work, TheBiob.
Not entirely sure what you mean, just putting a macro label in a block file doesn't seem to do anything for me. I can take a look at it if you provide the steps required to reproduce it.
It even doesnt work with the newest Wine version.
Can somebody fix this?
I put it on my todo list so it'll be fixed whenever I stop being lazy and actually work on the update again. Thanks for reporting.
Also, this update moves the map16 feature from spawn_bounce_sprite from $02 to $03 which might break resources that use it.
Apparently the changes were already edited in gps 1.4.0 without me knowing so I'll leave them for now, and if it gets accepted like this I'll keep it that way.
LDA #$02|!bank8 STA $9CI'm not sure if this change is worth a new update so I'll leave it here for now.
I find nothing wrong with BTSD. This one just makes it more complicated to use.
I hate that it removes BTSD hijacks, even more pain in the ass to use.
This is so that ASM block (or any other ASM that changes tiles, such as uberasm reusing the change block to do stuff blocks can't.) developers know about the block change routine.
Help anyone?
I was more talking about something like
Can't really test right now but I don't see a reason why this wouldn't work.
The problem is the bounce block direction, not the cape.
Do you have a better way of fixing the bounce block directions? Be my guest... Go download it Here...
Why is GPS the cause of this problem? And what would adding another offset do better than checking if the player is to the left or to the right of the center of the block?
A good example is the "Side Turn Blocks/Wood Blocks" that I am finished with almost, the problem is the spin attack/cape glitches the block sprite!
- New map16 area (Pages 40+) now supported
- Uses asar 1.50
- Changes to the list format (Old format still applies, just new features which might make stuff easier to organize)
- Updated a couple of routines
- Added a few routines
- Fixed shared subroutines (They weren't exactly broken but it could break if you used too many shared subroutines. Don't think anyone ever ran into this problem though)
See Changes.txt and README.txt for a more detailed description on what changed and how to use the new features.
That is another reason why we moved to an open source alternative.
If FuSoYa did the same thing, we probably would analyze the code inserted by the program and make our own level (and overworld) editor (thanks for authorizing us to distribute it so we can keep testing its code in the ROM).
As everyone knows, if the author of the closed software is dead, the software will stop updating for good, unless if the author hires another person to be the next generation in line to support it.
I have to agree with LX5, you basically have limits on programming your blocks with this broken software:
-its counter-intuitive with the offsets (like why -1 on the offsets?), you can't know what code and hijacks it used due to being "proprietary-secret" unless you check the code that was mentioned in fusoya's readme about custom map16 tiles.
-it requires a .net framework (most modern pcs now days have them pre-installed), when its possible to program your game to have them without it
-It uses xkas to insert code into your ROM, yes XKAS. As in, the outdated patching program with numerous bugs and glitches combine with the software itself not having an ability to even set the freespace. We are now in the asar age.
-Everyone know this: inserting lots of blocks take FOREVER, almost every half-second is 1 block successfully inserted to your ROM. Imagine if you have 50+ custom blocks. I could possibly watch youtube and it gets done when the video is over.
-Each time you insert new blocks, its not as simple as adding a list like most modern tools here, you have to go on the menubar, hit "add new block", and fill out the information, ONE AT A TIME, PER BLOCK. This could make block packs that must be used together in levels TEDIOUS to insert, especially my screen scrolling pipes, just count blocks where in there. With GPS, you can copy the provided list in such packs and insert them all at once, which this will win the race in terms of inserting them into your ROM (combine this with how slow it insert blocks). Even romi's spritetool uses the list system, and I appreciate the invention of that.
-Finding errors is a guessing game when looking back at your code, because the way it reports is that it uses a pop-up window and doesn't say why the error happened. So testing is also tedious.
GPS does not have any of those issues and have better features, my most favorite is the %callRoutine() when you reuse the same code without having duplicate codes in your ROM (especially the long map16 change routine).
Nope.
- Its GUI wasn't good either, it was horrible.
- Databases were horrible to work with. Slower as a snail to add blocks. They were even worse with collaborative projects.
- Developing for it was bad too; it wasn't good at reporting errors.
- It doesn't support WallRun offsets.
- It's slow at inserting blocks.
Faster insertion speed, ROM space saving, merging block and Map16 list, discription from blocks and Asar (at least for coders) is worse for you?
Actually... Well, you actually have got a point there. But it is possible to do some workaround. Of course, one have to ask p4 why he did that.
What kind of errors?
This tool will give errors for no reason, you can't replace anything on 00 or 01, and has a broken GUI.
Did I mention BTSD also has NONE of these issues and has always worked fine for me?
I'm trying to simply insert blocks and I'm getting errors for no reason. Ridiculous. Would rate 0 if I could.
When I try to insert the ROM, I get this error message: main.asm:26: error: A bank border was crossed somewhere prior to this point. [org $06F67B]
I don't know what a bank border is. Can someone please help?
200:130 ConveyorBlockRight.asm
210:130 BreakableBelowBlock.asm
Then when I inserted them to My ROM, I checked the Map16 Page 2, This happened, Does anyone know how to fix this? https://i.gyazo.com/1dae78006be7669ad2239784e205ca68.mp4
Either way, I uploaded it here
And sorry in case of it being my fault. Though I don't even have a zip file which doesn't contain the exe and I don't delete stuff I upload (Usually anyway)
Okay, I'm done modifying gpsEverything works *in theory* but I'm unable to compile the source code so I can't test it.
If anyone that is able to compile the source would do that then I could test if what I've written works. (I don't expect it to break but you never know.)
Edit: Nvm got it compiled myself. Will test it and then submit.
Changes I made:
== GPS ==
- The block pointers now point to the db at the start of the block instead of the first JMP like they used to
- Now allows db $37 as a valid header
- Changed "<file> lacks a db $42 header" message to "<file> lacks a db $42 or db $37 header"
== main.asm ==
- Runs the "wallrun" offset only if it contains a db $37 header. Otherwise returns without running that offset
Yes... and no. Depends on what you mean.
The number that determines what offset group it uses is decided by the programmer. The programmer can choose any number though.
I looked at gps' source and it shouldn't be difficult to make gps see db $37 as a valid header.
You'd simply have to add checks to determine wether or not to run the offset
I could do that but that'll have to wait until tomorrow.
That's just an example ($37 because of 1337).
So you would put db $37 at the top and the block would be treated as having a wallrun offset, but if it doesn't have that then it will be treated as not having one, just like how BTSD used to treat the topcorner offset.
If you could change it to that, that would be really great because then people could download wallrun specific blocks from the section and have them just work without having to adjust ALL other blocks.
Because LM installs ASM hacks which are required for this to work. If you don't save first LM never installs these codes. LM also expands the rom which is usually required since there isn't much space for custom stuff in an unedited rom.
- Added SA-1 support to both tool and base .asm files.
- Added a couple of standard defines in defines.asm, which gets assembled together every single block.
- Made the shared routines use the FastROM area on non-SA-1 ROMs.
- Added glitter.asm to the shared routines.
- Added spawn_bounce_sprite.asm to the shared routines.
- Converted all shared routines to hybrid (SA-1) support.
- Updated Asar core (asar.dll).
- Fixed crash when using too many blocks, due an asar.dll bug.
- Applied https://paste.ee/p/UIpMm (by Alcaro) to GPS GUI.
- Recompiled GPS GUI to fix a compilation issue which made it throw error when trying to run GPS console.
The version number has been raised to 1.2.0.
It's probably the sa-1 thing judging by the tags
Edit The error Give me is that.
block_boilerplate.asm:4: error: Unknown command. [insrc Blocks/Green Koopa Block.asm]
'.' is not recognized as an internal or external command, operable program or batch file.
Not block tool super deluxe
Nearly all programs treat it as a "this is not a filename, I'm overriding your default settings" flag, but only if it's at the start of the word; if any program whines about - as non-first character, that program is buggy.
link