Jump to content
Bohemia Interactive Forums

brightcandle

Member
 View Profile  See their activity

  • Content Count

    236

  • Joined

  • Last visited

  • Medals

Posts posted by brightcandle

  1. Posted

    Part of the problem with community content is its often not all that great. Take a look at RHS for example, it has a tonne of different M4's in it, many of which clip through the model, they also sound like airsoft guns. So while the content is there its quality varies greatly. The same is true of maps, pretty much every map we have tried has had significant issues, very few community maps actually work well. Altis is by far the highest quality map out there, and indeed I suspect the one that comes with the expansion will be good also. I don't want to loose that as BI makes the content higher quality than the community does. When it comes to features BI takes shortcuts, they sometimes do things well but they also skip over things because they thinks it makes the game to complicated (like windage and elevation adjustment) despite the fact that is how it works in real life. So the end result is that BI doesn't always get the core mechanics right and it tends to do a better job on content. The problem is that the community really has to hack in features and they are often problematic. I think the first thing to realise is the community has little to no say on this and BI will do its own thing, it always has.

  2. Posted

    Even if the rendering time was literally zero milliseconds the game still couldn't run at 60 fps. Rendering time is somewhat important in the game but really the big issue is the massive amount of time doing the simulation, something that likely has little to no dependency on the API, its probably mostly script run time which is why its all serial, because scripts assume they run in a serial world. That is a much bigger problem to fix, that is the reason why BI says they can't fix it. But eliminating the time to render (impossible by the way) wont fix the problem.

  4. Posted

    Because the zeroing system in Arma is based on an algorithm further complicating something that should be inherently simple.

    simple way to fix the problem is to completely revamp the optics in the game and add mil turrets this way regardless of suppressors, ammo velocity or weather conditions the player has far more control over his adjustments.

    Mil turrets are the way to go along with complete removal of 100m elevation zeroing on optics that do not have such a thing irl.

    For those sights that support it. Really the Red dots ought to be zeroed at 300m and whether we can change it or not isn't that important because you couldn't realistically do that in the field anyway. The optics is much more complicated because you have to choose the zero point, maybe it should be set the first time its placed on the rifle or something like that, so the zero point is dependent on the effective range of the rifle its placed on. Then we need turrets to adjust it further along with a range chart for windage and elevation.

    When they announced marksman DLC this is basically what I expected/wanted. It struck me this was the one thing missing in Arma that no mods did well and really ought to be in the base game. Sadly they thought bipods was what this was about to keep things "easy".

  5. Posted

    But BF is a GPU centric game and runs well on the consoles too, which have rather slow CPUs. ArmA is the opposite as it's a CPU centric game so the extra CPU speed comes into play. Problem is just it's not multi-threaded in such a way to make great use of multiple cores.

    Its not just a game being CPU bottlenecked its also why its CPU bottlenecked. If the issue is that the game is trying to make 20,000 draw calls then DX12 will help. If its because the games simulation is very complicated and 100% single threaded it wont. Its just not as simple as the average gamer that spurts this usual rubbish thinks it is. Arma is simulation time driven and its own code interacting with DX11 is what is slow. Thus the end result of moving to DX12 will be minimal without substantial changes to the code and architecture, changes which would benefit DX11 just as much.

    Can we please stop spreading this rubbish about this game, I swear every page people forget the answer to Arma 3's performance problems have been found, the developers have been caught lying about the cause and as they try and hype us on DX12 we should know better since we have solid data showing its not going to help much.

  6. Posted

    Our experience is its kind of a disaster. Its not just the pops, the terrible sound volumes its also the general sound stage and awareness with surround sound. Overall despite changing a bundle of things we seem to have taken a big step back from a few months ago with JSRS 2.2. The current sound situation is pretty bad and I am glad it will make JSRS 3 more efficient, but its also annoying it ends up delaying it so much as well. In the meantime I would just consider the sound "fundamentally broken".

  7. Posted

    Do we not realize that BIS created the framework and engine any code is based on in the first place? Tomorrow, if they wanted they could kill the modding community, like that! Their "thanks" is the opportunity to even create it in their platform in the first place IMHO.

    Now don't get me wrong I fully support thanking any independent content creators and giving credit where credit is due, especially when it comes from the community side- but the expectation that BIS somehow owes anyone anything is silly, it is us that are at the mercy of BIS whether or not that's good or bad can be debated and has been.

    And they are out our mercy as well. If we don't find their game amenable then we dont buy it and their company fails. This isn't a one way street, its in their best interests to treat their customer base well. For us 1.42 is a huge step back in capabilities because the release has broken a large swathe of mods and introduced worse implementations in their place but designed in a very similar way. I don't see this as progress and I can understand why some of the mod writers would be pretty annoyed with how this has happened. To me it shows a continued direction of BI wanting to shun the mod and milsim communities that sustained their franchise for so long.

  8. Posted

    Serious question: Why not? I don't know that much about sound editing, but are there not mathmatical principles behind the way sound behaves that can be utilized to make something sound not only good but also (more or less) correct for its environment?

    Also, yeah it kinda just sounds like you don't like the sounds rather than the actual sound system, which is a much more subjective criticism.

    Absolutly, if you fully ray trace the sound to every possible point and recreate the environment perfectly with a very detailed multiple bounce ray tracing sound engine its possible. I just don't know if that even remotely exists. Running it through a filter is not the same as modelling a real world environment and playing a sound in it and then capturing the result. Its more likely they added a bit of reverb and and other such basic tweaks to try and simulate the effect of that modelled world, which they obviously didn't do. The proof of how it was done is in the actual sound itself.

  9. Posted

    There isn't a computer available today that can run the game well. The only hardware improvement that could help Arma out is a massive increase in clock speed, and that we know isn't happening. Adding the additional working of compressing the video and sending it across the network is only going to make the game run even slower.

  10. Posted

    When they announced marksman DLC my community was joyfully excited about finally getting decent marksmanship ballistics, ie windage elevation and maybe even temperature and other variances that would make shooting predictable but skillfull. The reality is they reimplemented a load of features we have had in mods for Arma 3 for a year, it actually doesn't bring any new capabilities. The one thing we really needed them to implement they didn't, the stuff they chose to implement has been working well for a year. What they release is really buggy, to the point where we might rollback that is a shocking problem.

    I just don't agree that they have rolled out something important with this release for marksmanship, they actually seemed to have missed the thing that actually mattered in marksmanship. You get a better experience on the previous version of the game with mods. Yes it wasn't in vanilla, but considering how long this took, how many other issues their are with the base game (performance is always a problem has been since release and remains so) I can't see the value in what they did. We are literally taking steps backwards in sound and deployment and marksmanship in general because what they did was break the mods and what they gave us was worse. Its not like the feedback didn't get delivered with the quality of what had been produced, the bugs were reported they just weren't acted on.

    I am genuinely thinking BI really can't produce working software, it doesn't appear to know how.

  11. Posted

    Both AGM and CSE add this, and they seem to do it better than ACE2 did back in the day. I have never considered Arma 2 or Arma 3 vanilla playable experiences, they both required a lot of mods to make a realistic game that I felt was worth playing. That is OK because we have mods. I wished the mods didn't impact performance as much as they do (AGM runs pretty rubbish unfortunately) but I don't really care about inclusion into the base game. As the marksman DLC has proved BI don't do it better, they just do it differently. If anything the AGM weapon resting is a more polished and finished product than what they just released with marksman DLC, and combined with AGM recoil and such you have a more realistic package overall. To get realistic guns you have to go mods as BI is focussed on adding fantasy future weapons.

    What irritates me is everytime BI includes something we have a good mod for already it breaks everything (like now). If what they did was good quality I would just turn off the bit in the mod, but reality is the quality is pretty shoddy so what we get is a game that doesn't work until the modders fix it.

  12. Posted

    Its not like people didn't report the bugs on dev branch, they did. Of course BI released a different version of code to what was in the development branch anyway, so its not like anyone actually got to test that version of the code outside of BI. Thus they are responsible for it.

    All the bugs (sinking into the ground, recoil bugs and how insane how apparent it now is, reload bugs, shifting aim + many more) were reported, they just weren't fixed, they released it anyway.

  13. Posted

    The real balancing aspects of suppressors aren't yet modelled in the game, but if they were it would of benefit but less so in the marksman DLC. The main balancing aspects is that catching all those hot gases makes them hot. With rapid fire the suppressor will eventually reach a point where it warps and a round will hit it destroying the suppressor and potentially being quite dangerous to the operator and those around them. There is simply a limited amount of rounds you can fire. Even after a relatively moderate number of rounds they get hot enough that removing them is an issue, they are simply too hot to unscrew. Worse than that the constant heating and cooling of lower rates of fire can losen the suppresor. Most of these don't matter to the sniper and DMR rifles where we would expect the rate of fire to be very low, but its certainly an issue on carbines. it would be nice I think to have this modelled as the balancing aspect.

  14. Posted

    I had asked you last time on what settings were doing it and to try and do the same at higher ones and details (ultra for objects and 7-12km view distance and detail distance), but you provided no data for that :p

    If you think it some how changes the nature of the research then all the tools and capabilities are available to you to do this yourself. You don't get to demand that I do an experiment because you think it some how changes the validity of the results, what needs to happen is you do the research and show the difference and then we discuss its implications. Its a common tactic I see in every forum, someone turns up with real data and a whole bundle of people just say "uhuh its not valid because you didn't do X" and all the while they have zero evidence that it makes any difference and aren't willing to take the 10 minutes it would take to test their theory. So you are the one that wants to do that scenario, do it yourself and report back, we are all awaiting your amazing results that show somehow that in this one scenario DX12 would solve everything. Its not like I have any magic tools that others can't get its all available to all of us.

    I wont dance because you told me too. So take your tongue face and stick it, this is just a classic trolling tactic I wont have any of it. Do your own research.

  15. Posted

    Someone else has already mentioned rocks but another thing I noticed was some oddities in regards to object pop in. Some of the buildings around tal kar (left middle of the map) as you walk towards them or zoom on them will change colour at different distances. So as you walk around or get closer they flash a different colour and then pop to their higher quality texture, but the intermediate stage is a really obvious change. Its not all the buildings or objects but there are certainly examples of pop in is either weird (like the buildings where its white, then black then grey) or far too close (like some shows outside a building which appear at 20 metres or so).

  16. Posted

    The evidence is to the contrary, DX11 is not the limiting factor to Arma 3's frame rate. The game frame rate is limited more by its own simulation and the code it has surrounding DX11. This is a fact based on profiling information, its not a guess, its not a suspicion, its supported by cold hard numbers captured in development tools. People seem to ignore this like its a matter of opinion, it isn't, I have shown you the data and told you how to collect and verify it yourselves.

  17. Posted

    Out of curiosity, why would it matter what setting is being used by majority?

    Suggests something is wrong with the basic volume of the sounds in the game if almost everyone is turning it so far down. In most other games players manage sound globally, but for this one game it completely drowns out everything and you need to turn it way way down. It proves there is a problem with the sound design.

  18. Posted

    All you need: -noLogs -noPause -noSplash -world=empty

    The rest honestly don't make any practical performance difference whatsoever. If you want the game to run faster turn down your view distance and object quality, these two make by far the biggest difference as they are the things that hit the CPU hard in the rendering process. Drop down to 1500k or so on view distance and the game will run better, not well but better.

  19. Posted

    I have never did a deep profiling so i don't know whats are the limitations(and i'm not a game engine designer either), but i think it's kind a black box method without the source, isn't it?

    How do you know:

    -that the rendr process time is not limited by the engine to save ticks for the sim?

    -that there aren't some pre/post parations for the rendr process to fit in that limit?(overhead)

    The engine is built up to use single threaded DX(Arma 1, 2). Now its for multithreaded but single core, but maybe they didn't changed anything in the game engine design. Who knows? I think if they change a game engine design they can profit from DX12. Simply replacing the DX would make a minimal increase, because of the previous.

    Its not blackbox, because BI provide a debug build with a profiler in built we can actually see all the method names, all be it mangled a bit but much of the intent of them is clear for all the big pieces. So we know what is running and in what order and even the call structure of the code. We don't have the source code to work out why something is slow, but what is taking up time is easy to see. Your questions make no sense to a programmer and the spelling mistake in the second makes it even harder to fathom what it is you are trying to ask. There is no limit, the game is going as fast as it can and the evidence is in the profiler traces I have provided.

  20. Posted

    Dx12 isn't like a magic spell which automatically makes a game run with higher FPS. To access this kind of improvement, the developer needs to rethink/redesign how the engine works in some parts in order to get the best gains out of the new API. If this isn't done, there could be gains anyway, but not near as high as the things you can read here and there about dx 12.

    Also, there's no need to emphasis the fact that every developer hates to fiddle around with his game engine for various reasons (mainly $$$). In conclusion, IF some day BI actually decides to port arma 3's engine to directx 12 (which would be really surprising) that wouldn't by far mean that you would get like +50% FPS.

    Dynamic shadows would be nice tho' :bigglasses:

    Right now the rendr process represents roughly 1/3 of the time of a frame. Assuming DX12 completely eliminated that whole section and it now ran instantly (not likely as pointed out the time taken is in BI code and not DX) then the end result would simply be to increase frame rate by a third. That is the absolute maximum DX12 can bring without fixes to other areas of the game loop. Of course with most of the time actually in BI code its going to be much less than that in practice.

  21. Posted

    Right now Arma 3 is using about 2000 draw calls even with high rendering distance. As you increase the render distance you'll see the profiler show the rendr section of the profile increase, however when you look in the GPUView output you wont see a corresponding increase in DirectX API overhead. Thus I came to the conclusion some months ago that the game is rendr (and sim) limited but its not DirectX's fault, BI are no where near the limits of the API. Infact what we see is that the rendr section of the game is the only part that shows any amount of multithreading at all, but most of the time is in BI code and not in DX 11. I have done everything I can think of to determine the root cause of the problem (as a developer with years of experience in profiling and fixing problem programs incidentally) and my end conclusion is that all of the problem lies in BI's code. The primary factors for poor performance on the client is the games simulation, which includes running the scripts but not the AI (which is mostly server side) and the rendering process but this is mostly in BI code and not in DX11. I have all but categorically proved it with profiling output, Microsoft debugger tools and draw call estimations all of which tells us a lot about what Arma is doing when its running slow. The next step is BI needs to fix the game, and DX12 isn't going to do a lot in this case, it will improve the frame rate because it will reduce an overhead in the main thread and it might give BI some more avenues for parallelism, but fundamentally the problem is 100% with what BI has done and not the API they are using.

  22. Posted

    Its the same story client and server, it uses a bit over 1 core. We have profile traces for the client from the debug builds of the game that show why that is the case (the game is more or less single threaded except in the rendering stage) and so we can be pretty confident the server runs basically the same way and hence is mostly single threaded. This is why it doesn't use those cores, the best way is HC for when the AI is your issue.

  23. Posted

    The game is mostly CPU limited most of the time so it kind of doesn't matter, either is more graphics horsepower than the game can really use. When your frame rate drops during a mission it wont be due to your GPU with either solution. Maybe the Titan X will be a little quicker in those circumstances because there is a little less CPU overhead with one card verses two, but its negligible. In most other games I would anticipate that the 2x980 will run quite a bit faster than the Titan X.

  25. Posted

    The simple answer is a little over one core, the more complex answer is below:

    https://dl.dropboxusercontent.com/u/3638175/Capture%20Palagia.jpg (612 kB)

    You can get one of these yourself if you like by downloading the profiler build on steam and then using the command "diag_captureFrame 5" and then 5 seconds later this will pop up.

    The way to read this is its all the activities that go into producing one frame. There are 1000ms in a second and the frame above is 26ms or so which translates to 1000/26 = 38fps or thereabouts

    At the top you have 12 horizontal bars, these are the cores (6c12t for a 3930k). The coloured sections are activities running on the cores. You should also mentally draw a bar vertically each time the activity changes as well, because some activities can be multithreaded a little (rendering) and others can't.

    You might notice for example Arma 3 is dumb about its use of cores, as every other one is HT it should skip those in preference for even numbered cores, but it doesn't and this likely makes things slower not faster. That is about as much as I know about the answer at this point, I can tell you more about DX usage (the rendr section is not dominated by draw calls FYI) but that is the best picture of CPU usage I think we can currently get.

×