SFML community forums

General => SFML projects => Topic started by: l0calh05t on July 24, 2008, 05:36:10 pm

Title: Not Quite Pong
Post by: l0calh05t on July 24, 2008, 05:36:10 pm
having a little free time this week i decided to write a little pong-like game. except with better "physics". you can add spin to the ball, the paddles have rounded corners etc. for collision detection and most of the physics calculations i use box2d, graphics is immediate mode opengl at the moment. the physics are mostly fake though, since the velocity of the ball is fixed (but increased after each paddle contact) and it has a minimum x-component (so that the ball doesn't get "stuck" somewhere in the middle of the playing field). the game part itself is not quite finished yet (no scoring, and the ball bounces off the ends of the field). but i thought someone might want to try anyways (and tell me if the physics are ok)

controls:
w - player 1 up
s - player 1 down
i - player 2 up
k - player 2 down
r - reset

get source code and binary here:
http://cid-c017d9fd84c56d75.skydrive.live.com/browse.aspx/Public
Title: Not Quite Pong
Post by: SirJulio on July 24, 2008, 06:08:19 pm
Nice ! (red "angry" spinning ball is fun ! =p)

Physics seems ok (paddle recoil and spinning are great ideas), just a thing : French player really need key configuration (W is under S on azerty keyboard), maybe a simple file for custom config.
Title: Not Quite Pong
Post by: Daazku on July 24, 2008, 06:37:46 pm
You should share the DLL if you compiled in dynamic mode.
You should share the DLL if you compiled with VC++.

I can't run your pong :P.
Title: Not Quite Pong
Post by: l0calh05t on July 24, 2008, 07:00:01 pm
Quote from: "SirJulio"
Nice ! (red "angry" spinning ball is fun ! =p)

Physics seems ok (paddle recoil and spinning are great ideas), just a thing : French player really need key configuration (W is under S on azerty keyboard), maybe a simple file for custom config.


Done. (new version already uploaded with example binding file, just rename to bindings.txt)

Quote from: "Daazku"
You should share the DLL if you compiled in dynamic mode.
You should share the DLL if you compiled with VC++.

I can't run your pong :P.


Hm, I thought everyone around here would have the VC2008 runtimes already installed... Added to archive.
Title: Not Quite Pong
Post by: Daazku on July 25, 2008, 02:11:07 am
Good thanks!

It's seem laggy on my comp but its how the game is designed... (The ball flash and when we move bar its the same.... That not cool...)

Binding function is cool.
The deplacement of the bar is nice. (When you touch border you added a nice effect.)

You should throw the ball at a random angle at begenning...
Title: Not Quite Pong
Post by: l0calh05t on July 25, 2008, 08:24:17 am
Quote from: "Daazku"
Good thanks!

It's seem laggy on my comp but its how the game is designed... (The ball flash and when we move bar its the same.... That not cool...)


I'm not sure what you mean, could you explain please?

Quote

Binding function is cool.
The deplacement of the bar is nice. (When you touch border you added a nice effect.)

You should throw the ball at a random angle at begenning...

Actually I was planning to have one of the players "throw" the ball at the beginning (like in many wallbreaker games), but I still need to figure out how to do that. (probably by adding a distance joint between the ball and the paddle and destroying it just before throwing the ball)
Title: Not Quite Pong
Post by: l0calh05t on July 25, 2008, 01:58:00 pm
another update:

-basic audio added
-physics updates are now frame-rate independent
-physics updates are no longer performed in render thread
-much less locking
-should an old state be encountered by the renderer, the current state is extrapolated (prevents visible stutter)

the last two should fix most lag issues (that is, if you experienced any. i didn't)
Title: Not Quite Pong
Post by: Daazku on July 25, 2008, 05:53:05 pm
-physics updates are now frame-rate independent

Ya its the good way to do it but your pong take 50-90% of my computer cpu and the ball is now teleported during the game :P

I can't try to find what wrong because i don't have box2d and i'm to lazy to install it :P.
Title: Not Quite Pong
Post by: l0calh05t on July 25, 2008, 06:51:21 pm
no jumping/teleporting on my pc... and only ~12% cpu load. what kind of cpu do you have, and what is your screen refresh rate?

edit:

new version upload, could you try if it is any better?
Title: Not Quite Pong
Post by: dabo on July 25, 2008, 08:07:03 pm
I could't see the ball in the previous version but this one seems to work.
Title: Not Quite Pong
Post by: Daazku on July 25, 2008, 08:12:37 pm
It's like the first one. The ball seem to flash and i see 2 balls like if i cross my eyes XD.

I think you should try to put vertical sync to off.
Title: Not Quite Pong
Post by: l0calh05t on July 25, 2008, 08:15:58 pm
Quote from: "Daazku"
It's like the first one. The ball seem to flash and i see 2 balls like if i cross my eyes XD.


very strange. can you tell me your configuration? (cpu,refresh rate,graphics card)

Quote
I think you should try to put vertical sync to off.

meh. rather not. why waste cpu cycles on drawing (almost) the same picture again and again and again. (uploaded a no vsync exe anyways)
Title: Not Quite Pong
Post by: Wizzard on July 26, 2008, 01:13:31 am
It may just be me or my computer, but depending on the ball's speed the ball turns a shade of red. This is especially so in the executable with vertical sync. In the executable without vertical sync (where it's not so bad) the ball can turn almost completely red for a split second if I get it stuck between the side and my paddle.

Anyways, good work. I really like the flow. Now I just need a score system to prove to my buddy I just wiped the floor with him.
Title: Not Quite Pong
Post by: l0calh05t on July 26, 2008, 11:10:15 am
Quote from: "Wizzard"
It may just be me or my computer, but depending on the ball's speed the ball turns a shade of red. This is especially so in the executable with vertical sync. In the executable without vertical sync (where it's not so bad) the ball can turn almost completely red for a split second if I get it stuck between the side and my paddle.


The shade of the  ball depends on the ball's spin, not on it's speed. Try moving the paddle quickly just before the ball hits it. It should turn pink to red (depending on paddle speed

Quote
Anyways, good work. I really like the flow. Now I just need a score system to prove to my buddy I just wiped the floor with him.

Working on it :-)

EDIT:
Basic score system is in place, also, the no-vsync version is now included in the archive.
Title: Not Quite Pong
Post by: Daazku on July 26, 2008, 04:00:16 pm
Look REALLY REALLY REALLY better with no v.sync.... Do you clear the scren with 0,0,0,255 ? Because i think that can be why the ball is not perfect.

Ps: You reset the score at 100 that not cool !
Title: Not Quite Pong
Post by: l0calh05t on July 26, 2008, 04:59:22 pm
Quote from: "Daazku"
Look REALLY REALLY REALLY better with no v.sync.... Do you clear the scren with 0,0,0,255 ? Because i think that can be why the ball is not perfect.


obviously I have to clear the screen, how else would I do it? still very strange that you get better results without vsync, they're pretty much equal on my pc only that the no-vsync version consumes 98-99% cpu (on a dual core) and the vsync version only 14-20%

Quote
Ps: You reset the score at 100 that not cool !

No, I don't. Scores greater than 100 are merely not displayed correctly :-P (anyways, who plays pong up to a score of 100+??)
Title: Not Quite Pong
Post by: Daazku on July 26, 2008, 06:48:15 pm
Me?
Title: Not Quite Pong
Post by: Daazku on July 26, 2008, 06:52:40 pm
Quote from: "l0calh05t"
Quote from: "Daazku"
Look REALLY REALLY REALLY better with no v.sync.... Do you clear the scren with 0,0,0,255 ? Because i think that can be why the ball is not perfect.


obviously I have to clear the screen, how else would I do it? still very strange that you get better results without vsync, they're pretty much equal on my pc only that the no-vsync version consumes 98-99% cpu (on a dual core) and the vsync version only 14-20%

Quote
Ps: You reset the score at 100 that not cool !

No, I don't. Scores greater than 100 are merely not displayed correctly :-P (anyways, who plays pong up to a score of 100+??)


-No i know that. But in the case u didn't clear the screen with 100% that can be a problem.

-Me?

The game take 70% of my cpu.. Try to use the method SetFrameLimit() and use something lie 60.
Title: Not Quite Pong
Post by: l0calh05t on July 26, 2008, 08:36:19 pm
Quote from: "Daazku"

-No i know that. But in the case u didn't clear the screen with 100% that can be a problem.


Uhmm.. no? I use glClear(GL_COLOR_BUFFER_BIT);, which clears 100% of the viewport. (no matter what alpha value is used)

Quote

-Me?


And if I support scores >99, where should I stop? 999? 9999? Or just keep on increasing the number of digits forever (possibly overwriting the score of the other player)?

Quote
The game take 70% of my cpu.. Try to use the method SetFrameLimit() and use something lie 60.

Are you suggesting to use SetFrameLimit instead of vsync? Doesn't seem to make much sense  :? (of course, i might just not know the reason)

EDIT:
I just tried to use SetFrameLimit(60) instead of UseVerticalSync(true) and the results are absolutely horrible. Tons of tearing, jittery framerate etc. Not very nice...
Title: Not Quite Pong
Post by: Daazku on July 27, 2008, 07:23:28 am
Not instead... but personally setFrameLimit work well....

Anyway if your game take all my cpu and the ball is not nicely rendered on my comp that not really my comp the problem.. It's a fucking pong man.. I tested some other project like: http://www.sfml-dev.org/forum-fr/viewtopic.php?t=1082 (WallBreaker)

It take 0% CPU and is WELL rendered.

And personally again... Using thread for your pong is a bad idea.. You don't need it...
Title: Not Quite Pong
Post by: Wizzard on July 27, 2008, 08:53:46 am
This is why modern games come with many options. :wink:

In no way is any program guaranteed to run more efficient with or without multithreading and with or without vertical sync on any computer.
Title: Not Quite Pong
Post by: l0calh05t on July 27, 2008, 12:53:11 pm
Quote from: "Daazku"
Not instead... but personally setFrameLimit work well....

Anyway if your game take all my cpu and the ball is not nicely rendered on my comp that not really my comp the problem.. It's a fucking pong man.. I tested some other project like: http://www.sfml-dev.org/forum-fr/viewtopic.php?t=1082 (WallBreaker)


It is rendered perfectly well on my pc (both with and without vsync), so it *does* depend on the computer. If you tell me what kind of configuration you have, maybe I could find out what causes the problem (can't guarantee that, though)

Quote
It take 0% CPU and is WELL rendered.

And personally again... Using thread for your pong is a bad idea.. You don't need it...


I know I don't, but this game is a bit of a platform for experimentation. Better try this kind of stuff in a simple game first, before applying it to more complex games.

EDIT:
New version uploaded with drastically reduced cpu usage (~5% on my pc while the cpu is speedstepped down to 780 MHz)
Title: Not Quite Pong
Post by: Daazku on July 27, 2008, 05:03:12 pm
Système d'exploitation   Microsoft Windows XP Professionnel
Type   X86-based PC
Processeur   x86 Family 15 Model 2 Stepping 9 GenuineIntel ~3042 Mhz
Mémoire physique totale   1 536,00 Mo
Mémoire virtuelle totale   2,00 Go
Mémoire virtuelle disponible   1,96 Go
Espace pour le fichier d'échange   1,36 Go

vsync = 50% processor and the ball teleport lag.
vsync = 99% (all) processor and the ball is nearly perfect. (Maybe its the hight contrast balck white...)
Title: Not Quite Pong
Post by: l0calh05t on July 27, 2008, 11:39:08 pm
Quote from: "Daazku"

Processeur   x86 Family 15 Model 2 Stepping 9 GenuineIntel ~3042 Mhz


Is that a single-core P4? (I suspect using a single-core *could* cause problems if windows' scheduling is being really, really stupid... as it is quite often) With or without HT?

I tested it with cpu affinity set to only one core and cpu usage didn't increase, it actually dropped a little down to ~2%. (my cpu is a 2.2GHz Core 2 Duo mobile)

Quote

vsync = 50% processor and the ball teleport lag.
vsync = 99% (all) processor and the ball is nearly perfect. (Maybe its the hight contrast balck white...)


50% with the current version?? How can that be? It should be sleeping most of the time or waiting for vsync. vsync might be busy-waiting if the driver is badly written, which is the only way I could explain the discrepancy. have you got any way of profiling/testing the code, to help me find the problem? Anyways, thank you for the info.

PS: A slight "doubling" of the ball is also caused because of the high contrast but it isn't too bad on my laptop's screen.
Title: Not Quite Pong
Post by: Daazku on July 27, 2008, 11:50:10 pm
Quote from: "l0calh05t"
Quote from: "Daazku"

Processeur   x86 Family 15 Model 2 Stepping 9 GenuineIntel ~3042 Mhz


Is that a single-core P4? (I suspect using a single-core *could* cause problems if windows' scheduling is being really, really stupid... as it is quite often) With or without HT?

I tested it with cpu affinity set to only one core and cpu usage didn't increase, it actually dropped a little down to ~2%. (my cpu is a 2.2GHz Core 2 Duo mobile)

Quote

vsync = 50% processor and the ball teleport lag.
vsync = 99% (all) processor and the ball is nearly perfect. (Maybe its the hight contrast balck white...)


50% with the current version?? How can that be? It should be sleeping most of the time or waiting for vsync. vsync might be busy-waiting if the driver is badly written, which is the only way I could explain the discrepancy. have you got any way of profiling/testing the code, to help me find the problem? Anyways, thank you for the info.

PS: A slight "doubling" of the ball is also caused because of the high contrast but it isn't too bad on my laptop's screen.


Like i said it the with no vsync the game is okai and run well (with the problem of contrast XD) but it take all my cpu. (It's a game so it's not so bad but you should try to reduce that...)

Yes i have a single-core P4 cpu :D. (My pc is old.. 3 years old)
Title: Not Quite Pong
Post by: l0calh05t on July 28, 2008, 11:00:35 am
Quote from: "Daazku"
Like i said it the with no vsync the game is okai and run well (with the problem of contrast XD) but it take all my cpu. (It's a game so it's not so bad but you should try to reduce that...)

Yes i have a single-core P4 cpu :D. (My pc is old.. 3 years old)


Since the vsync version uses way more CPU than it should and the non-vsync version works better, I suspect your problems are caused by your graphics card driver. Anyways, I just uploaded a version with framerate limit, so you can try that one if you wish. Looks absolutely horrible on my comp though...

EDIT: Also added a non-threaded version.
Title: Not Quite Pong
Post by: Daazku on July 28, 2008, 02:24:43 pm
I wanted to test all executable on a laptop but no one start XD.

This application has failed to start because the application configuration is incorrect XD.

Long life to VC++ :P.

Some dll are missing i think....

(On my comp i had vc++ with the .net package and i uninstalled it but i think some dll are remaining).
Title: Not Quite Pong
Post by: l0calh05t on July 28, 2008, 07:40:30 pm
the dll's are all there afaik... there is only one correct solution to that problem... install the VC90 redistributable package. (Windows checks the C:\Windows\WinSxS directory, for these files if i'm not mistaken...)

http://www.microsoft.com/downloads/details.aspx?displaylang=fr&FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bf
Title: Not Quite Pong
Post by: Daazku on July 28, 2008, 07:47:32 pm
Ya but that suck HARD and i will not reinstall this #%$#@$% XD.

Long life to VC++
Title: Not Quite Pong
Post by: l0calh05t on July 28, 2008, 08:00:07 pm
it's not that bad imo. look at it this way: by having one system wide CRT, it can be shared by all apps built using that CRT (smaller exes, less waste of HD space). If you use mingw (or VC static CRT) you are always including parts of the CRT in your exes, which means that if you have many apps built that way, you'll have many copies of the CRT on your disc.
Title: Not Quite Pong
Post by: Daazku on July 28, 2008, 08:18:13 pm
So what? What is a 80k more in my exe or 1.7 Mo of shit on my comp? + the time it take to download and intall it?

Neway its just an opinion.. And the true is: If your user need to download something else that is not included in your package to run it its bad.

PS: Stay polite i didn't insult you!
Title: Not Quite Pong
Post by: l0calh05t on July 28, 2008, 08:49:58 pm
Quote from: "Daazku"
PS: Stay polite i didn't insult you!


??
Title: Not Quite Pong
Post by: Pwndja on July 28, 2008, 08:53:06 pm
Quote from: "Daazku"
PS: Stay polite i didn't insult you!


Ya not sure what he meant about this lol...
Title: Not Quite Pong
Post by: Daazku on July 28, 2008, 08:57:01 pm
Lol my english is not really good..

You say to me i'm an imo... Don't insult me i didn't insulted you. (Better i think)
Title: Not Quite Pong
Post by: Pwndja on July 28, 2008, 09:07:31 pm
Quote from: "Daazku"
Lol my english is not really good..

You say to me i'm an imo... Don't insult me i didn't insulted you. (Better i think)


LOL I think what he means by imo is "in my opinion" meaning how he thinks about it. I don't think there was any negative connotation implied by the word... it is just another acronym like lol jk HTML URL etc.

might just be a translation problem the acronym might mean something different in your language.
Title: Not Quite Pong
Post by: l0calh05t on July 28, 2008, 09:22:29 pm
Quote from: "Pwndja"

LOL I think what he means by imo is "in my opinion" meaning how he thinks about it. I don't think there was any negative connotation implied by the word... it is just another acronym like lol jk HTML URL etc.


jup, imo (or IMO) just means "in my oppinion" (IMHO means in my humble oppinion)

Quote
might just be a translation problem the acronym might mean something different in your language.


if I had said emo, it might have been an insult :-P
Title: Not Quite Pong
Post by: Daazku on July 28, 2008, 09:56:36 pm
Lol XD.. I saw some kiddies used IMO instead of EMO and i never saw the IMO accronym before XD. Sorry for that :P.
Title: Not Quite Pong
Post by: Daazku on July 28, 2008, 11:10:28 pm
So the result: The not threaded one isn't better thant the threaded one.
The one with frameLimit use only 0 to 2% of my cpu so that okai but the ball do little teleport at regular time...
Title: Not Quite Pong
Post by: l0calh05t on July 28, 2008, 11:24:42 pm
Quote from: "Daazku"
So the result: The not threaded one isn't better thant the threaded one.


if the non-threaded one isn't any better (from a cpu usage point of view), then we can be fairly sure it really is your graphics card driver that is busy-waiting on vsync.

Quote
The one with frameLimit use only 0 to 2% of my cpu so that okai but the ball do little teleport at regular time...

could you try to describe this 'teleport' more precisely?
Title: Not Quite Pong
Post by: Daazku on July 28, 2008, 11:25:55 pm
Bah it is a little little lag at each 1 sec... the ball move foward more than habitual.
Title: Not Quite Pong
Post by: l0calh05t on July 28, 2008, 11:35:59 pm
so... it's not too bad? problem is I can't replicate this behavior so it's really difficult to find the reason...
Title: Not Quite Pong
Post by: Daazku on July 28, 2008, 11:57:28 pm
Bah the movement is broken so its in relation with frame / time. Do you draw by elapsed time or frame?

Seem to be by elapsed time.. Maybe its a problem with thread? The app change thread each X second and when the app is in the other thread the application dont render?
Title: Not Quite Pong
Post by: l0calh05t on July 29, 2008, 06:15:48 am
I draw by elapsed time/system time. Every game state gets a timestamp containing the system time to which it corresponds, and the renderer interpolates (using the stored velocities but no collisions) from the state it receives to the current system time.

How can it be a problem with threading? Didn't you say it was just as bad without threading? Anyways, I use double buffered state, so the render thread only has to lock the front buffer while render commands are submitted. At the same time the physics thread can continue processing using the back buffer. As soon as it's done with that, it will try to lock the front buffer and swap buffers (a pointer swap), so all in all, the time any thread waits for the other thread should be very short. Not enough to create any visible jumps.

Anyways, I just had an interesting idea for a new pong variant:
Electrostatic Field Pong  8)
What do you think? Worth the effort?
Title: Not Quite Pong
Post by: Daazku on July 29, 2008, 02:11:33 pm
Bah i have little visible jump XD.

Code: [Select]
Anyways, I just had an interesting idea for a new pong variant:
Electrostatic Field Pong Cool
What do you think? Worth the effort?


That will worth it if the result is nice XD.
Title: Not Quite Pong
Post by: remi.k2620 on July 29, 2008, 08:36:29 pm
Quote from: "l0calh05t"
Anyways, I just had an interesting idea for a new pong variant:
Electrostatic Field Pong  8)
What do you think? Worth the effort?


It depends how you do it. I fear it to be too slow or too hard to control.
I think having two electrostatic sources - one at each end of the paddles and nothing between - would give an interesting result.

Edit : I tried to compile nqp but couldn't because I have libboost 1.34.1 and the lock and unlock methods you use in AsyncCallable.cpp are only in the new 1.35.0 version :(
Title: Not Quite Pong
Post by: l0calh05t on July 29, 2008, 10:25:49 pm
Quote from: "remi.k2620"
It depends how you do it. I fear it to be too slow or too hard to control.
I think having two electrostatic sources - one at each end of the paddles and nothing between - would give an interesting result.


Well, this is what I was thinking of:
Each player can charge his/her paddle either positively or negatively (basically applying a current). Since both players can do this, this should create some interesting interactions (anyone remember plasma pong?). The ball itself could be treated as a point charge that is affected by the potential field of the paddles. (obviously the ball should always have a charge and never be neutral)

Quote
Edit : I tried to compile nqp but couldn't because I have libboost 1.34.1 and the lock and unlock methods you use in AsyncCallable.cpp are only in the new 1.35.0 version :(


the changes shouldn't be too complex:
where I do mutex.lock(), you have to open a scope ({) and create a lock object using that mutex. where I do mutex.unlock(), you simply close that scope (}). and since there are only two places where this has to be changed, it shouldn't be too difficult.
Title: Not Quite Pong
Post by: remi.k2620 on July 30, 2008, 03:49:07 am
Quote from: "l0calh05t"

Quote
Edit : I tried to compile nqp but couldn't because I have libboost 1.34.1 and the lock and unlock methods you use in AsyncCallable.cpp are only in the new 1.35.0 version :(


the changes shouldn't be too complex:
where I do mutex.lock(), you have to open a scope ({) and create a lock object using that mutex. where I do mutex.unlock(), you simply close that scope (}). and since there are only two places where this has to be changed, it shouldn't be too difficult.


MainTask.cpp: In member function ‘virtual void n71A10890::MainTask::init()’:
MainTask.cpp:85: error: ‘class boost::thread’ has no member named ‘swap’
MainTask.cpp: In member function ‘virtual void n71A10890::MainTask::fini()’:
MainTask.cpp:97: error: ‘class boost::thread’ has no member named ‘timed_join’
MainTask.cpp:97: error: ‘boost::posix_time’ has not been declared

:(
Title: Not Quite Pong
Post by: l0calh05t on July 30, 2008, 08:20:54 am
wow, didn't even really notice I used so many new boost features... you could replace the timed join with a normal join. I'm less sure about the swap. Since threads are noncopyable, you would probably have to use a thread pointer and use new where i use swap.
Title: Not Quite Pong
Post by: Daazku on July 30, 2008, 02:18:14 pm
Download the new version :P
Title: Not Quite Pong
Post by: christoph on August 01, 2008, 05:59:06 pm
Hi

An Idea how to fix the following?

Code: [Select]
MainTask.cpp: In member function ‘virtual void n71A10890::MainTask::init()’:
MainTask.cpp:90: error: no matching function for call to ‘boost::thread::swap(boost::thread)’
/usr/include/boost/thread/pthread/thread.hpp:165: note: candidates are: void boost::thread::swap(boost::thread&)


The problem here is, that the boost::thread is an temporary which can't be used as non-const reference

Getting it to compile with following patch

Code: [Select]
diff -u a/MainTask.cpp b/MainTask.cpp
--- a/MainTask.cpp 2008-07-27 14:25:42.000000000 +0200
+++ b/MainTask.cpp 2008-08-01 18:02:55.000000000 +0200
@@ -83,11 +83,8 @@
  bindings.close();
 
  renderTask = new RenderTask_t(window,game);
- renderThread.swap(
- boost::thread(
- boost::bind(&GameTask::run,renderTask)
- )
- );
+ boost::thread thr(boost::bind(&GameTask::run,renderTask));
+ renderThread.swap(thr);
 
  accumulator = 0.f;
  clock.Reset();
Title: Not Quite Pong
Post by: l0calh05t on August 01, 2008, 07:48:39 pm
Your fix looks fine and should work.