Language…
14 users online:  AmperSam, BabaYegha, codfish1002, deported, h.carrell, Heitor Porfirio,  idol,  Losoall, MegaSonic1999, NewPointless, saucebrune, Sweetdude, TheKazooBloccGosh, TheXander - Guests: 296 - Bots: 420
Users: 64,795 (2,374 active)
Latest user: mathew

Gopher Popcorn Stew Beta (BTSD replacement) [Updated!]

Add -ldl to the end of the g++ invocation.
<blm> zsnes users are the flatearthers of emulation
Oh, thanks Alcaro
Melba: The Peach Saga - basic concept of 'hub' world finished

The Shrine Policy - Always think you're better than me
OK, for the most part, it does its job very well. There's just one snag - it seems to be incompatible with FuSoYa's SMB3 Screen Scrolling Pipes.
Melba: The Peach Saga - basic concept of 'hub' world finished

The Shrine Policy - Always think you're better than me
Originally posted by shrine
OK, for the most part, it does its job very well. There's just one snag - it seems to be incompatible with FuSoYa's SMB3 Screen Scrolling Pipes.



This is a known problem. I may provide a work around soon.

Also stay tuned everybody I have an update planned for tonight or tomorrow :D!
Updated the release candidate.
Will this be compatible with SA-1 in the future?
Originally posted by Rykon-V73
Will this be compatible with SA-1 in the future?


Technically if one decided to edit main.asm it would be compatible -- however no blocks in the blocks section are compatible, its its a bit of a null point.

I currently only use loROM mapping, but that will support SA-1 ROMs up to 4MB. In the future I may add 8MB support.

Edit: also updated the exe to remove a dll requirement.
Edit2: forgot to include main.asm

Also for anybody needing it here is the source: http://p4plus2.pastebay.net/1386773
Originally posted by p4plus2
Technically if one decided to edit main.asm it would be compatible -- however no blocks in the blocks section are compatible, its its a bit of a null point.

Well, in my SA-1 hack I am using custom blocks. I'm using imamelia's Manual Custom Block Inserter and it's pretty easy to convert it to make it SA-1 compatible because you just have to change [$0000] into [$3000]. The currently blocks I'm using are "passable by ON/OFF" blocks. However, in your tool you have to change some more things beside of converting some addresses to make it compitable for SA-1.
Originally posted by MarioFanGamer659

Well, in my SA-1 hack I am using custom blocks. I'm using imamelia's Manual Custom Block Inserter and it's pretty easy to convert it to make it SA-1 compatible because you just have to change [$0000] into [$3000]. The currently blocks I'm using are "passable by ON/OFF" blocks. However, in your tool you have to change some more things beside of converting some addresses to make it compitable for SA-1.



Internally the tool uses a standard lorom address encoder/decoder, but the ROM allocation is handled by asar. Realistically speaking if main.asm was converted and the ROM is an SA-1 ROM asar should handle it just fine. I would need to make changes to support ROMs above 4MB, but for the moment not many hacks would need that at all. I don't want to implicitly support the SA- for user friendly reasons. While this may seem counterintuitive consider a new user who doesn't understand blocks need converted. They attempt using the SA-1 and then don't convert blocks and the next thing you know their ROM is breaking and they are confused.

Realistically, anybody who knows enough about the SA-1 to make solid use of it should be able to handle the needed tweaks themselves. Think of it as a feature preparation screening process :P.

If at some point additional support is needed from myself source wise to make SA-1 patching possible, I can add such support. But I am fairly confident at this point that the tool should natively support it with user tweaking at the ASM level.

I am curious what "more things" you're referring to.
Looking into block_clean.asm you can see, that addresses at +$80:0000 are cleaned which are the fast rom addresses. However, in SA-1 it isn't fast rom nor a mirror of addresses $80:xxxx-$EF:xxxx but they're own addresses (sorry, if it's hard to understandible but I don't know the words to explain it :P ).
Originally posted by MarioFanGamer659
you just have to change [$0000] into [$3000]


Just so you know, the game will crash if a sprite touches a custom block. The code gets run by SA-1 when sprites touch it, but the SNES' multiplication registers are used, so it crashes. I remember a fix exists in the SA-1 thread.
Originally posted by Sakuya Izayoi
Originally posted by MarioFanGamer659
you just have to change [$0000] into [$3000]


Just so you know, the game will crash if a sprite touches a custom block. The code gets run by SA-1 when sprites touch it, but the SNES' multiplication registers are used, so it crashes. I remember a fix exists in the SA-1 thread.

Which SNES registers are used? I've tested the patch by placing a custom block and a sprite (like a shell less Koopa) and it didn't chrashed. I'll port my hack into a new rom if GPS is SA-1 compatible.
Is this v1.34? Because if so, I should update that to include an SA-1-compatible version...or just forget about it because GPS kind of makes it obsolete anyway.

----------------

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Just giving a name suggestion:

Blockport. This tool imports custom blocks into a ROM, so I thought that would make sense.
Unless "GPS" isn't already an established abbreviation, how about calling it "GoPoSt"? You know, the first two letters of each word and all.

Which, if entirely different names are still an option at this point, gives me two ideas (neither of which are related to block insertion):
- Pogo Stick.
- StopGo.

#ab{>_>} #ab{<_<}


 
Originally posted by p4plus2
I don't want to implicitly support the SA- for user friendly reasons. While this may seem counterintuitive consider a new user who doesn't understand blocks need converted. They attempt using the SA-1 and then don't convert blocks and the next thing you know their ROM is breaking and they are confused.

You could get around that by doing something like this: require that all SA1-compatible blocks contain the following define:
Code
!AllowSA1 = 1

and, when inserting blocks into an SA-1 ROM, throw an error when trying to insert a block that doesn't set !AllowSA1 to a nonzero value. That way, no undefined behaviour would occur, and the user would know what went wrong.
GradientToolLevelMusic UtilitySM64 Clean ROM verifierHQX VirtualDub FilterImoSPC2 (Alpha)Music Section SPC PlayerEmbeddable SPC Player for SMWCYouTube EmbedderJSRomcleanJS Address ConverterLazyHDMA
Originally posted by ShadowFan-X
Originally posted by p4plus2
I don't want to implicitly support the SA- for user friendly reasons. While this may seem counterintuitive consider a new user who doesn't understand blocks need converted. They attempt using the SA-1 and then don't convert blocks and the next thing you know their ROM is breaking and they are confused.

You could get around that by doing something like this: require that all SA1-compatible blocks contain the following define:
Code
!AllowSA1 = 1

and, when inserting blocks into an SA-1 ROM, throw an error when trying to insert a block that doesn't set !AllowSA1 to a nonzero value. That way, no undefined behaviour would occur, and the user would know what went wrong.



Its not a *bad* solution, but since we have no intentions on this point in allowing pure SA-1 blocks, sprites, etc into our sections that would be a grand total of zero blocks.

The problem with supporting the SA-1 in this fashion is it requires massive amounts of content duplication. Even packaging the resources together still implicitly has massive amounts of duplication.

Solutions are still being discussed, but thats getting a bit off topic for this thread.
For some reason even though it says that all db $42 blocks in the database are compatible I'm getting weird errors from some of them.

For example, one of the framal blocks that I set to be solid from frames 2-5 says error: invalid number [CMB.b #$05+#$01] and a block I have set to break if a shell hits it says error: unknown command [JSR $028663]

These blocks work perfectly in BTSD but I'm having a huge amount of trouble getting them to upload in that, so I'm trying GPS instead. What am I doing wrong?
nothing, but those blocks expect xkas shenanigans while gps uses asar.

remove the # on the +#$01 for the CMP (i assume you typoed), and change the JSR to JSL (its a 24bit address, not 16bit)
Originally posted by Ladida
nothing, but those blocks expect xkas shenanigans while gps uses asar.

remove the # on the +#$01 for the CMP (i assume you typoed), and change the JSR to JSL (its a 24bit address, not 16bit)


I did that, and my code is currently as such:

Code
!Gl = $20		; $00 if it should be based 

on level exAnim, and $20 if it should be based on 

global exAnim
!Slot = $00		; exAnimation slot the code 

should be based on

!Min = $02		; First frame the block 

should be solid on
!Max = $05		; Last frame the block 

should be solid on

db $42
JMP M : JMP M : JMP M : JMP R : JMP R : JMP R : JMP 

R
JMP M : JMP M : JMP M

M:
LDA $7FC080+!Gl+!Slot	;\
CMP !Min		;|
BCC R			;| Check if it is a correct 

frame
CMP.b !Max$01	;|
BCS R			;/

LDY #$01		;\
LDA #$30		;| If yes, solidify the 

block
STA $1693		;/

R:
RTL


It's still not working, so I'm very confused.