Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Disch

Pages: 1 2 [3] 4 5 ... 15
31
System / Syntax Error in initializing a Thread
« on: September 19, 2011, 04:34:30 am »
In SFML 1.6, the thread function must take a void* parameter:

Code: [Select]

void THreadFunc(void* userdata)
{
  //...
}

32
Feature requests / sf::Color, making it union
« on: September 19, 2011, 02:15:31 am »
I agree that this should not be added to SFML.

I also remember hearing the same thing about using unions this way as being undefined behavior.

That said... you can easily work around this in your program.  Just make your own color class that has union behavior and overload the sf::Color casting operator.

33
General / Collision between line and ball problem
« on: September 16, 2011, 07:18:51 am »
Very good job.  You really seem to understand the concept pretty well.

The problem is how you're testing the overlap.  Here's the function with my comments and fix:

Code: [Select]


bool IsColOnAxis(const VECTOR axisA, const VECTOR axisB, const VECTOR rectA[], const VECTOR rectB[])
{
    VECTOR axisAB = axisA - axisB;  // should be perpendicular axis, not parallel, but doesn't matter for rectangles.

    // if you want to correct that, though, you would do this instead of axisA - axisB:
    axisAB.y = axisA.x - axisB.x;
    axisAB.x = axisB.y - axisA.y;  // now axisAB is perpendicular to AB, not parallel

    // but again this REALLY doesn't matter with rectangles because each of the 2 important
    // axis are perpendicular to each other anyway.  If you were doing some other
    // kind of shape, though, this would have screwed it up.

    float Aprojections[4];
    float Bprojections[4];
    //rect A
    for(int i=0;i<4;i++)
    {
        Aprojections[i] = RetDotProduct(axisAB,rectA[i]-axisA) / RetDotProduct(axisAB,axisAB);  // probably should be "rectA[i]-axisB" since axisB is your origin.
                    // but that really doesn't matter.  All that will do is negate all your projected lines, but they will all be negated the same
                    // way, so it won't really affect anything.  I only bring it up because it confused me a little when I first saw it.
    }
    //rect B
    for(int i=0;i<4;i++)
    {
        Bprojections[i] = RetDotProduct(axisAB,rectB[i]-axisA) / RetDotProduct(axisAB,axisAB);  // same notes as above
    }

    float Amax = FindMax(Aprojections);
    float Amin = FindMin(Aprojections);
    float Bmax = FindMax(Bprojections);
    float Bmin = FindMin(Bprojections);

    // you only check to see if the B points are "inside" the A line
    //  you do not check to see if the A points are inside the B line, which will cause a failure
    //  when the A line is fully enclosed in the B line.
    //
    //  IE:
    //    ==================================    <- B
    //            =============                 <- A
    //
    //  In this case, your test was returning false, but it should be returning true.  This is why the function was failing sometimes.

    /*
    if((Bmin > Amin && Bmin < Amax) || (Bmax > Amin && Bmax < Amax)
        || (Amin > Bmin && Amin < Bmax) || (Amax > Bmin && Amax < Bmax))  // <- to fix you can add this
        return true;
   
    return false;
    */

    // Although the massive if statements are fugly and confusing.  Instead I would get rid of the above junk and do this instead:
    if(Bmax < Amin)     return false;
    if(Amax < Bmin)     return false;
    if(Bmin > Amax)     return false;
    if(Amin > Bmax)     return false;
    return true;

    // much simpler.  Also note that this is fewer checks (4 conditionals instead of 8) so it'll likely be faster.


    // You could also optimize this for rectangles.  The thing with rectangles is 2 of their sides are parallel with the other 2 sides.
    //  so really you only need to project 2 corners and not 4 (specifically, the corners that are not adjacent to each other, like [0] and [2])
    //
    // You also only need to project them onto 2 axis, not 4.  Because the other 2 axis will be parallel.
}

34
General discussions / The new graphics API in SFML 2
« on: September 15, 2011, 06:44:05 pm »
Quote from: "Laurent"
No! The point is to find something new that's much better than the current API. Ok, maybe the final result will be something very close to it, but please try to be as open as possible


Okay.  that was my misunderstanding.  =P

I'll think about this more when I get some free time.

35
General discussions / The new graphics API in SFML 2
« on: September 15, 2011, 04:48:03 am »
Quote from: "Laurent"
So a sprite would have to declare a getter/setter for every possible state: shader, view, transform, texture, blend mode.


Doesn't it already have that?  I thought the point here was to keep the current Sprite API as close to what it is now as possible while allowing the new lower-level functionality.

Quote
I don't think that getting rid of global states is a good idea. It's more flexible:


It's certainly flexible, but it's not very OO.  A good OO design can be just as flexible with less "gotcha!"  Perhaps don't remove it entirely, but I think you should definitely try to minimize it.

The whole idea of "global" is very "blech" to me.

Quote
some states are better activated once, globally, than assigned to every entity (view, shader)


I agree that View shouldn't be part of the RenderState class idea.  That's something that should be associated with a target.

It seems perfectly reasonable to me to have shaders associated with individual objects.  But if not, then keep them like they are now.  Separate things that you can optionally provide when you draw an object.

Quote
you can combine a transform with the current one (parent/child relationship)


I'm not sure I understand what you mean by this.  It sounds like you're saying you want to combine sf::Sprite's transform with the global transform -- but doesn't that kind of defeat the point?

Quote
- an object can set the states that it needs, while enjoying other states that it doesn't care about


Are you talking about high level objects (Sprite,Text) or low level ones (Mesh)?  I'm not sure I follow this either  =x



Maybe my idea wasn't really clear.  Let me try to better explain.

Sprite/Text API would stay pretty much the same as they are now.  You'd set them up and draw them to a RenderTarget.  They would be subject to further transformation by the target's View, but that's it.

The lower level API would require the user to keep a RenderState object and supply it whenever a mesh is drawn.  The mesh would be subject to transformations by the RenderState and by the target's View.  However since this RenderState does not have anything to do with any Sprites/Text, it wouldn't impact how those are drawn.


So to recap:

Overall association:
------------
View -> associated with RenderTarget
Color, Texture, Transform, Blend Mode -> associated with RenderState
Shader -> independent, applied per Draw() call as it is now


High level objects (Sprite/Text):
------------
Have an internal Mesh, RenderState.  Drawing a sprite would probably just be a wrap around drawing its interal mesh with its internal RenderState


Low level objects (Mesh):
------------
Need to have a RenderState supplied when drawing.  A shader could also optionally be supplied.


How it works:
--------------
You don't need to change any GL states between Draw calls unless the given RenderState has changed.  This means any number of Meshes can be drawn, all sharing the same RenderState, and the only thing that needs to be changed is the vertex/texcoord/etc lists you pass to OpenGL.

The higher level API still works as it did before.  The tradeoff of course being that you are constantly changing the render state for the sake of a simplified API.

What's more, since the RenderState embodies all the transformations, the high level API and the low level API operate independently, so you don't have to worry about the low level API "butting heads" with the high level API and causing unexpected transformations or other surprising/unpredicted render states.

36
General discussions / The new graphics API in SFML 2
« on: September 14, 2011, 01:20:20 am »
It sounds like the problem here is that there needs to be a global render state to accomidate the Mesh idea, but the Sprite idea needs its own render state that operates independently.


So how about introducing a new RenderState object?  When drawing a mesh, you would supply the desired RenderState (would have to be a mandatory parameter).  When drawing a Sprite, it would generate its own:

Code: [Select]

sf::RenderState lowlevelstate;
lowlevelstate.SetTexture( blah );
lowlevelstate.SetWhatever( whatever );

sf::Mesh mymesh = blah;
sf::Sprite mysprite = blah;

target.Draw( mymesh, lowlevelstate ); // uses low-level state
mysprite.Draw(target);  // uses sf::Sprite's internal state


sf::Sprite's Draw function would probably internally just manipulate it's own state and call target.Draw( spritemesh, spritestate ); or whatever.

37
General / Debug assertion fail!
« on: September 14, 2011, 01:01:03 am »
I guess I'm just too quick to blame heap corruption.  XD

Is this bug detailed somewhere?  It seems kind of strange that all you guys know about it but it hasn't been fixed yet.

EDIT:

I suppose I could try actually looking at the bugs page.  XD

https://github.com/SFML/SFML/issues/59


Don't mind me.

38
General / [SOLVED] SFML using 100% CPU (with limits on)
« on: September 13, 2011, 09:34:53 pm »
The way you have it coded, it will only do frames when events are in the queue, which is why you're getting such a low framerate.

Also when you're not running frames, you're spinning which is why you're eating up 100% CPU time.

The proper way to have a game loop would be like this:

Code: [Select]

while(_render.IsOpened())
{
  // empty the event queue
  sf::Event currentEvent;
  while(_render.PollEvent(currentEvent))  // <- while, not if
  {
    // notice in here we only do event stuff.  Do not render the scene here
    if(currentEvent.Type == currentEvent.Closed)
      _render.Close();
  }

  // NOW render the scene
  _render.Clear();

  _render.Display();
}


The idea is you want to render scenes unconditionally in a continuous loop.  The PollEvent thing just checks to see if any events have occurred that need your attention.

39
General / Segmentation fault
« on: September 13, 2011, 09:19:02 pm »
Can you post a small, simple program that reproduces the problem?

40
General / General questions about SFML 2.0
« on: September 13, 2011, 09:15:27 pm »
I'm not convinved the old approach (returning time in seconds as a float) was more precise.  In fact in another thread I recall Laurent even said that he never claimed timing functions ever got better than 1 ms precision.

Quote
Since GetFrameTime() and sf::Clocks both use Uint32, the minimum time that we can find is 1 ms, which gives us a top of 1000 FPS when measuring with 1/GetFrameTime().


Maybe try using a better method to measure the FPS?  =P

41
General / Debug assertion fail!
« on: September 13, 2011, 09:05:55 pm »
Quote
But that makes no sense.


Welcome to the wonderful world of heap corruption.  It might cause your program to crash.  It might cause it to do weird things.  Or it might work just fine with no hint of any problem.  What's more, which one it does might depend on the phase of the moon.

It's the worst/most difficult kind of bug to fix.  It's one of the reasons why people recommend you avoid using pointers directly.

Quote
Why would it work on 1.6


Because the heap would have been arranged differently and different (possibly less critical) things were being corrupted.

Quote
why does it happen when returning from main() in 'return EXIT_SUCCESS'?


Because the end of the program is when the heap's integrity is being examined and verified.

The actual problem is not happening when you exit main.  it's happening much earlier in the program.  It's only being discovered when main exits.

Quote
Happens only when I create an object of the class TtfText.


Then it's possible TtfText is what's corrupting the heap.

Or maybe not.  Like I said, heap corruption is weird and very hard to predict.  TtfText is definitely a good starting point, though.

42
General / Debug assertion fail!
« on: September 13, 2011, 08:43:17 pm »
Smells like heap corruption.

You're likely stepping outside of array boundaries somewhere or writing to a bad pointer.

43
General / Collision between line and ball problem
« on: September 13, 2011, 03:05:28 am »
OK!

Say you have two lines AB (with endpoints A and B) and CD (with points C and D)

Any point on line AB can be represented in the following form:
P = (B - A) * k + A

Where 'P' is the point, and 'k' is a value between [0..1].  Basically k acts as a "scale" to find the point according to it's distance from A.  So if P is exactly halfway between A and B, k would be 0.5

The same can be said of line CD.  Any point can be represented in the following form:
Q = (D - C) * m + C

To shorten/simplify future equations, I'm going to use some shorthand and say vBA = (B-A) and vDC = (D-C)


Now, assuming AB and CD extend to infinity, that means P=Q at the intersection point.

Which further means that:
Code: [Select]
P = vBA * k + A
Q = vDC * m + C

          P = Q
vBA * k + A = vDC * m + C


Now if we solve this equation for k and m, we have found the intersection point.  Assuming you know standard algebra, you should be able to solve it yourself so I'll skip the steps.  Basically you're left with this:

Code: [Select]
k = (vDC * m + vCA) / vBA
m = (vBA * k - vCA) / vDC


Now keep in mind that each of these equations are actually 2 equations in one, because the vectors all consist of both an x component and a y component.  So, actually, we have 2 ways to find k:

Code: [Select]
k = (vDC.x * m + vCA.x) / vBA.x
and
k = (vDC.y * m + vCA.y) / vBA.y


Likewise, we have 2 ways to find m.

Using this, we can substitute 'm' in one of the 'k' equations to eliminate it as a variable:

Code: [Select]
k = (vDC.x * m + vCA.x) / vBA.x
m = (vBA.y * k - vCA.y) / vDC.y

so

k = (vDC.x * (             m             ) + vCA.x) / vBA.x
k = (vDC.x * ((vBA.y * k - vCA.y) / vDC.y) + vCA.x) / vBA.x



Now we can solve for 'k' and have the result using only the given points A,B,C, and D.  We can also do the same thing to get 'm'.

So after all that solving you finally get this:

Code: [Select]
k = (vDC.y*vCA.x - vDC.x*vCA.y) / (vDC.y*vBA.x - vDC.x*vBA.y)
m = (vBA.y*vCA.x - vBA.x*vCA.y) / (vDC.y*vBA.x - vDC.x*vBA.y)


But wait a moment.... don't those expressions look a little familiar?

Code: [Select]
inline double PerpDot(const Point& a,const Point& b)                    { return (a.y*b.x) - (a.x*b.y); }

That's right!  It's good old PerpDot!  That magical linear algebra function!

This means we can further simplify:

Code: [Select]

k = PerpDot(vDC,vCA) / PerpDot(vDC,vBA)
m = PerpDot(vBA,vCA) / PerpDot(vDC,vBA)


Note the bottom part for each is the same.

Knowing that we're working with finite lines -- this means k and m must both be within the range [0..1] or else there is no intersection.

Also note the divide by 0 situation.  If PerpDot(vDC,vBA) is zero, there is no intersection.  Remember that PerpDot gives you sin(theta) and if sin(theta) is zero, it means the lines are parallel, so they cannot intersect.  Hence why the above equation wouldn't work in that case.



So all that roundabout math aside, we're left with a very, very simple function:

Code: [Select]

bool LineCollision( const Point& A, const Point& B,  // line AB
                    const Point& C, const Point& D,  // line CD
                    Point* out                       )  // filled with intersection point
{

    Point vBA(B - A);
    Point vDC(D - C);

    double f = PerpDot(vDC,vBA);
    if(!f)      // lines are parallel
        return false;
   
    Point vCA(C - A);

    double k = PerpDot(vDC,vCA) / f;
    if(k < 0)           return false;
    if(k > 1)           return false;

    double m = PerpDot(vBA,vCA) / f;
    if(m < 0)           return false;
    if(m > 1)           return false;

    if(out)
        *out = (vDC * m) + C;  // or (vBA * k) + A if you prefer -- same thing

    return true;
}

44
General / General questions about SFML 2.0
« on: September 12, 2011, 10:00:10 pm »
Quote
it seems that the performance decreased significantly. It worked at about 2000 FPS with 1.6, but about 700 FPS with 2.0.


FPS is logarithmic so it's a poor way to test performance.

This is only an increase of less than 1 ms per frame.  I wouldn't exactly call that "significant", but it depends on what you're doing I suppose.

I'll let someone else field the rest, though.

45
General / Collision between line and ball problem
« on: September 12, 2011, 08:22:36 pm »
You caught me at work!

I'll reply when I get home (maybe ~6 hrs from now)

But yeah, line-line collision is easy and fast using these same concepts.

Pages: 1 2 [3] 4 5 ... 15
anything