Multi-thread Applet, for timeleft measure?

Performance Tuning
#1

Hi all.

I’m starting with game development right know, and i’m stuck with some doubts. I have my client loading an applet, and I make it Runnable. Fine, but I read somewhere that it should not have any other threads inside an applet, except the Thread that owns the Applet. Ok, now here comes my doubt:

Inside run(), I make animations. Great, but there is a special Object that computates the timeleft for the next round, but it inherits from Thread class. Is there any best practice to get the same results? Show timeleft for next round, without stop animations and without loose time sync? (Showing the time making time - 1 sec, always).

Thankz fokes… :slight_smile:

#2

I’m not REALLY sure what the permissions are on Applets using .dll files, but if it is possible, I don’t see a reason why jbanes’ GAGETimer wouldn’t work here as a separate thread, so you’d get a regular heartbeat to control your animation.

I don’t really think that having only ONE thread should be treated as a hard and fast rule at all times. A timer like this is a good example to spawn a thread. That thread is ONLY keeping time for you, so it should be able to respond with near 0 latency… meaning your time clock should be pretty darn accurate.

Anyone know if an applet can use native code? (DLL file?)

#3

No it can’t, unless the user user gives it such a permission (by either editing the permissions file or running the policytool).

You don’t want applets formatting your harddrive, which they certainly can from native code, do you? =)

#4

Ah. Yes. That’s right.

Shows you how long it has been since I have written an Applet.

#5

Ok, backing to the real problem. :slight_smile:

So, any ideia on how to make timeleft measure, for example, to the next round? A single round take 6 min, and from one round to another, it can take for least, 1 min. My question is: can I use a separated Thread, inside my applet, to do something like this:

Applet … {
… new TimerThread(this);
}

TimerThread … {
run() {
…
timeleft–; // 1 sec less
Thread.sleep(1000); // sleep 1 sec.
updateApplet(); // draw to the applet the new timeleft value
}
}

Like I said before: I read on somewhere else, that it’s not a good idea to work with multi-threads in an Applet.

#6

Java games are somewhat different from normal java applications.

Do all the rendering and the game logic ( like physics, networking ) in ONE THREAD.

Do NOT use Thread.sleep or Thread.yield ( its Thread.sleep(0) ). On a Win98 System the ticks are generated every 50ms on a WinNT System every 10ms.

Do NOT use any synchronize. A Syncronize can slow down your frame rate dramatically ( maybe 10fps or lower ), game will flicker.

One example:

I you render at 60fps then u need to refresh the screen every 16.7ms ( now u see what happens if u sleep 50ms, u will drop frames )

In your main method u should have something like this

while ( isRunning )
{
render();

gameLogic();

sleep();

}

IMPORTANT: sleep is your own sleep method, i will explain this later.

I Use sun.misc.Perf as Timer it runs on my System with
1193180Hz and so i get 1193180 Ticks a second, with this timer u can measure everything in your app.

1 Tick ~ 0.838µs

For the sleep method i use a loop like this

while ( getTicks() < stop )
{
idx++;
}

stop is calculate before entering the loop, idx is a simple int.

I work for a game company and trust me, if u spawn a single additional thread u are doing something wrong.

#7

There is nothing wrong with using threads in an applet. Use a bunch of them if you wan’t. But as always, you must know what you are doing.

This example might work just fine, or couse a horrible bug, depending on what it does. If it calls repaint() on the applet, it’s fine. If it grabs the Graphics object of the applet and starts drawing, it will couse problems. Becuase the main applet thread might be drawing at the applet at the same time.

The safe to your problem would be to poll for change in you main thread, and repaint the graphics when needed.

#8

Using sun.* classes in applets is usually a bad idea. Atleast it was back in the days I was coding applet games (java 1.1). They are not part of the standard api, so some applet viewers might not have them.

#9

I have a Wrapper class around sun.misc.Perf, at the moment the java game is only running as application and comes with jre ( so i can control the version ).

But i hope sun will add some high resolution timer in the future ( then the Wrapper class will be rewritten )

#10

[quote]Ok, backing to the real problem. :slight_smile:

So, any ideia on how to make timeleft measure, for example, to the next round? A single round take 6 min, and from one round to another, it can take for least, 1 min. My question is: can I use a separated Thread, inside my applet, to do something like this:
[/quote]
This is a great situation for TimerTask and Timer. Have a look in java.util.* for those classes - they’re pretty self-explanatory, and part of the standard API.

You should be able to get them up and running v. quickly and easily. If not, post here again or msg me and I’ll give you some sample code (but you probably won’t need it :)).

Yeah, well, there’re a lot of misinformed opinions floating about the internet, aren’t there? :stuck_out_tongue: But seriously, without context it’s hard to know exactly what the reason was for that statement; it could well make perfect sense in the original context, but that context might have been lost when it got re-told several times to different people.

The need to “only have one thread” in a game comes mainly from when you are doing a lot of processing, or have a “real-time” game where you need to animate lots of things, have complex AI running in parallel, etc etc. Typically, if what you are doing is not action based, it’s not worth the effort (it often won’t bring you any benefits, but will cut down your available design decisions).

For applets specifically, I would always advise newbie java programmers to single-thread for a while mainly because they forget to obey the Applet contract - i.e. the stop() start() load() unload() etc methods - and end up leaving threads running in the web browser that they don’t know about and CANNOT terminate. A long time ago I wrote a fast 3D animated mandelbrot applet, and made this mistake. Every time you re-visited the page to show it to someone, it got slower :). Oh, how amusing that sounds now! But back then, it was very difficult to work out.

As soon as you feel confident you know your applet is stopping all it’s threads at the right point, there is absolutely no special reason not to use multiple threads. Use twenty of them - your OS probably won’t even notice (Ahem. Assuming it’s less than 8 years old…).

Hey, even Sun’s official tutorials include examples of running multiple Thread’s from within an Applet, so I really wouldn’t worry if I were you!

#11

If u use threads under Win9x u will be limited to max of 20FPS.

So u will never make a real game, never earn a lot of money and never make a living of it.

Java Thread.sleep limits you to 50ms sleep, u cant change this.

U can write a mandelbrot applet, but nobody will pay $15 dollar for it.

I am a professional game developer and trust me using Thread.sleep is a big NONO, even sun’s programmer dont use them, they use the same technique as me.

#12

[quote]If u use threads under Win9x u will be limited to max of 20FPS.

So u will never make a real game, never earn a lot of money and never make a living of it.

Java Thread.sleep limits you to 50ms sleep, u cant change this.
[/quote]
Firstly, “doesn’t work on win9x” isn’t a concern for many people these days. IIRC, the vast majority of people running any windows OS that is more than about 3 years out of date are corporates, becuase of the massive investment in getting 100,000+ desktops running the same version. Anyone know how many non-corporate desktops are running windows other than 2k, XP and above? One thing’s for sure - even AAA titles don’t always support win9x any more, so I don’t know why you expect that all game devs would want to.

Secondly, sleep does NOT “limit you to 50ms sleep”. I appreciate the point I think you are attempting to make (on all OS’s, everywhere, you cannot guarantee a granularity finer than X), but it’s not a useful one. I’ve been writing applets for many years on everything from RISC OS through Win95 (and SR’s), NT 4, 2k and XP. Back on RISC OS, the OS itself could only answer a System.currentTimeMillis() with multiples of ten millis, because it counted in 100’ths of a second. Didn’t cause much trouble though…

…or would you like to also tell us that we mustn’t write any games that use two mouse buttons (or - god forbid - 3 or more!) because Mac’s often come with only one?

Thirdly, the mandy app worked beautifully. My standard test machine was a P-90. Back then, with java 1.1.x, and greatly inferior JVM’s, performance was a much bigger problem than now. Didn’t have much trouble with Thread.sleep() though…(I’m not saying it’s perfect, just that it’s pretty easy to work with).

Apparently PopCapGames are NOT actually making multi-million dollar profits then? According to you, in their few years of trading, there’s no way they could have made any money. IIRC none of their games need timing on a finer granularity than 50ms (irrespective of how they’ve implemented them)…

Finally, no offence meant, but based on your statements I don’t think much of you as a pro games developer. Commercial games dev is about making compromises, and a large part of that is painful decisions about how big a section of your target market to cut out, by not supporting their OS/hardware/software combination.

#13

[quote]Anyone know how many non-corporate desktops are running windows other than 2k, XP and above?
[/quote]
I would guess quite a lot! ;D Of the machines in constant use in my house, there’s one Win95, two Win98, one WinME and one WinXP. I’m not about to go spend £500 on a new OS just because my current one is three years old - it still does everything it used to.

[quote]One thing’s for sure - even AAA titles don’t always support win9x any more, so I don’t know why you expect that all game devs would want to.
[/quote]
I’ve noticed Win95 support has all but gone, but from what I’ve seen Win98 is still very much a deployment platform. If I start to see games I want that don’t support Win98 I guess I’ll have to upgrade - my main gaming machine is Win98SE.

#14

I’d suspect you were a special case. Most of the technophobes I know have even upgraded to XP since its performance is so much better (and its so easily available :o)

Kev

#15

90% of our customers use a Win9x based computer system, only 0.5% use Linux or Mac

I use one Thread for all my Games, if u use multiple threads u have to sync with with the render thread ( bad idea to change variables in the mid of the render loop ). I tried multiple threads with sync and got a bad performance.

So after a lot of experiments i got a working solution for me. ( does not mean this is the one and only solution )

have on thread which handles rendering and game mechanics and networking

while ( !stop )
{
render()
gameLogic()
}

there is no sleep, means i get the max FPS for the machine.

in the gameLogic i go thru a list of GameEvents which have TimeFrames ( after x ms they get ticked ! )

so for e.g. my scrollEvent gets ticked every 50ms and calculates the diff between calls to his tick and so even if FPS is different scrolling is always done with they same speed.

In applets i use different time calculation ( i have 20Hz Timer System.currentTimeMillis ) so i can sample 10Hz means 100ms intervals, but i will experiment with Sleep(5) which gives me a 10ms sample rate and gives me ( i hope so ) the same smooth scrolling rate as my application does in the moment.

I also switched from 2 Buffers to 4 Buffers and that stabilized the FPS a lot.

#16

[quote]I’d suspect you were a special case. Most of the technophobes I know have even upgraded to XP since its performance is so much better (and its so easily available :o)
[/quote]
Just a thought: percentage-wise, what proportion of these people paid for their upgrade?

Assuming a “quite a lot” response, how many of those would still upgrade if the had to pay for it?

#17

Heck I have NEVER even paid for a PC let alone the OS.

My employer has always supplied me with a box for home. Even my Powerbook was sort of a bonus that I took as hardware instead of cash.

The last computer I bought with my own coin was an Amiga 3000. (should have waited for the 4000 - doh!)

Common PCs are too crappy to pay for. Most of them don’t actually work in my experience, e.g. one of the PCI slots won’t do DMA properly or some such thing. Decent stuff is generally a bit more expensive… and anything you can get doesn’t last long enough in terms of being able to cope with the latest software to be really worth paying for…

If I was forced to pay for stuff I would… but I would not upgrade every time a new OS came out… probably every other one.