Questions about future development.

[PlutoniumHeart]

Let's assume that we have a sort-of-working version (i.e. able to go into 3D environment for 90% of the times, in both debug and release version, and is functioning the way it was in FF6) of the code, what's the next step? Who's capable of/going to do it?

[vinnydiehl]

Once the code is functioning the same way that it was in FF6, we will focus on some of the most pressing bugs that were known, including multiplayer issues and air-to-air refueling, the latter of which I will tackle.

Once the open source project has a stable release, we will look into removing platform-specific code. This will be a collaboration of all developers and will be very much a long-term side project while we continue to support FF7.

[PeterMeyer]

100% agree.FF7 will our Longterm supported fallback Version and the last Microsoft Windows only Version. FF8 will be an new Technology Release (replacing Windows only Code).Chaos and myself are doing Linux Programming for Years now so if FF7 LTS can be delivered the real Codingfun starting with FF8 can begin, because many hot Features can be implemented.Check the Forum Section for Developers: The Coders Den, there are a lot of talk and Ideas about it.http://freefalcon.tk/forum/3602306/

[PlutoniumHeart]

For future work, I don't think it is realistic to move it to multi-platform, just think how much work has to be done, you have to get rid of the Register stuff, and then convert the DirectX 7 to Opengl, non of these are easy. On there other hand, I have noticed some old stuff in the code that's being generating very serious bugs, and I personally would perfer the team to working on this first. And when we have a set of code that is free of those ancient bugs, we should then try to implement higher version of DirectX or Opengl (As much as I love Opengl, it is going to be a HUGE project to convert, if it was possible) realistic flight and avionics, instead of going multi-platform.

With that been said, I believe I have a working set of code as of now, still having some issues in the debug (assertions) which I believe was there since the beginning of RV just like some random crashes, and also some differences between debug and release (most noticable is that the circles on MFD page HSD is cut into 4 quarter circles and looks wired, but it was working fine in bebug) and this can be eliminated by disabling release optimizations, but nontheless it's an indication of bugs. But I constructed this directly from the VS2003 version instead of working on what we have here. Let me know if you guys have a good way of receiving this set code.

[PlutoniumHeart]

One more thing is that I convert the VS2003 code to VS2012 instead of VS2010.

After you guys got my code, we should schedule some kind of discussion/meeting to decide what's the next step.

[Stewie23]

Hm make a new branch or repository with your working code, and upload it on git. Wouldn't that be a good way ?

[vinnydiehl]

@PlutoniumHeart: There don't appear to be any further steps necessary to migrate to VS2012- the code compiles there for me the same as it does on 2010.

[PlutoniumHeart]

@gbchaosmaster Yes, I know, what I am saying is that I have started my own conversion from the VS2003 code to VS2012, and fixed some bugs, and it is working. It is NOT based on what we have on github.

[PlutoniumHeart]

I can upload it to the develop branch, but it might erase most of the coding style clean up.

Also, I am trying to understand how things works, before I start trying to correct those ancient bugs (I think we all need to understand first, don't do stuff like just making assertion failure go way, but to understand why it is happening and fix the cause), so if anyone has any profound understanding of this thing, please share. For now I would really love to hear your opinions about the program's main entry point (where does it start), winmain() only starts the infinite loop and is not very helpful.

[Stewie23]

Thats why i suggested u make up an new branch, so nothing of the old stuff gets lost (well basicaly with git nothing gets lost) but since your stuff is not based on the master branch here, that would probaly the best way to do it.

[vinnydiehl]

@PlutoniumHeart Ah. Go ahead and upload that to a branch, name it VS2012 or something. I'll take a look at it and work on getting it into production.

[PeterMeyer]

VS2012 is dangerous because it uses a higher WinSDK Version and forces people to use Win7 or Win8 But if you have an new VS2003 to VS2012 conversion a new fork might be a good Idea. Crossplatform is our main goal and was part of the Project from the beginning. Im curious what makes your VS2003 to VS2012 Conversion run. Depends this on the blackboxed DLL/Lib Stuff we dont have the Sourcecode?

[PeterMeyer]

@ PlutoniumHeart The Infinite Loop is where all things are processed, Its an Stack design like the in the most Games.If some one want really slow down FPS and overall Performance this is the place to be.To your Question regarding WinMain. Yea WinMain is one of the Reasons we want go away from Micrsoft.In normal C/C++ it would be an int main() and not int CALLBACK WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow);# To upgrading to an newer Dx Version.DX7 and Dx8 are fixed function Pipelines. Dx10/11 and beyond are using Shaderlanguages, so you cannot simply upgrade the API Calls. You have to lean HLSL Shaderlanguage to perform this higher Level Calls. its the same effort as going to OpenGL where it is called GLSL (OpenGL Shader Language) HLSL and GLSL are allmost twins, but HLSL will force users to use newer Windows Versions.

[PlutoniumHeart]

@PeterMeyer I don't know what lib/dll did you guys remove, so I can't answer that question right now, but I did remove some libs that have something to do with 3d effect. Anyway, you will see when I upload the code. So what I do is just create my own branch? How do I do that?

As for the DX and Opengl stuff, I am only a beginer of Opengl, and knows virtually nothing about DX. I like the idea of converting to Opengl very much, but I can see a lot of issues ahead, I already tried to include Opengl headers, and it immediately introduced a lot of variable redefinition, which is very confusing... And BMS has successfully converted to DX9, and I think DX9 uses HLSL too, so I am a bit curious about that too...

[PeterMeyer]

No. BMS has only ported the DX7/8 Fixed function Pipeline to the more recent Version of DX9.Both Fixed Function Pipeline and DX9 is now officially deprecated and should not longer be used.All DirectX Games should now use HLSL and OpenGL GLSL.Writing Shader Programs is absolutly needed if you want to migrate to the nowdays Standards. Regardless if you use DX or GL. By the Way: ATI offers an utility where you can autoconvert HLSL to GLSL Language so you can see for your self its almost the same Syntax. You have the same work to do regardles if you want to go with modern DX or modern GL. But this is Futuretalk.Right now we have to take care thadt v7.0 comes out as long term supported Version so any old Databases and Aircrafts who is out there can be played.

[vinnydiehl]

and forces people to use Win7 or Win8

I almost consider this a feature. :laughing:

But I mainly want to see the VS2012 port because if it works, we're that much closer to getting it to work in 2010.

@PlutoniumHeart You can either make a new branch of this repo and drop in the entire codebase, or just make a new Git repo on your account and upload it there.

[PeterMeyer]

Youre are right. Gosh i wish dx, com and mfc was allready removed, then we can use cmake and we have no discussion about VS2010 or VS2012. It has nothing to offer Crossplatform libs does not have.

[PlutoniumHeart]

Hi all,

I am setting up my VS 2012 branch, at the same time you guys will need to do the following to make the build read terrain textures properly:

1. Go to terrdata/korea/texture folder in FreeFalcon main folder, backup texture folder and fartiles.dds file.
2. Open a CMD window, navigate to the Utilities folder in FreeFalcon main folder.
3. Use "seasonswitcher -0" command to unpack the texture, it may take a while
4. Copy your backed up "texture" folder and "fartiles.dds" file back to the /terrdata/korea/texture/ folder, replace any existing files.

Issues: This way you can see correct terrain texutre in game, with current EXE, but you will also notice that the height of the terrain is changing a little bit as your plane flys forward, not sure what's the issue here. But since we are going to do a major work converting DX8 stuff to OpenGL, might as well do a fix/rework of the terrain system, so should be fine for now.

For the VS2012 version of the code one of the most pressing problem at the moment is replace/remove (I prefer remove) the "drawparticlesystem" stuff, the writer of the related classes have no idea what he's doing, and the code is generating 90% of the crashes, and I am having a hard time trying to guess what he was trying to do.

The branch is ready at: https://github.com/PlutoniumHeart/VS2012FFalcon.git Please take a look.

Thanks!

[vinnydiehl]

The code is working on VS2012 + Win8 here. @PeterMeyer, what do you think about adopting this code and using 2012, at least temporarily until we get everything on OpenGL and won't have to worry about compatibility?

[PeterMeyer]

Hmm, I use Vista and cannot upgrade. But i can install VS2012 in VirtualBox in Win8, I hope i can backport the VS2012 thing to VS2010.

[PlutoniumHeart]

Should be working in Windows 7 too. I hate Windows 8.

[PeterMeyer]

Me 2. Regarding your OpenGL Tests.I tested a few libs for working with OpenGL, but i found out thadt only FreeGLUT provides everything we need (compatibility from the earlists GL Versions upto 4.2 with the latest Shader Lang Support). All the other Libs came with a terrible tree of libs and dll's we have to redistribute and bloats the Programm. FreeGLUT works fine on 64 and 32-Bit Intel/PPC/Arm Architectures. It runs in VS2003-VS2012, on Mac Development Environment XCode and with Linux Make Files as well. Using this, makes it possible to Cut off Dx, MFC,ActiveX, COM, registry ect) this would be a big step ahead.

[PeterMeyer]

Regarding Particlesys. I hope we can rewrite/reinvent it to an level the effects showing in the sim is acceptable. If not, there is a good chance we can simply using the Bullet Physics Lib inParticlesys.http://bulletphysics.org In our Forum there are some Posts about freeglut, bullet, tbb ect.http://freefalcon.org/topic/8414714/1/#new

[PlutoniumHeart]

We should probably convert to OpenGL first before considering anything else, for now, I don't know how to deal with it.

[PeterMeyer]

I wish we could do this, but simply we cant. FF7 should be a long term supported Version and the last DX Version. In FF8 you have card blanche and do all the cool OpenGL Stuff. Its just for the sake of compatibility and supporting the community. Its lame work fixing stuff but i hope it has an end and we really can begin working on FF8 asap!

[PlutoniumHeart]

I see, then we should find someone to rewrite it...

[PeterMeyer]

If i have VS2012 i will take a look of it. I hope i can clean out the code inside the trashy functions computing the needed functions results in lib bullet, this would prevent us from rewriting patriclesys from scratch.

[PeterMeyer]

Hi. I checked out your VS2012 migration. It doesnt compile at allI get tons of the old Errors int as default type not allowed or pvoid64 undefined ect.Looks for me this Code was not migrated or never touched. Are you sure you have uploaded the correct Soruces to your GitHub Repo?

[PeterMeyer]

After new checkout it seems it compiles now as expected. I found in the 3dlib Subproject there was a false include order and $(DX81_SDK/include was missing.

[vinnydiehl]

@PeterMeyer I didn't have a problem with that. That should be set in your user-side C++ include directories, not in the project settings. This setting is held across different versions of MSVS, so it saw mine from 2010.

[PlutoniumHeart]

I assume you guys all took a look at the code, so what do you think? Should we start converting to OpenGL based on this?

[vinnydiehl]

@PlutoniumHeart: I don't have a problem with starting the conversion from this version of the code, once we have the code stable, cleaned up, and working well, that is. I feel like this is much closer than the current code is, though.

I'll have to get the other fixes that we've done patched over to the potential new code, and that might take a while. I'll let @PeterMeyer get his opinion in, and think about how I might go about that.

[PlutoniumHeart]

So if I understood correct we are actually aiming at releasing a FF7 based on this code, which would have less bugs and more stable, only after that we are going to convert DirectX to OpenGL which is the FF8?

Looks good to me, but is there a time table for each step?

[vinnydiehl]

Yes, that's the plan. The only step that I had a time set on was getting the code flying, now that that is done we can plan further.

[PeterMeyer]

As far i can see there are grpahics errors, but i think we cannot deploy it as it is. We have to solve this Graphics Error first, then i think we can move ahead with FF8 and OpenGL.

[PlutoniumHeart]

What kind of graphic errors are we talking about?

[PeterMeyer]

If you jump into an TE for instance Basic Handling, then you see large white areas on the outside.This is almost the same behavior as in the unconverted FF6 VS2003 running source.

[PlutoniumHeart]

@PeterMeyer Did you do the 4 steps I described earlier in this thread?

[PeterMeyer]

yes, it runs but you have the white areas if you look outside the cockpit. seasonswitcher -0 was running and took some time.

[PlutoniumHeart]

If you have done that correctly then there won't be any white areas outside.

[PeterMeyer]

If you choose TE Basic HandlingTakeoff you get the Blue loading screen and it crashes with an Assertion \vs2012ffalcon\graphics\bsplib\objectlod.cpp Note: refCount > 0 But Dogfight works and Instant Action to. Im running the Debug build, but i will test the release type asap.

[PlutoniumHeart]

Yes, I know about those, and it is there from the very beginning, the conversion didn't introduce those errors, I fixed some along the way, but not all, we do need to address those assertions. However you should be seeming any texture errors on the terrain though.

[PeterMeyer]

I have not tested all possible flight scenarios yet but for Instant Action it looks like the Textures are shown correctly. Honestly i missed your 4 Instruction, this whitepaced the areas. It was my fault.

[PlutoniumHeart]

Well, about these assertion errors, it's going to take a long time to find the causes and fix all of them.

[PeterMeyer]

Hmm yes. Maybe we need a Skype or Teamspeak Meeting and talk about it. Installer is quickly builded bat we need a new Splashscreen and maybe we can give this away as Beta Version.

[PlutoniumHeart]

I can do teamspeak, just let me know when and the TS address.

[PeterMeyer]

I have no tsserver but i belive Chaos has. I think it makes sense Chaos you and me talking together in TS

[PeterMeyer]

Hi @PlutoniumHeart I just tested a Intel V13 Compilerrun. It seems to me thadt many of the Errors i allready solved in VS2010 now comming back again.Problems for Intel and GNU Compliance was allready solved. Can you backport your changes from the VS2012 Source to the VS2010 develop Branch? I think you know best what parts of the Code you have corrected. If we have your Changes in the VS2010 branch, it will compile on Intel optimizing Compiler again.It would be a great help.