Banner
Views: 845,441,663
Time:
30 users online:  bebn legg, CalHal, Carld923, Centipede, Dippy, DJSpleef, Dobosco, Earthling, Everest, FrozenQuills, Green Jerry, kebabchilla,  KevinM, Kezcade, Knight of Time, Maruhai,  Nameless, niko,  Ninja Boy, Pedroalone, Reese_Pufferson, savagecabbage, SLBros., Sping bot,  Tahixham,  Teows, toad64, Valkyria, xamexer, YamiMario - Guests: 68 - Bots: 86 Users: 46,497 (2,735 active)
Latest: peepee123
Tip: Use the Iggy/Larry Battle Tools to edit Iggy/Larry's platform.Not logged in.
Minor Releases
Forum Index - SMW Hacking - Resource & Tool Releases - Minor Releases
Pages: « 1 2 3 4 »
This change actually throws everything off now with both layers. Positioning moves down 1 tile in a 32x32 change and my ? blocks change to garbage tiles now, although they're custom I don't imagine that'd really mess things too much considering everything else works fine with the original code, just not with layer 2.
Huh. I tested it before posting, and it worked just fine with blocks on a moving Layer 2. You're not using an old version of Lunar Magic or something, are you?
Originally posted by imamelia
Huh. I tested it before posting, and it worked just fine with blocks on a moving Layer 2. You're not using an old version of Lunar Magic or something, are you?


I'm definitely using the latest version. The problem I mentioned with blocks becoming garbage tiles also happens with the original blocks. Perhaps its on my side since I have SA-1. If something is off, I believe it can only be this part of the code since I haven't seen a direct page change done like this.

Code
RunVRAMUploadLarge:
	PHB
	PEA $7F7F
	PLB
	PLB
	REP #$20
	STZ $00
	LDX #$0000
.Loop
	LDA $B80A,x
	BEQ .NoDelay
	DEC $B80A,x
	LDY $00
	LDA $B800,x
	STA $B800,y
	LDA $B802,x
	STA $B802,y
	LDA $B804,x
	STA $B804,y
	LDA $B806,x
	STA $B806,y
	LDA $B808,x
	STA $B808,y
	LDA $B80A,x
	STA $B80A,y
	LDA $00
	CLC
	ADC #$000C
	STA $00
	BRA .NextEntry
.NoDelay
	LDA $B800,x
	STA $004300
	LDA $B802,x
	STA $004302
	LDA $B804,x
	STA $004304
	LDA $B805,x
	STA $004305
	LDA $B807,x
	STA $002115
	LDA $B808,x
	STA $002116
	SEP #$20
	LDA #$01
	STA $00420B
	REP #$20
.NextEntry
	TXA
	CLC
	ADC #$000C
	TAX
	CMP $3066FB
	BCC .Loop
	PLB
	LDA $00
	STA $66FB
	RTS


I don't believe a ram change is necessary since this is messing with VRAM it has to be on the SNES side anyway but maybe the bank byte change I made with the CMP is off?
I can already see the error: You're using WRAM which only the SNES but not SA-1 can access (and SA-1 handles the blocks, not the SNES). Changing the databank to BW-RAM should work.

--------------------
Okay, my layout looks ugly.
Originally posted by MarioFanGamer
I can already see the error: You're using WRAM which only the SNES but not SA-1 can access (and SA-1 handles the blocks, not the SNES). Changing the databank to BW-RAM should work.


I didn't know that, I could've sworn the SNES handled that, but I was going to give that a try right now so I'll mess around with it and see if it works.
The SA-1 also can't access the SNES hardware registers.

Also, is the data bank for $66FB really supposed to be $30? I would have thought $00. I guess it doesn't much matter because of mirroring, though.
So a few things I just found out:

1. The ram change does indeed not matter at all. After MFG pointed it out I realized the original code was already working fine prior to that so that can't be it.

2. The updated code you gave to me imamelia actually does work but only after removing the NOP #5 because I realized your code is replacing the original, not adding to it and your updated code added 5 bytes so something was being overwritten after that was added.

3. The blocks are working like fine like with the original code again but now the only issue left is that blocks on the top part of the sub screens don't change properly while the bottom half does.
I just tested it with the top subscreen for both layers and didn't encounter any problems. Another SA-1 oddity, maybe?
Originally posted by imamelia
I just tested it with the top subscreen for both layers and didn't encounter any problems. Another SA-1 oddity, maybe?


Actually, this does seem to be the case. I tried this on a base rom with SA-1 applied and it still happens, so I think this one might be for Vitor to look into.
I finally finished the next ObjecTool version...sort of. It now includes template subroutines for all sorts of object types including slopes, and there is a file for usage notes. A couple of the subroutines are missing vertical level support, though honestly, are vertical levels even necessary in Lunar Magic 3? I'm pretty sure that the code is not optimized for space either. Anyway, if I could get some testing and feedback on this, that wouldd be appreciated.
There are a few sprite and object clipping indexes that aren't used by any of the original sprites or are exactly the same as other indexes. Sprite clipping indexes 0B and 15 are unused and index 32 is identical to 31, while object clipping 04 is used only by unused sprite 12, 06 is unused, and 0D is identical to 09. These are some hex edits that allow you to use one or more of those indexes for custom values. Sprite clippings are in order of X offset, Y offset, width, and height, while object clippings are four X coordinates followed by four Y coordinates for the right, left, bottom, and top points respectively. The values here are the normal ones.

Code
; sprite clipping 0B
org $03B577
	db $06
org $03B5EF
	db $06
org $03B5B3
	db $03
org $03B62B
	db $03

; sprite clipping 15
org $03B581
	db $00
org $03B5EF
	db $FE
org $03B5B3
	db $0F
org $03B635
	db $0E

; sprite clipping 32
org $03B59E
	db $00
org $03B616
	db $FE
org $03B5DA
	db $30
org $03B652
	db $12

; object clipping 04
org $0190CA
	db $10,$00,$08,$08
org $019107
	db $12,$12,$20,$02

; object clipping 06
org $0190D2
	db $07,$00,$04,$04
org $01910F
	db $04,$04,$08,$00

; object clipping 0D
org $0190EE
	db $10,$00,$08,$08
org $01912B
	db $08,$08,$10,$00

; make sprite C0 use sprite clipping 31 instead of 32
org $07F3F5
	db $32

; make sprite B1 use object clipping 09 instead of 0D
org $07F31D
	db $0D
Originally posted by imamelia
I finally finished the next ObjecTool version...sort of. It now includes template subroutines for all sorts of object types including slopes, and there is a file for usage notes. A couple of the subroutines are missing vertical level support, though honestly, are vertical levels even necessary in Lunar Magic 3? I'm pretty sure that the code is not optimized for space either. Anyway, if I could get some testing and feedback on this, that wouldd be appreciated.


You should avoid using $8A-$8B as scratch RAM during level object rendering. LM3+ uses that to keep track of Y screen offsets, and writing in there could cause writes to arbitrary RAM addresses in the next bank, leading to all kinds of insanity to happen.
Yeah, I found that out the hard way. The latest version that I gave the moderator uses $45 instead (among other changes).
Pages: « 1 2 3 4 »
Forum Index - SMW Hacking - Resource & Tool Releases - Minor Releases

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2020 - SMW Central
Legal Information - Privacy Policy - Link To Us


Menu

Follow Us On

  • YouTube
  • Twitch
  • Twitter

Affiliates

  • Super Mario Bros. X Community
  • ROMhacking.net
  • Mario Fan Games Galaxy