Dynamic sprite properties

[LordKraken]

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!

[Sporadic]

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.

 

[Sporadic]

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.

[+CyranoJ]

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.

[LordKraken]

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).

[Zerosquare]

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

[Clint Thompson]

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.

[LordKraken]

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

 

 

[JagMod]

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 = ;

[+CyranoJ]

Setting the scale flag dynamically has been added to the API and will be in the next API release, and from there into JagStudio.

[LordKraken]

Awesone thx! Will make z-sorting easier

[+CyranoJ]

12 minutes ago, LordKraken said:

Awesone thx! Will make z-sorting easier

Plan on adding Z-Sorting next.