It is currently Thu May 23, 2019 8:46 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 8 posts ] 
Author Message
PostPosted: Sun Dec 23, 2018 11:28 pm 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3461
Location: Richmond, Virginia
Haven't been able to find this information anywhere; does anyone know how the Super Scaler series of arcade systems (Hang On, Outrun, X Board, Y Board, System 32) actually drew the scaled sprites? I would guess the systems are framebuffer (not just linebuffer) based, but System 16 gives information about how the X Board is capable of displaying at maximimum 256 sprites, which I think would debunk this. Things like the smoke trail clouds in Afterburner scaling up to fit about the whole screen confuse me then.


Top
 Profile  
 
PostPosted: Mon Dec 24, 2018 1:28 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8370
Location: Seattle
I'm pretty sure it's still just-in-time.

If you look at the 315-5196 sprite table, it's 10 bytes per entry, including:
Top scanline
Bottom scanline
X position
16 bit dY/dy ("p") — specifies the stride from one scanline of source pixels to the next; also could be used to shrink things.
19 bit "start", not clear what units it's using. Maybe words = four 4-bit packed pixels?
6 bits of palette number
6 bits of "zoom"

Similarly, in drivers/segaorun.cpp, it doesn't mention anywhere near enough memory on the video board for a framebuffer—just 10 or 12 KiB of SRAM.

MAME still emulates the sprites here as a framebuffer, but MAME's not known for its accuracy. It is possible that the framebuffer is inside the chip, rather than external, though.

There's also a quote from the person who designed it, mentioned here:
My designs were always 3D from the beginning. All the calculations in the system were 3D, even from Hang-On. I calculated the position, scale, and zoom rate in 3D and converted it backwards to 2D. So I was always thinking in 3D.
— Yu Suzuki


Top
 Profile  
 
PostPosted: Mon Dec 24, 2018 1:56 am 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3461
Location: Richmond, Virginia
Wow, thank you for compiling that information! It's mildly unfortunate a lot of this information isn't available outside of source code anywhere.

And I'm really impressed that it's in time (segaretro actually specifies line buffers and pixels per scanline), as I've never seen any sprite pixel per line dropout..

Yeah, God damn, the X Board has 3200 sprite pixels per scanline...


Top
 Profile  
 
PostPosted: Mon Dec 24, 2018 2:59 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2851
I wonder how expensive it would've been to implement sprite scaling hardware on the SNES or Genesis. I know it's still a lot cheaper than hardware sprite rotation, because rotation takes per pixel VRAM access, and scaling doesn't. I think most of it would come from having a bigger sprite table.


Top
 Profile  
 
PostPosted: Mon Dec 24, 2018 3:06 pm 
Offline
User avatar

Joined: Wed Feb 13, 2008 9:10 am
Posts: 692
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
There was gonna be sprite scaling on MD but it was one of the things that got axed. Horizontally it shouldn't take much effort but vertically there's some extra state to store. There's no room left for VRAM accesses and silicon shots show that there's no space for any extra memory in the VDP either.

_________________
http://www.tmeeco.eu


Top
 Profile  
 
PostPosted: Mon Dec 24, 2018 3:11 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11348
Location: Rio de Janeiro - Brazil
TmEE wrote:
There was gonna be sprite scaling on MD but it was one of the things that got axed.

But it was eventually implemented in the Sega CD, right?


Top
 Profile  
 
PostPosted: Mon Dec 24, 2018 3:33 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21394
Location: NE Indiana, USA (NTSC)
psycopathicteen wrote:
I wonder how expensive it would've been to implement sprite scaling hardware on the SNES or Genesis.

Scaling without rotation can be done in real time in software, even on an NES. If I had an application, I'd make a tech demo of doing so on Super NES.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Tue Dec 25, 2018 6:33 pm 
Offline
User avatar

Joined: Wed Feb 13, 2008 9:10 am
Posts: 692
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
tokumaru wrote:
But it was eventually implemented in the Sega CD, right?

MCD has a setup with a framebuffer that can do blits and whatnot between the RAM banks, completely different from what the VDP would have had in it.

_________________
http://www.tmeeco.eu


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 14 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