Page 1 of 2 12 LastLast
Results 1 to 10 of 18

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

  1. #1

    Ponx - High DPI aware PONG style game for Linux

    During the coding of Grayout, a floodfill style game, I became aware of the high DPI monitor problem. Well, it's a problem for the unaware programmer, like me. I'm sure those with High DPI luxury monitors just love them . Anyway the situation got to be adressed somehow and hopefully it works decently now. I'd like to thank the community and especially @SilverWarior for valuable feedback and suggestions. See the Grayout thread

    Now I started a new test to tackle the situation. A PONG variation which I hope behaves decently even for High DPI monitors. Main objective was to test handling things that move, that is the ball and the paddles.

    It seems to work but of course it's just easliy scalable circles and squares so far.

    The fully playable Ponx beta version 0.9 is already downloadable for those of you who run Linux. Very modest system requirements and very simple gameplay. In fact it mostly uses only one key ( the "any key" ) as player input.

    I hope you can enjoy it a minute or two and I look forward to any feedback!

    Enjoy!


    Ponx_screenshot.png


    https://www.jonax.se/Linux.php
    Last edited by Jonax; 12-05-2022 at 03:34 AM. Reason: Accidentally hit publish too early.

  2. #2
    Quote Originally Posted by Jonax View Post
    Anyway the situation got to be adressed somehow and hopefully it works decently now.
    This one seems to scale properly. I just tried in a virtual machine with Linux Debian installed. So good work.
    One advantage of using Viirtual machines is that some software for virtual machines like WMWare actually allows you to set the Gest OP within the virtual machine to have higher resolution than the host machine. This then renders the Gest OS within a scrollable window which isn't very useful for normal use but for testing of how application might look on high resolution monitor it can be quite useful.

    Now for some game related observations

    Having ball movement slowdown when it comes near to left or right edge is an interesting approach. However I noticed some discrepancy of how the speed of the bal is determined. On the left side the ball slows down as soon as the left side of the ball touches the left white area. But on the right side it only slows down when the whole ball is already in the right white area. This makes me believe that you are controlling speed based on left position of the ball. Instead you should be checking for both lent and right side. Or even better just check the absolute distance from the center of the ball to the left and right white square borders. Or perhaps you could just check to see if the center of the ball is in either of the white squares to simplify calculations.

    Also you are detecting to see if ball has left the playfield on player or computer side by checking whether any part of the ball is outside the laying field. This isn't best approach. I had several scenarios where tiny part of the ball passed outside the playing field but if it would continue a bit further it would actually bounce back from my paddle since ball was moving in direction toward the paddle. Again checking to see if center of the ball has gone out of playing field would work much better since before that you would always have a slight chance to bounce the ball back in.

  3. #3
    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

  4. #4
    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.

  5. #5
    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.

  6. #6
    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.

  7. #7
    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.

  8. #8
    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.

  9. #9
    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

  10. #10
    Update:

    New version with rounded Paddle and slightly different gameplay uploaded.

    Version number now 0.96 so there may be room for some further adjustments before the 1.0 release.
    What happened to versions 0.93 - 0.95? Except for 0.95 which briefly appeared they never made it. Failed approaches but learning experiences, I say.

    Ponx 0.96 for Linux is downloadable from:

    https://www.jonax.se/Linux.php

    ponx096.png

    Is compiled on Debian but runs on openSuSE also. Haven't tried other distros yet..
    Last edited by Jonax; 24-05-2022 at 02:35 PM. Reason: Minor adjustments

Page 1 of 2 12 LastLast

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
  •