Jump to content
Bohemia Interactive Forums

Furret

Member
 View Profile  See their activity

  • Content Count

    360

  • Joined

  • Last visited

  • Medals

Posts posted by Furret

  6. Posted · Edited by Furret

    I think however that certain improvements, if usable, will be shared across the project :) This has also been stated to me by Matt (DayZ production assistant)

    Glad to hear there's communication between the teams and the possibility of sharing code.

    I'm interested to understand why you believe modding sites like armaholic wouldn't be possible with improvements to the multiplayers reliance on sending updates occurring around the player, even unrelated to them, to every player. I'm a little puzzled. Surely a more client-server styled architecture would benefit the game and modding in general?

  7. Posted · Edited by Furret

    Disappointing.

    edit:

    The bubble problem is a core issue with multiplayer. It's not feasible to go above 30 players in multiplayer without huge effort on the mission builders part to reduce script calls etc. It means the scope of missions possible is severely limited.

    Why have such a large area to play in when such a small number of individuals can play at the same time. Very frustrating.

    edit2: it would alleviate issues like this: http://sacriel.tv/forums/index.php?/topic/541-arma-3-altis-preperation/page-2#entry7307

  9. Posted

    ArmA games stream data from the install directory as needed, the game chooses what is and isn't needed, loading/unloading data from RAM as necessary.

    The stuttering occurs because something in your game is being drawn that isn't waiting in RAM, it needs to be loading from the install dir into RAM first, causing a minute micro-stutter.

    You can alleviate this micro-stutter by placing the game on a SSD or running a RAM drive with the game on it. Testing has shown there is very litter difference in these two methods.

    You can minimise the number of micro-stutter occurances by setting the -maxmem and -maxvram parameters to the maximum your machine allows, this creates a larger pool for the game to use, reducing the number of loads/unloads.

    (the -maxmem parameter is limited to a max of 2047, the -maxvram doesn't have a limit)

  12. Posted

    Okay so i think i have the ''standard download'' and now how do i switch to dev version? or maybe i have to download a mod for them? cuz i just see few units on the editor, no jets and other vehicles that i saw on some youtube videos hehe

    Honestly? just wait a week for the full release.

  14. Posted

    Thanks for the tip. :) After I added -maxVRAM=2047 (for GTX760), the game is very smooth again. Only unit spawning/scripts causes some stutters (could be my own fault), but under that FPS feel very good again.

    That's awesome news. Be careful with setting VRAM too high, you should set it to no more than 95% of your max. It may crash out if it's too high.

    (big fan of your work, keep it up buddy)

  17. Posted

    Because a huge amount of software still has no advantage on a 64bit OS, it's slowly getting there with new software but no where near the point where 64bit is needed.

    You've sort of misinterpreted the question, there is little reason to use a 32bit OS as 64bit OSs are backwards compatible with 32bit applications.

  19. Posted

    i believe this is because core 0 is the primary worker and when it becomes overloaded everything slows down ...information to render become less per second(FPS drop)

    My understanding of multithreading is you have a primary process that can spawn sub-threads. So, core 0 has the primary process and each successive core can run many sub-threads. What's odd is there seems to be some sort of lock being used that causes the rendering part of the thread to wait until such things as AI are processed(MutEx lock perhaps?, Rendering has lower priority than AI thread?). I lack sufficient experience with multithreaded programming to explain why this is so.

  21. Posted · Edited by Furret

    End-users are limited to black-box testing. We can't really reach concrete answers and are limited to making informed estimates/guesses as to what are the causes of low CPU utilisation. The only people who really know what causes these issues are those with access to the source, i.e. the developers. Everything else is just conjecture.

  22. Posted

    as it's not simple task like some of You trying to claim...

    Hearing developers' musings while working on these optimisations would likely satiate people in threads like these, people hungry for information on the topic, regardless of how small the changes may be.

    I personally just want to learn about the inner workings of the engine.

  24. Posted

    When using AI in a mission the games FPS drops considerably while CPU and GPU usage goes down.

    What is the technical reason for this?

    Is the main game thread waiting for data to be provided from an AI thread?

    If so, how is the rendering engine coupled with the games logic to necessitate a wait for data from the AI thread/process?

    I’d love to hear how the main ArmA process works.

×