Jump to content
IGNORED

Z-Buffer / Depth Sorting


OVERRiDE

Recommended Posts

Hi guys,

 

I am looking to understand exactly what controls we have as end-users of JagStudio (black box and all) regarding how to control the order in which objects get drawn on screen.

 

For Sprites, I believe I have found the answer to my own question just by testing things - the order you define sprites in rapinit.s determine the order they get drawn, so items at the start of list effectively get the furthest depth assigned.  I can manipulate this (for my own purposes) by keeping "shadow" copies of sprites in the list, in order my desired depth, that I activate on demand in order to create the depth effect I am looking for.  However, this solution is not very scalable. Furthermore, this solution does not apply to Text rendering through the API.

WIP: Notice the layers of the 3 main sprites visible, closest to the screen based on the sprite scaling is going to occlude the further from camera sprites:

 

image.thumb.png.4de45f2274851db112a7aa8727a06750.png

But I am currently having to avoid sprites being rendered in the area of the screen where I want to render text.  I am not seeing a way around this, please advise!

Thanks,

Link to comment
Share on other sites

@CyranoJ thank you for the reply, I need to pay a bit more attention to the existing sample projects it seems.


I am using userdat1 to store my Z values which is what I need to sort on, and using the raptor sorting function works like a charm even sorting on userdat1 😀, just important to note ( as commented in the example ) that you must have an active sprite before starting sprite being sorted, and after the last sprite being sorted ( I was getting crashes until I read that comment ).

Only issue then, this does not seem to apply to Text rendering?  How do we get the Text rendering to appear over the Sprite layer?
image.thumb.png.c2762d7969fc43880a27e93f2f908385.png

 

Thanks!

  • Like 1
Link to comment
Share on other sites

The text/particle layer is just another object in rapinit.s.

 

So if you want the text on the top, just move that object elsewhere (further down) in the list. 

 

You can even have multiple text layer objects defined. However, all print commands will print to both layers. 

 

Also, to conserve precious bus bandwidth, you can limit the height of the text layer in rapapp.s (near the top a variable called "raptor_particle_buffer_height". 

 

Remember though, the whole object list must start and end with an active object. So if you move the text layer, make sure whatever is first is active.

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

  • 1 month later...

Ok so back on this topic, I am seeing hardware crashes when using the zsort function in some scenarios and I'm not sure why ( able to reproduce in BigP + real hardware ).

 

I've followed the comments in the sample project - I have an active sprite before and after the first and last sprite being sorted.  Is there some limitation that all sprites in the list to be sorted need to be active?  I seem to get issues when de-activiting sprites in the middle of the list being sorted.

 

Function Call:

rapSortSprites(ship, R_sprite_userdat1, font - ship - 1, SPRSORT_LOW);


I am sorting on userdat1, and have initialized all sprites to have an int value assigned
 

void initLevel() {
    // Set Z-Pos (userdat1) for all sprites
    sprite[background].userdat1 = SCALE_DOWN;  
 
    for(int i = ship; i < font; i++) {
        sprite[i].userdat1 = SCALE_NORMAL;  
    }
 
    sprite[font].userdat1 = SCALE_UP + 1;
}


Sprite Definitions ( background and font are always active )

enum sprites {
    background = 0,
    ship,
    boss,  
    column1_1,
    column1_3,    
    bullet1,
    bullet1_2,
    bullet1_3,
    bullet1_4,
    bullet1_5,
    bullet1_6,
    bullet1_7,
    bullet1_8,
    bullet1_9,    
    bullet1_10,    
    bullet1_11,
    bullet1_12,
    bullet1_13,
    bullet1_14,
    bullet1_15,
    bullet1_16,
    bullet1_17,
    bullet1_18,
    bullet1_19,    
    bullet1_30,        
    enemy_bullet1,
    enemy_bullet1_2,
    enemy_bullet1_3,
    enemy_bullet1_4,
    enemy_bullet1_5,
    enemy_bullet1_6,
    enemy_bullet1_7,
    enemy_bullet1_8,
    enemy_bullet1_9,    
    enemy_bullet1_10,    
    enemy_bullet1_11,
    enemy_bullet1_12,
    enemy_bullet1_13,
    enemy_bullet1_14,
    enemy_bullet1_15,
    enemy_bullet1_16,
    enemy_bullet1_17,
    enemy_bullet1_18,
    enemy_bullet1_19,    
    enemy_bullet1_30,            
    explosion1,
    explosion1_2,
    explosion1_3,
    explosion1_4,
    explosion1_5,
    explosion1_6,
    explosion1_7,
    explosion1_8,        
    explosion1_9,
    explosion1_10,
    shield1,
    enemy1_1,
    enemy1_2,
    enemy1_3,
    enemy1_4,
    enemy1_5,
    enemy1_6,    
    vision1,
    font
};
Edited by OVERRiDE
Link to comment
Share on other sites

33 minutes ago, OVERRiDE said:

 Is there some limitation that all sprites in the list to be sorted need to be active?  I seem to get issues when de-activiting sprites in the middle of the list being sorted.

 

 

Yes, I'm pretty sure they all need to remain active. @CyranoJ can confirm though in case I'm misremembering as it's an API call (I'll then update the docs). 

 

As a workaround, you could set them all to "edge_ignore" and the y position to 300 (for example). Raptor will still process them but they won't be drawn. 

Link to comment
Share on other sites

1 hour ago, OVERRiDE said:

Ok so back on this topic, I am seeing hardware crashes when using the zsort function in some scenarios and I'm not sure why ( able to reproduce in BigP + real hardware ).

 

I've followed the comments in the sample project - I have an active sprite before and after the first and last sprite being sorted.  Is there some limitation that all sprites in the list to be sorted need to be active?  I seem to get issues when de-activiting sprites in the middle of the list being sorted.

 

Function Call:

rapSortSprites(ship, R_sprite_userdat1, font - ship - 1, SPRSORT_LOW);


I am sorting on userdat1, and have initialized all sprites to have an int value assigned
 

void initLevel() {
    // Set Z-Pos (userdat1) for all sprites
    sprite[background].userdat1 = SCALE_DOWN;  
 
    for(int i = ship; i < font; i++) {
        sprite[i].userdat1 = SCALE_NORMAL;  
    }
 
    sprite[font].userdat1 = SCALE_UP + 1;
}

 

Sorry I can't help with your question, but I have to ask.  How to you get such nicely formatted text to display?  Anything I try to paste into the forum turns to trash, spacing goes all to hell, etc.

Link to comment
Share on other sites

20 minutes ago, Stephen said:

Sorry I can't help with your question, but I have to ask.  How to you get such nicely formatted text to display?  Anything I try to paste into the forum turns to trash, spacing goes all to hell, etc.

Copy / Paste from my IDE lol.  I use Visual Studio Code for my Jag projects.  Something like Notepad++ may not play so nicely ( recommend code editor for JagStudio for whatever reason )

Link to comment
Share on other sites

1 hour ago, Sporadic said:

Yes, I'm pretty sure they all need to remain active. @CyranoJ can confirm though in case I'm misremembering as it's an API call (I'll then update the docs). 

 

As a workaround, you could set them all to "edge_ignore" and the y position to 300 (for example). Raptor will still process them but they won't be drawn. 

Thanks for the reply!  To understand fully, when you say "wont be drawn", you mean wont be visible on-screen, or wont be processed by the OP?  If the later, how does Raptor determine what not to send to the OP?  Any sprite where ypos > screen height?

Edited by OVERRiDE
Link to comment
Share on other sites

15 minutes ago, CyranoJ said:

You don't need to sort bullets or explosions they're on the same layer. 

 

Arrange the list sensibly and you likely won't have to sort at all 

Your making the assumption that Z values are static, which is a reasonable assumption but in this case is not correct 😉

Link to comment
Share on other sites

20 minutes ago, OVERRiDE said:

Copy / Paste from my IDE lol.  I use Visual Studio Code for my Jag projects.  Something like Notepad++ may not play so nicely ( recommend code editor for JagStudio for whatever reason )

Odd - I also use VS Code.  Wonder if it's a linefeed issue?

Link to comment
Share on other sites

6 hours ago, OVERRiDE said:

Thanks for the reply!  To understand fully, when you say "wont be drawn", you mean wont be visible on-screen, or wont be processed by the OP?  If the later, how does Raptor determine what not to send to the OP?  Any sprite where ypos > screen height?

I'm pretty sure Raptor will cull it and it won't be added to the OP display list. 

Link to comment
Share on other sites

9 hours ago, CyranoJ said:

RAPTOR sends the entire list to the OP, and then patches up the link pointers to skip over disabled items.

So then culling is not actually applied and all sprites that are active will be sent to OP, regardless of X,Y position?

 

Instead of moving the inactive sprites coordinates and keeping them active, I've done a quick test of storing active flags while making all sprites active, sorting, then restoring the active flags, but this is leading to some quite odd results.  Raptor does not seem to be happy with this approach lol.

 

Is it possible to just generate the display list during run-time instead of having the OP list generated at compile time?  For example, rapPushSprite(x,y, width, height, gfxbase, ... ) or rapPushSprite(OP sprite in RAM) which would add a sprite to the display list for a single frame?

Link to comment
Share on other sites

Culling is perfomrned to remove ("skip over") active sprites by changing the list link pointers. I'm not sure what you mean by "not applied" as this is effectively the same thing.  If a sprite is active, its being sent to the OP.  If it's outside of x/y boundaries, and edge_kill is set, it will be culled, else, its going to the ObjectProcessor as instructed.

 

You can set up a basic RAPTOR list then use the pre/post Object creation as described in the manual, but don't expect huge performance from this.

 

I would suggest stop trying to force raptor to do what you think you need and instead work with it to get the results you require.  It does require a change in methodology from the norm of "code must control everything" but the results will be worth it.

Link to comment
Share on other sites

On 4/26/2023 at 11:16 AM, OVERRiDE said:

Your making the assumption that Z values are static, which is a reasonable assumption but in this case is not correct 😉

 

Then create bullets in each depth plane, and set them all to inactive, and swap them when then change - no sorting required.

 

Inactive objects cost you nothing.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...