Jump to content
COMBATSIM Forum

Krycztij

Members
  • Posts

    1,934
  • Joined

  • Last visited

  • Days Won

    2

Krycztij last won the day on February 5 2018

Krycztij had the most liked content!

About Krycztij

  • Birthday 09/05/1981

Recent Profile Visitors

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

Krycztij's Achievements

Brig. General

Brig. General (7/10)

3

Reputation

  1. Yeah, the actual smoke and mirrors is updating only the part of the world that’s interacting with the player, and only on-demand. E.g. airfields in TAW have wind socks. I forgot the exact number, but it’s about 4000. You’d rather not update them 60 times a second – just the one close to the player. There’s also a few hundred contrails in the world, and this is already enough to bring weak systems to their knees. Anyway – I’m planning a system to interconnect the planes/buildings/etc. in TFXplorer, sure, but the urgent problem is getting the current version to a releasable state. While the new GUI is good enough, the remappable controls are far from usable, and we have plenty of regressions like bullets being invisible …
  2. We have a viewer for .3 files which can open >90% of shapes: http://krishty.com/taw/3view_en However, the format is reeeeally special and hard to handle. I don’t think there’s a chance to one day have Load/Save support. For TFXplorer, we try to get away from .3 files (due to their difficult handling and them not being GPU-friendly). Mikew has documented his great effort in converting .3 to VRML here: P.S. Sorry for missing your post on SimHQ! Combatsim has RSS/Email support, which means I’m notified of answers directly, but SimHQ requires me to actually open the site, which happens rarely.
  3. Lots of tools, tables, screenshots, and graphics. I think some of them were assumed lost when SimHQ/Photobucket went down. That’s fantastic stuff! 👍 I’ll add it to my archives step by step. That’ll take a while but rest assured that nothing is lost! @Home Fries I’m sure some of those files are interesting for our Dropbox as well …
  4. Yeah, if you have any backups from those days, please send them. I’m building http://krishty.com/taw/forums/ from various PDFs, page snapshots, and Wayback copies.
  5. Aside from mikew’s links, for a quick start on TFXplorer, I recommend http://krishty.com/taw/tfxplorer_en or my YouTube channel. If you want to use the source code, see this post.
  6. Polak, very nice to have you here! I’m also interested in the specific aspects that made EF2000/ADF/TAW such magic experiences. Being a technical person, it’s rather easy for me to port TAW’s world and physics to TFXplorer. The actual fun and excitement of gameplay though are so much harder to identify and grasp for me.
  7. Yeah, first thing you should try with any disassembler: Can you re-compile the code into a working executable?
  8. This makes sense. You wouldn’t want to grant a VM direct access to your keyboard drivers, as this would mean the VM could listen to every keystroke on your physical system (not just while you’re typing in the VM). So your virtual machine software usually presents a virtualized keyboard which is fed with the keystrokes that go to the VM window, and nothing else.
  9. Some USB keyboards create virtual devices for extended functionality, e. g. providing buttons and sliders for sound volume control. This is not part of the ordinary keyboard protocol, so they create a virtual dummy device related to SFX. (Observe that one of them has axes, and the other two have buttons – could be a slider vs. +-buttons if related to SFX.) Windows does not seem to allow me reading input from those devices, but nonetheless enumerates them for me. This makes TFXplorer behave strangely around them. I will have to conduct further research on this later, so don’t throw away that keyboard
  10. When in the repository with Developer command prompt, run git log to display the last commits. But I gotta say that the branch details in the bottom right of VS are a lot better.
  11. Start > Developer Command Prompt for Visual Studio 2019 cd path of the TFXplorer repository on your drive git pull TFX/_auto_build_current_version.bat
  12. FWIW, 10% of that should be a new git version, because git for Windows comes with an entire Linux toolchain (vi and so on, and probably MinGW). So it’s not all overhead I was thinking about adding the compiler to the repo; it’s just 20 MiB for x86 and x64, respectively. But MSBuild (the toolchain for processing VS project files, similar to Linux’ make or CMake) is .NET-based and an entirely different beast.
  13. FWIW, I committed a huge API change to the repository, which had me working on it for weeks. However, the sound/graphics API requires a final big change before I can move on to other things (mostly GUI/input again to the get TFXplorer to a usable state).
  14. Not, not there yet. The way civilian planes are spread out over the world is predestined for these things, but it’s not available in the API yet. Castle Game Engine ftw! I actually used many of its VRML sample files to get my VRML support right!
  15. Okay, a few words on APIs. May be useful as an overview of TFXplorer’s extension architecture. TFXplorer is based heavily on extensions now (or plugins, or mods, whatever you call it). There is no built-in terrain or plane. The TAW/EF2000/TFX terrains are provided from an extension, and the F-22 is provided from an extension as well. I want to pursue the extensions mechanism because it is central to modern flight simulators like Microsoft’s or DCS. So TFXplorer must offer extensions an API. Extensions must use that API to declare assets, to render their planes, etc. The classic (and most simple) way to provide an API is via exported C functions. That’s what the C runtime does (fopen), or C++ (std::chrono::system_clock), or Linux (open), or Windows (CreateFile). TFXplorer/3View did this when the extension system was originally introduced, and some outdated parts of its API are still provided in that manner. This approach has a drawback, however, and that’s versioning/compatibility. Once a function is exported, we cannot change its interface without breaking dependent applications. That’s why Win32 provides weird names like CreateFile2 or GetVersionEx – in order to not break applications which use the old CreateFile and GetVersion. Not breaking old extensions can be solved by supporting the old functions forever, but this leads to another problem: Users mixing versions of the API. You have no means of forcing users to use your new API over your old one, and they will likely mix them up (e.g. use the old ReadFile on a file opened with the new CreateFile2). To account for that, your implementation complexity no longer grows linear with the number of supported versions, but exponentially. This can be solved by stepping away from global functions. Instead of offering the extension all supported functions, the extension has to ask for a specific version and will receive this specific API. This approach is known from Direct3D 9, where the only function that’s initially available is Direct3DCreate9 (similar for newer versions and for DXGI). You call it and pass the version number of the SDK you’re compiling with, and you receive an IDirect3D9 interface with the actual API matching that SDK version. The Vulkan API goes a similar way, only the version number is encoded in the structure type you pass to vkCreateInstance. Internally, you can maintain the APIs isolated from one another. Extensions cannot mix up APIs except by bad intention (they’d have to initialize the API twice with different versions). Problem solved. TFXplorer introduced this in 2020, though the transition is, again, incomplete. There’s another problem lurking, though. TFXplorer extensions are based on callbacks. Extensions initially provide a table à “I provide plane ABC and if the user wants to fly one, call function XYZ to create it.” This makes sense as the GUI/simulation dictate what has to be done, and extensions are only asked how it should be done. But TFXplorer provides a huge set of functions, and entropy dictates that extensions will eventually call them in any possible combination. There are, however, combinations that don’t make any sense – for example, an extension may start placing airplanes in the level when all we asked it for was loading its sound effects. Or it may start loading terrain data when all we asked it to do was drawing an airplane. (The last example is real: When I added the moving map to the F-22 cockpit, I just threw the code for loading it right into the drawing function. This is bad for a number of reasons. But it seems that having rotten smelly code in your codebase is useful to identify problems in your API early ) The API needs separation of concerns. When an extension draws a plane, it should only use the draw functions. When an extension starts a scenario, it should only use the functions to place airplanes/tanks/buildings. So we shouldn’t let an extension access the entire API in the first place! Here’s how it works now: Extensions provide a table à “I provide plane ABC and if the user wants to fly one, call function XYZ to create it.” The table starts with the version number of the SDK the extension was built with. (An inline function in the SDK header ensures this.) TFXplorer internally remembers the version number for the extension so it can return the proper API for the SDK it was compiled with. (Of course I currently maintain only one version internally and that won’t change until the first actual release in 2025 or so.) When TFXplorer actually calls into an extension for things like “I need plane ABC, please create it”, then it passes a minimal interface which only contains the functions an extension is allowed to call during that task. (This interface is versioned according to 1. and 2..) The interfaces for individual tasks are mutually exclusive. Consistency is checked whenever an API function is called. This has a nice side-effect for multi-threading: The interfaces being passed to extensions need not all use the same implementation. Instead of letting extensions tinker with simulation state directly, we can now easily create job objects, call extensions in parallel, pass them individual job objects to do their stuff, and synchronize the results afterwards instead of doing it all over the place. It also has nice implications on testing. This transition has just started and is not yet in the new repository, but it does work well for me so far. It uncovered a load of code smell from 2012–2014 that’s being fixed. Apart from that, the repo contains a slightly extended Settings page.
×
×
  • Create New...