64bit and multithreading

[Auss 208]

Doh yep I get you now, This is the concern I have when the English versions released. We will get hit hard with players and this game better be able to support the hoards that will jump on and play or we will lose a truck load of them which will be a shame.

[wamingo 1]

64bit is for specialist users. It supports a ridiculous amount of memory. Can do large number calculations faster. And unless a truely completely different generation of games suddenly spawns out of nowhere, it's of absolutely no use to gamers in the next couple of years.

Granted, 64bit platforms are now more available, so why not do the switch? Well, 2 vista versions (32/64bit) and no gamer wants xp64, and xp/2k will undoubtedly be supported for ages still anyway (32bit). That should speak for itself.

Why not make it support 64bit natively? Well why not make it support linux? Or how about macintosh?

Multithreading. Like suma says, Multithreaded programming is complicated. I dare say it is probably the worst thing to have happened to gamers period, because this seemingly tiny thing, will in fact complicate things so badly, degrading quality, declining number of games, and rivers of bugs will flow our way, very soon.

This isn't an extension like a shader 2.0 with driver support.

[CouchMonkey 0]

It may be complicated, but it has to be done. If they plan on allowing this game to facilitate 100+ players it has to be able to fully utilize a multi-core server. Period. Our own tests have shown that right now 60+ players are not feasable because the processing overflows from one core to the others thus slowing the system down. Not to mention that the netcode is still a beast.

Long and short of it is that no, it is not the number one priority, but it must not be discounted simply because it is hard and not that many games use it.

[Millenium7 0]

While programming native multi core support is difficult it could be possible to emulate it to an extent. If BIS could write a dedicated server which communicates with other dedicated server programs you could have 1 running on each core (or seperate computers) to form a single server.

[zlutor 2]

Quote[/b] ]Multithreading: Yes, ArmA is missing specific optimization for Dual Core systems. The same can be told about many (perhaps most) ... both nVidia and ATI in the drivers, you can see a measurable performance gain in ArmA (my measurements have shown 5-20 % improvement depending on the scene).

Well, although i think MSFlightX is not a good example, you are right that not every game or simulation has multithreading and 64bit support. But the point is that we dont talk about MS and its Flight Simulator. We are talking about ArmA. Just for the files: Half-Life (yes even HL1) and HL2, Battlefield2, Ghost Recon Advanced Warfighter, Rainbow Six Vegas, Americas Army, Gothic 3, ALL Unreal Engine based Games since Unreal1 are multithreaded, Ofcourse ID Software's Quake IV Engine, ...

we could expand this list a lot more.

multithreadin is complex and complicated but that is the comon business of professional developers. im pretty sure that adding multithreading afterwards is rarely possible due the immense amount of time (and money).

just take it as some kind of critics for the responsible head-of of this project. usually when development has begnu multithreading should have stood on the list. even when ofp was recent, there already was known that intel and amd would produce multicore processors for the consumer market. also classic smp systems (multiprocessor boards) were already pretty popular. so i dont think ppl would understand reactions as "oops, how we should know?!".

...

just my point of view

Simon

Fully agreed. Just try out e.g. BF2 on a single and on a dual core CPU...

Having a 'modern' game without multi-core support is a shame. Regardless the really existing difficulties what multi-threading gets into the picture, it must be there. No question. It is question of professionalism. ;-)

It is quite frustrating that my CPU has two 2GHz cores and I am able to get ~20FPS (causing 70% load on one core) even if graphich setting are not so high... O.K. I have to admint that 7600GT is not the most powerfull card on planet but this config gives me 100+ FPS in BF2 (1024x768 and full detail)

[zlutor 2]

Multithreading. Like suma says, Multithreaded programming is complicated. I dare say it is probably the worst thing to have happened to gamers period, because this seemingly tiny thing, will in fact complicate things so badly, degrading quality, declining number of games, and rivers of bugs will flow our way, very soon.

This isn't an extension like a shader 2.0 with driver support.

Multithreading is not the Evil itself. Just you have to make it right, that is the key issue. Never try to make 'tricks' but solve the problems instead. There are several good techniques out there to manage them. Nobody has to reinvent the wheel. It is just part of SW development, too. Being professionally trained it is just a task to complete. It is not even 'art of programming', basics were founded in '70s (if I remember right).

There are quite many 'independent' things in games (AI, phisics, grapics, etc.) they just offer themselves to be processed paralel...

[crashdome 2]

While programming native multi core support is difficult it could be possible to emulate it to an extent. If BIS could write a dedicated server which communicates with other dedicated server programs you could have 1 running on each core (or seperate computers) to form a single server.

About the best thing I've heard so far in this thread.

I spoke about this in another thread, but cannot remember the title or location... so I will summarize:

I recently saw a video where two (previously non-gamer) software developers used advanced movement prediction and peer-to-peer gaming to reduce bandwidth on an old version of Quake. It was the lamest video I ever saw. The prediction technology has been used in every modern FPS (AFAIK) and they made it seem like a next-Gen tool. Likewise, peer-to-peer gaming has been shown to cause massive problems in NATs which make up a huge segment of the gaming market nowadays. Well, regardless of the garbage in the video, a comment posted went on about how you could break up tasking by utilizing a other gamer's clients as psuedo-routers for the network info.

Example Case:

A) One server with 100 players means there are 100 packets being generated and sent individually to 100 clients.

B)One server with 10 sub-servers each having 10 clients (100 total). The main server ONLY communicates with the sub-servers by sending 10 packets. The sub-servers in-turn generate the appropriate info the the 10 clients.

The most obvious benefit is bandwidth. Someone pointed out that bandwidth on most *major* servers is not a problem (having T3s and the like). However, that still does not address the need for the server to process the information for 100 clients.

Now, currently in OFP, every member of the player's group is handled by the client. This is OK in the case of AI, but not so good with other players in your group (adverse affects, etc.) In ArmA, it seems to have been improved. Is it possible, in some way to develop a small dedicated server which handles multiple clients like OFP/ArmA handles grouped units on the client?

For example, one sub-server could register three clients and handle the calculations for the three clients and their grouped units and transmit (on the main servers behalf) to the other sub-servers. It's a half peer-to-peer and half client/server framework. The servers are peer-to-peer and the clients are client/server.  This addresses the problem of NATs for the average player, reduces load on the server, AND reduces bandwidth (if needed).

Seriously BIS, is this an off-the-wall solution? Is it even viable?

[EDIT] Found it: http://www.flashpoint1985.com/cgi-bin....t=59693

Ties in with the multi-threaded discussion...[/EDIT]

[max power 21]

Sounds like some kind of ping multiplier to me. Every stop you need to take to synchronize takes time. Ten servers communicating amongst each other and ten other clients seems like it would go a long way to slow down the flow of information as a whole. I am far from an expert on this issue, however.