It is currently Mon Oct 23, 2017 9:21 pm

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 21 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Tue Nov 15, 2016 10:31 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3074
Location: Nacogdoches, Texas
93143 wrote:
If (a) the internal/PPU-side OAM address auto-increments after a CPU-side write during HBlank

If it doesn't, you're only writing to sprite 0's X position? :lol: I kind of wonder why you wouldn't think it would though. What would be the point in changing the behavior?

93143 wrote:
(b) the PPU caches the data it reads from OAM during active display, rather than reading it again during HBlank

You're talking about those potentially unused 84 "dot cycles"? As nice as it would be, I don't see this happening. How could "step 1" In the Fullsnes document take 256 cycles, while steps 2 and 3 do not take a single one?

byuu wrote:
Uniracers is the only game that does it, and I suspect they got really lucky that it worked at all

They sent the data for changing sprite 1 and 2's position in HiOAM just as it was being scanned by coincidence?


Top
 Profile  
 
PostPosted: Wed Nov 16, 2016 11:38 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 788
Well, I tried it, and no joy. At least, not with the scanline basically full of sprites... It seems the PPU does in fact read OAM during HBlank, because on real hardware the writes are ending up all over the place. In higan, they all go to the highest HiOAM address actually used on the scanline (NOT the top of HiOAM like I thought), which implies the same thing if you think about it in context.

(Take this result with a grain of salt - I didn't do too much double-checking, so I may have screwed something up.)

I'd try to check for address incrementing, but it's late. Maybe tomorrow I'll try on a scanline without any sprites and see what it does...

Espozo wrote:
If it doesn't, you're only writing to sprite 0's X position?

No, it wouldn't even get that far, not even if sprite 125 or higher was on that particular scanline. It would repeatedly write to the last HiOAM byte the PPU looked at (assuming sprite rendering was finished - if not, it would go wherever the PPU was reading at the moment).

Quote:
As nice as it would be, I don't see this happening.

Well, it doesn't. It would have been nice if the PPU had turned out to internally cache the OAM data for the 32 sprites on the scanline, rather than having to read it again during HBlank, but I guess the designers figured there was no point adding extra circuitry just so that OAM could sit idle for 85 dot-cycles per line...

Quote:
They sent the data for changing sprite 1 and 2's position in HiOAM just as it was being scanned by coincidence?

More probably they sent the data after sprite rendering was finished, and the internal address had been left at that byte by the PPU.


byuu wrote:
The only viable trick with OAM mid-frame is a trick that some games use to make an entire background from sprites alone: you can change the tiledata address at the halfway point, but leave all the sprite attribute data alone.

It's not very useful. Yet several games do this for no reason: Megalomania OP, Winter Games main menu, etc.

You might find a use in making a static 256x224 background while using Mode7 as a giant single rotating sprite.

Are you serious? Actual games do that?

I thought it was just that one demo, and it didn't even do it right (used HDMA rather than a mid-line IRQ, thus interrupting rendering and causing glitches)... I was so proud of figuring out the right way to do it, too...

My (glacially proceeding) shmup port uses this trick for a Super FX layer on top of a Mode 7 background, which is why I was investigating it.


Top
 Profile  
 
PostPosted: Thu Nov 17, 2016 6:57 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19122
Location: NE Indiana, USA (NTSC)
93143 wrote:
byuu wrote:
You might find a use in making a static 256x224 background while using Mode7 as a giant single rotating sprite.

Are you serious? Actual games do that?

A static background plane behind a mode 7 main playfield is seen in On the Ball/Cameltry. And about half the bosses in Super Mario World, from when mode 7 was a brand new gimmick, likewise are drawn as a mode 7 layer with sprites for terrain.

Quote:
My (glacially proceeding) shmup port uses this trick for a Super FX layer on top of a Mode 7 background, which is why I was investigating it.

The same technique used in the title screen of Yoshi's Island, correct?


Top
 Profile  
 
PostPosted: Thu Nov 17, 2016 12:21 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 788
Yeah, but what I believe he's talking about is specifically changing OBSEL partway down the screen, so as to access more than 16 KB of sprite data. I'm pretty sure none of the games you mention do that.


Top
 Profile  
 
PostPosted: Thu Nov 17, 2016 12:51 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1338
I named two games that do it already. Give those a try and see for yourself.

Both of them had single-line errors in my scanline renderer at one point in time because the timing of when OBSEL is cached is really important with this trick.


Top
 Profile  
 
PostPosted: Thu Nov 17, 2016 1:25 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 788
byuu wrote:
I named two games that do it already.

I know; I was referring to the games tepples named. I looked up the ones you mentioned on YouTube, but it's hard to tell a sprite layer from a BG layer when Mode 7 isn't involved. I believe you, so I don't think I'll bother pirating them to check.

I suppose it could be interesting to see how they do it - whether they make the change during HBlank or active display...


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 21 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot] and 4 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