The future of the sim..?
-
-
Very good point! Wonder what ever became of that sim? Probably in perpetual development just like Jet Thunder and the Seven G F18 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.
-
So are you also saying that if someone coded something into FF and it seemed useful, there could be potential interest in importing that piece of code to BMS?
Of course … and/or even would rather be invited to join the team if its personality fit with the team’s general view (remember that it is not a commercial entity, goal is to have pleasure doing it together and enjoy the achievement together.)
Look … Crusader has been invited to join the team on my request after some information’s exchanges about SP4 missiles and radar via PM on the public forum. After some discussions on TeamSpeak he became a real friend and showed that he can work in a team, being smart, open minded, pleasant (note that efficiency is not the most important quality, the paramount quality is on the human and relation side) … now he one very active dev.
Such good guys are probably here and there … and will probably join one day the team if we notice them. But it is on invitation … in fact, no need to ask to join => refer to BMS F.A.Q.:Contribution:
Q: I’m inspired by what you have done and I have more time on my hands than I know what to do with, and I think I have the same screw loose that you all do. Can I join the BMS team? I’ve been a beta tester before…or I’ve been involved in OpenFalcon development…or I’ve been flying F4 since the beginning…
A: So have we. Short answer - NO! Long answer - we do add people to the team periodically when it seems like a good idea, if they’re interested. Please do not ask us to join. There’s plenty of scope for folks to get involved in the future development of the BMS community add-on, even if they aren’t ‘on the team’. In particular though if you have skills as a texture artist you could get to work right away! Past that, make a suggestion of what you’d like to work on, or where you think you can make a solid commitment to deliver. Realize we’re not going to adopt the “come one, come all” approach though. As you can imagine, a huge influx of new hands working on the problem would be tough to manage in a way that everyone comes out happy.
Q: What do I do if I want to make some mods and contribute them to the BMS team?
A: BMS encourages modding as this will benefit the community in general. However, please don’t expect support for bugs that are reported from modified installations as a “right”; it is likely beyond the resources of the BMS team to try to pinpoint all possible problems on anything other than a clean install. We’ll make best efforts to help but please bear in mind that there are real limits on what we can reasonably do outside the materials that are part of a release.
… However, even if integrated to the team, this guy will have to be VERY patient before having access to the code and this is why we have to be friend first because it is, above all, a question of confidence, trust and friendship. Many other have the same story … Hayab, Lazy, Polak … etc …
For the ppl who think the open source is the way to go … search for “FreeFalconOSC” … and see their progress since 2013.
-
maybe a little focus on the “Red” side, some people like to fight for the guys with a cause.
QUESTION:
are we stuck with the f16 MFDs?
-
Just get that VR support so i can get back to BMS
Sent from my iPhone using Tapatalk
-
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