• Rise from your gwave!

Sprite types and color banks

Discussion in 'Saturn Dev' started by mrkotfw, May 1, 2018.

  1. mrkotfw

    mrkotfw New Member

    I'm fairly confused and unsure where to specify set actual sprite type bits.

    - Sprite type (0..7) for a 16-bit frame buffer needs to be specified.
    - Inside the command table, 4BPP normal sprite, 12 bits are available for the color bank

    Effectively, those 12-bits are what? Offset to CRAM? Or actual sprite type bits? Or is it an offset to CRAM, where the entry itself contains the sprite type data, and an offset to the actual RGB555 value?

    I'm testing per-sprite priority, which should be possible, given the PR bits in the sprite type.
     
  2. XL2

    XL2 Member

    Funny thing that you mention it now as I got it working myself like 2 or 3 weeks ago (as seen here : )

    You can set max 8 sprites with priorities. I don't want to add confusion, but your command will reference a sprite "type" from 0 to 7 (I'm not talking you the bits info here, really what you see in the manuals as "priority"), and you can decide to give them different priority (usualy you only need 2, so say Sprite "type" 0 at priority 5, and Sprite "type" 1 at priority 4. (the sprite type here just references a priority setting, so you could always use Sprite 0 for everything and all your sprites will have priority 5).

    The color code includes the MSB, the sprite priority, the VDP2 color calculation ratio (one out of 8 registered ratio values), the color bank offset and the color ID.
    So, depending on your sprite type, you will have different values.
    But say you have a 8 bpp sprite, you need 3 bits for the color bank (one of the 8 possible 256 color banks in your 2048 colors RAM) and 8 bits for the pixel color ID.
    That's what will be transfered to the VDP2, which will then apply the color calculation while writting to the framebuffer.

    The sprite priority, at least from my personnal experience, is mainly (if not only?) for color calculation/shadow using the VDP2 as using different priorities won't impact which sprite pixel gets written over which sprite pixel (the ordering of commands sent to VDP1 will determine those), only what priority the sprite has over the other VDP2 layers.

    Say I put my color calculation ratio condition at (priority <= priority 4), then I want to use some sprites without the effect, I will give them priority 5.
    But for those sprites that I want to use the effect on, I will give them priority 4 or less and specify the ratio (0 to 7).
    16 CLUT sprites can be used both as RGB and color bank sprites, but I couldn't change the color calculation ratio since it needed more bits for the LUT address and setting the priority didn't seem to work when I tried. But you can set your color calc condition at MSB and set the color MSB to 1.
    Note that for CLUT sprites you need to set the 16 RGB values' MSB to 0 so that they get treated as VDP2 CRAM sprites.

    Another usage with priority that you could also, I guess, "hide" a sprite behind a layer or a VDP2 window (could be nice to mix both to have full transparency over sprites using the VDP2, using the NBG0 or NBG1 as some kind of framebuffer like in Burning Rangers with some software rendering).

    Some of this info could be wrong since I'm using SGL and only use a couple of manual draw commands, but overall it should help you I hope.
     
    Last edited: May 1, 2018
    mrkotfw likes this.
  3. antime

    antime Extra Hard Mid Boss

    The sprite type is set in the VDP2 SPCTL register, it is not a per-sprite setting. The CMDCOLR word is just the high-order bits of the final pixel value that is written into the frame buffer. VDP2 interprets the frame buffer data as listed in figure 9.1 of the VDP2 manual.
     
    Last edited: May 2, 2018
  4. mrkotfw

    mrkotfw New Member

    I ran through some experiments, and despite setting *SPCTL* to all sprite types from 0 to 7, setting the priority via *RISA/PRISB/PRISC/PRISD* doesn't seem to work. As in, the only value that is respected is *PRISA=0x707* with any given type (0 to 7).

    I set *SPCTL* to *0x0027* for sprite type 7 and paletted. I write to the register before and inside a VBLANK-IN interrupt handler.
     
  5. XL2

    XL2 Member

    What exactly are you trying to achieve?
     
    mrkotfw likes this.
  6. mrkotfw

    mrkotfw New Member

    I'm attempting per sprite priority between VDP2 backgrounds.

    Hardware shows the same results as Yabause. Yabause reports that I'm using sprite type 7. But even if I change the priority for *PRISD* to 0x0707, it's not respected. It isn't until I set *PRISA* to 0x0707 that I see sprites over the background.

    I'm thinking that when I set these registers is the solution?

    How could it be that VDP2 still is using sprite type 0?
     
  7. XL2

    XL2 Member

    The sprite type and priority are different. I used "sprite type priority" in my previous comment, but I guess I just make it confusing.
    The sprite type, as said by antime, applies to every sprites and you only have 1, while you can set 8 different sprite priority and set it per sprite in your color code.
    Are you using SBL/SGL?
     
  8. mrkotfw

    mrkotfw New Member

    I'm using my own library.

    Yeah, the sprite type is set in *SPCTL*, and the priority per command table is set in its *CMDCOLR* member.

    At this point, I can't even set the priority via the PRISA-D registers.
     
  9. antime

    antime Extra Hard Mid Boss

    The priority value given in CMDCOLR is an index into the S0PRI-S7PRI subregisters of PRISA-PRISD. The sprite format only affects how many bits (1-3) are available to specify the priority register (ie. for sprite type 2 with only one priority bit you can only select S0PRI or S1PRI, while for sprite type 4 with two priority bits you can select between S0PRI-S3PRI). The colour calculation bits work the same.
     
    mrkotfw likes this.
  10. mrkotfw

    mrkotfw New Member

    I had to reread the part about the PRISA-D registers, and I don't know why I overlooked that they're not priorities based from sprite types, but sprite registers. This also came from how PRINA-D works as well. I had thought the priority bits in the color code was an relative offset and not an index.

    I reread your posts and they make sense.

    Once I get home, I'm going to run some tests.
     
  11. mrkotfw

    mrkotfw New Member

    The documentation is all over the place, but luckily it isn't missing huge chunks of information.
     
  12. vbt

    vbt Staff Member

    Can you be more clear about multiple sprites priorities ? I already did that using special bit on tiles, but i don't see how to change priority on sprites. What must be set in cmdcolr ?
     
  13. mrkotfw

    mrkotfw New Member

    Yes, depending on the sprite type, there are at most 3 bits for the sprite register priorities (VDP2 PRISA-PRISD) in CMDCOLR. So if you set those priority bits to 0, then that sprite would use sprite register 0 for its priority.
     
  14. vbt

    vbt Staff Member

    so using sbl, it means something like that :

    // sprite 1 priority = 3
    SCL_SET_S1PRIN(3);
    SCL_SET_SPCCEN(1); // useful ?
    ss_spritePtr->control = ( JUMP_NEXT | FUNC_NORMALSP);
    // use priority bit for sprite 1
    // 1 << 13 = 0x2000
    ss_spritePtr->color = 0x2000 | color<<4;
     
    Last edited: May 21, 2018
  15. mrkotfw

    mrkotfw New Member

    I'm not sure what some of those macros do. Verify by checking VDP1 VRAM (or via Yabause) and check that the right bits are being set.
     
  16. vbt

    vbt Staff Member

    i'd be curious to see a working sample (whatever the lib used) with such thing :

    sprite 0 : priority 1
    nbg0 : priority 2
    sprite 1 : priority 3
    nbg 1 : priority 4
     
  17. XL2

    XL2 Member

    You would only see the NBG1 background unless you use color calculation.
    If you remove the NBG1, sprite 1 would be visible, but not sprite 0.
     

Share This Page