Fulqrum Publishing Home   |   Register   |   Today Posts   |   Members   |   UserCP   |   Calendar   |   Search   |   FAQ

Go Back   Official Fulqrum Publishing forum > Fulqrum Publishing > IL-2 Sturmovik

IL-2 Sturmovik The famous combat flight simulator.

Reply
 
Thread Tools Display Modes
  #11  
Old 01-19-2010, 07:59 PM
Flyby's Avatar
Flyby Flyby is offline
Approved Member
 
Join Date: Oct 2007
Posts: 701
Default

Quote:
Originally Posted by yarbles View Post
My only knowledge of apps designed to work in multi-core/cpu environments is stuff like Oracle in Solaris/Red Hat on Enterprise workstations. In order for those apps to be optimized to take full advantage of the 32 cpu workstations w/ 256 GB of RAM - an army of coders were employed. Oracle's business depends on optimized I/O. I think our expectations for BoB are way out of wack. Folks want crazy AI, DoD quality FMs, etc.. it won't happen. There just isn't enough man power in Oleg's lab to code the stuff to fully take advantage of the modern day computing power. I would imagine will get something similar to what we've already seen but w/ better eye candy. We may see BoB have a better handle on how to deal with more planes in the air and better terrian but other than that under a very restrictive budget, I wouldn't expect to see things much more advanced that what's already been done.
Wow! Wouldn't that be something if SoW came out behind the power curve instead of ahead of it? You may be on to something, yarbles. Then again, people spent billion$ trying to come up with a gaming system that would run IL2 smoothly with all options turned on (only to be hindered by single-core processors). So it's possible that a lot of items in IL2 that caused stutters, and single-digit fps might actually perform quite well with a dual or a quad. Still, I'm filled with an exquisite dread that when SoW comes out even the most powerful gaming systems out there won't be able to run it full tilt. In LOMAC the clouds could be an fps-killer, not to mention the water (but that was a coding thing too, iirc). I wonder how much of an FPS killer flying over London will be? Wouldn't it be ironic if, in BoB, people avoided missions over London because the city, and the flak brought a modern gaming rig to it's knees? Will Oleg allow that to happen to an area so crucial to the game- play immersion and the title? I think Oleg will have so much going on in SoW that a dual-core will be the minimum requirement. Remember those screen shots of ground objects (that can be effected by damage)? Also, even with a small team, SoW_BoB has been quite a while in the making. So it's possible that there won't be a system that can run it at full tilt. Funny to think about, eh?
Flyby out
__________________
the warrior creed: crap happens to the other guy!

Last edited by Flyby; 01-19-2010 at 08:02 PM. Reason: explosive diarrhea!
Reply With Quote
  #12  
Old 01-19-2010, 09:44 PM
mazex's Avatar
mazex mazex is offline
Approved Member
 
Join Date: Oct 2007
Location: Sweden
Posts: 1,342
Default

Quote:
Originally Posted by dduff442 View Post
Hi All,

Will SoW:BoB take advantage of 64-bit, quad-core architecture, hyperthreading etc?

The PC gaming industry has gotten seriously out of whack. $800 twin-gpu setups are common, but no more than a tiny handful of games use more than 2 CPU cores, more than 2GB of ram or are multi-threaded. A great opportunity for deep AI and immersive, interactive and open worlds is being totally ignored by the industry. This is all the stranger as RAM and CPUs are relatively cheap compared with high-end graphics cards.

I'm hoping SoW:BoB will make use of the PC features that will be mainstream in the coming years. FSX is the only game that does at the moment (seriously, this is a fact). SoW:BoB is ideal for hyper-threading and the 16GB of RAM the Home Premium editions of Win 7/Vista allow would permit environments of incredible detail to be portrayed, along with intensive layered AI processing etc.

There's a lot of expectation out there for BoB, and I'm no different. I held off buying a new PC until it became imminent. (I'm very reassured at the busy look of your offices BTW!) A bit of info about the processing capabilities of BoB at this point might whet people's appetites even more....

Regards,
dduff442
(have played online as Kestrel666)
Well, you describe the "strange" scenario well above - how come that so few games use multiple cores effectively but rely on beefy GPU:s? I guess you are not a programmer? It's really hard to use many threads effectively in an application that uses a main render loop that runs the screen updates at very high steady speed (many threads doing the render is even worse - though in some cases possible). When you are going to synchronize/join data for that render thread with a number of separate other threads (AI, network, loading stuff etc), you will have to keep you tounge in the right mouth The threads running on different cores really live their own life (and should do so) so the syncronization has to be effective to not get threads waiting for other threads etc (producing stutters and lag). Getting a bunch of threads to dance together while the main render thread runs at a steady 60 loops/sec is like a tango with four wifes - without annoying any one of them

EDIT: It's naturally a grail to be able to be able to write the optimal game engine using all cores available in a system... Even writing a game that runs two threads well can break programmers and companies backs - F4/Microprose anyone?

Last edited by mazex; 01-19-2010 at 09:52 PM.
Reply With Quote
  #13  
Old 01-19-2010, 09:52 PM
Tree_UK
Guest
 
Posts: n/a
Default

Quote:
Originally Posted by mazex View Post
Getting a bunch of threads to dance together while the main render thread runs at a steady 60 loops/sec is like a tango with four wifes - without annoying any one of them
LOL, got to be quote of the year, nice one Mazex S!
Reply With Quote
  #14  
Old 01-19-2010, 11:13 PM
JG27CaptStubing JG27CaptStubing is offline
Approved Member
 
Join Date: Dec 2007
Posts: 330
Default

Quote:
Originally Posted by Flanker35M View Post
S!

Falcon 4.0 used multicore to an extent and being quite old game So let's hope SoW will use more cores to even out the workload, could finally put my i7 to work!
There was quite a bit of genius behind the development of Falcon 4. While not perfect by any stretch it was a multithreaded application back in the day of 1998. It basically gave the game a 40 -60% improvement of FPS when over the FLOT. The only time this really came into play was in the campaign mode. It ran the real time 2D world as a separate thread. It also helped out when dealing with the Disaggregation in the 3Dworld. Amazing game even to this day in its current form it has an even better improvement working with multiple cores.

FSX is a bit of a misnomer in terms of utilizing Multicore. The team kind of cheesed it a bit because all it does is deal with the preloading of the game when coming into other areas. Sure it helps out but nothing like leveraging other cores to handle things like AI, and Flight Modeling. To my knowledge there won’t be a real time campaign element to it. But like someone mentioned the sky has opened up in terms of processing power. Lots of memory now and CPU/GPUs to leverage.
Reply With Quote
  #15  
Old 01-20-2010, 12:46 AM
dduff442 dduff442 is offline
Approved Member
 
Join Date: Jan 2010
Location: Ireland
Posts: 114
Default

Quote:
Originally Posted by mazex View Post
Well, you describe the "strange" scenario well above - how come that so few games use multiple cores effectively but rely on beefy GPU:s? I guess you are not a programmer? It's really hard to use many threads effectively in an application that uses a main render loop that runs the screen updates at very high steady speed (many threads doing the render is even worse - though in some cases possible). When you are going to synchronize/join data for that render thread with a number of separate other threads (AI, network, loading stuff etc), you will have to keep you tounge in the right mouth The threads running on different cores really live their own life (and should do so) so the syncronization has to be effective to not get threads waiting for other threads etc (producing stutters and lag). Getting a bunch of threads to dance together while the main render thread runs at a steady 60 loops/sec is like a tango with four wifes - without annoying any one of them
This is all just nonsense. The reasons games don't employ computing power effectively are:

A) The development cycle of nearly all PC games is tied to that of console games. Consoles focus almost totally on graphical bells and whistles to the exclusion of all else.

B) Game devs don't profit (or rather feel they will) from a focus on long-term, evolving codebases. Graphics engines etc are stable technology. Individual game engines on the other hand are throwaway crap for the most part, with few going through more than 2 or three iterations. If Blah I is a classic, Blah II will be derivative, and Blah III is sure to add loads of half-assed junk options as the devs know the wheezing wreck of a codebase is already beyond rescue. Most codebases are dead already if the original design team is disolved. This hasn't been the 1C:Maddox way in the past and I hope it doesn't go down this route now.

C) The development cycle of most games has little to do with engineering. It nearly always starts with the concept art, followed by rounds of meetings by the suits as the company considers distribution, market segment issues, the company's portfolio of other titles etc. The result is never something anyone might love: it's something random disinterested businessmen think is okay, the lowest common denominator creatively speaking.

D) The actual coders are only involved at a low level and only get their say after (C). 'Game engines', where they exist at all, cover graphics and (at best) some scattered elements of the modeled environment. The wheel is reinvented for each new release as far as gameplay is concerned. Why do you think gameplay in FPS games has barely moved forward since Thief in 1998?

Multi threading on multiple cores needn't even be that efficient on all processors with modern PCs to still make a big difference to gameplay. Not all processing need be done on a frame-by-frame basis. For example, top-level AI heuristics could provide direction to lower-level manoeuvre AI which could in turn guide AI behaviour on each frame. Synchronisation of the first two strands isn't critical and memory bandwith issues etc. would not be significant.

Developer commitment to high-quality engineering and a sustainable codebase can be very profitable as the Oracle example cited elsewhere proves. The reason it features so little in the gaming industry is that it no more guarantees profitable games than do good lighting and camerawork in the movies, so it takes a back seat to the often stupid ideas of the business 'creatives'. This attitude is short-sighted, however.

A stable, tightly-knit dev team committed to incrementally improving a sustainable product could blow away the competition in many areas of gaming. Flight sims are evidence of this. Image processing and compression tech are other good examples. Look at the humble jpeg, basically the technology that made the internet possible. JPEG (and MPEG, MP3, MP4 and other derivatives) will be 18 this year. That sort of thing is real technology, not the throwaway stuff pumped out by the games industry.

Regards,
dduff
Reply With Quote
  #16  
Old 01-20-2010, 03:59 PM
mazex's Avatar
mazex mazex is offline
Approved Member
 
Join Date: Oct 2007
Location: Sweden
Posts: 1,342
Default

Quote:
Originally Posted by dduff442 View Post
This is all just nonsense. The reasons games don't employ computing power effectively are:

A) The development cycle of nearly all PC games is tied to that of console games. Consoles focus almost totally on graphical bells and whistles to the exclusion of all else.

B) Game devs don't profit (or rather feel they will) from a focus on long-term, evolving codebases. Graphics engines etc are stable technology. Individual game engines on the other hand are throwaway crap for the most part, with few going through more than 2 or three iterations. If Blah I is a classic, Blah II will be derivative, and Blah III is sure to add loads of half-assed junk options as the devs know the wheezing wreck of a codebase is already beyond rescue. Most codebases are dead already if the original design team is disolved. This hasn't been the 1C:Maddox way in the past and I hope it doesn't go down this route now.

C) The development cycle of most games has little to do with engineering. It nearly always starts with the concept art, followed by rounds of meetings by the suits as the company considers distribution, market segment issues, the company's portfolio of other titles etc. The result is never something anyone might love: it's something random disinterested businessmen think is okay, the lowest common denominator creatively speaking.

D) The actual coders are only involved at a low level and only get their say after (C). 'Game engines', where they exist at all, cover graphics and (at best) some scattered elements of the modeled environment. The wheel is reinvented for each new release as far as gameplay is concerned. Why do you think gameplay in FPS games has barely moved forward since Thief in 1998?

Multi threading on multiple cores needn't even be that efficient on all processors with modern PCs to still make a big difference to gameplay. Not all processing need be done on a frame-by-frame basis. For example, top-level AI heuristics could provide direction to lower-level manoeuvre AI which could in turn guide AI behaviour on each frame. Synchronisation of the first two strands isn't critical and memory bandwith issues etc. would not be significant.

Developer commitment to high-quality engineering and a sustainable codebase can be very profitable as the Oracle example cited elsewhere proves. The reason it features so little in the gaming industry is that it no more guarantees profitable games than do good lighting and camerawork in the movies, so it takes a back seat to the often stupid ideas of the business 'creatives'. This attitude is short-sighted, however.

A stable, tightly-knit dev team committed to incrementally improving a sustainable product could blow away the competition in many areas of gaming. Flight sims are evidence of this. Image processing and compression tech are other good examples. Look at the humble jpeg, basically the technology that made the internet possible. JPEG (and MPEG, MP3, MP4 and other derivatives) will be 18 this year. That sort of thing is real technology, not the throwaway stuff pumped out by the games industry.

Regards,
dduff
Well, calling other peoples opinions nonsense is just troll behavior and I won't swallow that bait...
Reply With Quote
  #17  
Old 01-20-2010, 06:46 PM
dduff442 dduff442 is offline
Approved Member
 
Join Date: Jan 2010
Location: Ireland
Posts: 114
Default

Well I'm sorry I upset you but your remark about guessing I'm not a programmer got me going. I think enough reasons other than technical grounds were given for the near total lack of either memory- or processor-intensive games was given in any rate. Other fields in computing use these features routinely.
Reply With Quote
  #18  
Old 01-21-2010, 08:15 AM
Feathered_IV's Avatar
Feathered_IV Feathered_IV is offline
Approved Member
 
Join Date: Dec 2007
Posts: 1,471
Default

SoW better have 250+ aircraft in the air at any given time.
If it pretends to be anything more than the piddling skirmishes of Il-2, it had better take advantage of 64bit and multi core systems.
Reply With Quote
  #19  
Old 01-21-2010, 02:07 PM
dduff442 dduff442 is offline
Approved Member
 
Join Date: Jan 2010
Location: Ireland
Posts: 114
Default

Quote:
Originally Posted by Feathered_IV View Post
SoW better have 250+ aircraft in the air at any given time.
If it pretends to be anything more than the piddling skirmishes of Il-2, it had better take advantage of 64bit and multi core systems.
I'd love to see this happen. That would truly elevate SoW to a level way above the competition. With that many a/c involved, squadron leaders would need to make important decisions in the air which would be novel.
Reply With Quote
  #20  
Old 01-22-2010, 05:40 PM
Blackdog_kt Blackdog_kt is offline
Approved Member
 
Join Date: Jan 2008
Posts: 2,715
Default

I've had ridiculous amounts of aircraft present at the same time in one mission back when i was still flying European Air War. That game is older than IL2 and it could do 255 aircraft on screen at once without problems. Of course, it wasn't as detailed as IL2.
However, despite the fact that graphics, FM and DM were inferior, it was superior in the amount of random events during missions (returning from an escort mission you could stop time compression/autopilot and fly manually and you'd find convoys to strafe), the way you commanded the AI (and they actually listened and executed) and the amount of aircraft in the air.

I'll be very excited if we can have something similar with SoW quality FM/FM and graphics, because it adds tons of immersion. In that mission, i had 12 FW190s under my command and going up against 36 heavy bombers and 12-24 escorts. Instead of engaging i sat back and radioed for reinforcements twice and lucky me, i got them both times (this didn't happen all the time, sometimes you didn't even get one flight). So, we were now 3 flights of 12 on the LW side (36 planes), against 36 bombers and 2 flights of 12 escorts (36 heavies+24 escorts=60 total USAAF). This was a grand total of 96 aircraft. The thing is, there was a second group of 36 bombers a couple of miles behind the first one.

FM/DM and graphics aside, just seeing 132 aircraft going at it in a small part of the sky, following realistic tactics (ie only the inexperienced enemy AI escorts gave chase to the deck, the rest would just try to spoil your attack runs and stuck with covering the bombers like they should, and you could see top, close and lead cover for each bomber group) and watching flak puffing all around kind of hammers the point home in a very effective manner.
Reply With Quote
Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 07:52 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © 2007 Fulqrum Publishing. All rights reserved.