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.