Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Krycztij

  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.
  16. My Windows 10 is so horribly broken since last month. My PC force-reboots every night to try and update the system (even though I disabled updates in the GUI, registry, group policies, and services). Then if fails with a cryptic error code and rolls back. All for nothing, except that Edge is force-installed every morning. When I look up the error code, it means either “Edge cannot be installed” (why is Edge even in my security updates?), “Edge is not installed” (wrong), or “the invisible system-reserved hard disk partition created by Windows on first install has less than 500 MiB of free space” (the heck they want me to do about it?!). It’s a disaster. My wife has to do with many Windows Server systems in her day job, and she says they are all better than the normal Windows 10, so I’ll give it a try: I’m doing my backups right now and after that, I will install Windows Server 2019. It has a 180-day evaluation period, and this can be prolonged six times or so. No Cortana, no Edge. I found out that you can even uninstall Defender!
  17. If you intended to ask “what happens if somebody wants to contribute?”, then the answer is “send the modifications to krishty at krishty dot com”. Slightly updated version is up. Please delete your checked-out repository and download it again. (Or back it up, delete it, then restore your backed-up files in the new repository.) This is because I cleaned up the repository’s history, and it turns out git doesn’t like this at all. Specifically, I removed source files that were never used or had nothing to do with TFXplorer converted source from ca. 2016 onwards to UTF-8 with Linux line endings, from the catastrophic mess of codepages and line endings that was there before merged changes like “fixed typo”, “fixed another typo” into single commits moved a few git settings back in time to make it easier to work with old versions.
  18. Woah I had that on my mix tape during the millenium, brings back memories! I’m suprised that you know that great little niche game, and indeed the artist contributed a song to it! These two are said to be about holidays as well
  19. Programmers only listen to either death metal or synthwave. I listened almost exclusively to Cat System Corp for the past six years. (This has to be the best album of the 2010s.)
  20. Hah, I remember that one. In the garden of Eden, from I. Ron Butterfly!
  21. Apart from being one of the most literal videos ever: Did they really film their Jamaica holiday video in England?! Love the song, though. (I love how their live performances sound not a bit different)
  22. Indeed, your Windows Dark Mode setting determines whether the GUI renders light or dark. The color variation is a result of me taking snapshots at different times of day. There will be a setting in the GUI to override this, but I haven’t added it yet due to lack of a combo box control Yes it is, in the sense that no one but me can screw up anything
  23. Currently introducing tiled layout into the settings GUI. The problem with the current layout is lots of wasted space on wide screens. See for example (and note that the Windows 10 Settings App has the same problem): With the new layout type, controller settings are displayed left-to-right until the line is full, then the line breaks. This is a little more difficult to implement than I thought, because I need to take into account the different item heights and their margins, but it feels so much better now: That’s pretty important for the flight controls, where a few dozen settings are on one page and you’d be scrolling to death in a plain vertical layout. But I’ll show snapshots of those another time. ———— You can see customized names for devices, buttons, and axes in the above snapshots. These were broken for quite some time; a fix will be pushed soon. Just a detail, but handy during development. ———— I guess that would be overkill. I’ve wasted too much time on the GUI already. Allowing for customized GUI would bring us closer to the original titles, but that time might be better spent in improving gameplay …
  24. Very cool! My first (and only) VR experience was when I got my hands on a Oculus prototype in the early days. The resolution was so low and the flickering so strong that I couldn’t use it more than five minutes straight, and the sensors would gradually lose my orientation while I rode a few laps in LFS, so I’d end up with the steering wheel behind me. But I remember clearly to this day how lucid the game became. I suddenly noticed details like powerlines and couldn’t stop staring at those beautiful reflections on the dashboard. The arms on the in-game steering wheel became seriously disturbing, as I confused them for my own. Gotta get me a headset when GPUs become affordable again …
  25. (continuing from https://community.combatsim.com/topic/48771-tfxplorer-and-windows-10) I pushed the latest commits with a few GUI fixes. Most importantly, the new layout engine is implemented, saving me lots of time in building the upcoming GUI pages for control bindings. Writing formulas by hand to place all texts and buttons dynamically was an incredibly tedious task; now I “just” need to define rules like “place these buttons and text labels left-to-right”. I’m still not satisfied with the result, but we’re getting somewhere …
  • Create New...