Results 1 to 10 of 18

Thread: Ponx - High DPI aware PONG style game for Linux

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Thanks for feedback and encouragement. I really like the Virtual Machines too and find them useful for testing.

    I didn't think about that speedy area discrepancey, but you are right of course. I think I'll arbritarily make the center crossing decide the speed for next version. The discreepancy was indeed as you deducted because I started programming with the top-left corner as coordnates for the ball. Made coding easy at first but increasingly messier as more functionality was added. Should have gone for ball center from the beginning.

    Also you are right about the occasional misalignments when deciding hit or miss. Is possible due to rounding error, or possibly a case of finishing the loop and moving the ball yet a bit before the moving stops...

    Why the fast area in the middle? Well. I'm getting older and don't have reflexes for super fast original PONG style movements. Slower is nicer from a personal perspective and I generally prefer more contemplative gameplay. However having that slow game speed makes the gameplay boringly slow, even for me. Don't have the patience to wait for the ball to crawl over the whole field. So the fast area is a compromise..
    Last edited by Jonax; 13-05-2022 at 06:56 PM. Reason: typo

  2. #2
    Quote Originally Posted by Jonax View Post
    Also you are right about the occasional misalignments when deciding hit or miss. Is possible due to rounding error, or possibly a case of finishing the loop and moving the ball yet a bit before the moving stops...
    No I'm not talking here about rounding errors. What I'm talking here is about the scenario that you can see on next screen mock up. The paddle is moving downwards and the ball is traveling toward left an up.
    Ponx_screenshot.png
    In reality you could still bounce the ball in such scenario back to the game field but game registers that I lost the ball as soon as it crosses the left edge of the game field and thus doesn't give me a chance to bounce the ball back in such scenario.

    Quote Originally Posted by Jonax View Post
    Why the fast area in the middle? Well. I'm getting older and don't have reflexes for super fast original PONG style movements. Slower is nicer from a personal perspective and I generally prefer more contemplative gameplay. However having that slow game speed makes the gameplay boringly slow, even for me. Don't have the patience to wait for the ball to crawl over the whole field. So the fast area is a compromise..
    Yeah I figured out that something like this might be the reason for the slowdown. It is a nice touch.
    However the change between fast and slow speed is quite big and sudden so it feels a bit odd. Perhaps splitting the white areas to multiple smaller areas where each area would gradually reduce the speed of the ball might make this feel less odd.
    In order to avoid performing multiple hit-tests against white areas for slowdowns you could instead you could just use the X distance from the middle of the gray area. Doing so even opens you the ability to go and for instance use logarithmic equation to calculate smooth speed transition.

  3. #3
    Now I see what you mean. I agree one could expect the ball to remain in play under such a circumstance. Meanwhile I was thinking the ball should be out, if touching the baseline beside the paddle. Like if the pale colored areas were some sticky glue.


    The reason for this to simplify the programming of course. I'm afraid letting the ball cross that line may cause a host of new programming headaches. If I had tried that apporoach I'd probably still be sweating over special cases and have nothing to show. On the other hand it may not be so bad and improved gameplay is priceless.


    So how to continue? Well, it's weekend and decent weather. I'll take a walk outdoors and think about possible approaches.

  4. #4
    Quote Originally Posted by Jonax View Post
    The reason for this to simplify the programming of course. I'm afraid letting the ball cross that line may cause a host of new programming headaches. If I had tried that apporoach I'd probably still be sweating over special cases and have nothing to show. On the other hand it may not be so bad and improved gameplay is priceless.
    If you start using relative distance from the center of the ball against center of the playfield I believe you could perhaps even simplify your programming quite a bit.

    First you need to make sure that your playfield coordinates are position so that the position 0:0 will be in the center of your playfield. I'm guessing you are now working with Window coordinates. So you would make this transformation by simply subtracting half of the width of your playfield window width from X coordinate and half of your playfield window height from Y coordinate.

    For instance in my quick mock up I use mouse for moving the ball so I transform my mouse coordinates to PlayfIeld coordinates using

    Code:
    PlayfieldX := X-(PaintBox1.ClientWidth div 2);
    PlayfieldY := Y-(PaintBox1.ClientHeight div 2);
    I then pass this Playfield coordinates to my Collision detection procedure that looks like this


    Code:
    procedure TForm5.CheckCollision(X,Y: Integer);begin
      //Reset collisions
      TopBorderCollision := False;
      BottomBorderCollision := False;
      LeftBorderCollision := False;
      RightBorderCollision := False;
    
    
      //Check for top/bottom collisions
      if Abs(Y) > ((PaintBox1.ClientHeight div 2)-BorderThickenss) then
      begin
        if Y < 0 then
        begin
          TopBorderCollision := True;
        end
        else BottomBorderCollision := True;
      end;
    
    
      //Check for left/right border collisions
      if Abs(X) > ((PaintBox1.ClientWidth div 2)-BorderThickenss) then
      begin
        if X < 0 then
        begin
          LeftBorderCollision := True;
        end
        else RightBorderCollision := True;
      end;
    
    
      //Check to see if ball is in slowdown area then reduce its speed
      if ABS(X) > ((PaintBox1.ClientWidth div 2)-BorderThickenss-SlowdownAreaWidth) then BallSpeed := 20
      //else keep it moving at full speed
      else BallSpeed := 20;
    
    
      //Check paddle collision
      if X > 0 then
      //Player padle collision
      begin
        //Simple collision checling against paddle using X coordinate of the ball
        //Ball Y position si within player paddle area
        if (Y >= PlayerPaddle.Top) and (Y <= (PlayerPaddle.Bottom)) then
        begin
          if ABS(X) > ((PaintBox1.ClientWidth div 2)-PlayerPaddle.Width) then //Bounce the ball from the paddle by multiplying X speed by -1;
        end
        //Because the ball Y position is not within the PlayerPaddle area it means we will have to check collision
        //against PlayePaddle corners instead
        else
        begin
          //Top corner
          if System.Math.Hypot(ABS(X-PlayerPaddle.Right),ABS(Y-PlayerPaddle.Top)) < BallDiameter then
          begin
            //Bounce ball from top paddle corner. It would probably result in great change of the ball trajectory angle
          end;
          //Bottom corner
          if System.Math.Hypot(ABS(X-PlayerPaddle.Right),ABS(Y-PlayerPaddle.Bottom)) < BallDiameter then
          begin
            //Bounce ball from top paddle corner. It would probably result in great change of the ball trajectory angle
          end;
        end;
      end;
    end;
    I hope my code mock up can give you good enough idea of how to work with such approach and how easy it actually is. I tried to comment it as good as I can so ti can be even more understandable.
    I'm guessing you will have to make some changes so that it will work with your data structures
    Last edited by SilverWarior; 14-05-2022 at 06:50 PM.

  5. #5
    Thanks a lot for taking the time and effort with that code. I really appreciate that


    Indeed it looks neat and totally readable. As you point out I got to make some adjustments but the code seems totally usable in general.


    Problem is more my lack of time and energy. I'm afraid the attempt will not be done in the near future.


    I could learn a useful thing from the code. The Hypot function. I wasn't aware about that one, and I do use the Pythagoras a lot in my coding. I will use Hypot from now on instead of writing the whole sqrt(x*x+y*y) thingie.

  6. #6
    Quote Originally Posted by Jonax View Post
    I could learn a useful thing from the code. The Hypot function. I wasn't aware about that one, and I do use the Pythagoras a lot in my coding. I will use Hypot from now on instead of writing the whole sqrt(x*x+y*y) thingie.
    I strongly recommend you also check other functions in Math unit. I'm pretty sure you might find some other useful functions there. Also some of the functions in Math unit are also optimized to be able to make use of hardware acceleration making them more efficient.

  7. #7
    Quote Originally Posted by SilverWarior View Post
    I strongly recommend you also check other functions in Math unit. ..
    Nice. I'll have a look at the math unit. As you say there might be some other useful function I've missed. Even better if there is hardware acceleration.


    I have uploades a minor update to Ponx. Verision 0.92 now has somewhat smoother speed transition. Not totally smooth but better than before.


    The paddle got to wait for now but I haven't given it up totally, yet.
    Last edited by Jonax; 16-05-2022 at 09:39 AM. Reason: missed tag

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •