ZDaemon Forum Index ZDaemon
Client/Server DOOM
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

[Dehacked]XScale and YScale thing property

 
Post new topic   Reply to topic    ZDaemon Forum Index -> Implemented Requests
View previous topic :: View next topic  
Author Message
Body-Guard
Spamming!


Joined: 08 Jan 2006
Location: Hungary

PostPosted: Sun Aug 24, 2014 1:45 pm    Post subject: [Dehacked]XScale and YScale thing property Reply with quote

Although dehacked has a Scale property, it does not allow different scaling on different axis. Reading a bit of d_dehacked.cpp I found this:

Code:
else if (stricmp (Line1, "Scale") == 0)
            {
               info->xscale = clamp ((int)(atof (Line2) * 64), 1, 256) - 1;
               info->yscale = clamp ((int)(atof (Line2) * 64), 1, 256) - 1;
            }


This is just a guess, but if I am correct, the only thing preventing us from having the ability to scale individually on X and Y axis is that dehacked does not have keyword for it.

Request: Provide XScale and YScale keyword so we can scale on individual axis too. Example dehacked code:

Code:
# Scales equally on both axis, we have this already
Thing 1
Scale = 0.5


Code:
# Different scale for X and Y, this feature request
Thing 2
XScale = 0.3 
YScale = 0.7



This feature would not deprecate Scale keyword. (it is still useful if we need equal scaling on X and Y, and backwards compatibility)
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
Sr69Mm-jC
Spamming!


Joined: 21 Jul 2011

PostPosted: Sun Aug 24, 2014 3:15 pm    Post subject: Reply with quote

What should the behavior be if some user defines both Scale and XScale for example? Should X/Y scalers override the 'normal' scale in this case? Or should they stack up, rather?
Back to top
View user's profile Send private message
Body-Guard
Spamming!


Joined: 08 Jan 2006
Location: Hungary

PostPosted: Sun Aug 24, 2014 3:22 pm    Post subject: Reply with quote

Apart from that being a "don't do that" situation, could be handled like this:

if Scale AND XScale OR YScale is present (2 of the keywords):
-use Scale keyword (ignore the lone XScale/YScale)

if Scale AND XScale AND YScale is present (all 3 keywords):
-use XScale and YScale (ignore Scale)

if only XScale is present:
-use XScale value, YScale is default (1.0)

if only YScale is present:
-use YScale value, XScale is default (1.0)

I think that pretty much sums up the logic.
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
Empyre
Spamming!


Joined: 13 Dec 2006
Location: Texas, USA

PostPosted: Mon Aug 25, 2014 12:57 am    Post subject: Reply with quote

Another way to do it would be to apply all uses of Scale, XScale, and YScale in the order in which they appear. For example: If XScale 1.25 appears and then Scale 0.75, then the sprite would be stretched horizontally by 1.25 first, and then shrunk overall by 0.75.
If the engine can't handle doing multiple scaling operations, then the logic in the above post would be best. After thinking about it some more, maybe that would be better than my idea anyway. That way, a wad maker could use XScale and YScale to fine-tune the shape of the sprite in ZDaemon, but also include Scale for other ports that don't support XScale and YScale, with the caveat that those other ports might choke on the commands they don't support, rather than just skipping past them.
My conclusion is that I have no conclusion. This is simply food for thought.
Back to top
View user's profile Send private message Send e-mail
Body-Guard
Spamming!


Joined: 08 Jan 2006
Location: Hungary

PostPosted: Mon Aug 25, 2014 8:24 am    Post subject: Reply with quote

Dehacked is luckily intelligent enough to skip unknown keywords. The format that is used by Zdaemon is around since 1998 and became pretty much a stable standard at ZDoom based ports (with BEX extensions coming from Boom). No need to worry about our custom additions, they simply get ignored at other ports. Besides, anyone would rather go with DECORATE at ZDoom so there is no need to go down that harsh on compatibility regarding dehacked. As long as it doesn't break existing patches and it is a feasible request, there is basically no reason to not to implement it.
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
UberGewei
SuperAntler


Joined: 01 Sep 2010
Location: The Netherlands

PostPosted: Sat Jan 04, 2020 11:36 am    Post subject: Reply with quote

Accepted & added for next release.

Body-Guard wrote:
Apart from that being a "don't do that" situation, could be handled like this:

if Scale AND XScale OR YScale is present (2 of the keywords):
-use Scale keyword (ignore the lone XScale/YScale)

if Scale AND XScale AND YScale is present (all 3 keywords):
-use XScale and YScale (ignore Scale)

if only XScale is present:
-use XScale value, YScale is default (1.0)

if only YScale is present:
-use YScale value, XScale is default (1.0)

I think that pretty much sums up the logic.


For the biggest part I agree with that logic, but scale will always remain the standard. Therefore, if scale is present, xscale and yscale are ignored.
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    ZDaemon Forum Index -> Implemented Requests All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group