Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (534)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2] 3
  ignore  |  Print  
  fps expected for platform game  (Read 10383 times)
0 Members and 1 Guest are viewing this topic.
Offline Abuse

JGO Coder


Medals: 11


falling into the abyss of reality


« Reply #30 - Posted 2002-12-24 23:39:12 »

/me chuckles

I thought it was Christmas day, not April fools day  Grin

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline elias

Senior Member





« Reply #31 - Posted 2002-12-25 01:24:30 »

It _is_ christmas - as a present you get to hear cas speak positively about threads. And never again...

- elias

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #32 - Posted 2002-12-25 08:48:35 »

I think that Cas is very happy about threads - they just have to be used right...

I myself have one time thought of doing a world with one thread, and then another thread that captures the world state and renders it. Never actually implemented, but seemed like fun idea - especially with the world being run in another process - or another computer...

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #33 - Posted 2002-12-25 09:58:51 »

Sounds a bit like quakeworld. Why aren't you drunk yet?

Cas Smiley

Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #34 - Posted 2003-01-13 19:31:36 »

Hi guys!

I just want to tell you that I implemented the concept explained by Orangy Tang and WOW, it work very well!

Thank you Orangy Tang!

My scrolling is by far smoother than using my sleep timer kind.

Sorry for the delay about this news but I was very busy.


Cas, your algorythm seems well too but I preferred using Orangy Tang's algorythm.

Thanks to all.

Offline GergisKhan

Junior Member




"C8 H10 N4 O2"


« Reply #35 - Posted 2003-01-13 23:12:47 »

AnalogKid,

Would you be so kind as to post an example of the code change you made?  I'd like to compare your original version on page 1 with what you have now.

The reason is that I still don't fully understand the difference between tick and time based animations as discussed so far, and how the sleep-timer hack fits in.

Your solution may be the very thing I've been looking for.  

Thanks.

gK

"Go.  Teach them not to mess with us."
          -- Cao Cao, Dynasty Warriors 3
Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #36 - Posted 2003-01-14 16:13:24 »

OK

Let say that your hero runs at a maximum of 100 pixels/second (according to its acceleration).  To respect this constraint, you must determine how many pixels your hero will move each frame.

So if your machine can achieve 80 fps then we can say that each frame takes  12.5 milliseconds (1000 / 80).  What time does it represents in seconds?

12.5 / 1000 = 0.0125 second.

Remember that our hero moves 100 pixels/second maximum so to move him in the current frame we increment his x position by:

100 * 0.0125 = 1.25 pixels

Now imagine that your game runs on a slower machine and the fps drop to 50 fps.  No real problem here because your hero will still move at 100 pixels/second but the animation will be less smoother:

1000 / 50 = 20 milliseconds/frame
20 / 1000 = 0.02 second/frame

100 * 0.02 = 2 pixels/frame

And the other great thing about this is that your animation will be as smooth as the fps your computer can achieve!  So if your game can run at 100 fps then your animation will be smoother!

But to implements this algorythm succefully you must store the x position (and also y) of your hero as a float or double value because his position is incremental using floating point values.


Here is the code of my rendering loop:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
public void run() {
    alive = true;
       
    createBufferStrategy();

    Graphics g;
    long startTime;
    float frameDuration;
    int frameCount = 0;
    long fpsStartTime = System.currentTimeMillis();
    running = true;

    // Render the animation.
   while (alive) {
           
                // Store the start time of the frame.
               startTime = System.currentTimeMillis();

                // Render all animation stuff.
               render();

                // Paint the frame and render it.
               g = bufferStrategy.getDrawGraphics();
                do {
                            paintFrame(g);
                } while (bufferStrategy.contentsLost());

                // Put the offscreen image to the screen.
               bufferStrategy.show();
                g.dispose();
           
                // Update the frame rate every second.
               frameCount++;
                if (System.currentTimeMillis() - fpsStartTime >= 1000) {
                            fps = frameCount;
                            frameCount = 0;
                            fpsStartTime = System.currentTimeMillis();
                }

                // Calculate the time elapsed for the frame.            
               frameDuration = System.currentTimeMillis() - startTime;
                animationContext.setFrameDuration(frameDuration / 1000.0f);
            }
            running = false;
}



You can see that I use a class called AnimationContext.  This class is used to store the duration of the current frame in seconds.  This instance is instancied by another class and is accessed by all the actors that need it to calculate the number of pixels to move.


I hope this helps.


Good luck.

Offline GergisKhan

Junior Member




"C8 H10 N4 O2"


« Reply #37 - Posted 2003-01-14 19:22:50 »

Oh.  Wow.  Duh.

I did this too, only I locked it to a particular fps and did not readjust the rates to account for any drop/increase in rendering ability.

I must re-evaluate that position; it might smooth things out.

In my system, I move 64 pixels per second, and locked fps at 32 fps to guarantee 8 pixels per frame.

I think this might be foolish.  I think I should use this way better, to simply guarantee 64 pixel movement per second.

Now here's a question: let's say the machine drops below  a certain fps needed to draw all eight frames of animation I have, what then?  As in, what happens if for some ungodly reason I can do 2 FPS ... in what position is the actor left standing?  More programmatically speaking, what animation frame is displayed?

Are we dropping frames to suit fps?

gK

"Go.  Teach them not to mess with us."
          -- Cao Cao, Dynasty Warriors 3
Offline ryanm

Senior Member


Projects: 1
Exp: 15 years


Used to be bleb


« Reply #38 - Posted 2003-01-14 19:49:59 »

You could determine which animation frame to display based on the distance moved since the last frame.

You give your character a stride length, and an array of animation frames, and do

1  
2  
3  
4  
arrayIndex += ( int ) ( distanceTraveled / strideLength );
arrayIndex %= animFrames.length;

displayFrame( animFrames[ arrayIndex ] );


As long as the sprites are designed with a particular stride length in mind, this would also stop the character from skating instead of walking.

This is all off the top of my head, so is probably fatally flawed in some way...
Offline vydias

Senior Newbie




Welcome to my world!


« Reply #39 - Posted 2003-01-19 21:53:33 »

Analogkid's solution seems like a lot of extra work just to compute the physics for a 2d game.  

We use 3 threads in our game. One for drawing (low priority), 1 for game communications with our server, and 1 for physics. We set the drawing threads priority to low because it is the least important process. Physics and Server comm are vital to keeping your game in sync.  Setting the drawing thread priority to low doesn't mean you are going to kill your frame rate either. I've noticed no difference unless I have CPU hungry applications running.

I don't see a reason for setting a frame rate at all. What if you have scrolling text or some animation that only looks good at certain speeds? are you going to adjust the framerate for this? you might have 2 things that need to run at different speeds on the same screen. Treat everything that has to do with physics in your physics thread and simply draw at fullspeed. With the low priority of the Drawing thread other applications running on your system should find time to share the cpu as well.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Abuse

JGO Coder


Medals: 11


falling into the abyss of reality


« Reply #40 - Posted 2003-01-20 18:19:46 »

eek, a multiThread heathen

release the hounds!!

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #41 - Posted 2003-01-20 19:24:20 »

For 2D games I would not suggest implementing multi-threading because I think is it not necessary and NO, there is no so much extra work to do to implement these simple physics calculations if you implement it in a base class like an actor.

Also having multiple threads involve synchronizing states which is an expensive task and the VM have to switch the execution context all the time which is also an expensive task for your program.

Offline markuskidd

Junior Member


Medals: 1



« Reply #42 - Posted 2003-01-20 20:31:35 »

For most networking situations, a seperate thread is going to be a must. I can also imagine that, depending on the details, a physics thread also makes sense. There's not necessarily anything wrong with the information he gave..
Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #43 - Posted 2003-01-20 21:01:44 »

A separate thread to do the networking code is the only way to do networking. Excellent.
A separate thread to do physics is possibly the worst way to do it that you could conceive of.

Cas Smiley

Offline markuskidd

Junior Member


Medals: 1



« Reply #44 - Posted 2003-01-20 21:10:02 »

Oh well, what can I say?  Cool I haven't gotten much into physics yet.
Offline vydias

Senior Newbie




Welcome to my world!


« Reply #45 - Posted 2003-01-21 03:19:56 »

You can code everything and anything for a game into a single thread if you wanted to.

The question here is what makes sense for your game and 'NO' you don't have to syncronize your drawing threads, physics threads and network thread. That would be very foolish. I can't think of a single reason why you would need to.

If the complexity of your project is great then you need to seperate your tasks and it makes no sense why you can't use an extra physics thread (independent of frame rate) to change your world at set intervals.  This is true for most games but definately is true for 2d rts games that don't need anything less then pixel accuracy for movement, firing, ect. I can see your point with some 3d games that require a finer resolution. The physics thread would be going too often and may start hurting your games performance. But this is a 2d forum and we are talking about what is a good 2d design.

Most games don't need to have a super active physics thread. Our game is graphically intensive and our physic thread operates about 1/100 of the time our graphics thread so how does this slow anything down? I've tested performace and I get no change in my frame rate with or without a physics thread.

All I know is that by seperating our physics from our Rendering has made our life a lot easier and we have suffered no performace loss from adding it and I'd venture to guess that most graphic intensive games would see similar results.

What harms performance more then anything using the java awt is displaying text on the screen. Some of our game screens can drop from 75fps (max refresh rate) down to 30fps on a p2 400 with adding a few hundred characters of text.
Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #46 - Posted 2003-01-21 10:29:33 »

I'll explain again why Threads don't work in this situation:

Physics simulation is a function of actual time elapsed where you take regular samples. The samples need to be regular because human beings are very, very sensitive to changes in rate.

If you use a Thread to make your regular samples you will find that your samples are not regular at all but dependent on several platform-independent behaviours like thread switching latency, scheduling algorithms, other threads running in the O/S, etc; in other words, it makes your code non-deterministic.

Apart from human beings picking up in this non-deterministic behaviour very, very quickly and feeling uncomfortable, you have another problem in that you are synchronizing it with another non-deterministic thread which is your rendering thread. This will multiply the irregularity. You probably don't even realise this but you have already seen what this looks like when you play a network game (although the causes are different) - things stop in mid air momentarily, you freeze solid for half a second etc.

This is not a problem on your dual-processor 2GHz development machine running XP Pro. It just happens to work OK for you - hurrah!

But on my Celery 350 Win98SE box, the rendering thread and physics thread may not interact quite so beautifully all of the time. And remember - your threads are not the only runnable threads - you have to share the OS with whatever else might be running. Who knows what the *nix based systems do?

If you want to make life easier for yourself, you put physics and rendering in the same thread. Then you know that what you are rendering needs no synchronisation, and is an accurate representation of that which you have just calculated. This means you have removed a whole chunk of complexity and arsing around trying to make it deterministic again (the usual Java woes - "Why is it jerky? Why does it pause every now and again? Why is keyboard input sluggish?" etc solved at a stroke). So why it's less complicated to put it in a separate Thread I have no idea.

Anyway, that's the way I do things Smiley and it means I haven't had to use the synchronized keyword yet, which must have saved me considerable typing...

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #47 - Posted 2003-01-21 10:58:56 »

A couple of additional points:
Say your physics works at twice the speed of the rendering thread - you're now doing twice the work, yet only seeing half the calculated results, and so wasting alot of time. If your rendering is going twice as fast, then you either show the same frame twice (in which case you'd have been better sitting idle and letting the GC get a look in) or you do some sort of interpolation inbetween last and current frame - in which case you've overcomplicated things and are likely to get worse results anyway.

Quote
you don't have to syncronize your drawing threads, physics threads and network thread

Oh yes you do. Either explicitly with syncronisation blocks (which can be hell to code) or with a thread safe collection on anything that overlaps (in which case you're getting alot of overhead which you won't appreciate at first).

When our team did CatAttack, we had separate threads for networking, and all was good. Until we started seeing weird logic errors and random crashes. We hadn't syncronised anything and were just letting the two (or more if you were the server) threads operate on the same data. You lose the integrity of your data structures at random points - and you can't think "This is so unlikely to happen, its not going to happen to us", because with both threads looping constantly and rapidly, sods law will mean that the obscure sequence of events you thought impossible will turn up within a few seconds.

(Out solution was a buffer between the threads, where network commands could be queued up, then locked, processed, emptied and unlocked at the end of every frame).

Multithreading bugs are hell to track down and fix, and you gain almost nothing except uncertainty..

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline vydias

Senior Newbie




Welcome to my world!


« Reply #48 - Posted 2003-01-21 17:39:10 »

Ok, I'll agree with cas on his point of unexpected lag if you don't syncronize the physics thread in multiplayer but this is rather simple thing to do (and has nothing to do with using the slow syncronized keyword for the thread). It is relatively simple to syncronize a two player multiplayer physics thread, I'll agree if you are doing more then this or if your physics thread becomes overly complicated it might be a better design to base physics on elapsed time. Most games 2d games don't contain overly complicated physics and I'd argue that you are using a ton more cpu to compute physics if you are getting 75fps (which we do on our min required system p2 400) but you only need to update your physics every 50ms (which is the physics interval for our game). So infact we are saving almost 4x the physics calculations by having a seperate thread.  By not setting a max to my fps I'm able to create a scrolling game that has very fast response because I don't have the ton of overhead that comes with updating my physics everytime I want to redraw the buffer and it creates a much better feel to the game overall.

That is why I state that most people would find using a physics thread for 2d games would improve performace if you don't need to have high resolution for state changes. 3d games would almost certainly require more precise physics and I would agree that having a second physics thread for doing this would slow things down.

I see your point but I also think that with the correct implementation, having an extra physics thread is the better choice for some games.
Offline whome

Junior Member




Carte Noir Java


« Reply #49 - Posted 2003-01-22 04:05:21 »

TheAnalogKid,
How do you implement a good collision detect in time based movement?

Here, sprites don't move tile by tile so a simple x-y checks don't not apply well. Time based movement may move two sprites across each other, but still never meet in a coordinate system (A moved 32pixels, B moved 16pixels where A sort of flew through B sprite).


Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #50 - Posted 2003-01-22 06:59:00 »

If you get objects leapfrogging others, you will need to look into 'swept' volumes, between the old and new positions. A point is swept into a line, a sphere into a lozenge, etc. Then you test these into each other. The real problem is back-tracking to the correct collision point, but most of the time a quick approximation will work fine there.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline whome

Junior Member




Carte Noir Java


« Reply #51 - Posted 2003-01-22 10:54:40 »

Where can I find more info about fixing a "leapfrogging" collisision detect problem?
whereisthemoney
Guest
« Reply #52 - Posted 2003-09-10 15:11:23 »

Sorry to dig this up, but I think that the whole concept of fps is kinda missinterpreted here.

Instead of calculating new positions according to fps for every frame, we should be thinking in terms of skipping frames. This way everything works right, no extra animation frame calculations, and no added multiplications.

So, here's a little (pseudo)code:

1  
update: Ya ain't worth it. Bye

Offline MGodehardt

Junior Member




why does the chicken cross the road?


« Reply #53 - Posted 2003-09-15 12:04:50 »

[size=4]DO NOT USE MULTIPLE THREADS IN GAMES[/size]

i agree to princec, ever thought about synch all variables between render and physics thread ? if u DO NOT SYNC EM your game will go berserk.

[size=4]DO NOT CUT FPS[/size]

why do u wanna cut off the fps rate ? let it flow, u want FPS based movement ? hmmm think about it.

do avatar movement based on time ( for e.g. you scroll screen by 1 ( or whatever you want ) every 50ms, its really easy to achieve this in ONE THREAD.

I wrote alot of stuff n games under DirectX and WE DO NOT CUT OFF FPS grrrrrrrr

DO NOT DRIVE ME CRAZY
Offline kevglass

JGO Kernel


Medals: 120
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #54 - Posted 2003-09-15 12:13:34 »

Using big fonts is like shouting, people will notice it but it doesn't make you right. (not that I know if you are or not). Its also fairly irritating.

Kev

Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #55 - Posted 2003-09-15 12:44:32 »

Tongue Maybe I'll just nip back and edit me comment on page 2!

Ah, just be thankful Java_VRML_Animator hasn't appeared in the thread.

Cas Smiley

Offline MGodehardt

Junior Member




why does the chicken cross the road?


« Reply #56 - Posted 2003-09-15 13:32:03 »

Quote


Ah, just be thankful Java_VRML_Animator hasn't appeared in the thread.



argh ... Java_VRML_Animator, you wrote it
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #57 - Posted 2003-09-15 13:50:53 »

Quote
Tongue Maybe I'll just nip back and edit me comment on page 2!

Ah, just be thankful Java_VRML_Animator hasn't appeared in the thread.

Cas Smiley


Cas, a suggestion: Write up the argument you've become famous for Grin in an article, and introduce it / title it something like "Real-Time Games".

Part of the problem with this issue is that your viewpoint is definitely not *always* correct for every game...and a lot of people find themselves in a situation where it isn't actually best. Unfortunately, they seem to have difficulty appreciating that you are describing a very mainstream technique, one that should be part of their toolbox - many interpret it as "do it this way; all else is wrong".

Give it a name, and I think a lot of people will interpret it more sensibly. For people who don't know precisely what RT means, it probably will also make them think "Hey, I bet that's a way of making my game go faster!" and so you'll grab the attention of lots of people just with the title. And you wouldn't even be misleading them Smiley

It also makes it extremely easy to have a section "*When* should I be using Real Time programming?" - and easy to provide links to the many many many CompSci courses on the web which have nice, simple, easy to understand lecture slides on RealTime scheduling.

Just a thought...

Oh, and everyone else [naming no names] please stick to reasoned arguments with supporting evidence...it makes the conversation more interesting.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #58 - Posted 2003-09-15 13:59:33 »

Quote
Cas: I'm currently having a thread for each triangle in my 3d shooter. Each triangle is then given a dynamic priority depending on how close it is to the camera. Then all triangles will do

1  
2  
3  
4  
5  
while (true) {
 synchronized (this) {
   Renderer.display(this)
 }
}


to have itself rendered. The Renderer in turn does this

1  
2  
3  
4  
5  
6  
synchronized (this) {
   if (num_triangles < MAX_TRIS_PER_FRAME) {
     gl.makeCurrent();
     tri.render();
   }
}


That way I can control how many triangles is rendered, and by using threads, I'm assured the maximum throughput (every triangle renders as fast as they can, no more waiting for a traditional single threaded rendering loop to render it).

However, I might be forced to redo this in C++ as the JVM is really bad at handling threads Sad((. My approach only gives me about 1-2 fps for a quake modelviewer test. My guess would be that using C++ would give me about 60-100 fps. Do you think I should file a bug report to SUN or are they too lazy to respond to serious game programmers like me?

- elias


ROFLMAO.

malloc will be first against the wall when the revolution comes...
Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #59 - Posted 2003-09-15 18:25:41 »

Quote
[...]
[size=4]DO NOT CUT FPS[/size]

why do u wanna cut off the fps rate ? let it flow, u want FPS based movement ? hmmm think about it.
[...]


I cut fps if it makes sense.

In my TinyRivers game I aim for approx 60... and it's ok that way. On kinda up to date machines it runs with 2000 - 13000 fps and that doesn't make any sense - obviously Smiley

If the window isnt active I cut em even down to approx <10 fps... just enough for beeing able to draw itself (if you move another window infront of it).

弾幕 ☆ @mahonnaiseblog
Pages: 1 [2] 3
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (35 views)
2014-07-24 01:59:36

Riven (33 views)
2014-07-23 21:16:32

Riven (21 views)
2014-07-23 21:07:15

Riven (24 views)
2014-07-23 20:56:16

ctomni231 (55 views)
2014-07-18 06:55:21

Zero Volt (47 views)
2014-07-17 23:47:54

danieldean (38 views)
2014-07-17 23:41:23

MustardPeter (43 views)
2014-07-16 23:30:00

Cero (59 views)
2014-07-16 00:42:17

Riven (56 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!