Sign up Calendar Latest Topics
 
 
 


Reply
  Author   Comment  
Jormungandr83

Registered:
Posts: 35
Reply with quote  #1 
Obviously the server needs to be the best computer, but what about after that?

I have 5 identical laptops, save for one which was twice the RAM as the others. I had been using this one for Helm as I assumed it was very important to have the fastest computer controlling the ship, but now I wonder if that assumption was incorrect.

So does anyone know which of the clients needs the best computer? How should I prioritize processing speed?

Thanks!
ryleyra

Registered:
Posts: 2,910
Reply with quote  #2 
Well, one thing to keep in mind is technically the server is controlling the ship. All the Helm really needs to do is intercept the player inputs and transmit them to the server. As long as the client is able to keep up with the network traffic without creating lag, it should be fine.

The bigger issue, I think, is the graphic requirements, and the number of different objects that have to be tracked at the same time. Mind you, this is entirely a guess on my part, but I would think that the most memory-intensive station would be Science. It is the only station that can actually see and track every single object in the sector. It also has to render all of the enemy ships, in 2D only, but that still takes more processing time than LRS, which does not render silhouttes.

I would say Helm and Weapons are probably tied for second, with Weapons needing a little more power for Gun Camera mode. Engineering may also need some processing power for rendering the damage control grid and ship silhouette in 3D, although probably not as much as Helm and Weapons. Comms probably has the lowest requirements.

It is important to note, though, that every station has access to the LRS map, and every station has a VIS screen. That means that every station has to keep track of each object in the sector, even if it is not displaying it, AND every station has the requirement to display a 3D rendering of the area around the ship. Now, VIS can be turned off (on the PC, using the switch defined in artemis.ini) which can be helpful for running it on a PC tablet that may not have a lot of processing power. But I'm guessing the VIS screen takes the most processing power of any display of a station.

I would also think that the Fighter station or a Mainscreen for a second ship takes far more 3D graphic rendering power than a standard station. It just doesn't need to keep track of the server information AND render the mainscreen like the server does.

So in order of descending processing power:

1) Server
2) Mainscreen, Fighter
3) Science, Gamemaster, Captain's Map
4) Helm, Weapons, Engineering
5) Comms

Again, that's just a guess. Research into this topic might be interesting. [biggrin]
Pithlit

Registered:
Posts: 8
Reply with quote  #3 
I think memory and processor resources are about the same for all stations.

The server sends information for all objects on the map to all clients.
My weakest laptop starts to lag when more than about 100 objects are on the map, no matter what station I take. Lag increases when enemies launch fighters, Lag decreases whenever we nuke some big blob of enemies.
Even Comms keeps track of the position and type of (I think all) objects, because the enemies shown are sorted by distance to the players ship.

Graphics required differs between the stations.
Mainscreen, Fighters (in 3D Mode) and Vis (obviously) require most graphics. My weakest laptop needs about 10! seconds to switch to a 3D view (which means i start controling a fighter 10 seconds after pushing the launch button.)
Graphic is loaded when pushing the button which switches the view: so you won't need more resources if you have a vis tab as long as you don't push it.


I once tried the game on a pc from 2004 (Windows XP / 32-Bit Arch Linux) with 512 MB ram and a very old and broken Nvidia graphic card (it once could render 3D or 2D objects).
3D views were just empty background images, in Helm and Weapon and Science 2D ships could not be displayed (so you can only see ship names).
Comms worked quite fine, but the game always crashed when taking the first damage.
Jormungandr83

Registered:
Posts: 35
Reply with quote  #4 
Thanks for the ideas! I'll try giving the science station the extra memory, and I'm definitely going to disable VIS in all the clients.

I'll try to have a system monitor going in the background and see if I notice anything fun!
notsabbat

Avatar / Picture

Registered:
Posts: 1,221
Reply with quote  #5 
Having a good PC for helm is good as well. It probably doesn't need more system resources than other stations, but its a bigger deal if it messes up. you don't want a momentary freeze up when you are cruising near a mine field.



__________________
-Captain of the TSN Gungnir JN-001
-Eastern Front online group member
-My continuing bridge build:
http://artemis.forumchitchat.com/post/immersion-bridge-build-in-progress-7335195?pid=1290158413
ryleyra

Registered:
Posts: 2,910
Reply with quote  #6 
Quote:
Originally Posted by Jormungandr83

I'll try to have a system monitor going in the background and see if I notice anything fun!


I expect Helm and possibly Weapons will have the most network traffic. Science will probably have a burst of traffic to initialize everything, and then sit idle once the Science officer is done scanning. I'm not sure how much traffic Engineering and Comms will have.

It'll be interesting to see if Engineering spends most of its time simulating things independently of the server. For instance, the server probably doesn't care where DamCom teams are, or what they are working on, just which systems are working and which aren't.

As I said, all stations have to keep track of the whole sector, because of the LRS screen (which can't be turned off) and as Pithlit said, even Comms has to sort the objects by distance. I suspect, though, that all the objects are not sent across the network each cycle, but instead each console simulates them separately, and the server probably sends sync packets of some sort. I have noticed that fighters turn so fast that their rotational position becomes unsynced with the server almost immediately.

I'm curious about all this, but I don't know if anyone else is. [biggrin]

LawsonThompson

Registered:
Posts: 587
Reply with quote  #7 
Count me in as curious about this one, too. I'm using 7+ year old hardware for most bridge stations, but the fighter console definitely needs some 3D rendering horsepower. Switching to "VIS" can be a show-stopper for older laptops; disabling VIS everywhere keeps my bridge alive. 

In the particular case of the original poster: Artemis RAM requirements are actually quite low, so using the machine with the most RAM won't gain you much except to reduce the impact of background tasks and improve some disk performance via caching. 

I've benchmarked machines for Artemis by selecting a client position and the Observer screen. Let the game get started, then press Alt-F to turn on the frame rate counter. Switch to Observer to see the 3D rendering view, then back to the console view. The difference in frame rate in the 2D console vs. 3D Observer view is a good relative number to compare machines. The stronger the machine, the smaller this difference.

If your frame rate drops below 30 regularly, you'll have some issues on a busy map. 

OH! One more tip: make sure the Windows Control Panel > Power Management settings for all machines are set to "Desktop" or "Always On". If you pick "Balanced", most machines will throttle the CPU when not in use. This can cause some micro-stuttering in some cases.

Regarding sync: If you have a very large, crowded sector, you'll see it load in pieces in the LRS and Science view. I'm not sure how much data is sent per cycle, but it'll take a bit before the entire game state is spread across all machines. I assume the server keeps a local copy of each station's needed state, then sends the bits out until they're all acknowledged. Once that's done the server only needs to send the deltas out and receive inputs back. This explains why if you cut power to maneuvering, Helm will show the ship is turning, then will "slide" back after the server gets all the state information sent back out and each console corrects itself to reflect reality. This may also explain why a late joiner may lag the entire game, and creates the theory that the entire game flow will slow down to pace with the slowest CPU in the game. 

__________________
----
Visit us at http://www.ltebridge.com
Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.