LordKraken Posted February 20, 2021 Share Posted February 20, 2021 Hello, So I have been playing around last evening and I'm wondering which sprite properties are static (i.e defined at compile time in rapinit.s). Let me use an example: sprite[sprBugIndex].scaled = R_spr_scale; sprite[sprBugIndex].scale_x = 64; sprite[sprBugIndex].scale_y = 64; This code actually does not work, unless the scale flag is already set to spr_scale in rapinit.s for this sprite. Are there other flags that can only be define at compile time? Maybe we could update Table A in the doc? thx! Quote Link to comment Share on other sites More sharing options...
Sporadic Posted February 20, 2021 Share Posted February 20, 2021 18 minutes ago, LordKraken said: Hello, So I have been playing around last evening and I'm wondering which sprite properties are static (i.e defined at compile time in rapinit.s). Let me use an example: sprite[sprBugIndex].scaled = R_spr_scale; sprite[sprBugIndex].scale_x = 64; sprite[sprBugIndex].scale_y = 64; This code actually does not work, unless the scale flag is already set to spr_scale in rapinit.s for this sprite. Are there other flags that can only be define at compile time? Maybe we could update Table A in the doc? thx! I'm pretty sure that should work, as all properties are definable at runtime now. So you may have just found a bug I'll investigate and report back. Quote Link to comment Share on other sites More sharing options...
Sporadic Posted February 20, 2021 Share Posted February 20, 2021 That is indeed something that cannot be changed just by that property. I will update the docs. There might be a workaround we can do to update that property which we will look into in due course. Thanks for finding that. 1 Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted February 20, 2021 Share Posted February 20, 2021 41 minutes ago, Sporadic said: So you may have just found a bug Not a bug, an omission! It never occured to me anyone would want to do that. I'll add it to the "to-do' list for the API. 2 Quote Link to comment Share on other sites More sharing options...
LordKraken Posted February 20, 2021 Author Share Posted February 20, 2021 To be fair I would probably never do that in a real game, just played around with the sprites, so that's how I ended having that code (there might be a use case though, for instance if we reorder the sprite list to fake a z-buffer, etc.) Also, stupid question, is there a performance impact if the flag is always on but the zoom factor is 1 (well 32). Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted February 20, 2021 Share Posted February 20, 2021 (edited) 7 minutes ago, LordKraken said: To be fair I would probably never do that in a real game, just played around with the sprites, so that's how I ended having that code (there might be a use case though, for instance if we reorder the sprite list to fake a z-buffer, etc.) Also, stupid question, is there a performance impact if the flag is always on but the zoom factor is 1 (well 32). Yes, scaled sprites take longer to be processed by the object processor than standard ones, even at unity zoom. Edited February 20, 2021 by Zerosquare 2 Quote Link to comment Share on other sites More sharing options...
Clint Thompson Posted February 21, 2021 Share Posted February 21, 2021 12 hours ago, LordKraken said: Also, stupid question, is there a performance impact if the flag is always on but the zoom factor is 1 (well 32). 12 hours ago, Zerosquare said: Yes, scaled sprites take longer to be processed by the object processor than standard ones, even at unity zoom. Definitely not a stupid question, I never knew until I started playing around with the scaling myself and then later found some documentation covering the issue some time later. Curious, what brought up the question though as it seems you may have snagged somewhere? I was quick to learn it can cause some nasty problems (degradation quickly) if you're trying to do too much by way of a lot of 16-bit graphics and multiple higher quality sounds at the same time. And to further clarify for anyone else who may stumble upon this, this is not an underlying issue or weakness with JagStudio, this is a Jaguar issue at its core. 2 Quote Link to comment Share on other sites More sharing options...
LordKraken Posted February 21, 2021 Author Share Posted February 21, 2021 6 hours ago, Clint Thompson said: And to further clarify for anyone else who may stumble upon this, this is not an underlying issue or weakness with JagStudio, this is a Jaguar issue at its core. What!? but it cannot be Jaguar fault, it's a 64 bits 2 2 Quote Link to comment Share on other sites More sharing options...
JagMod Posted February 21, 2021 Share Posted February 21, 2021 Ideally what should happen is that whenever the scale_x and scale_y values are both equal to 32, it should revert back to an unscaled bitmap automatically. Then you don't need the .scaled flag. e.g. Scaled: sprite[sprBugIndex].scale_x = 64; sprite[sprBugIndex].scale_y = 64; Not Scaled: sprite[sprBugIndex].scale_x = ; sprite[sprBugIndex].scale_y = ; Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted February 26, 2021 Share Posted February 26, 2021 Setting the scale flag dynamically has been added to the API and will be in the next API release, and from there into JagStudio. 4 Quote Link to comment Share on other sites More sharing options...
LordKraken Posted February 26, 2021 Author Share Posted February 26, 2021 Awesone thx! Will make z-sorting easier Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted February 26, 2021 Share Posted February 26, 2021 12 minutes ago, LordKraken said: Awesone thx! Will make z-sorting easier Plan on adding Z-Sorting next. 3 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.