The future of the sim..?
-
Not sure Fighter Ops (FO) is still under active development. Many of its sim concepts have been (are being) incorporated into other sims (like DCS) faster than FO could develop them. FO is a great example of how difficult it is to develop a new flight sim. It probably reached a publishable stage of about 75%, entailing tens of thousands of effort-hours, before collapsing. Its Achilles heel was, IMO, the inability of its core group to create a functioning team-oriented development organization.
Once again, Fighter Ooops is dead. AFAIK, NONE of the work done with FO made it into any other sim, unless some went to DCS under guise and fed them unfinished work. It was never at 75% published. Also, what killed FO was far more than “the inability of its core group to create a functioning team-oriented development organization”. I will leave it at that.
-
This post is deleted! -
dx9 - dx10 is a major change actually. When I made that transition on my graphics engine I had to rewrite most of it. The issue is one of synchronous graphics calls in dx9 and asynchronous graphics calls in dx10. For example in dx9 you can update positions and shader variables up to the point you call draw. In dx10, if you do that your engine will be slow as a dog. This is due to the use of shader constant buffers in dx10 which when changed cause a pipeline stall. However, if the dx9 code was written to update all values then do the rendering in sequence without changing those values in between then it would be more trivial. Now , dx10 - dx11 is a small change. dx12 is ridiculously complicated.
-
dx9 - dx10 is a major change actually. When I made that transition on my graphics engine I had to rewrite most of it. The issue is one of synchronous graphics calls in dx9 and asynchronous graphics calls in dx10. For example in dx9 you can update positions and shader variables up to the point you call draw. In dx10, if you do that your engine will be slow as a dog. This is due to the use of shader constant buffers in dx10 which when changed cause a pipeline stall. However, if the dx9 code was written to update all values then do the rendering in sequence without changing those values in between then it would be more trivial. Now , dx10 - dx11 is a small change. dx12 is ridiculously complicated.
Agreed. A DX 11 update, though being a GFX code re-write, would be the best way to go. And, DX 12 has no major GFX enhancements from DX 11. It allows different GFX cards, with different instructions, to work with each other AFAIK. So, a DX 11 would be ideal IMO. But getting BMS to even DX 10 will be a big undertaking. I think this team is up for that. Time will tell.
-
Exaclty the thing is the original poster slapped his own license to something leaked and put it on github , that doesnt make it “open”
Well actually it does. Putting it on a public repo on GitHub makes it open source. Why is it open source? Everyone can see it. Its not free open source (although the readme claims otherwise, saying it is released under the BSD2). If I had a copy of the BMS source and leaked it, BMS (whatever version was leaked) would be open source. Without a license that permits people to do something with that source, it would not be free open source (and thus would not be overly useful).
Yes FFosc is open, no, despite their claims to the contrary, it is not FOSS.
For the ppl who think the open source is the way to go … search for “FreeFalconOSC” … and see their progress since 2013.
Actually I agree with Vyper on this one. Anyone who would normally contribute to FOSS would look at the license for FFosc and turn and walk away. Open source yes, free no.Big distinction.
One area that your example is counter-intuitive: people can do that. We can look up and see every bit of progress on FFosc (none since 2014). As mentioned above we can fork the repo, make our own changes, and if the upstream was still active, pull request those changes in the upstream repo. Being able to see and assist development… even if it attracted only one more line of code than would have been done otherwise, that alone makes it the way to go.
-
The issue is one of synchronous graphics calls in dx9 and asynchronous graphics calls in dx10. For example in dx9 you can update positions and shader variables up to the point you call draw. In dx10, if you do that your engine will be slow as a dog. This is due to the use of shader constant buffers in dx10 which when changed cause a pipeline stall.
Well, I’ll admit that I’m almost totally not familiar with DX9, but DX11 I do know to some level of knowledge, and I don’t understand what you refer to by saying that it would be slow to update CBs before draw calls.
For all I know, if you structure CBs in a way that makes sense according to the update frequency - e.g IMMUTABLE CB for stuff that never change, perFrame CB for stuff that may change every frame (e.g sun position) and perObject CB for stuff that changes per object (e.g World matrix) - Then you should be fine. Of course it’s better to keep number of draw calls as minimal as possible, but that’s a generic rule… If you need to draw many objects that cannot be batched/instanced then I don’t know other way to draw than updating the required per object CB and launch the draw call. Is there any magic?
What I did heard though is that DX10/11 are much more sensitive to Render states changes, so unlike DX9 one should be careful when designing large engines to take care of this stuff specifically.
-
Agreed. A DX 11 update, though being a GFX code re-write, would be the best way to go. And, DX 12 has no major GFX enhancements from DX 11. It allows different GFX cards, with different instructions, to work with each other AFAIK. So, a DX 11 would be ideal IMO. But getting BMS to even DX 10 will be a big undertaking. I think this team is up for that. Time will tell.
This is not really correct. DX12 is the first and only DX API that allows you to leverage multiple CPU cores during the render stage. The pipeline is a little more clustered from the developer standpoint, but in the end it results in a much more efficient transition through the pipeline stages. It also has some native buffer replication functionality which improves performance during the swap. The problem with DX12 right now, is that most developers are still writing the back side like it’s 11, which results in a performance hit, instead of gain.
-
Well, I’ll admit that I’m almost totally not familiar with DX9, but DX11 I do know to some level of knowledge, and I don’t understand what you refer to by saying that it would be slow to update CBs before draw calls.
…
What I did heard though is that DX10/11 are much more sensitive to Render states changes, so unlike DX9 one should be careful when designing large engines to take care of this stuff specifically.This is why I said earlier it would require a complete GFX rewrite and not just an adaptation to the new API. It’s tedious, but well worth the effort in the end.
-
This is why I said earlier it would require a complete GFX rewrite and not just an adaptation to the new API. It’s tedious, but well worth the effort in the end.
Yea well… you can’t make an omelet without breaking a few eggs. So if we like it or not, a rewrite will happen at some point.
-
Agreed. A DX 11 update, though being a GFX code re-write, would be the best way to go. And, DX 12 has no major GFX enhancements from DX 11. It allows different GFX cards, with different instructions, to work with each other AFAIK. So, a DX 11 would be ideal IMO. But getting BMS to even DX 10 will be a big undertaking. I think this team is up for that. Time will tell.
IRC DX 12 allows for better CPU scaling as well as the number of objects and details can increase. I too would like to see BMS to go to DX 11 just for VR support if it’s possible. I would be great to see a commercial effort but I understand the IP issues. I’m sure most of us would be willing to pony up for a fully supported product. Heck I’ve already paid well over 200 bucks for BOS BOM and BOK.
-
I think immersive VR is the way ahead.
-
The looooong future…
VR has a long way to go until it has enough client base. Now its what 1%? Or lower among flight sim users? So waist ultra resources for something that will be mainstream in x years? Doesnt seem efficient. Sure i would love to have vr and tomorrow bms to release a vr exe but…sent from my mi5 using Tapatalk
-
redesigned MFD system that will allow for different types instead of f16 fits all
-
IRC DX 12 allows for better CPU scaling as well as the number of objects and details can increase. I too would like to see BMS to go to DX 11 just for VR support if it’s possible. I would be great to see a commercial effort but I understand the IP issues. I’m sure most of us would be willing to pony up for a fully supported product. Heck I’ve already paid well over 200 bucks for BOS BOM and BOK.
Ok, more scaling and objects. But not a big GFX improvement was my point.
-
This is why I said earlier it would require a complete GFX rewrite and not just an adaptation to the new API. It’s tedious, but well worth the effort in the end.
Very interesting discussion, folks.
If a complete gfx rewrite is on the cards (pun intended ;:)), could we please consider a cross-platform engine like OpenGL or one of its successors?
For BMS to become completely “free” in the true sense of the word, it needs to be untied from the windows platform (and in a proper way, not by using some WINE hacks that don’t work for half of the people half of the time).
IMHO (or, in this case, not so Humble opininion), win10 is dead as a valid and legit gaming platform (too many issues to mention here, and also I don’t want to derail the thread). so ithis would be a major step forward towards making BMS a cross-platform sim.
All the best, Uwe
-
so ithis would be a major step forward towards making BMS a cross-platform sim.
BMS is not all of the cake … you totally forgot the controller hardware (Cougar, Warthog etc.) that must also run on the client machines. Unter windows it’s already a PITA to get the whole bunch running, under Linux it would be a nightmare :shock:
-
OpenGL is not an option.
-
BMS is not all of the cake … you totally forgot the controller hardware (Cougar, Warthog etc.) that must also run on the client machines. Unter windows it’s already a PITA to get the whole bunch running, under Linux it would be a nightmare :shock:
I’ve had good results so far with my HOTAS Cougar (dx mappings only), the a10 tablet and the TM MFDs without hacking too much on Linux (Mint 18.1). 3d performance is on-par with win7, headtracking using linuxtrack works nicely too (delanclip).
Warthog supposedly works in DX mode on Linux, too (haven’t tested this yet)
I agree though it’s a bit of a chicken and egg problem… but maybe hardware vendors will be finally smelling the coffee (and the gfx manufacturers already do) and improve or step up their Linux support.
Again, I’m not meaning to derail the thread with a win vs. XXXX discussion, but I’d consider cross-platform a major point in BMS’ favour over the next decade.
X-Plane does it nicely, so does flightgear, so it’s not exacty impossible nor a nightmare, more of a wet dream hopefully coming true one day (FG devs getting together with BMS for truly modular, cross platform sim… hmmmm :D)
All the best, Uwe
-
OpenGL is not an option.
Hello, I-Hawk.
I was following this interesting discussion, when I’ve read your last statement.
For me, not an expert or a skilled developer like you are instead, would you kindly explain your point of view?Thanks in advance, with best regards,
-
That’s not what I meant. It just seems that people are responding with things like “what happens when we run out of ideas? We’ll never run out of ideas”, and I don’t think that’s what he meant when he posed the initial question. I think he meant sooner or later the project is going to get to a point where the continued development will no longer provide the satisfaction to those of you keeping it going, or there will be aspects that need attention that are beyond the limits of the current teams technical expertise (That’s not a dig or a slam, I’m a coder too and we all have our limits and specialty areas, and lets face it DX is just a pain in the A no matter how much experience you have with it), or when the imposition it causes in your personal lives gets to the point that you have to/want to do something else. Maybe I misunderstood what he meant, but that comment was not meant to be a dig at BMS or say it won’t keep evolving. I just think he meant that the game has come a long way, and sooner or later you reach a limit to how much you can change things from the original without having to do other major overhauls, which cause problems with other modifications, etc, etc, big circle and so on…
That’s pretty much what I was talking about. I love the game and know that the team has lots of features that they can and want to implement. I guess I didn’t understand that it is a labour of love and that their work is not prohibiting another dev team from making another F16 sim. I just thought that they would eventually get to a point where they would much rather devote their time to creating another sim . Such a sim would allow them to make use of the latest DX/OpenGL/Vulkan API from the start to to implement all the features and systems that they are, technically, unable to add to Falcon BMS.