Insanatrix

DAGR's are an air to surface guided rocket/missile.

Frame rate is roughly the same between alpha and beta, it's the hitching and stuttering that's making it unbearable. I hope they can do something before release cause at this point I'm about ready to just uninstall it and give up.

That's because V-sync isn't using triple buffering. Would allow for higher fps while using V-sync under 60fps or whatever your monitor's vertical sync is, but would add increased latency.

I said maybe, I didn't say the Messiah deigned it to be true. It just feels like DayZ is getting more attention from rockets posts and then what we are seeing with ArmA 3. I wouldn't even blame them for wanting to focus on something else. I'm just afraid A3 support will be dropped off once DayZ comes out and if it seriously takes off. Then we'll be stuck with something even buggier and problematic than ArmA 2 was.

Same thing here with the Beta and stuttering, It seems to have gotten worse with the last dev build, even making normally playable missions unplayable due to the stuttering and the input lag.

I dunno, I'm starting to believe the hyperbole at this point. :rolleyes:

All I care about is learning what the problem is exactly, and then getting exposure for it in the hopes that it will get fixed. I hear you guys saying, "The dev's know, it will be fixed when it's fixed" etc... but it certainly doesn't seem or feel like that's the case. How many times do I need to buy the different iterations of the same game + expansion before they have enough funds to expand their team so they can fix the problems? What is a valid length of time for these recurring issue's to be fixed? I can be totally wrong about the "why" in these issue's that exist. For me as a consumer, the "why" means very little, it's only me trying to understand it better by putting my foot out there. What matters to me is that they are fixed so I can actually use the software that I purchased. I realize the topic of this thread is "Proposal for a new game engine" and I don't agree with that for most of the above mentioned reasons like having to get familiar with the tools and the capabilities. That doesn't mean that there isn't something seriously wrong with this one that hinders the performance on A LOT of users computers. As good as this game looks, with the ragdolls and such, I would honestly give all of that up to have something I can actually use. All these improvements mean very little if the software just doesn't run. I would rather time be spent on fixing core issue's than adding in things that while great in their own right and certainly add to the experience, are eclipsed by the unfixed issue's that still persist. It's pure frustration at this point, expecting improvements and getting very little except visual stuff that almost compounds the issues.

Ok, I'm wrong, You win.

What you really need is a 2600k @ 10ghz to truly get the ArmA experience. Sarcasm aside, Most of the graphics options won't affect performance except for Shadow detail, Object detail, and View distance. Outside of that you're pretty much SOL and just have to deal with it, at least that's what I've been told.

Responses in bold. Arguing about it at this point doesn't matter because nothing will be done to fix it. Whether it stems from the fact BI doesn't have the resources to fix it, or they just don't want to.

I think the majority of the issue's with the RV engine stem from the SQF scripting and the extent to which it is used within the engine and the limitations of it. I realize BI want the game to be moddable and through SQF they can achieve that while still maintaining some closed source. Holding on to the scripting language simply so the game is extremely moddable at the cost of performance and functionality is not the way to go though. Correct me if I'm wrong, but isn't the interpreter limited to a single thread and is also limited to executing code every 3ms? If so, both of those are huge bottlenecks considering the scope of usage of SQF script for actual engine functionality. That means that there is already a resource limitation inherent to SQF as well as a processing limitation, irregardless of hardware. I mean you're not talking about configuring some engine variables through script here and there, you're talking about running heavy simulations in SQF script rather than in compiled C. Running those heavy simulations in a scripting environment that is by it's very nature quite limited. Again, I get that they want those simulations to be moddable, but is the cost to be able to do so with the current scripting environment worth it? At this point fixing the problems with the engine would require such a rewrite of the engine that you might as well start over from scratch, hence the unwillingness to really do it and just try to band-aid fix every problem and move on. It's just been compacted on since OFP, every SQF script for a new function has added on to the pile of what would have to be rewritten to fix the issue's. I truly believe the real question is, why do they need to fix it? Why would they need to fix the issue's when they have a loyal fan base that would buy pretty much anything they put out. I mean this engine could run average 2 fps and you would get tons of people on these forums talking about how the game runs great and they're having the time of their lives. Also they have DayZ now, which will appeal more to the mainstream crowd. They've hinted around about wanting to get away from the whole Military Simulator genre and try some new things. Maybe ArmA 3 will be the last ArmA. Maybe that's why there was so much work put into the engine of DayZ and so little into ArmA 3. It's funny that people talk about how much work the engine changes are when it comes to ArmA and how BI doesn't have a big enough team, yet they are somehow managing to do it with DayZ by totally rewriting the engine for the needs of DayZ and it's closed source nature as well as it's heavy need for lots of AI and such. I guess that's some food for thought...

http://en.wikipedia.org/wiki/File:AMD_Bulldozer_block_diagram_(CPU_core_bloack).PNG 2 integer cores with a one FPU, Shared L1 instruction cache, and Shared L2 data cache. If you read the white papers on them, they have issue's with certain script interpreters and environments. http://developer.amd.com/wordpress/media/2012/10/SharedL1InstructionCacheonAMD15hCPU.pdf

It doesn't do much except spread the already minuscule load across more cores. There's not much more depressing than going from a 75/40/25/25 total core load to a 75/30/15/15/8/8/8/8 total core load. In some cases it actually makes performance worse.

Yeah Sahrani was my favorite vanilla island.

Beta is actually performing worse for me. A lot of hitching, lower frame rate and a very unsmooth experience, Both in SP and MP. Lots of texture flickering and z-fighting on building walls and surfaces. I don't just go in the editor though and place down a single soldier and say "oh lawd everything's running GREAT!", I actually play missions and such. It seems like there's a soft cap of about 2-3 squads of active AI total before performance takes a massive hit. I was in a server with someone, just me and him walking around with nothing going on and my fps was like 18-19. No it was not Wasteland. Even in SP in some of the showcases I still drop down to 20-22 fps, and missions I make where I'm careful about the amount of active AI I have and I try not to use scripts as much as possible, I still get around the same performance. We're also still just running around on Stratis, we have no idea how Altis will run. That's gonna be the real test. Not gonna be much fun if Stratis is the lesser of two evils and we're stuck with it because Altis runs like crap. According to moderators and developers in some of the performance threads, this is the performance we should expect.

What do people think, Intel is gonna magically announce the 10ghz RV engine i7 behemoth, just because BI's engine is written for the stone age of technology? If anything you're just gonna start seeing 6-8-10-12 core i5's and i7's, still running around 3-3.5ghz. The issue lay with Bohemia Interactive, it's their issue to fix. Technology isn't gonna save ArmA 3 like it did ArmA 2 and ArmA. It's not gonna be huge jumps in speed, but rather jumps in number of core's per physical CPU's. It's already been shown numerous times in numerous locked threads how the RV engine just does not scale beyond 2 core's and can barely utilize those 2 core's. Also asking someone to overclock a top of the line CPU should not be considered the norm to provide acceptable performance, that's just poor coding and poor resource management.

It's the game and that's pretty much it. It has nothing to do with your hardware, it has to do with the software not being able to utilize it correctly. Nothing to do but wait and see if they can ever fix it. According to Max Power in this thread, http://forums.bistudio.com/showthread.php?157268-CPU-GPU-low-activity/page2 , It's as solved as it's ever gonna be so I wouldn't expect much.

First let me say I'm not countering your post or anything, It just is a good example of the actual problem at hand. That's why I'm quoting you. Here's the problem, CPU resources don't change in that same example because the engine, not the CPU, is already bottlenecked even with an empty editor. The simple fact you have to look at is that the only difference between a program running at 100fps with 100% usage and the same program running at 10 fps and 100% usage is simply that the program needs more resources, more power, to do it's job. That is when you would say that the CPU is bottlenecking your program. Yet we are in a situation where our CPU's are underutilized and our GPU's are underutilized. Throw 100 AI in that same empty editor and CPU usage doesn't change, but performance takes a nose dive. The blame at that point goes from the hardware to the software, because it's not the hardware that can't keep up or doesn't have enough power, but it's the software that can't utilize those resources effectively. That's been the core of the problem for a long time, the RV engine doesn't utilize the resources of current hardware properly. The reason for that falls heavily on the SQF scripting, the nature of how it's processed, and the extent to which it's used for calculations and functions within the engine.

If that were the case, I don't think we would have ArmA 3 in an alpha or beta capacity since there are still a lot of broken things that have been broken since before ArmA 3 and ArmA 2, but we still see progress and additions in areas don't we, we still see new iterations of games don't we? Is software ever perfect or is it ever completely bug free? I doubt they wait for every bug to be fixed before adding in newer functions, I mean we would still be in Alpha at this point right since there are bugs from Alpha that haven't been fixed, yet we just got Beta content additions. I think there's more of an internal opposition to weapon resting and bi-pods, hence Dwarden's comment of having to "fight" for it.

Plain and simple, it's the engine and not your hardware. It won't be fixed because it would require a rewrite of all SQF code into another scripting language that is multithreading friendly, probably Java since they were looking to incorporate it. At this point, I doubt it would happen seeing as how about 70% or so of this game is written in SQF and that percentage grows with every update.

It depends on the amount of stuff you are carrying, and default loadouts in the editor, like the rifleman and team leader etc..., don't incur fatigue very easily because they are so low on ammo/gear usually.

It was cancelled because it was to be an armed reconnaissance helicopter and UAV's overshadowed the development and the need for it. They were cheaper and didn't put lives at risk. The only thing unrealistic about the current choppers, aside from the handling, is the acceleration.

I noticed that as well, recoil is amplified by the amount of zoom. At first I thought it was just because you could see your target with better precision but I did a couple tests and sure enough if you go between the red dot on the RCO or ARCO and the magnified optic, there's a difference in recoil.

If you put a 9mm suppressor on the SMG's they magically have recoil in full auto.

I think what they are getting at is that the ACP-C2 is a .45 handgun. It would be like chambering the EBR in 5.56 simply because the MXM is 5.56.