| View previous topic :: View next topic |
| Author |
Message |
GHS
Regular
Joined: 06 Jun 2005
Posts: 100
|
 Posted: Wed Jan 28, 2009 12:48 am Post subject: TG16/PCE sprite capability's question |
 |
|
What are the systems real sprite capability's, and dose it have anything to do
with why most games (action) are in 256 instead of 352 or in between? |
|
| Back to top |
|
 |
Tomaitheous
Elder
Joined: 27 Sep 2005
Posts: 306
Location: Tucson
|
| Posted: Thu Jan 29, 2009 7:52 am Post subject: Re: TG16/PCE sprite capability's question |
|
|
| GHS wrote: | What are the systems real sprite capability's, and dose it have anything to do
with why most games (action) are in 256 instead of 352 or in between? |
Yup 
16 sprites or 256 pixels per scanline - which every comes first. Just like with other systems of the era, opaque and non opaque pixels of the sprite count too. But like I said, it's per scanline, so it's possible to have overflow effect just one pixel row(1pixel tall) of a sprite.
Off screen sprites can count too if they are one the same X line. The Memory Width Access Register sets how wide the tile map is (BAT) but also how long to parse for sprite X positions on the relative scanline. So if you have some sprites off screen or just need to park them somewhere, make sure to stick them somewhere else other than just to the left or right (choose a Y value that's offscreen).
The VDC of the PCE is very fast. It grabs *ALL* the sprite pixels during hblank (it'll stall the CPU if you try write to vram during this process if sprites exist on the current scanline, but it's small amount of time). Nothing is fetched during active display. And while the VDC is fast enough to grab additional sprite pixels when you change to the higher res of 352 or 512 pixels, the internal buffer that holds the prefected pixels is only 32words wide (256 pixels). So increasing the res doesn't put more sprites per scanline and the number is still 16, but they appear smaller since the res is higher. It's strange because the PCE supports 32 wide pixel sprites and if the buffer was wider, the higher res would work out just fine because the VDC would have enough time to fetch all of them.
Alternatively, if you try to widen the display frame, say from 256 pixels to 272, then the VDC won't have enough time to fetch all the sprite pixels during hblank and thus drop 1 sprite every so many pixels the screen is widened. The frame width and the pixel size do not directly effect one another. But I doubt you would expand the frame further into overscan horizontally. It's not the norm.
Anyway, games that run in 352 pixel mode tend to flicker more as the developers try to keep the size ratio of the objects the same for the higher res. The 352 res mode is 25% smaller than the 256 pixel mode. Keeping things in ratio, if you use 352 res then it's like having a 192pixel scanline buffer for 256 pixel mode.
You can also ask questions over at the Pce dev forum too. After all, it's a forum solely for but PCE dev 
_________________
www.pcedev.net |
|
| Back to top |
|
|
GHS
Regular
Joined: 06 Jun 2005
Posts: 100
|
| Posted: Thu Jan 29, 2009 6:46 pm Post subject: |
|
|
So its 16 sprites of 16 width and 8 sprites of 32 width a line and a max of 64 sprites on screen is it?
Dose the max sprite count change with sprite size? |
|
| Back to top |
|
|
Tomaitheous
Elder
Joined: 27 Sep 2005
Posts: 306
Location: Tucson
|
| Posted: Fri Jan 30, 2009 3:38 am Post subject: |
|
|
| GHS wrote: | So its 16 sprites of 16 width and 8 sprites of 32 width a line and a max of 64 sprites on screen is it?
Dose the max sprite count change with sprite size? |
You can have a mixture of 16 and 32 pixel wide sprites on the same scanline. So saying eight 32wide or sixteen 16wide is misleading. That's why I stated 16 sprites or 256 pixels. You can have 10 sprites on a scanline and still hit the 256pixel buffer limit. Once all 256 pixels have been fetched on a scanline, it won't fetch the rest. The reason why I say 16 sprites per scanline is that in the smallest sprite size, 16pixels wide. If the sprite was 8 pixels wide, then the VDC could fetch up to 32 sprites on a scanline (8x32 =256 pixels). It just happens that 16 sprites at the smallest width is 256 pixels. So, 16 sprites or 256 pixels per scanline.
Also, the whole sprite table is internal to the VDC unlike other systems. The VDC could show all 64 sprites in a single scanline if it had the pixel fetch buffer big enough (and you shorted the screen display frame or increase the dot clock(res)) because it has instant access for parsing the table. Parsing vram would be slower. The VDC takes the sprite table in vram and transfers it to the internal sprite registers during vblank. There are only 64 registers. It doesn't matter if the sprite size is 16x16 or 32x32 or 32x64, it's still one sprite for the register. So yeah, 64 sprites per VDC frame. I say frame, because you can have multiple frames on screen. It's not as great as it sounds, but you can show two screens totalling 128 sprites and even more. Good for two or three split player screens each with its own set of 64 sprites. But that's a more advance topic.
_________________
www.pcedev.net |
|
| Back to top |
|
|
GHS
Regular
Joined: 06 Jun 2005
Posts: 100
|
| Posted: Fri Jan 30, 2009 4:34 pm Post subject: |
|
|
| How many sprites can you piece together, or how big can a character sprite be? |
|
| Back to top |
|
|
Tomaitheous
Elder
Joined: 27 Sep 2005
Posts: 306
Location: Tucson
|
| Posted: Sat Jan 31, 2009 3:55 am Post subject: |
|
|
A sprite size is: 16x16, 16x32, 32x16, 32x32, 32x64 (I believe 16x64 too but I've never tried). There's a bit to set the width ( 16 or 32) and a two bits to set the height, though you only get 16, 32, and 64 pixel heights.
So the largest sprite entry in the table is 32x64, but you can place sprites side by side to make bigger sprites manually. Just like the Genesis, SMS, SNES, and NES do. The pieced together sprite size is limited to the scanline limit (256 pixels wide), but the length is as many as you can stack high one after another (and have room for in the 64 entries of the sprite table).
If you're clever, you can add and remove sprites dynamically on the left/right sides, as it scrolls across the screen *if* it's more than 256 pixels wide.
_________________
www.pcedev.net |
|
| Back to top |
|
|
GHS
Regular
Joined: 06 Jun 2005
Posts: 100
|
| Posted: Sat Jan 31, 2009 7:09 pm Post subject: |
|
|
| Is there a way to make the sprites smaller, 4x4 8x8?, allot of games where you shoot projectiles look smaller than 16x16. |
|
| Back to top |
|
|
Tomaitheous
Elder
Joined: 27 Sep 2005
Posts: 306
Location: Tucson
|
| Posted: Mon Feb 02, 2009 2:44 am Post subject: |
|
|
Nope. It does boggle the mind why some game has really small graphics when the smallest sprite size is 16x16. It's just wasted space.
_________________
www.pcedev.net |
|
| Back to top |
|
|
GHS
Regular
Joined: 06 Jun 2005
Posts: 100
|
| Posted: Mon Feb 02, 2009 4:21 pm Post subject: |
|
|
| When you exceed the sprite line limit what exactly happens, do all sprites get cut out, do some get dropped, if so what determines it, priority and can you decide which gets dropped? |
|
| Back to top |
|
|
Tomaitheous
Elder
Joined: 27 Sep 2005
Posts: 306
Location: Tucson
|
| Posted: Thu Feb 12, 2009 11:10 pm Post subject: |
|
|
| GHS wrote: | | When you exceed the sprite line limit what exactly happens, do all sprites get cut out, do some get dropped, if so what determines it, priority and can you decide which gets dropped? |
When a sprite lands on scanline that is at max, the that row of pixels will not be shown. Just like with any other sprite based system. You can avoid the blank out by shifting the order of the sprites every other frame. This is the famous 'flicker' of back then. Flicker was a work around for the sprites not showing at all. You'd rather have a bullet of enemy flicker, than to not seem them at all. How 'tall' the blank out or how many scanlines worth - all depends on the coordinates of the sprites. It could be a minimum of only one scanline.
The order they are stored in the sprite table determines the priority layering of each sprite onscreen - how some sprites appear on top of others. The VDC also fetches and displays them in that order. So the last or lowest layer will get dropped.
_________________
www.pcedev.net |
|
| Back to top |
|
|
GHS
Regular
Joined: 06 Jun 2005
Posts: 100
|
| Posted: Sat Feb 14, 2009 2:52 pm Post subject: |
|
|
You said opaque and transparent pixels count too. What if the howl row of sprites was transparent and you ad another dose that still count, or if they are hidden behind a layer? If so why dose it calculate what it dose not show?
Cant it do something like a hidden surface removal? |
|
| Back to top |
|
|
Tomaitheous
Elder
Joined: 27 Sep 2005
Posts: 306
Location: Tucson
|
| Posted: Sat Feb 14, 2009 8:22 pm Post subject: |
|
|
| GHS wrote: | | You said opaque and transparent pixels count too. What if the howl row of sprites was transparent and you ad another dose that still count, or if they are hidden behind a layer? If so why dose it calculate what it dose not show? |
Yes. It's like that for NES, SNES,SMS,MD,TG,SGX,etc. For the sake of speed and reduced complexity of the VDC design(i.e. cost), it fetches a single row of sprite pixels in a cell per fetch. After it prefetchs all the pixels, if then logically decides if the pixels are shown or not. So transparent pixels also count. So that's why it's calculated but not shown.
In contrast, the Sega System16 Arcade board does not have a fixed 'cell' size in a sprite. Each row of pixels in a sprite is determined by an end marker(usually the highest pixel niumber) - so there's no wasting of fetching more pixels than what's needed. It still has a transparent pixel number (0) but the length of each row is defined down to the pixel, not the smallest cell size like with the above mentioned consoles.
| Quote: |
Cant it do something like a hidden surface removal? |
Nope. Because of how the all the cell rows are fetched based on their X relative position. The video processors fetch all the data first, then use simple logic to determined which pixel is drawn. So, for a minimum you have to fetch at least a cell width's of pixels. And, assuming that one sprite completely overlaps and hides another sprite, there's not enough time/bandwidth for the these old video processors to test for that.
There's also the fact that sprites hidden behind BG layers are used for complex masking purposes. You don't want to lose that feature. It's when you have a sprite hidden behind a BG layer(invisible normally), but set to a higher priority than a sprite that's on top of the BG layer. When the lower priority sprite(relative to sprite index) overlaps the higher priority sprite underneath the BG layer, the sprite pixel on top of of the BG layer will not be shown. You'd think the sprite under would be shown though, but it fact the BG layer in it's place is shown through. This is used in quite a few games for complex masking of sprites and BG layers.
Some have speculated it's because the video processor doesn't fetch the sprite row of cell pixels, but if that were true then it wouldn't effect the sprite buffer and not cause sprite overflow in some situations. It would also need to know in advance the two tiles on that area. The video processor doesn't as it fetches the tiles in realtime as it's drawing out the display, and wouldn't have any idea before hand when fetching the sprite data. Logic points to a little more complex priority system between the sprite priorities to each other and to the BG layer.
_________________
www.pcedev.net |
|
| Back to top |
|
|
GHS
Regular
Joined: 06 Jun 2005
Posts: 100
|
| Posted: Sun Feb 15, 2009 3:39 pm Post subject: |
|
|
What about the SGX, what is its sprite capability and how dose it compare to the PCE?
PS: I think the SGX hardware should have bin incorporated in to the CD ad on but with a custom 16-bit version of the CPU, like the SNES. Also with a bigger color pallet but thats for another topic. |
|
| Back to top |
|
|
Tomaitheous
Elder
Joined: 27 Sep 2005
Posts: 306
Location: Tucson
|
| Posted: Sun Feb 15, 2009 6:56 pm Post subject: |
|
|
| GHS wrote: | What about the SGX, what is its sprite capability and how dose it compare to the PCE?
PS: I think the SGX hardware should have bin incorporated in to the CD ad on but with a custom 16-bit version of the CPU, like the SNES. Also with a bigger color pallet but thats for another topic. |
The SGX has an additional 16bit VDC (sprite/tile video processor). So that's double the BG's and double the Sprites. It also has it's own separate 64k of vram. To mix the two video processor outputs, there is 16bit a priority controller called "Patty" (HuC6202). This chip decides the priorities between the layers as well adding a new definable window size. The windows regs can clip either of the VDCs output. Not all emulators correctly emulate all of the priority modes. Probably because none of the games use the extra mode(s). Not much is really known about the priority controller because there were only a handful of games to reverse engineer from and not official (leaked) documentation on the chip.
So the SGX has 32 sprites or 512 pixels per scanline bandwidth, but of course it's still 16 or 256 pixels per video processor.
They could have included the extra VDC (it's no different than the one in the PC-Engine models) and the patty chip into the Duo unit. I really do think internal politics help play a dealing blow to the SGX. Hudson and NEC did a lot of development for the PC-Engine system when it originally came out and through out its life. SGX did not receive anything close to this and the time between title releases was pretty large. It's curious that no developers took an interest in it, yet the PC-Engine was immensely popular in japan. You'd figure there would be at least some title cross overs for it, left alone being incorporated into the Duo as an upgrade.
_________________
www.pcedev.net |
|
| Back to top |
|
|
GHS
Regular
Joined: 06 Jun 2005
Posts: 100
|
| Posted: Mon Feb 16, 2009 3:26 pm Post subject: |
|
|
So the SGX doubled the sprites to 128 on screen. More sprites so you could have 352 ress instead of 256 action games. I just figured out something, in 256 ress you could make a full 3rd background layer, I think.
O the possibility's if they incorporated it in to the CD, one could dream. But, I read that the CPU couldn't keep up withe the VDCs, so its meaningless.
How dose the PCE compare (in sprites) to the MD and SNES (advantages, disadvantages)? |
|
| Back to top |
|
|
|
|
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 vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
