Ponx - High DPI aware PONG style game for Linux

[Jonax]

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 8). 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 (https://www.pascalgamedevelopment.com/showthread.php?32772-Grayout-Simple-Linux-freeware-game)

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!


1583 (https://www.jonax.se/Linux.php)


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

[SilverWarior]

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.

[Jonax]

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

[SilverWarior]

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


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.

[Jonax]

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.

[SilverWarior]

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


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



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

[Jonax]

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.

[SilverWarior]

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.

[Jonax]

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.

[Jonax]

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

1585

Is compiled on Debian but runs on openSuSE also. Haven't tried other distros yet..

[SilverWarior]

New version with rounded Paddle and slightly different gameplay uploaded.

Let me guess. You decided to go with rounded edges on the paddle in order to simplify physics when ball hits edge of the paddle since this way you can actually use physics of two balls bouncing of each other. ;)

[Jonax]

Let me guess. You decided to go with rounded edges on the paddle in order to simplify physics when ball hits edge of the paddle since this way you can actually use physics of two balls bouncing of each other. ;)

Indeed thus the rounded edges. Round objects are so much easier. Though I took some liberties with the physics of bouncing. For further simplification of course. And for somewhat improving the gameplay, I hope. And when you mention bouncing balls I have an idea of making a remake of an ancient bouncing balls program I once made in Delphi 3. But no promises there. Haven't even started yet. Though I figure some code from this program can be recycled there.

[SilverWarior]

And when you mention bouncing balls I have an idea of making a remake of an ancient bouncing balls program I once made in Delphi 3.

Well if this old game you mention is heavily physics based then you should perhaps consider using some existing physics engine in that game instead of trying to handle all the physics yourself.

Lately Box2d https://code.google.com/archive/p/box2d-delphi/ is considered as a basic 2D based physics engine that many Delphi developers use. Now while the headers are designed for Delphi I'm guessing you should not have to much trouble compiling them with FPC just make sure you enable Delphi mode https://www.freepascal.org/docs-html/prog/progse74.html (might not be necessary) and Advanced Records (which already seem to enabled by default in FPC 2.6.0 and newer) since the headers heavily rely on using them.

Or perhaps you might decide to use Kraft Physics Engine https://github.com/BeRo1985/kraft instead. Kraft Physics Engine is much more advanced and also fully supports 3D physics. It is being used in Castle Game Engine https://castle-engine.io/ which is one of the most popular pascal based game engines lately.

[Jonax]

Thanks SilverWarior. I got to have a look at those engines. I just spawned a new Virtual Machine for the purpose. Noticed a new Lazarus version recently arrived. Though seems to be mostly smaller adjustments this time. But that's the easy part. The tricky thing will be to try out those physics engines.

Meanwhile I will make an other attempt to handle the physics myself in the upcoming heavily physcis based game, or program. If it ever gets done of course. It's easy to talk about games to do but then really finishing them is a totally other matter. And I haven't even started yet..

[SilverWarior]

It's easy to talk about games to do but then really finishing them is a totally other matter.

Tell me about it. I myself have half a dozen unfinished game ideas in the works. Main reason why they are not finished is the lack of needed knowledge to turn my quite big ideas into code. Some people might even say that I'm aiming to big.

[Jonax]

Tell me about it. I myself have half a dozen unfinished game ideas in the works. Main reason why they are not finished is the lack of needed knowledge to turn my quite big ideas into code. Some people might even say that I'm aiming to big.

The eternal conflict between ambition and resources. Of course I have no idea about your projects and situation but scaling back a little might be a good approach. There's the matter of availabe time and energy. On the other hand it's never wrong to aim for the stars...

Can you say anything about your favourite top ideas?

[SilverWarior]

Can you say anything about your favourite top ideas?

Why not.
First one of the ideas that I had but abandoned them because someone else beaten me to it ;)


Many yeas ago (about 20) after playing one of the first bridge builder games named Pontifex (https://www.youtube.com/watch?v=LwD5muwJkBo) I came to idea that you could use same approach for making much more complex physical objects than just bridges. In fact my idea was to make a car racing game that would use such system for complex physical simulation of the whole car body. But at that time my knowledge of programming was just in its infancy.
A few years later I found out that two french computer science students also got the same idea nad actually made a game out of it. The name of the game is Rigs of Rods. At that time I was booth sad and happy at the same time. Sad because they have beaten me to my idea. And happy because I knew from then on that I'm capable of coming up to awesome ideas on my own. That is one of motivations that is driving me all these years.
And yes one of the original developers of Rigs and Rods is the leading designer of BeamNG drive that you might be more familiar with.


Now to some of my current ideas that are in the works. Sort of in the works:

Space exploration/trading game that is a mix between Star Control 2, Freelancer, Battle Cruiser 3000 AD. The goal is to have ship made from various systems and subsystems similar as in BC3000AD which can be damaged, repaired or even upgraded individually. The galaxy is going to be procedurally generated.
I already have code for procedural generation of planets that include making heigthmap and then paint the surface based on that heigthmap following specific rules. Might need a some improvement for allowing more variations.
I have core code for defining ship systems and subsystems. Needs a rewrite because in its current design it to prone to bugs (I learned a few things about working with classes from then ;)). Also I want to standardize the class structure some more so that I can implement another feature of being able to scan other ship systems status more easily.
I believe I still have a mockup for Supply & Demand based economics systems somewhere ???
Squad based tactics game heavily inspired bx X-Com 3 Apocalypse but with much bigger depth.
I already have a system of interconnected classes that allow me to to define characters with even more detailed stats that you can find in original X-Com games. The same system of classes also allows me to have modular items and weapons where final stats of specific item or weapon is defined from te components that they are made of.
This system also incorporates RPG based battle system where distance and orientation not only affects the chance for hitting your target but also the amount of damage that you can deal to that target based on which armor slot of the said target gets hit and of course its stats. Not to mention that I already have three damage types (physical, heat and poison) each dealing final damage to the target in distinct way.
I had code for Multilevel Isometric gameworld but unfortunately it was heavily tied to a graphical engine whose development was since abandoned. So I need to take time and rewrite this again.
Another idea I have is for a City Builder with a very advanced traffic simulation. I come up to this idea when learning more advanced approaches of pathfinding.
Not much code already done for this except the pathfinding mockup that works surprisingly well. Traffic is capable of causing total gridlocks by taking into account past average speed of traffic through specific road section. So when congestion occurs on one street cars try to chose other alternative route that might be longer but has higher traffic speeds. This eventually balance the traffic quite nicely.


And there are many more ideas I have that I haven't even started to work on them.

Any way the main obstacle right now is UI. Why? Thorough out my time I switched between several Graphical engine since their development was abandoned. And since each of them used their unique way for handling UI or in one case the need for me to write my own way for handling UI switching to different Graphical engine meant that my previous UI code would become mostly unusable.
This is one of the reasons why some time ago I started working on an even more challenging project. And that is writing my own UI library that is designed in a way so that ti could be used by multiple Graphical/Game engines. So that if I ever have to change Graphical engine again I at least won't have to start all over again. But as you can guess this is no easy task at all.

[Jonax]

Congrats to the bridge builder idea. Always nice to get confirmation the ideas are viable. I think I heard about the Pontifex but I never tried it. Too much Startcraft I for that.


Your projects in the works sound interesting. Especially the first one. I always liked strategy better than tactics, but that's a personal preference of course. You could perhaps use the pathfinding algorithm from project #3 in the trade mechanics somehow.


I do believe that the UI library project is no easy task. I wouldn't know even where to begin. But sounds like a good thing to become more future proof in case of more graphics engine changes.


I know it's not the same but I remember not being able to install my ancient Delhpi 3 after getting my first 64-bit windows 7 laptop. That's when I found Lazarus btw. Some of the old code could be converted/re-used but there were issues. It's annoying when suddenly the old tried methods don't work anymore. Btw I still keep that Win 7 laptop because that's my only way to use my scanner.


I look forward to see whatever new projecs you may come up with in the future.


For my own part I'll take a break with the PONX and have begun on the remake of the pysics based game. So far I managed to add a second ball and that's at least a start. But nothing to show yet.