 |
|  |
 |
|
JimC
|
|
Birmingham, England
May 1999 time: 05:13
|
|
If we're going to use threads for any heavy processing, I suggest that we look up as much data as possible on various VM performances - some older versions have terrible problems when it comes to synchronization etc....
I've attempted to get RTS-standard (around 20-25fps) animation using Java, with a program thread, a display thread, a background AI thread, a path-finding queue thread and node generator thread.
Using the range of thread priorities available with the standard JDK values, there was still noticable jerkiness (and I used as little synchronization as possible).
So, it seems are options are:
- try using native threads ???
- become VM experts
- avoid RTS
- pray that JIT compilers will speed things up
- spend 5 years in development, by which time 2000MHz computers will be around
Has anybody else tried running heavy-duty threads in the background?
Jim
|
|
|  |
 |
|
JimC
|
|
Birmingham, England
May 1999 time: 05:13
|
|
OOOOps it looks like I pushed the wrong button - this is supposed to be under 'Threads in RT'
Jim
|
|
|  |
 |
|
F_Smith
|
|
Austin, Tx 78728
May 1999 time: 05:13
|
|
Hi, Jim:
Just saw this thread -- no pun intended.
The speed of java is increasing as we speak. By the end of the year, with 'HotSpot' and other things, it should surpass current code.
But even so, as long as we stick with 'slow' movement for units, I think we can handle it.
P.S. -- I asked this before, I'll ask it again: can't we use one thread for both unit movement and AI? I don't quite understand the architecture model ya'll are talking about for the AI. Why a seperate thread for something that only has to make choices once every cycle?
|
|
|  |
All times are GMT. The time now is 05:13. Apolyton Time is 00:13. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|