Quantcast

Results 1 to 9 of 9

Thread: sprite overflow - a closer look

  1. #1
    Wildside Expert
    Join Date
    Sep 2010
    Posts
    212
    Rep Power
    10

    Default sprite overflow - a closer look

    I have a question: If you exceed the sprite pixel count limit (320 pixels) - how does the system render the sprites afterwards? Does the whole scanline get cleared not showing any pixels or do you lose only some sprites? Is this related to one "overflown" scanline only or does it affect other lines with the same sprite (s)? Is there any other known behaviour of how the system renders the sprites after hitting the limit?

  2. #2
    Hero of Algol Kamahl's Avatar
    Join Date
    Jan 2011
    Location
    Belgium
    Age
    30
    Posts
    8,597
    Rep Power
    142

    Default

    The genesis renders a maximum of 320 sprite pixels per line, any more than that are simply not drawn.

  3. #3
    Wildside Expert
    Join Date
    Sep 2010
    Posts
    212
    Rep Power
    10

    Default

    I think you put it too simple. I am quite sure it is much more complex than that...

  4. #4
    Death Bringer Raging in the Streets Black_Tiger's Avatar
    Join Date
    Oct 2006
    Location
    Vancouver
    Age
    43
    Posts
    4,867
    Rep Power
    107

    Default

    I believe that all sprites/meta sprites have levels of priority. The lowest level priority sprites are the first to lose scanlines of visibility where the limit is exceeded. Like flicker, this result may be programmed in, but that's how it seems to go in most 16-bit console games. The sprite pixels per scanline limit for Genesis also changes with the resolution.
    Quote Originally Posted by year2kill06
    everyone knows nintendo is far way cooler than sega just face it nintendo has more better games and originals

  5. #5
    Wildside Expert
    Join Date
    Sep 2010
    Posts
    212
    Rep Power
    10

    Default

    Interesting. I would also like to know if the limit applies to one scanline or if it affects other lines of pixels of the same sprite(s) in the overflow.

  6. #6
    Mastering your Systems Shining Hero TmEE's Avatar
    Join Date
    Oct 2007
    Location
    Estonia, Rapla City
    Age
    30
    Posts
    10,095
    Rep Power
    110

    Default

    Once 320 pixels are drawn no more pixels are rendered on that line. There is nothing more to it. Same deal when 20 sprites are reached on the line, the remaining are not rendered on that line. All restarts on the next line.
    Death To MP3, :3
    Mida sa loed ? Nagunii aru ei saa "Gnirts test is a shit" New and growing website of total jawusumness !
    If any of my images in my posts no longer work you can find them in "FileDen Dump" on my site ^

  7. #7
    Master of Shinobi
    Join Date
    Sep 2013
    Posts
    1,199
    Rep Power
    23

    Default

    is this related to flickering? Or I'm mixing things up?

  8. #8
    Death Bringer Raging in the Streets Black_Tiger's Avatar
    Join Date
    Oct 2006
    Location
    Vancouver
    Age
    43
    Posts
    4,867
    Rep Power
    107

    Default

    Quote Originally Posted by TmEE View Post
    Once 320 pixels are drawn no more pixels are rendered on that line. There is nothing more to it. Same deal when 20 sprites are reached on the line, the remaining are not rendered on that line. All restarts on the next line.
    I think that like Kamahl, you are describing something which goes on under the hood, but leaving out the part that explains what we actually see and why.

    When new sprites like bullets in shooters break the sprite limits, which seems to usually just be the scanline limit, horizontal strips within existing sprites disappear and reappear. It doesn't matter the order in which various sprite-based objects appear, there is a priority for the sprite break-up, which usually means that an enemy sprite loses lines.






    My guess is that what you're describing is when each new frame or line of video is rendered from scratch, and that sprites that a programmer wants to break-up/drop-out first are always rendered internally last. Even though they appear visible to players before and after the sprite break-up and also visually beneath other sprites. The kind of behavior Tom M. was asking about, as far as how we see it manifest in games, seems to be the design of the programmer to work around the hardware limits.



    Tom M.: I've also noticed that both sprite limits being exceeded drops out or break-ups individual sprites within meta sprites. For example, in that TFIV screenshot, the lines of horizontal break-up only pierce half of that sprite's width. In sloppy PC Engine games, when the sprites-per-line limits are broken, you sometimes see single squares popping in and out (like 1/4 chunk of a round explosion). It looks like many games are selective with which parts of meta sprites flicker first. It makes more sense for the back end of that TFIV enemy sprite to drop out first, since the player is dealing with the front end.




    Quote Originally Posted by chilled View Post
    is this related to flickering? Or I'm mixing things up?
    Although some sprite flickering, like slowdown, is supposed to have often been programmed in to many 8-bit games, 16-bit games usually just push the sprite limit and let bits of sprite break-up occur. Not pushing the limit would be a waste in games that can use a lot of sprites. Parts of sprites usually end up "flickering" from rapid fire sprites like bullets, but sprite break-up/drop-out doesn't always happen like that.
    Quote Originally Posted by year2kill06
    everyone knows nintendo is far way cooler than sega just face it nintendo has more better games and originals

  9. #9
    Road Rasher
    Join Date
    Apr 2013
    Location
    SF Bay Area, California
    Posts
    301
    Rep Power
    21

    Default

    As best as I can tell from my work on BlastEm, sprite rendering is split into 3 stages and there are 3 corresponding limits to sprite rendering. The first stage is to scan the entire sprite table for sprites that span the next line (sprite rendering starts a line early). This stage provides the per-frame sprite limit. There is only enough internal sprite attribute table cache for 80 entries and only enough time to scan that many in H40 mode (64 in H32). This appears to store the indices of the first 20 (16 in H32) sprites spanning the line in some kind of internal buffer for the next stage. The second stage reads the uncached half of each of the sprites identified in stage 1 and either stores that or the necessary information about which tile-rows to draw in an internal buffer. This stage effectively provides the 20 sprite per line (16 in H32) limit as there is not enough VRAM bandwidth available to read more than that many sprite table entry halves during this phase. The final phase draws individual tile rows to an internal line-buffer and provides the 320 pixel (256 in H32) limit. It's probably better to describe this as 40 tile row (32 in H32) limit than a 320 pixel limit since in some sense transparent pixels aren't really drawn, but they still count toward the limit regardless. This rendering occurs during hblank and available VRAM bandwidth again is the likely source of the limit. This line buffer is then composited with the background layers during the active display period.

    As best I can tell, all 3 phases run in sprite table linking order. The Genesis hardware has no indication of priority between sprites other than their order in the table. Sprites later in the table get drawn over ones earlier in the table so it will tend to be sprites that are "on top" that get dropped. However, sprites do have a priority bit that is used for compositing with the background. This means that a low priority sprite can overwrite a high priority sprite and get hidden by high priority parts of the background which is a bit weird, but not much of an issue in practice.

    Hopefully that helps.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •