Jump to content
Sign in to follow this  
LordKraken

Dynamic sprite properties

Recommended Posts

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!

Share this post


Link to post
Share on other sites
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.

 

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites
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.

  • Like 2

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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 by Zerosquare
  • Like 2

Share this post


Link to post
Share on other sites
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.

  • Like 2

Share this post


Link to post
Share on other sites
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 :D

 

 

  • Like 2
  • Haha 2

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

  • Like 4

Share this post


Link to post
Share on other sites
12 minutes ago, LordKraken said:

Awesone thx! Will make z-sorting easier :)

Plan on adding Z-Sorting next.

  • Like 3

Share this post


Link to post
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...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...