Jump to content
COMBATSIM Forum

Krycztij

Members
  • Content Count

    1,679
  • Joined

  • Last visited

  • Days Won

    2

Krycztij last won the day on February 5

Krycztij had the most liked content!

Community Reputation

3 Neutral

About Krycztij

  • Rank
    Brig. General
  • Birthday 09/05/1981

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Krycztij

    The Combat Simulator Project

    Yes, they have worked hard towards standard compliance and finally reached it in the first half of 2018. There are some switches for backwards compatibility, but honestly it is far better to delete the old MS-specific cr*p You’re doing great!
  2. Krycztij

    The Combat Simulator Project

    I have no idea on this either
  3. Krycztij

    The Combat Simulator Project

    Have you tried starting it from the „Developer Command Prompt for VS 2017“ in the start menu?
  4. Krycztij

    The Combat Simulator Project

    Yes. The DirectX SDK and the Platform SDK have been merged into the Windows SDK. This is installed with Visual Studio, and you find it under C:\Program Files (x86)\Windows Kits\<version number>. The version number is just important for the feature set and does not define a requirement for the final executable – if you choose the 10.0 SDK but don’t call Windows 10/8/7-specific APIs, it will run on Windows Vista as well.
  5. Krycztij

    The Combat Simulator Project

    Quite impressive … I’ll have a look at the code! If there are problems with building the Windows version, feel free to ask me …
  6. Krycztij

    Joachim Roenneberg has died

    It’s suspected the scientists were saboteurs themselves. Heisenbergs scripts show that during all the years of war, he never bothered to calculate fundamental formulas of the bomb, yet after his capture he worked out many of the concepts in just one week. Completing their research would not have bought the scientists anything – on success, they would have been pressured into military projects immediately. On failure, they would be sent to die at the Ostfront. So they probably prolongued their institutional research as long as they could. Anyway, RIP.
  7. Krycztij

    Weekend music

  8. Krycztij

    Who's Lurking?

    FWIW, most internet traffic (probably 75 % for sites like ours?) is crawlers for search engines. Probably Russian crawlers, though. Only the admin will ever know.
  9. Krycztij

    Who's Lurking?

    Reading almost every post (subscribed to CSim via RSS), but rarely answering – I don’t understand temperature in degrees Fahrenheit :-)
  10. Krycztij

    TAW terrain format

    Another post for the bigger picture – sorry but I think it’s important for understanding. Lean viewer started in April 2016 as help for us to read the LBM files of Total Air War and EF2000. In August 2016, I extended it for support of 3D meshes to simplify workflow in my job. I could have started a separate project for it, but I didn’t. Looking back, this was indeed a good choice because now we have all the WRL goodness. People from the 3D printing world got noticed of my tool and urged me to release it publicly. IMHO, Lean Viewer was too unstable and too messy to release. Instead, I started the STL viewer project, which is basically the stable portion of Lean Viewer – a stable, minimal UI and the well-tested STL loader. No support for 30 years old image formats. No buggy VRML. The STL viewer is not exactly popular, but many people from the 3D printing communities use it. Removing the messy parts from Lean Viewer really paid off – it’s rock solid; I only had to provide hard technical support once. I get lots of mail about it. I get donations once in a while. The feedback is very positive, but there’s also feature requests, and a few bug reports. Now, whenever I fix a bug, I have to fix it twice – in the STL Viewer and in Lean Viewer. Whenever I add new features, I have to add them twice – in the STL Viewer and in Lean Viewer. That’s bad. It’s eating up my time. And even though I constantly merge STL Viewer progress into Lean Viewer, it doesn’t seem to get any closer to a state that could be released to the broad public. So I’m currently trying hard to unite the code bases. This is not exactly work for TFX, so I’m a little uncomfortable bothering you with it while you’re working even harder to get a new terrain, but I’m sure that eventually, we’ll all profit from it. Some things that I’m currently trying to unite: There’s this awesome guy from South America who uses Lean Viewer to paste screenshots of Ace Combat models over his own photographs. I added support for screenshot-to-clipboard via CTRL+C- for him. Currently porting this to STL viewer. Lean Viewer’s UI has many tabs and menus, and my wife has greatly improved the code to support variable sized tabs. Trying to roll this out in both viewers. Adjustable material colors (STL viewer). Currently trying to port this to Lean Viewer. Wireframe/outline rendering (STL viewer). Porting this to Lean Viewer. Drag’n’Drop support (STL viewer). Porting to Lean Viewer. Better lighting (STL viewer). Porting as well. Top/left/side views (STL viewer). Porting to Lean Viewer. STL viewer has a setup with proper support for file extensions (instead of Lean Viewer’s ugly, hacky menu command). Lean Viewer gets one as well. Lean Viewer’s scene tree supports fancy things like instancing and material editing (and is generally incredibly fast, even with thousands of objects and millions of polygons). Porting to STL viewer. STL viewer had a tab with GPU settings added per user request, and Lean Viewer just got it as well. (It’s the one on the far right.) … I hope to have a single code base for all of this in the future. I wish I had done this in 2017 already. I hope you understand that PNG display is currently the least of my problems …
  11. Krycztij

    TAW terrain format

    I fall back to Windows’ GDI+ for loading them as textures, and it’s okay for that purpose. Treating them directly in the viewer is a different beast though. The spec is too complicated for me to implement right now, mostly because it requires my own zlib/DEFLATE implementation (and honestly, JPEG would have higher priority because with my own JPEG decoder I could finally apply the arithmetic coding extension to all my pictures and save 15 % of hard drive space ) Yeah, the only one of practical usage Just for the sake of it: You can also view IFF/ILBM/HAM/SHAM, ACBM, PBM, TIM, DIB/RLE, PCX/PCC, WAD, and SPR (see the filter on the right side in the Open File dialog). That’s what it was originally for, viewing TFX’s Amiga image formats. I’d rather go for inline files. Textures are currently just hacked in, and together with inline files, they should be treated as “external dependencies” with asnychronous loading and failure-proof placeholders. This would solve lots of problems the viewer will embrace with future formats (e. g. OBJ meshes have MAT files with material properties as external dependencies). Anyway, just trying to get you, me, and the few other users (mostly Ace Combat paleontologists) to a synchronized state to simplify my maintenance.
  12. Krycztij

    TAW terrain format

    Pretty awesome, as always! And very elegant, too … I’m so keen on using all these shiny new things … Mike, here’s a new Lean Viewer build. No things of great interest, but just to synchronize our state. If you hit CTRL+C while displaying a mesh, you can paste a screenshot into Gimp or other tools. (It doesn’t work with all programs because Windows clipboard is fubar, but Gimp is compatible and even supports my transparent background.)
  13. Krycztij

    TAW terrain format

    32-bit BMP support is very spare as well; 90 % of facilities built into windows don’t support it either. (Yes, the situation *is* this bad, and it was one of the original reasons for me to make Lean Viewer.) I really recommend PNG, it will work well even with transparency in indexed colors.
  14. Krycztij

    TAW terrain format

    Did you write the BMP files yourself? Did you load them yourself? If you use 3rd-party libraries, please consider that very few software supports transparency in BMP at all. Lean Viewer does (because its BMP loader was written by me), but when I switch to Windows’ built-in BMP loader, all transparent parts come out as black. Could this be a problem? Did you try to use PNG instead (which supports transparency from the ground up)? Apart from that, I’m really impressed by that workflow!
  15. Krycztij

    TAW terrain format

    VRML has no method of handling this; no modern game engine has. There is a concept of decals, but it doesn’t apply here. TFXplorer renders fine due to two facts: a special depth buffer setting („draw pixel if its distance is smaller than or equal to previous pixel’s distance“); this avoids Z fighting (the flickering) in most cases GPUs must guarantee ordering of triangles, i.e. pixels of later triangles must cover those of earlier triangles if the depth buffer value is equal In essence, the later pixel always wins. I programmed it this way specifically for TFX’s painter’s algorithm. I do not want this in the new VRML renderer because it prevents efficient grouping of triangles by texture. Assume three triangles: with a grass texture; with a dirt texture; again with a grass texture. These would generate the following command sequence with classic TFX-era rendering: select grass texture (costly) draw triangle #1 (cheap) select dirt texture (costly) draw triangle #2 (cheap) select grass texture (costly) draw triangle #3 cheap More efficient would be: select grass texture (costly) draw triangles #1 and #3 (cheap) select dirt texture (costly) draw triangle #2 (cheap) (This grouping is typically done offline, during loading of the scene.) Keeping the ratio of triangles to texture changes high is paramount for performance – imagine a million triangles collapsing into four commands if they just use two textures. But obviously it breaks when all three triangles are in the same place, because now we’ll see dirt instead of grass! For now, I see two solutions: The Right Thing to Do™: create a new texture from merging the overlapping polygons into one. This is pure math horror, it’s academic and we won’t do it. Cheap Trick: When you define the materials, define them in the order of drawing. I may not be able to guarantee the order of triangles, but I may be able to guarantee the order of materials. I.e. define the grass first and the dirt later. I’ll take measures to assure it’s rendered in this order. … and I’ll have a look at Lean Viewer this weekend so you can inspect your output properly.
×