It is currently Fri Nov 24, 2017 4:46 pm

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 14 posts ] 
Author Message
PostPosted: Sun Sep 17, 2017 3:53 pm 
Offline
User avatar

Joined: Sat Jan 03, 2015 5:58 pm
Posts: 368
Location: ...
Hey, look, bsnes-plus says I've made a bit of progress in my fighting game! A 32x32 portion of Sektor appears as a sprite.
Image
higan says so too on my desktop, except I can't provide a screenshot (haven't bothered building higan on this slow laptop).

Well, uh, my SNES disagrees. It shows the sprite when it's moved to the very left part of the screen. Other than that, it's absent. This shakily recorded video proves it.

I've played around a bit, looked for changes to make and so far have only tried changing sprite size. Had to change the tile too, but 8x8 is confirmed to have the same issue with me.

This is the code as of me posting this. Builds with latest version of bass-untech. The code in fighter.asm should show in a pretty straight-forward way what I'm doing. The actual OAM magic is in oam.inc, which I got from tepples (and need to remember to add the lorom-template license to the repo for, because that's not all that I've taken from it). Every other game I've played on my SNES has worked perfectly, I don't know what the deal could be.


Top
 Profile  
 
PostPosted: Sun Sep 17, 2017 5:32 pm 
Offline
User avatar

Joined: Thu Dec 25, 2014 10:26 pm
Posts: 309
Location: Canada
If it's a difference between higan and real hardware, then it's beyond me... Hope byuu sees this, something this simple really shouldn't be misbehaving on emulator. Sorry I can't help. :/


Top
 Profile  
 
PostPosted: Sun Sep 17, 2017 5:35 pm 
Offline

Joined: Sun Mar 27, 2016 7:56 pm
Posts: 138
I tested it on my own Super Everdrive and got results much like yours.
Attachment:
fighter1.jpg
fighter1.jpg [ 89.14 KiB | Viewed 748 times ]

However, I have it set so that resetting resets the ROM rather than returning to the menu, and upon resetting and moving it back to the left, I ended up with this instead, with much more of the sprite being shown.
Attachment:
fighter2.jpg
fighter2.jpg [ 100.18 KiB | Viewed 748 times ]

Because of that, it seems very likely that there's something wrong with your init code. It might not be the cause of the sprite only showing up on the left, but it does seem to be a serious issue regardless.


Top
 Profile  
 
PostPosted: Sun Sep 17, 2017 6:52 pm 
Offline
User avatar

Joined: Sat Jan 03, 2015 5:58 pm
Posts: 368
Location: ...
Huh...changing the OAM transfer code to not copy the high table at all causes the example to work perfectly upon reset. I think I'm not using the high table code properly.


Top
 Profile  
 
PostPosted: Sun Sep 17, 2017 7:22 pm 
Offline
User avatar

Joined: Sat Jan 03, 2015 5:58 pm
Posts: 368
Location: ...
So the solution to the problem turned out to be something pretty ridiculous.

Usually when you end up with an incorrect opcode size in your code, your code just doesn't work. It eventually will hit a brk or something, maybe a return or something.

But in my sprite clearing routine, that uh...that didn't happen. Somehow all the wrong opcodes ended up making the code work anyway, just without properly initializing sprites.

So now the demo's working on hardware always, but there's junk in the top left corner. Let's see what kind of fun I have figuring this one out.


Top
 Profile  
 
PostPosted: Sun Sep 17, 2017 7:34 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1339
You're not setting the DMA bank properly on the OAM transfer.

Code:
ldx #zero; stx DMAADDR   // set to correctly to $811d
lda #bankbyte(zero); sta DMAADDRBANK  // this write fails
ldx #$0000; stx DMALEN  // this write should be $0000 but is $811d, so the ldx failed to execute


Likely reason is lda #bankbyte(zero) is being miscompiled as 16-bit whereas A is 8-bit here.

It ends up being set as #$ff in higan.

You're thus relying on uninitialized state, so it's going to vary between hardware and higan's attempts at pseudo randomization.


Top
 Profile  
 
PostPosted: Mon Sep 18, 2017 5:44 am 
Offline
User avatar

Joined: Tue Apr 05, 2016 5:25 pm
Posts: 146
Assuming that you're zero-initializing your RAM copy of OAM, having all other sprites in the top left corner is normal. You'll probably want to move them offscreen by setting the nineth byte of their X coordinate.

_________________
SNES NTSC 2/1/3 1CHIP | serial number UN318588627


Top
 Profile  
 
PostPosted: Mon Sep 18, 2017 6:11 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10119
Location: Rio de Janeiro - Brazil
On the NES, the correct way to hide unused sprites is to use large Y coordinates (239 or larger) to put them past the bottom of the screen, otherwise they may still contribute to the sprites-per-scanline limit. I assume it's the same with the SNES, so you should hide sprites at the bottom, not the sides.


Top
 Profile  
 
PostPosted: Mon Sep 18, 2017 6:32 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1835
Location: DIGDUG
Quote:
I assume it's the same with the SNES, so you should hide sprites at the bottom, not the sides.


It's not the same.

On SNES, sprites wrap past the bottom back to the top of the screen. And, you can have sprite sizes larger than the 16 pixels below the bottom of the screen.


Also, I think, only sprites in "range" are counted in the scanline count....so sprites far enough offscreen to the left don't count. (Not sure, correct me if I'm wrong).


EDIT, however, if you have sprites set to 8x8 or 16x16, then, yes, you could put their Y value at $ef (239), and it won't show up.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Mon Sep 18, 2017 6:51 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19257
Location: NE Indiana, USA (NTSC)
On at least the NTSC Super NES, Y=224 also works unless you're using 64x64.


Top
 Profile  
 
PostPosted: Mon Sep 18, 2017 7:00 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10119
Location: Rio de Janeiro - Brazil
dougeff wrote:
On SNES, sprites wrap past the bottom back to the top of the screen. And, you can have sprite sizes larger than the 16 pixels below the bottom of the screen.

Then maybe you should set both X and Y coordinates to large values. I won't pretend I know anything about SNES development though.

Quote:
Also, I think, only sprites in "range" are counted in the scanline count....so sprites far enough offscreen to the left don't count. (Not sure, correct me if I'm wrong).

On the NES, "in range" means in the current scanline. Like I said, I know jack shit about SNES development, but from a hardware standpoint, it makes more sense to exclude sprites after one range check (Y only, like on the NES) rather than 2. It would be nice if someone could clear this up.


Top
 Profile  
 
PostPosted: Mon Sep 18, 2017 7:28 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19257
Location: NE Indiana, USA (NTSC)
By the NES definition, a 64x64 pixel sprite at Y=208 is in range on scanlines 208-224 and 0-15. In 239-line mode, a 32x32 pixel sprite at scanlines Y=232 through Y=239 and Y=0 through Y=7.

(These Y values may be off by one.)


Top
 Profile  
 
PostPosted: Mon Sep 18, 2017 8:25 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2981
Location: Tampere, Finland
HihiDanni wrote:
Assuming that you're zero-initializing your RAM copy of OAM, having all other sprites in the top left corner is normal. You'll probably want to move them offscreen by setting the nineth byte of their X coordinate.

If you do this, just note that the official manual explicitly cautions against setting the X coordinate to $100 (-256), because in this case it will count against the sprite limitations despite not being displayed.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Mon Sep 18, 2017 3:09 pm 
Offline
User avatar

Joined: Tue Apr 05, 2016 5:25 pm
Posts: 146
I'm placing mine at X=-255 (originally intended as a code optimization but I guess it also works to avoid the bug(?) you described).

_________________
SNES NTSC 2/1/3 1CHIP | serial number UN318588627


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 14 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: lint and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group