Skip to main content ↑ ↓
Topic: Sphere SFML v0.90 (Read 1565447 times) previous topic - next topic
0 Members and 4 Guests are viewing this topic.

Re: Sphere SFML v0.75alpha

Reply #135 –
So Atan2 will give an angle. This is the direction to offset the distance check by.
Cos will give you the amount of X to use, Sin will give you the amount of Y to use.
So, in fact it kinda turns the persons base into an oval or a circle if they have a square base.

Image 1 is a person to the left (the player) trying to talk to the person on the right. Notice the 8 pixels do not go far enough.

Image 2 includes the correction. Since you are to the left Atan2 will return PI. Cos(PI) is 1, and so 8 pixels (the size of the bases width divided by 2). That's enough to puncture the base and give you a distance within 8 pixels of the player. Atan2 is used since we need to add this offset to each direction you could approach the other sprite at.

In fact if I assumed a square base I don't need all of that math. I just add size/2 to the distance and just use that.
Code: (csharp) [Select]

Line[] pBase = person.GetBounds();
int w = (int)(pBase[0].End.X - pBase[0].Start.X);
float dx = person.Position.X - compare.Position.X;
float dy = person.Position.Y - compare.Position.Y;
 
if ((int)Math.Sqrt(dx * dx + dy * dy) <= _talk_dist + w/2)
    return person.Name;


Since Atan2 would have just given an extra distance all around it can be simplified out. But that's not true if you approach from the east or the north for rectangular sprites, and so this accounting has to be made.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here
 

Re: Sphere SFML v0.75alpha

Reply #136 –
Wait, so Sphere calculates talk distance based on the center of the base...?  I guess it makes a certain amount of sense, but at the same time it's counterintuitive--if it were me implementing this from scratch, I'd probably set it up to use distance between the edges of the bases instead--or better yet, just inflate the base rects by the talk distance and simply check if they intersect.  This way the same talk distance would still work even if you changed the size of your sprites later.  Oh well, not much you can do since you're aiming for parity with Sphere.

Re: Sphere SFML v0.75alpha

Reply #137 –
Quote from: Lord English – on

Wait, so Sphere calculates talk distance based on the center of the base...?  I guess it makes a certain amount of sense, but at the same time it's counterintuitive--if it were me implementing this from scratch, I'd probably set it up to use distance between the edges of the bases instead.  This way the same talk distance would still work even if you changed the size of your sprites later.  Oh well, not much you can do since you're aiming for parity with Sphere.


No you are right, it uses the edges in a way. It starts from the center, then finds the edge, then checks distance from that edge to your edge, but mathematically. The side effect is that it turns it into ovals/circles rather than true rectangles. I'm actually not certain if that's what sphere really does, but it beats doing extra work to check in which direction you are talking from using constructs other than math.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Sphere SFML v0.75alpha

Reply #138 –
What's wrong with just inflating the baserects and checking for an intersection?  That would save you from having to do all that trig, which might help performance...

Re: Sphere SFML v0.75alpha

Reply #139 –
Quote from: Lord English – on

What's wrong with just inflating the baserects and checking for an intersection?  That would save you from having to do all that trig, which might help performance...


Actually I don't follow. It might work for square bases as I did above, but what about rectangular bases?
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Sphere SFML v0.75alpha

Reply #140 –
I think the issue revolves around the implementation of baserects in the first place. Even though there's only one per spriteset it can be placed anywhere on it and sized within the sprite's bounds. I gather there might have been an intent of one of the older devs to add support for multiple baserects per spriteset somewhere in the future, but that's pure conjecture on my part. If I was updating the spec I'd definitely use some of those reserved bytes in the beginning for more bases.

Re: Sphere SFML v0.75alpha

Reply #141 –
Quote from: Radnen – on

Quote from: Lord English – on

What's wrong with just inflating the baserects and checking for an intersection?  That would save you from having to do all that trig, which might help performance...


Actually I don't follow. It might work for square bases as I did above, but what about rectangular bases?


What I mean is, calculate the size of the rect for each dimension (x2 - x1, y2 - y1) and then add to the size of each dimension sqrt(talkdistance), keeping the center where it is.  Then simply check if the talker's inflated base intersects with the other sprite's base.  Now that I think about it though, this would allow you to talk to someone while facing away from them, which probably isn't desirable.  So yeah, your method is better. :P

Re: Sphere SFML v0.75alpha

Reply #142 –
No wait, in Sphere if you face away you can't talk to the other entity. In my Engine you can. This is a problem... I'll have to visit the vanilla talk code - it's doing more than just figuring out a distance.

And it's here:
https://github.com/sphere-group/sphere/blob/v1.6/sphere/source/engine/map_engine.cpp#L6110-6130

Definitely not what I expected! Potential bug in there; if your sprite doesn't have a cardinal direction it fails, even if you are facing the person you are talking to. I'll introduce direction vectors like in Lithonite and my combat engine. It'll solve the problem but not make it backwards compatible if you decide to use different directions for north/south/etc. But then again you wouldn't be able to use the FACE commands either.

Edit: I just used the Sphere method instead. The code looks like this now:
Code: (csharp) [Select]

        public static string GetClosest(string name)
        {
            int talk_x = GetPersonX(name), talk_y = GetPersonY(name);
            string direction = GetPersonDirection(name);

            if (direction.Contains("north"))
                talk_y -= _talk_dist;
            if (direction.Contains("south"))
                talk_y += _talk_dist;
            if (direction.Contains("east"))
                talk_x += _talk_dist;
            if (direction.Contains("west"))
                talk_x -= _talk_dist;

            foreach (Person p in People)
            {
                if (name == p.Name)
                    continue;
                float dx = p.Position.X - talk_x;
                float dy = p.Position.Y - talk_y;

                if ((int)Math.Sqrt(dx * dx + dy * dy) <= _talk_dist)
                    return p.Name;
            }
            return null;
        }
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Sphere SFML v0.75alpha

Reply #143 –
Interesting fact of the day:

In Sphere 1.5/1.6 using a map of pre-calculated sqrt values is almost 2x faster than using Math.sqrt.

In Sphere-Sfml: using Math.sqrt is almost 4x faster than a map of sqrt values.

That means using math in Sphere-sfml is so damn much faster than caching. Which is interesting since you can use a sqrt map to speed up your old games that used distance formulas often, but in my version of sphere you'll in fact get a slowdown. From this test I have also revealed that array accesses must be far slower than in Sphere 1.5/1.6, about 2x slower in fact. Despite being a language compiled to CIL I believe that 'boxing' and 'unboxing' is causing this.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Sphere SFML v0.75alpha

Reply #144 –
Boxing only applies when you convert a value type to a reference type (storing an int in a variable of type object, e.g.).  Just passing values around won't cause anything to be boxed or unboxed.  One thing you might want to try though: Compile the thing directly to x86 or x64 and test again.  Right now you're compiling it as "Any CPU", i.e. pure CIL.  I'm not positive, but I think targetting a specific platform lets the compiler make additional optimizations that it can't do in the general case.

Re: Sphere SFML v0.75alpha

Reply #145 –
Quote from: Lord English – on

Boxing only applies when you convert a value type to a reference type (storing an int in a variable of type object, e.g.).  Just passing values around won't cause anything to be boxed or unboxed.


So you think boxing doesn't happen in array [] resolutions? I'm pretty sure when you get or set an array element it's being boxed. Jurassic implements a Jurassic array with object types so when you put a double or int into an array it's boxing it somewhere down the line, and grabbing a value would then unbox it.

In Xamarin studio I can't make builds other than Any CPU. I might have to try in VS.

Edit:
It's slower when built for x86, and I don't have SFML for x64. Ugh, building for x64 is a nightmare. I don't know enough to get the References list to choose which dependency to use. I believe I need to create a cloned copy that uses a different references list entirely. But in the end I don't think making platform-specific builds will help that much...
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Sphere SFML v0.75alpha

Reply #146 –
If you have an array of ints, for example, and you store ints in it, it makes no sense for the ints to be boxed.  The array itself is a reference type, sure, but the elements aren't.  The only way you'd end up with boxing happening is if: 1) you have an array of type object and then store value-type values in it, or 2) you use one of the old, non-generic collection types like ArrayList that cast everything to object internally.  A native value-typed array should never cause anything to be boxed.  If it did, I think I would have to take that up with the compiler writer!

edit: Just found this Stack Overflow post, I was right, arrays don't box: http://stackoverflow.com/questions/8213887/does-system-array-perform-boxing-on-value-types-or-not

Re: Sphere SFML v0.75alpha

Reply #147 –
LordEnglish you can't compare a C# array to a JS array! There's a distinction between doing this in C# and implementing JS in C#.

In C# you can't do this without boxing:
Code: (csharp) [Select]

array[0] = 0;
array[1] = "hello";
array[2] = true;


Now tell me what you'd do to implement a JS array that behaves just like the above. Of course there's boxing involved!

Maybe I wasn't clear enough:
Quote from: Lord English – on

If you have an array of ints, for example


In a JS environment you can't be certain of that like you can in C#.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Sphere SFML v0.75alpha

Reply #148 –
OH!  See, I thought you meant the performance drain was on the C# side, you weren't entirely clear in the original post where the sqrt() calls were being done, and your remark at the end about a "language compiled to CIL" made me think you were referring to C#.  Especially since we were just discussing sqrt() earlier in the thread in the context of talk distance checking...

Re: Sphere SFML v0.75alpha

Reply #149 –
Ah, :P I can see how that can be ambiguous. Haha, yeah the JS engine I use compiles it to CIL, but must handle JS arrays as boxed C# arrays, it's the only way to do it, unless you use the new C# dynamic constructs, which Jurassic doesn't use since it was made prior to .NET 4.0.

Edit:
Ugh! People are created after the update script has ran at least once.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here