EDuke32 Scripting "CON coding help"
#901 Posted 18 September 2012 - 09:59 PM
#902 Posted 18 September 2012 - 11:53 PM
I've been thinking of incorporating some of the math commands added in EDuke 2.1.1, though obviously not the dumb ones like finddist2d. Thoughts?
#903 Posted 19 September 2012 - 04:26 AM
#905 Posted 19 September 2012 - 05:39 AM
#906 Posted 19 September 2012 - 05:51 AM
This post has been edited by Fox: 19 September 2012 - 05:51 AM
#907 Posted 19 September 2012 - 06:12 AM
#908 Posted 19 September 2012 - 06:18 AM
But using CON you can force them to remain only blocked. So you can have objects like Doom, which block your passage but let projectiles fly across it.
#909 Posted 19 September 2012 - 06:22 AM
Fox, on 19 September 2012 - 06:18 AM, said:
Maybe that's why I assumed they (blocking players & blocking bullets) are one and the same.
#910 Posted 19 September 2012 - 07:04 AM
Hendricks266, on 18 September 2012 - 11:53 PM, said:
Adding these seems sensible, since what we have now with dist and ldist can lead to kind of API-inverted code ("set sprite positions, call dist, reset positions." Ugh.)
By the way, they compute pretty crude approximations to the hypotenuse length, for example ldist is
125/128 * max(x,y) + 53/128 * min(x,y).
See the second answer for this question on stackoverflow for the idea behind it (53/128 = 0.41406, sqrt(2)-1 = 0.41421, approximately).
Quote
I'm less sure about those ones being useful. The composite ones like "sin(a - b)" can make sense in a floating point setting, where computing them in a special fashion may significantly increase accuracy, but with integers being the only numeric type in CON, there's not much to be gained. For the hypotenuse length, we have calchypotenuse (unwieldy long name for fear of name collisions). I'm not very happy with the way it turned out though, it currently has a discontinuity at the squared hypotenuse equalling INT32_MAX. X raised to the Yth power is something that CON is missing, but again, with only integers there doesn't seem to be much use for it, since you'd most often use Y=2 or Y=3. Mod and abs would not add anything really new. This leaves the tangent and the logarithm: the first can be calculated by a ratio of the sine to the cosine (with appropriate scaling), and a base-2 log could be useful (but possible to code as loop currently[*]), the natural one looking out of place again.
[*]edit: I'm thinking about the rounded variety here, like "log2(9)=3".
#911 Posted 19 September 2012 - 11:28 AM
If not, would this be at all possible to implement? I can see several potential uses for this.
#912 Posted 19 September 2012 - 11:41 AM
As far as adding math commands, I think the more coding features into the engine is always better. The "power" or exponent math would be very attractive for some stuff I'm doing (expvar and expvarvar?). I think having better trig functions would be awesome, but exactly which ones or how they're implemented I'll leave guessing up to people more involved.
This post has been edited by Reaper_Man: 19 September 2012 - 12:25 PM
#913 Posted 19 September 2012 - 12:38 PM
Reaper_Man, on 19 September 2012 - 11:41 AM, said:
Do you need the ability to pass fractional bases or exponents? In that case, we'd need to decide where to place the implicit binary point. (Or pass numerator and denominator separately, but I guess that would be just as confusing.)
Quote
In which way "better"? CON's sine and cosine have 15 bits of precision. Approximate arctangent is there (getangle), tangent can be calculated as mentioned previously. Is there anything practical missing?
#914 Posted 19 September 2012 - 01:11 PM
I'm sorry I meant "more" and not "better". I also can't think of anything off hand, I haven't had to do trig math in eduke in a while, so hopefully someone else can field that better.
EDIT
An absolute value command would be useful too (absvar).
This post has been edited by Reaper_Man: 19 September 2012 - 02:21 PM
#915 Posted 19 September 2012 - 03:15 PM
ifvarl X 0 mulvar X -1
for the "absvar" function.
#916 Posted 19 September 2012 - 04:47 PM
Reaper_Man, on 19 September 2012 - 11:41 AM, said:
I like yours better.
Reaper_Man, on 19 September 2012 - 11:41 AM, said:
I used to think this but then I realized I only wanted it for ^0.5 to do a square root and then I discovered the sqrt command. Generally you'll only want a square or cube, so you can mulvarvar 2-3 times. Much more and the int32s could overflow.
Helixhorned, on 19 September 2012 - 12:38 PM, said:
This reminds me: there are two things I have promised to add that will have to involve integer <--> float conversion for use in CON. One is a "rotatemodel" command which will be rotatesprite with additional model parameters such as pitch and roll added. The other is a userdef control for the ambient light level. Should I use the same mulscale implementation as the trig commands, use a numerator/denominator style, or something different? I like the fraction myself.
#917 Posted 19 September 2012 - 05:36 PM
RichardStorm, on 19 September 2012 - 03:15 PM, said:
ifvarl X 0 mulvar X -1
for the "absvar" function.
Yes it works. My code is littered with things like that. It's not only a wasted cycle/computation it's longer code. It's stupid to run If-Then when you don't need to.
#918 Posted 19 September 2012 - 06:18 PM
Mblackwell, on 19 September 2012 - 05:36 PM, said:
Unless there is a measurable impact of that you can show me, implementing expvar and absvar commands would only perform those instructions on the source side. It would by far be the most optimal way to implement them. Anything else (including going through C math.h functions) would be even slower, which is still only a relative term.
The execution of the CON VM is nowhere close to being a bottleneck. With a constant, maximum 30 game states per second performance requirement, some simple math doesn't have much impact.
#919 Posted 19 September 2012 - 06:45 PM
Dig?
#920 Posted 19 September 2012 - 07:35 PM
As for floating point math, I'm well used to the dirty trick of multiplying vars by 10 or 100 depending on what decimal place I'll need access to, then diving back down when I'm done. Like I said, used to doing dirty tricks.
This post has been edited by Reaper_Man: 19 September 2012 - 07:36 PM
#921 Posted 20 September 2012 - 12:48 AM
Hendricks266, on 19 September 2012 - 04:47 PM, said:
The additional parameters for "rotatemodel" being angles, I suggest going the least surprising route and making them BUILD angles (0..2047). For the ambient light, scaling by 100 would be convenient, I think, so that values from 0 to 1000 correspond to r_ambientlight of 0 to 10.
#922 Posted 20 September 2012 - 04:23 AM
#923 Posted 20 September 2012 - 04:26 AM
Helixhorned, on 20 September 2012 - 12:48 AM, said:
But you'd lose a lot of the accuracy that way (rotation). It would be better to use something similar to the z parameter so 32768 is half, 65536 is a full rotation if you want it to be flawless. However I believe you're correct and the current pitch/yaw/roll parameters accept/use -1024 to 1024
#924 Posted 20 September 2012 - 04:15 PM
RichardStorm, on 20 September 2012 - 04:23 AM, said:
I believe you need to add code so that when any actor is hit by one, it shoots another one with the same values gathered from the ht* members.
#925 Posted 20 September 2012 - 06:56 PM
Hendricks266, on 20 September 2012 - 04:15 PM, said:
That's correct unless you do weird tricks like change the spritestat to actor, move the actor, and then change it back to a projectile. But now I've just confused the situation.
#926 Posted 21 September 2012 - 12:08 AM
Hendricks266, on 20 September 2012 - 04:15 PM, said:
True, I did something like that with hitscan to make a Railgun. It worked very well in the end.
By the way, the Railgun in Shadow Warrior is veeery lame, while the trail spawns behind any actor (until it hits a wall), the shoot itself stops when it hits the first obstacle. So it gives the illusion of piercing, but in reality he doesn't do that.
#927 Posted 21 September 2012 - 12:16 AM
Fox, on 21 September 2012 - 12:08 AM, said:
This is sadly true. I wanted to test the Railgun's capabilities so I made a test map with a ninja of every SW sprite pal (0-32) lined up in a very narrow corridor, with a dead end on one end and a window with a raised ledge on the other so I could shoot them with impunity. I was very disappointed when they took 33 shots to kill.
#928 Posted 21 September 2012 - 12:31 AM
#929 Posted 21 September 2012 - 02:05 AM
This post has been edited by RichardStorm: 21 September 2012 - 02:57 AM