18 users online: AntonioDosGames,  Burning Loaf, DaHitmenGuy,  Fernap, FrozenQuills, GrenCarret, HeitorPorfirio2006,  Hooded Edge, Ignacio Eduardo Aguilar, Jordan, KungFuFurby, MarioSonic4life, Pedda, PixlBitNick, schema_tuna, TheBourgyman, wye, Yoshivert99 - Guests: 81 - Bots: 240 Users: 55,723 (2,321 active)
Latest user: ponchotaco
Not logged in.
Posts by Ramon
Ramon's Profile - Posts by Ramon
Pages: « 1 229 30 31 32 »
All I've found on the forums so far is this thread:

Castle Destruction Cutscene ExGfx?

Sadly it isn't very informative (on top of possibly being out of date, being 9 years old). There's the ROM map entries about Layer 2 tilemaps, but no additional info on them.

So what I'm trying to do is change the Yoshi egg sprite to be something different in each sequence. Ideas I've had for accomplishing this:

-) Use a different ExGFX file for each sequence and point each sequence to a different ExGFX file.
-) Use the same ExGFX file for all sequences with different positions for each 'Yoshi egg', and make it use a different tile in each sequence.
(Which I'll be tackling depends on which would be more convenient code-wise.)

Though my main concern is whether it is actually possible to make the cutscenes use specific ExGFX files. Any ideas?
If my humble self may divulge complimentary information that shall hopefully aid the OP in his quest for custom sprite domination:

Check out this thread. Essentially, currently there're two 'standard' sprite tools, PIXI and GIEPY. However due to reasons listed in that thread GIEPY shall become the new standard tool. Therefore I suggest holding off on using PIXI and use GIEPY from the beginning.

Heed my words, I've solely used GIEPY in my hack and pretty much got every sprite from the sprite section I've used so far (over 100) to work.
For anyone interested, I've resorted to using uberASM to simply nil out the Bowser sign sprite slot as long as certain events have not passed. T'was much simpler than expected, I really only had to find the OW sprite table in the RAM map. The code looks as follows:

Code
init:

LDA $1F0E|!addr		; check whether event 67 passed
AND #$01
BNE .return
LDA $1F10|!addr		; check whether event 76 passed
AND #$02
BNE .return
STZ $0DF1|!addr		; remove LM sprite slot 9 aka Bowser sign sprite

.return
RTL


From my tests so far it does work as intended. On a new file the sprite will not be there, and on a file with event 67 activated the sign does appear. Have not tested whether it works when visiting the submap without either event, then completing one of the events and returning, but as long as OW sprites are reloaded on map change there shouldn't be a problem.

EDIT: Turns out the case I described above (visiting area, no sprite, then do one of the events, re-visit area) did not work as intended, as the sprite still didn't appear. So I made a little correction to the code:

Code
main:

LDA $1F0E|!addr		; check whether event 67 passed
AND #$01
BNE .sign
LDA $1F10|!addr		; check whether event 76 passed
AND #$02
BNE .sign
STZ $0DF1|!addr		; remove sprite slot 9 aka Bowser sign sprite
RTL

.sign
LDA #$08
STA $0DF1|!addr		; add sprite 8 to sprite slot 9 aka Bowser sign sprite
RTL


For now, it seems to be working fine. The part with removing the sprite slot could be omitted if one simply disables the sprite in LM, but for visual puroses in the editor I decided to simply leave it at that.
Ok. If I understood correctly the problem is that importing another set of BG map16 will overwrite some BG map16 you are already using.

First, when importing your second set, make sure you move them to an empty space (I recommend a new page altogether). After importing the map16, these tiles should still be selected/highlighted in the editor so you can still move them around before overwriting anything - click on them and keep holding the mouse button while pressing up/down arrow keys to move the selection around pages.

After you placed the tiles on a new map16 page, now you need to remap the tiles in the BACKGROUND EDITOR, not the map16 editor. Go to the level that uses the new background and use that remap function. Also make sure you have the correct ExGFX settings.
You need to enter a value there depending on how many pages from its original position you moved the new map16 tiles. For instance, if originally the tiles are on page 84, and you moved them to page 88, you'd need to enter 400 as the offset value. (This is assuming the map16 imported tiles start on the top of a page.)
Can you retrace all the exact steps you've made and post them here? (Especially important is the map16 page the original BG is imported at, and then where you moved it to.) There are a few places where things can go wrong, so I guess doing it step-by-step would be safest for now.
Hi,

I'm using the No Yoshi Entrance Edit patch, but I've come to realize that this patch doesn't work for level numbers greater or equal 130 and I cannot figure out why.

Here is a paste of the patch. The readme makes no special mention of specific level numbers.

And to be clear in advance, I'm sure about editing the correct lines and values in the data file that comes with it and that the patch has been applied correctly, as I've tested various different levels in multiple steps and it seems levels 130-136 still allow entering with Yoshi despite disabling it in the patch like in some other levels. I just extrapolated it to happen for all levels thereafter. The patch still works for levels 12C, 12D.

If you really want to look at the data file then you're welcome

EDIT: After a little more testing, it seems the problem lies with the way RAM address $1B9B (No Yoshi for next rooms flag) is handled. Does anyone know where to find the routine that actually removes Yoshi when this flag is set?
So I've made a little more progress on my quest. First of all, the Yoshi Egg used in the castle destruction cutscene is actually the one in GFX13 (Tile 1), not GFX22 (Tile 6, above speech bubble). I found the location where the Sprite GFX Settings for the cutscenes are loaded:

Code
...       
CODE_009471:        AE C6 13      LDX.W $13C6               ; Cutscene number 
CODE_009474:        A9 18         LDA.B #$18                ;\
CODE_009476:        8D 31 19      STA.W $1931               ;/ Set correct tileset
CODE_009479:        A9 14         LDA.B #$14                ;\ Set correct sprite GFX
CODE_00947B:        8D 2B 19      STA.W $192B               ;/
...
CODE_0094D7:        20 DA A9      JSR.W UploadSpriteGFX     ;\ 


The hijack at $009479 to make it use a custom GFX set based on the current cutscene number isn't a big feat.
Now, the next step would be to create custom Sprite GFX settings to include the ExGFX I need for the sequences. And this is where the problems arise...

As noted above, the code will branch to "UploadSpriteGFX", which I assume is a general routine used in various places in the code. That routine gets the value in $192B (index for sprite GFX settings as found in LM, plus some hidden ones) and 'uploads' the GFX based on that value. The vanilla SMW has predefined settings for 0-19. My plan would be to create a custom GFX list that will include/append the ExGFX files I need.

So I start working on a hijack for the beginning of the routine, and unsurprisingly, I've come across a problem pretty early that I can't figure out the cause of.

Here's the part of the original code I'm replacing:

Code
UploadSpriteGFX:    A9 80         LDA.B #$80                ; Decompression as well? 
CODE_00A9DC:        8D 15 21      STA.W $2115               ; VRAM transfer control port ; VRAM Address Increment Value
CODE_00A9DF:        A2 03         LDX.B #$03                
CODE_00A9E1:        AD 2B 19      LDA.W $192B               ; $192B = current sprite GFX list index 
CODE_00A9E4:        0A            ASL                       ; \ 
CODE_00A9E5:        0A            ASL                       ;  }4A -> Y 
CODE_00A9E6:        A8            TAY                       ; / 
CODE_00A9E7:        B9 C3 A8      LDA.W SPRITEGFXLIST,Y     ;  | 
CODE_00A9EA:        95 04         STA $04,X                 ;  | 
CODE_00A9EC:        C8            INY                       ;  | 
CODE_00A9ED:        CA            DEX                       ;  | 
CODE_00A9EE:        10 F7         BPL CODE_00A9E7           ; /


And this is my current hijack:

Code
org $00A9DA						; gfx upload
	autoclean JML customspritegfx
	;NOP #18					; not entirely necessary

freecode							
customspritegfx:
		LDA #$80
		STA $2115
		LDX #$03
		LDA $192B|!base2
		ASL #2
		TAY
.loop
		LDA NEW_SPRITEGFXLIST,Y
		STA $04,X
		INY
		DEX
		BPL .loop
		JML $00A9F0				; jump back to original code
		

		
NEW_SPRITEGFXLIST: 
		; original 0-19
		db $00,$01,$13,$02,$00,$01,$12,$03     ; Forest ; Castle 
		db $00,$01,$13,$05,$00,$01,$13,$04     ; Mushroom ; Underground 
		db $00,$01,$13,$06,$00,$01,$13,$09     ; Water ; Pokey 
		db $00,$01,$13,$04,$00,$01,$06,$11     ; Underground 2 ; Ghost House 
		db $00,$01,$13,$20,$00,$01,$13,$0F     ; Banzai Bill ; Yoshi's House 
		db $00,$01,$13,$23,$00,$01,$0D,$14     ; Dino-Rhino ; Switch Palace 
              	db $00,$01,$24,$0E,$00,$01,$0A,$22     ; Mechakoopa ; Wendy/Lemmy 
              	db $00,$01,$13,$0E,$00,$01,$13,$14     ; Ninji ; Unused 
              	db $00,$00,$00,$08,$10,$0F,$1C,$1D
              	db $00,$01,$24,$22,$00,$01,$25,$22
              	db $00,$22,$13,$2D,$00,$01,$0F,$22
              	db $00,$26,$2E,$22,$21,$0B,$25,$0A
              	db $00,$0D,$24,$22,$2C,$30,$2D,$0E
		; new 1A-1F
              	db $00,$00,$00,$08,$10,$0F,$1C,$1D
              	db $00,$01,$24,$22,$00,$01,$25,$22
		db $00,$22,$13,$2D,$00,$01,$0F,$22


I've essentially just taken over the code and replaced where to load the GFX index from.
Following problem occurs: After the Nintendo Presents logo, the intro music starts playing but the screen stays black.
Though after some testing I made following observations:
-) removing the loop (as in BPL .loop) makes the game work (albeit with partially garbeld graphics, as expected)
-) removing the loop but manually copy-pasting the looped section once will also already cause the problem, however it is not consistent which of the pasted opcodes crashes it
-) using X instead of Y (using PHX TYX and afterwards PLX) will make the title screen work, but still load a wrong sprite tileset, and the black screen problem occurs at the Welcome! screen when starting a new file

I feel like there's something fundamental I'm missing here. Any ideas? (I have a feeling it's got to do with the routine being loaded by JSR.)
Well, while I haven't 'fixed' or figured out the cause of the bug, I did find a workaround for the affected sprites. Setting the sprites' Tweaker byte to "process interaction with player every frame" (fourth Tweaker byte, bit 5) will make the boo block and the Reznor platforms behave properly. Either modify those in the ROM directly or replace the original sprites with their respective disassemblies with GIEPY. It seems to work fine so far.
As far as I'm concerned, a jump or JSL to ProcessInteract will mess it up because the routine will try to RTS out without being JSRed to, hence I haven't even tried it. Feel free to test it though; I won't be at my workstation for a couple more days.

If you didn't mean JML or JSL, then please clarify. I'm not especially well versed in assembly yet.
Ahh, thank you both, that brings me one step closer. The game will now load. And after some short testing, it seems to work as intended; I can now use custom GFX index settings!

Apart from adding new GFX index settings to the lot, the main problem will actually be how to point them to ExGFX files. I've figured their addresses can be read from LM's Super GFX Bypass dialogue, but how will the game be able to address/upload those? (In the sense that in vanilla SMW, $13 points to GFX13 and the game knows how to handle that gfx file somewhere in the code... but how would that work with ExGFX?)
Let's see... the title screen level was now different with garbled graphics, can't really tell which level it switched to. Also after moving forward one block Mario teleports to the actual title screen level, playable.

Apart from that, it doesn't seem it changed anything at first glance. Entering levels 135+ works normally, but still allows Yoshi.
I'll have a closer look later when I get back from uni to test it further, my only idea so far would be a patch conflict.
It seems you were right about that. I didn't realize I had a slightly modified version of EntranceEdit that actually caused the bug, so I simply replaced it with the original, added your hijack and voila, it seems to work fine so far!

Thank you for your help, this problem is solved for now. If I notice any weird behavior that I can trace back to this change, I'll post here again.
Yes, it's quite simple. If you're familiar with Map16, create your own tiles based on your custom tileset and then use LM's Direct Map16 access to insert them into your level.
Once again I'm having a similar problem. I found the part where the GFX indices point to their location in the ROM (Y holds the GFX index, aka GFXyy):

Code
CODE_00BA28:        8B            PHB                       ; preserve data bank ; Accum (8 bit) 
CODE_00BA29:        5A            PHY                       ; preserve Y (ExGFX file number)
CODE_00BA2A:        4B            PHK                       ; \ current bank
CODE_00BA2B:        AB            PLB                       ; / -> data bank
CODE_00BA2C:        B9 92 B9      LDA.W DATA_00B992,Y       ; \ 
CODE_00BA2F:        85 8A         STA $8A                   ;  | get address of 
CODE_00BA31:        B9 C4 B9      LDA.W DATA_00B9C4,Y       ;  | ExGFX file from
CODE_00BA34:        85 8B         STA $8B                   ;  | pointer tables and
CODE_00BA36:        B9 F6 B9      LDA.W DATA_00B9F6,Y       ;  | store to $8A-$8C
CODE_00BA39:        85 8C         STA $8C                   ; /
CODE_00BA3B:        A9 00         LDA.B #$00                ; \
CODE_00BA3D:        85 00         STA $00                   ;  | store destination
CODE_00BA3F:        A9 AD         LDA.B #$AD                ;  | for decompressed
CODE_00BA41:        85 01         STA $01                   ;  | ExGFX file (GFX
CODE_00BA43:        A9 7E         LDA.B #$7E                ;  | Buffer) to $00-$02
CODE_00BA45:        85 02         STA $02                   ; /
CODE_00BA47:        20 DE B8      JSR.W CODE_00B8DE         ; GFX decompression routine
CODE_00BA4A:        7A            PLY                       ; restore Y (ExGFX file number)
CODE_00BA4B:        AB            PLB                       ; restore data bank
Return00BA4C:       6B            RTL                       ; Return 


Naturally I want it to read from a custom table once again to be able to include ExGFX, so I do this hijack in accordance to the earlier one posted in this thread:

Code
org $00BA2C		; gfx upload (use custom table for pointers to ExGFX location in ROM)
	autoclean JML customgfxupload

freecode
customgfxupload:
		PHX
		TYX
		LDA.L POINTER_LO,X 
		STA $8A
		LDA.L POINTER_HI,X
		STA $8B
		LDA.L POINTER_BANK,X
		STA $8C
		PLX
		JML $00BA3B					; jump back to original code


...where currently the POINTER_## tables are exact copies of their original tables.

It works for the most part. Strangely, only specific graphics appear messed up:

Nintendo Presents screen (this one only adds white vertical lines for some reason)

Mario Start

Similar garbage for Game Over and Time Up (probably also Bonus Game). But everything else in the main game (from a short test run) is fine.

I'm stumped yet again why it would only affect these few instances. Any ideas?
This is an issue I've been encountering for a looong time already (probably already back when I first started SMW Hacking like 14 years ago) but could never be bothered to figure out. But at some point it's enough.



Placing custom Map16 tiles at the top left corner of the level in LM will mostly turn it into garbage. To be more exact, the tiles that appear are the Map16 page 0 equivalents of the tiles I placed in LM. Why does this happen and is there a quick way to fix it except using page 0 map16 tiles?

I'm assuming it's some sort of LM limitation, but it's one I've never found any explanation of anywhere.
Yeah, that makes sense. I actually believed it was a Lunar Magic or SMW limitation, since I'm sure I had this happen ages ago back when I hadn't actually used any sort of external resources. Guess I was wrong, since I now updated my GIEPY version to your fork and the problem disappeared. Thanks for the fast answer!
Soo... it turns out that the last hijack did (practically) nothing because Lunar Magic itself actually already hijacks the JSR to the part I am hijacking. Oh well :D

With this new information, of course I'm now interested in how exactly Lunar Magic handles GFX processing... I've got a disassembled $0FF900 from Telinc (ExGFX pointer handling for decompression), and while it helped me understand how I should be doing this, for some reason it still won't click.

1) First of all I checked LM's hijack at $00AA6C (UploadGFXFile). This one JSLs to $0FF160, which sadly is undocumented so I don't really know what LM is doing there.

2) LM's ExGFX decompression routine at $0FF900 takes a 16-bit value from the accumulator which is supposed to be the ExGFX number. That's fine and such, but the original code would just feed it an 8-bit value and it'd still work. If I try using values of 80 and above in the original GFX tables, the GFX will bug out, but original GFX values work as normal.

EDIT: FALSE ALARM! Using values >= $80 does actually work. For some reason it didn't when I tried it earlier; I took a fresh copy of my hack as a test ROM and then it worked. *shrug*

So for now I'm just trying to figure out how to change the palette of the Yoshi egg, but I think I'll manage. I'll edit it in once I find out.

EDIT2: Found it. Yoshi egg sprite uses OAM slot with $0380-$0383, so storing appropiate values to $0383 at the end of the castle destruction cutscene routine did the trick.
This means that you don't have enough ARAM space to cover the song echo. To fix it, either:

a) Reduce the echo's delay (first value after a $F1 command, usually somewhere at the start of a song). This is the recommended fix. AFAIK originals never exceed $04 or so, but in my experience values up to $0C are safe to use with default global songs

b) Remove some of the global songs to free up some ARAM space. Probably not practical in 99,9% of cases.
Originally posted by DPBOX
Never mind. Someone on Discord helped me out. This issue is solved now.


Could you maybe post the solution here for people who might have the same issue in the future and come across this thread?
Pages: « 1 229 30 31 32 »
Ramon's Profile - Posts by Ramon