OVERRiDE Posted March 23, 2023 Share Posted March 23, 2023 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: 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, Quote Link to comment Share on other sites More sharing options...
CyranoJ Posted March 23, 2023 Share Posted March 23, 2023 See example: zsort 1 1 Quote Link to comment Share on other sites More sharing options...
OVERRiDE Posted March 23, 2023 Author Share Posted March 23, 2023 @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? Thanks! 1 Quote Link to comment Share on other sites More sharing options...
Sporadic Posted March 23, 2023 Share Posted March 23, 2023 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. 3 1 Quote Link to comment Share on other sites More sharing options...
OVERRiDE Posted March 23, 2023 Author Share Posted March 23, 2023 @Sporadic it's all so obvious once you point that out 😅 This topic is solved. Thanks guys! 2 Quote Link to comment Share on other sites More sharing options...
OVERRiDE Posted April 25, 2023 Author Share Posted April 25, 2023 (edited) 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 April 25, 2023 by OVERRiDE Quote Link to comment Share on other sites More sharing options...
Sporadic Posted April 26, 2023 Share Posted April 26, 2023 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. Quote Link to comment Share on other sites More sharing options...
CyranoJ Posted April 26, 2023 Share Posted April 26, 2023 Yes, they'll need to be active. Quote Link to comment Share on other sites More sharing options...
Jag_Mag Posted April 26, 2023 Share Posted April 26, 2023 (edited) Pre planning your game is a must,made mistakes in frogger that taught me a lot. Edited April 26, 2023 by Jag_Mag Quote Link to comment Share on other sites More sharing options...
+Stephen Posted April 26, 2023 Share Posted April 26, 2023 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. Quote Link to comment Share on other sites More sharing options...
CyranoJ Posted April 26, 2023 Share Posted April 26, 2023 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 Quote Link to comment Share on other sites More sharing options...
OVERRiDE Posted April 26, 2023 Author Share Posted April 26, 2023 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 ) Quote Link to comment Share on other sites More sharing options...
OVERRiDE Posted April 26, 2023 Author Share Posted April 26, 2023 (edited) 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 April 26, 2023 by OVERRiDE Quote Link to comment Share on other sites More sharing options...
OVERRiDE Posted April 26, 2023 Author Share Posted April 26, 2023 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 😉 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted April 26, 2023 Share Posted April 26, 2023 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? Quote Link to comment Share on other sites More sharing options...
OVERRiDE Posted April 26, 2023 Author Share Posted April 26, 2023 28 minutes ago, Stephen said: Odd - I also use VS Code. Wonder if it's a linefeed issue? Perhaps... are you on Linux? Im on Windows and things "just work" lol Quote Link to comment Share on other sites More sharing options...
CyranoJ Posted April 26, 2023 Share Posted April 26, 2023 49 minutes ago, OVERRiDE said: Your making the assumption that Z values are static, which is a reasonable assumption but in this case is not correct 😉 OK, but don't assume the 30 year old Jaguar is an i5 1 Quote Link to comment Share on other sites More sharing options...
Sporadic Posted April 26, 2023 Share Posted April 26, 2023 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. Quote Link to comment Share on other sites More sharing options...
CyranoJ Posted April 26, 2023 Share Posted April 26, 2023 RAPTOR sends the entire list to the OP, and then patches up the link pointers to skip over disabled items. Quote Link to comment Share on other sites More sharing options...
OVERRiDE Posted April 26, 2023 Author Share Posted April 26, 2023 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? Quote Link to comment Share on other sites More sharing options...
CyranoJ Posted April 26, 2023 Share Posted April 26, 2023 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. Quote Link to comment Share on other sites More sharing options...
CyranoJ Posted April 28, 2023 Share Posted April 28, 2023 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. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.