Jump to content

TurbofanDude

Members
  • Content Count

    245
  • Donations

    $0.00 
  • Joined

  • Last visited

Community Reputation

23 Neutral

About TurbofanDude

  • Rank
    Software Developer
  • Birthday 08/24/1996

Contact Methods

  • Website URL
    https://tfdidesign.com
  • ICQ
    0
  • Skype
    turbofandude

Profile Information

  • Gender
    Male
  • Location
    United States
  • Interests
    Music, aviation, computers, fitness.

Flight Sim Profile

  • Commercial Member
    No
  • Online Flight Organization Membership
    VATSIM
  • Virtual Airlines
    Yes

Recent Profile Visitors

4,718 profile views
  1. We're aiming to get the final update out VERY soon.
  2. We definitely appreciate the support - and we always do promos during events! @GameSyns is the marketing guy, so exact specifics are more up his alley.
  3. We've been working on addressing that in the last few updates as best we can.
  4. @DaveCT2003 You can see an itemized change log, along with the dates of release, here: http://forums.tfdidesign.com/index.php?/topic/2268-beta-change-log/ Regarding the view switch CTD, I'm very interested to hear your findings. We've been attacking it from the debugging side but have been sent down the rabbit hole of random, unrelated DLLs and useless call stacks, so a different input on it will definitely be a good thing.
  5. Yes, the system that TrueGlass uses is a full particle system that generates real-time particles and simulates them throughout their life cycle. This is how it avoids the repeating-texture effect and is able to react properly to speed changes, etc. I have updated the wording on the pages for TrueGlass and RealLight to settle any worries about source model access - we would NEVER expect third parties to send us the source for their models. It was just a bit ambiguous wording.
  6. @Jovabra I PM'd you so we can solve this directly - I don't want to ask for anything (email, etc.) publicly.
  7. Did this get resolved via ticket?
  8. All tickets get replies - if you didn't hear back, it never reached us. It sounds like you're having an issue getting our replies - have you checked your spam box? Have you messaged anyone on the forums regarding it? Have you attempted to see what's going on anywhere except venting on a third party forum we may not even see? I don't mean to be overly harsh, but we take great pride in working personally with everyone that contacts us, so it bothers me to see a post like this, especially knowing we haven't exhausted our options yet.
  9. 6 years later, and in Prepar3D v4 now, and this is STILL the way it works.
  10. We were having some intermittent issues this morning, it SHOULD be starting to get back up now.
  11. No, it absolutely is a matter of being complacent. We've been trained to accept mediocre as fantastic. Poorly optimized code can bring even the most powerful of systems to a halt. Nobody ever said you'd have 1m resolution imagery for the entire world - you use repeating textures setup in a way to blend naturally, maybe with some additional maps to help it determine proportionate temperature, etc. to blend as it moves across the country and world. Again, the possibilities are endless as soon as you start thinking outside of the box. That said, a GTA V level world for a simulator is INSANE and not a reasonable goal, of course. There are things like Unreal Engine 4, which has been used to create large scale flight games, that are capable of immense things at 60 FPS. Yes, you're correct, one bad feature can ruin it - this is why we should expect developers to understand this and properly optimize their code (which very little do). Even my own code can use improvements - the second you assume it's somebody else's fault or that that's all you get, you stop growing and we end up with an 11 year old platform being dragged forward. This is all from my 6 years as a professional programmer, including experience with Direct3D and HLSL, I'm not making things up. It's time to start thinking outside the box and stop accepting mediocre. That goes for both sims.
  12. It's sad to see it come to this. Such potential, and so far, questionable, at best, ethics and business around it. Based on the information currently available, we share your thoughts.
  13. Please open up a ticket with us - the second the display lag is fixed we will nail down CTDs are soon as possible.
  14. Rob, Your whole reply impressed me - very well said. Henry, In response to your original question, I've got a few points that I think about when picking a language. I'm fluent in both C#/.NET and C++ (and C++/CLR, which is .NET for C++). My thought process on using .NET is this: similar to what Rob said, many times, chunks of the code aren't available directly to client and won't be as easily accessible to a "hacker" or decompiler or if it is, does it really matter? The other thing to consider is the amount of time it would really take somebody to reverse it. For example, smartCARS (our ACARS platform) was written in C++ using the .NET (CLR) for the GUI. There are parts of it, that, if decompiled, would reveal something similar to the original source. That said, it's mixed in with native code that generates line after line of bit shift operators or ridiculous references that I can't even figure out when comparing it line by line with the original source. The amount of time it would take to put that back together, even with partial source, isn't at all worth it for a "hacker." Our installer system is written in C# - if it's decompiled, yes, it would be visible. In this case, it's not the technology that's important, it's where it's used. There are only so many ways to accomplish the same task of installing files. The above points, of course, supplement Rob's points. Simply using C++ isn't an obfuscation method - it does stop things like dotPeek from reversing it to easy-to-read source, but it doesn't make it edit proof. To answer the original question, what keeps us using one language or another? It's what we need - we deal with language-relevant problems as they come. If you need flexibility and integrated support/tools - use C#/VB. If you need heavy optimization or native interaction (gauges, etc.) - use C++. That said, ultimately, it's mostly up to developer experience and preference as both sides of the field are starting to balance out.
  15. Oh, I know it. Still an exciting thing to think about. Also kind of scary that there are so many companies potentially losing money and productivity by under-utilizing modern technology.
×
×
  • Create New...