| |||
Views: 88,431,121 |
Main | FAQ | Uploader | IRC chat | Radio | Memberlist | Active users | Latest posts | Calendar | Stats | Online users | Search | 04-17-24 11:33 PM |
|
Guest: Register | Login |
0 users currently in ROM Hacking | 1 guest | 1 bot |
Main - ROM Hacking - Yet another SNES ASM problem... | New thread | New reply |
cory21391 |
| ||
Flurry Level: 37 Posts: 70/260 EXP: 331642 Next: 6611 Since: 03-01-07 From: NC, US Last post: 5120 days Last view: 5120 days |
It seems everywhere I turn since I finished my damn map there's been problems between me and non-working code. This time, however, it is related to sprites. I have some issues getting my sprite to, ya know, DISPLAY ON SCREEN!!!! It's just frustrating not understanding stuff. Anyways, I think it may be 1 of 4 things:
1. I don't understand the name and base selection bits and how to use them. (register $2101) 2. I don't know which order to send the bytes to sp table 1 3. I don't know if I'm accessing table 2 correctly 4. not sure which bits per byte in table 2 are x position msb and which are sprite size toggle bits help would be appreciated extremely since I kinda need sprites for my damn game anyways, here's the code (jumps from level 1 label after turning the screen off to 'setupscreen1' then rts-es to level 1 where it fades the screen in ]brightness of $03, then $07, then $0B, then $0F] and loops forever.) EDIT: loads entire palette ($10 colors) to $80 in CGRAM and $0800 bytes of sprite data to $4000 in VRAM right after turning the screen off
____________________ |
MathOnNapkins |
| ||
Super Koopa Level: 62 Posts: 191/842 EXP: 1934202 Next: 50484 Since: 02-19-07 From: durff Last post: 4480 days Last view: 4003 days |
It may be related to the notion of "OAM reset". Also there may be some difficulties arising from the manner in which you are writing to the low table and then to the high table
Instead of doing this all from ROM, I'd suggest setting up a buffer in WRAM to store all your OAM data. reserve $220 (544) bytes. Then when you want to blit your OAM data, just write to $2102/3 to reset the address to zero. Then blit all $220 bytes using a DMA transfer. That's what most games do and they usually do it each and every frame. edit: also, make for damn sure you are in Vblank when these writes occur. ____________________ Zelda Hacking Forum hobbies: delectatio morosa |
cory21391 |
| |||
Flurry Level: 37 Posts: 71/260 EXP: 331642 Next: 6611 Since: 03-01-07 From: NC, US Last post: 5120 days Last view: 5120 days |
I don't think that matters initially, since, well, I did turn the screen off completely... I do that when I change screens so I can make sure that I have enough time to change everything and setup tilemaps and such. But yeah, after the screen's back on, wai. But ok, if I can use DMA to write to the low/high tables correctly, I'm still not sure about the name and base bits. Qwertie's doc says
but says nothing about the name bits (and says to get the VRAM WORD address, you must divide by 2 after ls-ing) so how do the 'n' bits work in conjunction with the 'b' bits? EDIT: damn. I used WRAM and it still didn't work. idk what could be wrong here, unless it is the b and n bits. here's the new code I tried and failed at
and here's the binary tiledata: http://www.uploading.com/files/EZ9BQGF7/sprite1.bin.html (please excuse the terrible sp GFX, I drew this in like 1 min) so... does anyone know what's wrong? ____________________ |
smkdan |
| ||
Ninji Level: 36 Posts: 71/238 EXP: 288451 Next: 19659 Since: 05-26-07 Last post: 4054 days Last view: 4003 days |
There's two 256 tile nametables for the sprites. The base bits define the location of the first, and the name bits define the location of the second relative to the location of the first. regs.txt says this for retrieving a sprite.
i.e. If the base bits equal 2, then the first nametable is at 4000h word in video memory. If the name bits are equal to 0, it's stored directly after the first, at 5000h in that case. There's a nametable select bit for each sprite to choose which one to get the sprite from. regs.txt also says this: Writing to either $2102 or $2103 resets the entire internal OAM Address to the values last written to this register. E.g., if you set $104 to this register, write 4 bytes, then write $1 to $2103, the internal OAM address will point to word 4, not word 6. So as you're writing 1 byte to $2103, $2102 will be set back to the value you last wrote to it. |
cory21391 |
| ||
Flurry Level: 37 Posts: 79/260 EXP: 331642 Next: 6611 Since: 03-01-07 From: NC, US Last post: 5120 days Last view: 5120 days |
where? the only thing I know of related to GFX in OAM is the 9-bit character location (all of byte3 and LSB of byte 4) Oh and are the character bits relative to the name table or the base? ex. if the sprite uses name bits for a name address of $5000 (base of $4000), would tile 0 for that sprite then be at $5000, or would the character #'s still start from the base address (tile 0 being at $4000)? ____________________ |
MathOnNapkins |
| ||
Super Koopa Level: 62 Posts: 205/842 EXP: 1934202 Next: 50484 Since: 02-19-07 From: durff Last post: 4480 days Last view: 4003 days |
the LSB of byte 4 IS the nametable select bit. You're using qwertie's doc again. I strongly suggest you download Anomie's register doc, it's a lot more recent and has stuff that Qwertie's doc doesn't, including details on when specific registers can be written (during Vblank, Hblank, forceblank, etc.) ____________________ Zelda Hacking Forum hobbies: delectatio morosa |
cory21391 |
| ||
Flurry Level: 37 Posts: 81/260 EXP: 331642 Next: 6611 Since: 03-01-07 From: NC, US Last post: 5120 days Last view: 5120 days |
EDIT (again):
well, I have another problem. Now my sprite displays, but only the top left 16x16 tile (sp is 32x32.) idk why, I even tried to draw stuff in on the right 16x16 and it didn't show that either (my sp is actually 16x32, so I'm using 1 32x32 sp to create it.) screen of sp: screen of GFX code:
____________________ |
Main - ROM Hacking - Yet another SNES ASM problem... | New thread | New reply |
© 2005-2023 Acmlm, blackhole89, Xkeeper et al. |
MySQL - queries: 67, rows: 94/94, time: 0.016 seconds. |