Duke4.net Forums: cstat 1024 - Duke4.net Forums

Jump to content

Hide message Show message
Welcome to the Duke4.net Forums!

Register an account now to get access to all board features. After you've registered and logged in, you'll be able to create topics, post replies, send and receive private messages, disable the viewing of ads and more!

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

cstat 1024

User is offline   MetHy 

#1

cstat 1024 which was introduced in r5400 has apparently been broken since r5491

Comparison, sprite in front has cstat 1024:

r5474

https://i.imgur.com/gcPRRVs.png

r5491:

https://i.imgur.com/OZTv8TT.png


I think nobody realized since due to the lack of communication on this feature, afaik it's nowhere to be found on the wiki for instance, I barely remembered it existed until a few days ago myself. If it is possible to fix it I would recommend adding a hotkey for it, it could be a very useful feature if mappers knew when they can use it.

Joined is a test map, the start point is the same angle as in the pics above, it should give sprite clipping unless cstat1024 works and gives the sprite in front a higher priority.

Thanks

Attached File(s)

  • Attached File  test.rar (265bytes)
    Number of downloads: 42


This post has been edited by MetHy: 12 April 2019 - 12:46 AM

2

User is offline   Mark 

  • Honored Donor

#2

I never noticed the break because I've always turned off grid locking in Mapster32 and manually drag the top sprite out a tiny bit.
0

User is offline   oasiz 

  • Dr. Effector

#3

Unfortunately that doesn't help in all cases as there can be math / rounding errors where the wrong sprite will be in front of you. This can happen at more odd angles quite easily.
Try putting a sprite paper on the wall and start writing "text" on it and you will see that some letters will be eaten by the paper without mercy.

This is more of a "You are lower priority and I double dog dare you to try otherwise"
0

User is offline   Mark 

  • Honored Donor

#4

Hmm...Manually spacing them works for me. I guess I've been lucky so far.

This post has been edited by Mark: 12 April 2019 - 01:13 AM

0

User is offline   MetHy 

#5

The front sprite is placed in front of the bottom one in the test example and test map I've provided.

From most view angles it looks fine, but there are angles, like where I took the screenshots from, where clipping occurs, especially in classic.
Cstat 1024 would make sure it's always given the highest rendering priority, no matter where you view them from. Helpful with sprite constructions, lights and gradients, etc

This post has been edited by MetHy: 12 April 2019 - 01:35 AM

0

User is online   Trooper Dan 

  • Duke Plus Developer

#6

I've tried using that cstat a few times but it has never worked for me. Come to think of it, all of my attempts were post 5400. I didn't bother reporting it because I figured it was an experimental feature that never worked in the first place. Interesting to see that it did work in the past.
1

User is offline   Mark 

  • Honored Donor

#7

View PostMetHy, on 12 April 2019 - 01:31 AM, said:

The front sprite is placed in front of the bottom one in the test example and test map I've provided.

From most view angles it looks fine, but there are angles, like where I took the screenshots from, where clipping occurs, especially in classic.
Cstat 1024 would make sure it's always given the highest rendering priority, no matter where you view them from. Helpful with sprite constructions, lights and gradients, etc

Maybe its a software mode thing. I use 32bit and polymer.
0

User is offline   Mark 

  • Honored Donor

#8

I loaded the test map and it does indeed glitch only in software mode which explains why I didn't notice it long ago.
According to the changelogs, 5484 made a fix to cstat 1024. I guess it didn't work as intended.

This post has been edited by Mark: 12 April 2019 - 04:55 AM

0

User is offline   Hendricks266 

  • Weaponized Autism

  #9

View PostMetHy, on 12 April 2019 - 12:44 AM, said:

cstat 1024 which was introduced in r5400 has apparently been broken since r5491

I think you fell into a trap when bisecting this. As Mark noted, r5484 was a faulty commit, but it got reverted in r5723 and I debugged and reinstated it in r5857, confirming at that time that it worked in Polymost. If it broke a second time in Polymost it must have happened after that point.
0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks are property of their respective owners. Instead of reading this text, you could be playing Ion Fury! ;) © 2019 Voidpoint, LLC

Enter your sign in name and password


Sign in options