AFCAD for FSX?

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#21
Well I guess re-writing would follow the 80:20 rule. 80% of it would be easy but the last 20% more difficult :) One way might be to move as much C++ code into library dlls as makes sense - these can be then used with C# without changing the code. It does mean that C# will treat them as unmanaged resources.

You could try a converter on your C++ code - here is one http://code2code.net/ but be prepared to do a fair bit of manual cleanup :(

If you do a search on google for C++ to C# conversion or converters then you will find some discussions on the subject.
 
#22
Well, yes, the best solution would be inserting the already written C++ code in a DLL to not change it then make some kind of program in C# that would call the DLL. And about the converter, i think it would be like if you were translating from one language to another using any actual translator....with this i mean the accuracy...lol....most of the translated thing maybe not accurate as expected....But anyways, i will try the converter to see how its translate..but having in mind, as you told me, that i may need to do some manual cleanup.

Manuel Ambulo
 
#24
The one major disappointment I have with AFCAD is that it is not compliant with the FS2004 BGLComp SDK. Though of course Lee released it long before the SDK came out.

Some of us have been working with the SDK in the FSX Beta. Some interesting new things there - and some which were in FS2004 but did not work - we want to try them in FSX.
 
#26
I think that the problem is that MS is killing a lot of indepent languages. VB6 depends just from 1 dll ( MSVBM60 ), but VB.NET and above need .NET Framework installed. The same is happening with C++. Our luck is that we still can program stand alones programs ( that don't depend of external DLL ) in MSVS.

Its very miserable programming a GUI app in C++ without .NET, but at the end you get an independent executable and a very, very faster app than if you had used Framework ( because it really kills the startup performance of applications ).

I don't know what to do. I continue to program in VB6 because the IDE opens very fast and when I run my app, it opens instantly, different from VB2005 or any other tool using Framework. So I don't know what is worthy: use a 9 year old IDE, migrating to VB2005/C++ with the framework or studing a lot of C++ to create a GUI application independent from all those dlls and ocx.

Fergo
 
#27
I didnt really knew that programs made in .NET where sooo slow at startup....is it sooo slow?.(even if it is a simple and low resources program)?..(i didnt tried making programs in C# neither using any .NET language....).

Manuel Ambulo
 
#28
I think that the problem is that MS is killing a lot of indepent languages. VB6 depends just from 1 dll ( MSVBM60 ), but VB.NET and above need .NET Framework installed. The same is happening with C++. Our luck is that we still can program stand alones programs ( that don't depend of external DLL ) in MSVS.
Sorry, but I think the problem is that you are not aware of why VB was killed. If you know programming well (on the level where you would say "oh no, not again" instead of "I don't know how to do that" if someone ask you to write a compiler) you have no problem understanding what is happening. While some people where regretten the death of VB, professionel programmers around the world where popping the champagne bottles.

VB was killed because it was a horrible language. Not just a bad language, no horrible. The syntax itself is goofy, but that is not really the problem. The problem is a lack of completely fundamental requirements in a modern environment - requirements like using garbage collection instead of reference counting, full exception support, and full support for object oriented programs (not an addon like VB has). VB had developed to a hack over the years (with it's pseudo object orientation etc) and the end of the line had been met - it was not possible to add the requirements of a modern environment anymore. And without it, there where two choices. Either MS should not implement modern libraries in the OS (so no WPF, WCF, or WF), or they should drop VB. As the world has to move on they did the obvious - dropped an old language that was too old to be fixed. How could that possible be the wrong choice?

And now we are at it, the only environment that actually supports simple deployment is .NET. It has a single runtime setup that is distributed as part of Windows Updates - and it will obviously be included in the OS going forward. VB programs ends up requiering one or another COM component (and now we are at it, COM is another outdated monster that needs to be killed so we can move on to better things) as soon as it leaves the "Hallo World" level. C++ does not support side-by-side install of DLLs so it's just DLL hell waiting to happen.

Its very miserable programming a GUI app in C++ without .NET, but at the end you get an independent executable and a very, very faster app than if you had used Framework ( because it really kills the startup performance of applications ).
Yes, it kills performance loading all the systems ensuring your program runs correctly - protected from your bugs, or your attemts to attack my computer (you as in "the programmer", not you personally). Let me see - wait an extra second to load, or run an insecure program - hard call? NOT. I am not the only one who is now ALWAYS choosing a .NET program over a C++/VB program if the choice is available. If it is not available I would require a lot more confidence in the programmer and expectations the program will be really beneficial before I try something as stupid as running C++/VB programs. And we are getting more and more thinking like this - as people become more aware of what .NET is and why it is insane to allow anything unmanaged to execute on your system.

I don't know what to do. I continue to program in VB6 because the IDE opens very fast and when I run my app, it opens instantly, different from VB2005 or any other tool using Framework.
I don't really know what to say.... the time you get back from using a modern programming environment over something as old as VB comes back to you so many times more than the time you loose waiting for your IDE to open. It just makes no sense.
So I don't know what is worthy: use a 9 year old IDE, migrating to VB2005/C++ with the framework or studing a lot of C++ to create a GUI application independent from all those dlls and ocx.

Fergo
Neither is worthy - move on.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#29
I didnt really knew that programs made in .NET where sooo slow at startup....is it sooo slow?.(even if it is a simple and low resources program)?..(i didnt tried making programs in C# neither using any .NET language....).

Manuel Ambulo

Well I am not sure that I agree. It is true that a .NET program is 'compiled' when it starts but I have never found the start-up time to be a real issue, consider how long FS or MS Word take to load. Also once the program is opened it is compiled to machine code and performance should not be that different than any other program. If start up time is very critical then it is possible to 'pre-compile' before or after installation.

It is true that dotNet is a large library - much larger than VB6 for example. But these days of ADSL 20Mb downloads are common in the FS world. Also with Vista the NET libraries are part of the install as I understand it.

There are a number of game makers now using C# and managed DirectX for their games so NET programs can't be that bad :) Have a look here for some of them http://www.thezbuffer.com/categories/games.aspx

However, in the end it is all down to personal choice. FS Addons can be made using just about any programming language you favor.
 
#30
If you need a Beta tester or something, I'll be glad to help you all out.
I've some Afcad's under my belt right know. Check Avsim.com and search for Victor Nauta in the file library. The only thing wich bothered me was de lack of 3D scenery which you can't adjust with Afcad, think off the taxiway signs or the jetways.

cheers

Victor
 
Last edited:
#32
Something just popped up in my head.

It would be nice to include all kinds of taxiway markers. Like gate numbers and all that. Also it would be nice addition if you could modify the road system of the ground vehicle.

I'm currently a student in civil technoligy and I use a couple of CAD programs. What is nice of a program like Autocad2006 is that you can work in layers. Little example: if there is a possibility of taking a satellite image and place that as the background image. It would be nice to switch it off and you wouldn't se it. But your taxiways are still there in a seperate layer. Or you'll be making the groundvehicle layer which you could switch off so you only see taxiwas and all that.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#34
Those markings are a good idea, the only question is which code to use for them? :). For my current project I use Fs2002 style ground polygons for them and the text is generated automatically from an AutoCAD file. So I think adding such features would mean that we can't do it with XML code only.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#35
I think I would prefer that we use only XML if at all possible - and if it can be done that way in FSX. If not then we will need to use whatever method works :)
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#36
I think I would prefer that we use only XML if at all possible - and if it can be done that way in FSX. If not then we will need to use whatever method works :)
I haven't studied it in full detail yet, but it looks like for really realistic markings the XML code is still not good enough.
 
#37
I'm not in to programming and all that. But isn't possible to make it out of seperate images instead of making the lines go in to the of a number.
You could add something like a scale factor. It depends on how wide the apronroute is, so at Heavy gates the number is slightly bigger than at a regionale apron.
Or do you want it as a seperate object in the scenery so that it's not actualy part of the taxyway system.
 
Top