Jump to content

feersum.endjinn

Member
  • Content Count

    528
  • Joined

  • Last visited

  • Medals

Posts posted by feersum.endjinn


  1. Couple of years ago I did some cleaning and found few old hard drives, took backup of their contents before wiping and throwing them into recycling and proceeded to forget about it all. Well, few days ago I started digging through the backups just for sake of curiosity and amongs random crap I found DXDLL source code. With Kegetys' permission, I now cleaned up it a bit and posted it on GitHub under GPL2 license.

     

    I don't really know if this was the final version or not or whether it even compiles (or even Visual Studio version you're supposed to use), but it for me it was fun nostalgia trip reading through it up and maybe someone else finds it interesting too.

     

    Source code and small writeup from what I remember about it's functionality is now at GitHub:

     

    https://github.com/jarkkom/dxdll

    • Like 4

  2. Quick question about sections.

    In some of my lods, I have a section called "not mapped" that is associated with the zesleh proxy does this count as a section or is it ignored?

    It doesn't really count, as it is only rendered when weapon is firing.

    I guess ArmA could in theory have two different index buffers for when weapon is firing and when it's not, but I doubt memory:gpu cycle tradeoff would be worth it tounge2.gif


  3. I'm interested. Is there a way to "trade off" performance between sections and texture number?

    For example, if a model is made with say, 7 sections, 3 of which are very small textures (say, 128x128 max), or no texture at all, is it faster to have the three sections or have one section with 3 teensy textures within it?

    Less sections is always faster. You should merge your small textures into one bigger texture, and smallest LOD should never have more than 1 section (with some special textures like muzzle flashes being exception, as most of time they are not rendered).

    Technical reason for this is that one section can be rendered using single Direct3D call so there are less usermode<->driver context switches and more work can be offloaded to hardware instead of doing it on CPU.

    See this graph (batch is same thing as section in this case) for performance comparisons.

    What this chart means is that if your LOD consists of 1500 faces that are in single section, it would render about 5x faster than having 5 sections that are 300 faces each. And these numbers are for old hardware like Radeon 9800, for newer GPUs differences are even greater.

    patsitvx3.th.png


  4. Norsu told me to post here as apparently some other people have also had problem with their models ending up with waaaay too many sections despite faces sharing same material and texture. This apparently happens often when parts from old OFP MLODs are copied into new O2.

    And as everyone hopefully already knows, too many sections = baaad for performance.

    This is our starting situation. Note number of sections in status bar on top of O2. This is waaaay too much for such middle LOD and as such, ingame performance more than halves when there are full squads worth of soldiers with RK95 onscreen compared to if they were equipped with BIS' M4's.

    http://www.somuchforsubtlety.net/arma/sectionfixing1.jpg

    Now, to fix that we first select all faces that are supposed to be in same section and hit "E" key to get to face properties dialog. Note that "User value" field is empty instead of having number there, it means faces in selection have different values in there, which causes them to be split into separate sections. We type there "0" and hit Apply.

    sectionfixing2.jpg

    We do same thing for textures and material fields in they contain "..." and make sure that Lighting & Z-bias also have identical values.

    http://www.somuchforsubtlety.net/arma/sectionfixing3.jpg

    Now we can see that amount of sections has dropped to 3, but model still contains 1 section for muzzle flash and 2 sections for weapon. It is a lot better, but we want to still get it down to just 2, muzzle flash and weapon.

    Next step is going to "Face" menu and selecting "Sort"

    http://www.somuchforsubtlety.net/arma/sectionfixing4.jpg

    Often after this operation number of sections displayed doesn't want to update right away, so we go into another LOD and then come back to editing same LOD. After this small detour however finally our model is where we want it to be - one section for muzzle flash and one for whole weapon LOD and now ArmA engine can render whole weapon using single Direct3D call which makes modern GPUs very happy.

    http://www.somuchforsubtlety.net/arma/sectionfixing5.jpg

    <span style='color:red'>4 hotlinked pictures over 100kb removed.</span>


  5. Some of the VOIP issues are hard to repro. We've been looking for reliable ways to repro some things (ie: static chat, broken-up chat, not being able to hear specific people) for a bit and haven't figured it out yet. Bear in mind too that this is a public beta for a reason - the sheer number of people involved can find issues that smaller groups cannot, due to the number of man-hours available. If you find repro for any of the VOIP issues, post them - they'll be addressed.

    It doesn't seem to be hardware issue because we've had people with wildly different hardware all having the same issues. Common theme is that longer you stay in server and more people join and leave server, more likely it is that your VOIP will break down. Long running missions where people come and go constantly like Evolution are best way to reproduce the bug.

    In many ways it resembles old "missing weapon sounds" bug that was in ArmA's release version.


  6. In 2nd prison camp liberation mission, saving game after you've liberated prisoners and loaded them into truck, exiting ArmA and then reloading later gives you some error about 'missing class/' and mission fails immediately as if all prisoners were dead.


  7. why cant this be compatible with earlier versions, i mean, the reason why im not downloading 1.07 is

    1# because its not compatible with my fav sound pack FDF

    2# The community has yet to download therefore the only reason why i play Arma (multiplayer) would be impossible

    Earlier versions of ArmA can't load OFP style .wrp's. With new code added into 1.07 people found out you can just feed old OFP format .wrp's to ArmA and they work just fine if you hex edit textures to point into .rvmat material description files that contain reference to original texture.


  8. I'm not sure if this is specific to latest build, I didn't have chance to test previous 1.7beta.

    When going inside buildings, I get small "rays" that radiate from center of the screen towards edges. This is using GeForce 7900GS in Windows XP with latest official driver version 93.71.

    I tested this using Evolution 1.05a multiplayer map, any of huts near spawn point at South Sahrani airport have same exact bug.

    Inside a building in 1.05:

    http://img126.imagevenue.com/img.php....7lo.jpg

    Inside a building in 1.07 build 5157 at same spot:

    http://img183.imagevenue.com/img.php....2lo.jpg

    It looks bit like typical glitch that results from overheating, but I tried to eliminate that factor by actually underclocking both GPU and VRAM and testing both 1.05 and 1.07 back to back. When hraphics card is running at same temperature and same Mhz this only happens in 1.07 but not in 1.05.


  9. This is in fact just a matter of belive...!

    A new DX runtime never made something "older" faster as it was before.

    Show us your proof.

    Or is it just a matter of believe?

    Applications link to specific release dll, like in ArmA's case d3d9_29.dll (or whatever it was), which is October 2006 release of DirectX. Newer versions have different DLL's, latest one being _32 I think.


  10. I can write installer program for toolset using "Nullsoft installer", if it is ok with BIS (it's open source "zlib" license so that shouldn't be an issue). Only hard part is finding out what files are actually required for functional installation and what is leftovers from development and maybe reorganizing some like Maya plugin to more descriptive folder names.

    Generating .bat file with proper subst commands according to what directory user selected at installation is fairly easy too.

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"># CWR test script

    Name "Oxygen 2.0"

    OutFile "Oxygen2Setup.exe"

    InstallDir "C:\BIS\"

    #InstallDir "C:\$PROGRAMFILES\Bohemia Interactive\Mod tools"

    Page Directory

    Page InstFiles

    Section

    SetOutPath $INSTDIR

    File /r BinMake

    File /r TexConvert

    File /r Oxygen

    # texViewNEW.inf

    WriteRegStr HKLM "Software\BIStudio\TextureConvert" "configPath" "$INSTDIR\TexConvert\TexConvert.cfg"

    # binMakeNEW.inf

    WriteRegStr HKLM "Software\BIStudio\BinMake" "path" "$INSTDIR\BinMake\"

    WriteRegStr HKLM "Software\BIStudio\BinMake" "exe" "$INSTDIR\BinMake\BinMake.exe"

    WriteRegStr HKLM "Software\BIStudio\BinMake" "binarize" "$INSTDIR\BinMake\binMakeRules.txt"

    ClearErrors

    FileOpen $0 $INSTDIR\mapDrives.bat w

    IfErrors doneMapDrives

    FileWrite $0 "subst p: $INSTDIR\Project$\r$\n"

    FileWrite $0 "subst u: $INSTDIR\u$\r$\n"

    FileWrite $0 "subst b: $INSTDIR\b$\r$\n"

    FileClose $0

    doneMapDrives:

    SectionEnd


  11. You can edit FDF mod stuff however you want as long as you don't redistribute whatever changes you made.

    This is mainly because people would do all kinds of tweaks and then crash dedicated servers when they joined with their homemade mods (especially animation packs were notorious in this regard). And then everyone would email and bitch about it to FDF mod team.

    So it's just easier for us to forbid all redistribution without explicit permission. If you want to use parts of FDF mod in your own works, just ask and we'll talk. There's lots of cooperation between different addon makers and mod teams as FDF Mod credits can tell.


  12. Some features like night vision might be replicated with providing custom pixel shader in NVG goggles optic texture material.

    Does it mean it will be present in FDF 2.0? wink_o.gif

    Seeing the number of things uncovered by pple like you and Keg, I expect a second revolution from FDF 2.0, tbh tounge2.gif

    Question is : will there be a FDF 2.0?

    No, that was just thinking what might be possible in theory (there isn't any way to compile pixel shaders to BIS format yet, even though they look like kinda standard DX shaders with some ArmA specific headers), even though material definitions can be edited as they're standard raP files.

    There probably will be FDF 2.0 but what features it will have, nobody knows.


  13. Though dxdll would be nice to see again, I would be curious at what all could be done, the water would be an interesting thing to see..if reflections of land masses and objects is possible then that would make it even more realistic and lively. The night isn't much of an issue, again, gamma and brightness adjustments can change it greatly.

    It would destroy performance with current hardware. Ask again in couple of years tounge2.gif

    Some features like night vision might be replicated with providing custom pixel shader in NVG goggles optic texture material.


  14. Securom doesn't really care about Daemontools or other virtual CD drives until it detects game is actually running from image. I have running it all the time and of all software I have, only some certain patch of Raven Shield wouldn't run at all with Daemontools present in system (and it got fixed in next patch).


  15. So, I've played 1.04 with German CD-key (because cdcheck works with German copy and owner of English version needs his DVD for playing too) and I've come across few bugs. As all versions are basically identical, and only cdkey determines the language, should I report these bugs even if isn't really supported combination?

    I'm talking about really annoying about bugs like

    http://img44.imagevenue.com/img.php....0lo.jpg

    which is caused by faulty language.pbo, someone just copypasted old code in buildings\stringtable.csv, path should be ui_action_open_ca.paa

    Quote[/b] ]STR_DN_OUT_O_DOOR,"Open doors","Otevřít dveÅ™e","<img image='\ca\ui\data\ui_action_open.paa' size='4' />","Otwarte drzwi","Открыть двери","Ouvrir portes","Abrir puertas","Apri le porte"

    STR_DN_OUT_C_DOOR,"Close doors","Zavřít dveÅ™e","<img image='\ca\ui\data\ui_action_close.paa' size='4' />","ZamkniÄ™te drzwi","Закрыть двери","Fermer portes","Cerrar puertas","Chiudi le porte"


  16. I'm still atleast a month or so away from getting a hard copy of ArmA... I'm curious about running a dedi server and playing at the same time on this new pc. The possibilities of creating/testing missions, would be alot easier compared to uploading to a dedi box for each lil change...just to test for multi~play errors.

    Tools like FireDaemon should make the task of pinning cpu's to apps fairly easy.

    Tools like ImageCfg.exe from Microsoft can mark .exe header permanently so that executable runs always on certain processor.

    But I've gt AMD X2 4400+, running game and dedicated server at the same time doesn't give any kind of performance hit even without forcing them to run on certain CPU.

×