Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: FreeSpaceFreak on February 09, 2012, 04:52:42 am
-
Done with my moderately successful wxWidgets cleaning tool, I tried to build wxFRED on MSVC10. It didn't work. Compile-time errors, run-time errors, you name it. So I fixed it. Diff attached.
Warning: it has taken a blunt axe and a bulldozer to fix it.
- Upgraded the project file from wx 2.8 to 2.9, since 2.8 doesn't work on MSVC10. Theoretically it should still compile under 2.8 as well, you'll only have to change the linked libraries in the project file.
- Upgraded to Unicode. wxWidgets is planning on dropping ASCII support in the near future (http://docs.wxwidgets.org/trunk/overview_unicode.html#overview_unicode_supportin), and with wx 2.9 Unicode is much more convenient already.
- Removed non-existing voicefilemanager files from the project
- Removed non-functioning XML stuff from the project
- Added ../../code to the include directories
And possibly some more which I forgot already. Oh, and I only fixed Debug configuration - haven't touched Release (yet). And I haven't been able to test my changes in Linux, something's wrong with the linked wx libraries there (couldn't find wx/wxprec.h) and the FSO makefiles (i.e. autogen.sh, configure.ac, Makefile.am) are a little over my head, so I couldn't fix it. (On that note, wouldn't it be easier to have separate makefiles for wxFRED?)
Now, what does it do? Nothing. When run, it's just an empty frame. I might have thrown out some functionality with the weird XML stuff, I'm aware of that. But at least it compiles and runs now, so that's an improvement.
[attachment deleted by a ninja]
-
Done with my moderately successful wxWidgets cleaning tool, I tried to build wxFRED on MSVC10. It didn't work. Compile-time errors, run-time errors, you name it. So I fixed it. Diff attached.
As far as I know, simply getting wxFRED to compile and run is farther than anyone else has gotten in the recent past, so well done. I'll need to take a closer look at your attached diff later. By the way, if you could attach .diff files as uncompressed files, rather than in a .zip archive, that would be appreciated.
Warning: it has taken a blunt axe and a bulldozer to fix it.
I suppose you have to start with getting something working and then build up from there. :)
- Upgraded the project file from wx 2.8 to 2.9, since 2.8 doesn't work on MSVC10. Theoretically it should still compile under 2.8 as well, you'll only have to change the linked libraries in the project file.
Hmm, odd that 2.8 doesn't work on MSVC 2010. I've used 2.8.12 with VS2008 Professional, but I've never tried VS2010.
- Upgraded to Unicode. wxWidgets is planning on dropping ASCII support in the near future (http://docs.wxwidgets.org/trunk/overview_unicode.html#overview_unicode_supportin), and with wx 2.9 Unicode is much more convenient already.
Yeah, upgrading to Unicode is a good move.
- Removed non-existing voicefilemanager files from the project
- Added ../../code to the include directories
Yup, these are changes I also had to make to get it to compile, although I couldn't get it to link. This was the VS2005 project running in VS2008.
- Removed non-functioning XML stuff from the project
The XML file is an XRC file (http://docs.wxwidgets.org/trunk/overview_xrc.html), an XML-based specification of wxFRED's GUI widgets (dialogs, buttons, etc) and their layout. It's analogous to MSVC's RC files for Windows GUI applications.
And possibly some more which I forgot already. Oh, and I only fixed Debug configuration - haven't touched Release (yet). And I haven't been able to test my changes in Linux, something's wrong with the linked wx libraries there (couldn't find wx/wxprec.h) and the FSO makefiles (i.e. autogen.sh, configure.ac, Makefile.am) are a little over my head, so I couldn't fix it. (On that note, wouldn't it be easier to have separate makefiles for wxFRED?)
I'd think that since wxFRED, like FRED 2 Open, is intimately tied with the FSO codebase, since they all use the mission data structures, separate autotools configuration scripts for wxFRED wouldn't be possible, but that's just a guess.
Now, what does it do? Nothing. When run, it's just an empty frame. I might have thrown out some functionality with the weird XML stuff, I'm aware of that. But at least it compiles and runs now, so that's an improvement.
The reason it's an empty frame is that it's missing the XRC file, as mentioned above. That said, a working project with an empty frame is indeed a better starting point than a non-working project with an XRC file. ;)
One thing that will certainly help if you haven't done it yet is to build wxrc, which IIRC compiles the XRC file to a binary format that wxFRED can use. wxrc is in a separate MSVC project within the wxWidgets source tree. in 2.8.12, the wxrc project is in wxWidgets-2.8.12\utils\wxrc .
Thanks for looking into this.
-
- Upgraded the project file from wx 2.8 to 2.9, since 2.8 doesn't work on MSVC10. Theoretically it should still compile under 2.8 as well, you'll only have to change the linked libraries in the project file.
Hmm, odd that 2.8 doesn't work on MSVC 2010. I've used 2.8.12 with VS2008 Professional, but I've never tried VS2010.
wxWidgets 2.8 and VS2010 is how I build wxLauncher and it works just fine (2.8.10 and 2.8.11, haven't tried 2.8.12). The bit about not being able to build wxLauncher with VS2010 has to do with CMake not generating the correct solution.
And possibly some more which I forgot already. Oh, and I only fixed Debug configuration - haven't touched Release (yet). And I haven't been able to test my changes in Linux, something's wrong with the linked wx libraries there (couldn't find wx/wxprec.h) and the FSO makefiles (i.e. autogen.sh, configure.ac, Makefile.am) are a little over my head, so I couldn't fix it. (On that note, wouldn't it be easier to have separate makefiles for wxFRED?)
I'd think that since wxFRED, like FRED 2 Open, is intimately tied with the FSO codebase, since they all use the mission data structures, separate autotools configuration scripts for wxFRED wouldn't be possible, but that's just a guess.
It would be possible but it doesn't make any sense separating the build scripts becuase of the common dependency on code.lib.
-
So I fixed it.
Now that' some attitude :D
-
Hmm. On the plus side, I got the XRC menu bar to show up. The menu bar and most of the dialogs have already been constructed (good work Goober?), as pretty much one-on-one copies of the original FRED. A wxformbuilder (http://sourceforge.net/apps/wordpress/wxformbuilder/) project file is also included.
On the downside, most of the dialog boxes are broken, and even the latest version of wxformbuilder doesn't appear to be doing anything about it. It might be wx2.9 being more correct on the form buildup, I guess - the XRC files produced by formbuilder have some very fishy sections (mainly number of rows x columns not matching number of cell entries).
As for 2.8 on VC10, the project files won't convert properly for me, so can't build it. Zacam linked me to wxPack (http://wxpack.sourceforge.net/), which is supposed to work, but I'd rather stick to official releases if possible...
-
Taylor constructed a large number of the XRC dialogs, so credit should go to him as well.
-
Hmm. On the plus side, I got the XRC menu bar to show up. The menu bar and most of the dialogs have already been constructed (good work Goober?), as pretty much one-on-one copies of the original FRED. A wxformbuilder (http://sourceforge.net/apps/wordpress/wxformbuilder/) project file is also included.
Well done on getting it working.
On the downside, most of the dialog boxes are broken, and even the latest version of wxformbuilder doesn't appear to be doing anything about it. It might be wx2.9 being more correct on the form buildup, I guess - the XRC files produced by formbuilder have some very fishy sections (mainly number of rows x columns not matching number of cell entries).
What do you mean by broken?
If wxFormBuilder is producing invalid XRC files, that's... kind of a problem. I'd certainly hope that newer versions of wxWidgets aren't breaking compatibility with older XRC files. I've done XML editing by hand (DocBook (http://docbook.org/) to be precise) and wouldn't necessarily be averse to manually editing the XRC file if necessary, even if it wouldn't be my first choice. Too bad the wxWidgets Team doesn't publish an XML schema of the XRC format, which could be used to validate XRC files in conjunction with XML editors. I mean, in theory it could be reverse engineered from the published XRC examples and the wxrc source, but that would be messy and not fun, not to mention it'd need to be updated any time they change the format. :sigh:
As for 2.8 on VC10, the project files won't convert properly for me, so can't build it. Zacam linked me to wxPack (http://wxpack.sourceforge.net/), which is supposed to work, but I'd rather stick to official releases if possible...
Yeah, my inclination would also be to stick to official releases. At least official releases are backed by the wxWidgets Team, even if there are known issues that go for years without being fixed. With a third-party bundle, though, you're at the mercy of whoever maintains it. In the case of wxPack, it's kind of disconcerting that it hasn't been updated in a year and a half, and the documentation and packaging are highly Windows-centric. :doubt:
-
Taylor and I both used DialogBlocks to edit the XRC. It unfortunately requires a registration fee. (I think at one point I may have offered to cover the registration fee for any SCP member who wants to use it, so I'll keep that offer open.)
-
Trying to support both 2.8 and 2.9 seems like a disaster just waiting to happen.
-
any chance throwing in some scripting support? would be useful for creating plugins for fred, and automating some repetitive operations.
-
What do you mean by broken?
The rows x columns thing produces runtime errors... It can be fixed in wxformbuilder, but it needs to be done manually. I did it for the asteroids editor, but something else in the hierarchy (probably a missing wxFlexGridSizer or something) is now causing several panes to show up on top of each other. It's looking just fine in wxformbuilder, but when compiled it's a mess.
If wxFormBuilder is producing invalid XRC files, that's... kind of a problem. I'd certainly hope that newer versions of wxWidgets aren't breaking compatibility with older XRC files. I've done XML editing by hand (DocBook (http://docbook.org/) to be precise) and wouldn't necessarily be averse to manually editing the XRC file if necessary, even if it wouldn't be my first choice. Too bad the wxWidgets Team doesn't publish an XML schema of the XRC format, which could be used to validate XRC files in conjunction with XML editors. I mean, in theory it could be reverse engineered from the published XRC examples and the wxrc source, but that would be messy and not fun, not to mention it'd need to be updated any time they change the format. :sigh:
It's probably all fixable in wxformbuilder, don't think we really need an other program for it (like DialogBlocks). It will only require some care - someone needs to go through the dialogs after compilation and fix everything that needs repairing.
Trying to support both 2.8 and 2.9 seems like a disaster just waiting to happen.
Bah, I did that for the cleaning thing I wrote... The issues I ran into is that for 2.8 compatibility, you need the wxT() or _T() macros around each literal (2.9 doesn't need those anymore), and the command-line description uses a different string encoding (which I solved with a simple version number check, #if (wxMAJOR_VERSION >= 3 || (wxMAJOR_VERSION == 2 && wxMINOR_VERSION == 9)) ).
But in the long run, you're right, we'd probably better switch over to 3.0 and stick with it for a while, I guess.
any chance throwing in some scripting support? would be useful for creating plugins for fred, and automating some repetitive operations.
I'd been thinking about a built-in text editor with copy+paste, that should help some with the repetitive stuff... Scripting, ehh, we'll see.
Attached diff makes the XRC menus work, so you can check out the dialogs. I also fixed Release configuration (the Inferno configurations I haven't touched yet). Sorry I had to zip it up, it's too big otherwise.
[attachment deleted by ninja]
-
What do you mean by broken?
The rows x columns thing produces runtime errors... It can be fixed in wxformbuilder, but it needs to be done manually. I did it for the asteroids editor, but something else in the hierarchy (probably a missing wxFlexGridSizer or something) is now causing several panes to show up on top of each other. It's looking just fine in wxformbuilder, but when compiled it's a mess.
*snip*
It's probably all fixable in wxformbuilder, don't think we really need an other program for it (like DialogBlocks). It will only require some care - someone needs to go through the dialogs after compilation and fix everything that needs repairing.
Even if it's fixable in wxFormBuilder, it sounds like a pain to do, not to mention error-prone. Besides, if Goober's willing to pay for a registered copy of DialogBlocks... :nod: And since I'm a student, you can get it for ~50% off (http://www.dialogblocks.com/buy.htm).
Trying to support both 2.8 and 2.9 seems like a disaster just waiting to happen.
Bah, I did that for the cleaning thing I wrote... The issues I ran into is that for 2.8 compatibility, you need the wxT() or _T() macros around each literal (2.9 doesn't need those anymore), and the command-line description uses a different string encoding (which I solved with a simple version number check, #if (wxMAJOR_VERSION >= 3 || (wxMAJOR_VERSION == 2 && wxMINOR_VERSION == 9)) ).
But in the long run, you're right, we'd probably better switch over to 3.0 and stick with it for a while, I guess.
I agree that trying to support multiple versions of wxWidgets is not a good idea. I'd be inclined to move past 2.8, although that'd make releasing on Linux more complicated, since then people couldn't use the 2.8 packages that are available in many distros' repos.
any chance throwing in some scripting support? would be useful for creating plugins for fred, and automating some repetitive operations.
I'd been thinking about a built-in text editor with copy+paste, that should help some with the repetitive stuff... Scripting, ehh, we'll see.
It's too early at this point to know what new features might be added to wxFRED. I'd say that scripting support isn't necessarily out of the question.
Attached diff makes the XRC menus work, so you can check out the dialogs. I also fixed Release configuration (the Inferno configurations I haven't touched yet). Sorry I had to zip it up, it's too big otherwise.
Okay, thanks. I'll need some time before I can look at it, although it'd likely need to pass muster with Goober before it or some form of it could be committed.
Thanks again for working on this.
-
Since one of the points of using wxWidgets is to remain compatible across multiple platforms, I'd be in favor of using the older, more commonly supported versions.
-
Hmm, fair enough. I suppose we could start with using 2.8, and then if there's a feature or bug fix in 2.9+ that we must have, then we can consider whether to switch.
-
Though, by the time that wxFRED is actually available for general use, 2.8 will not be the "common" version. So I don't know if going with the older currently well supported 2.8 really makes that much more sense.
-
If it's "currently" well supported, then that's what we should "currently" design to. Then we can cross the upgrade bridge when we come to it.
-
I'm inclined to agree with Iss. Even under the best of circumstances, wxFRED would not be ready for release until many months from now. Targeting what's currently well supported when there won't be anything releaseable any time soon doesn't make much sense to me. Furthermore, from what I've seen of 2.9, upgrading code written for 2.8 would take a non-trivial amount of work (and I might be understating that), although I don't know the details offhand.
Besides, my first steps on this project don't even involve coding but rather understanding how to use FRED and how FRED works, internally and externally, with internally meaning how FRED's state changes in response to FREDder actions, as well as how FRED implements some of the more complex GUI widgets like the 3-D grid. (That also means I wouldn't need a registered copy of DialogBlocks for a while. [Although the price can always go up... ;7])
-
I'm inclined to agree with Iss. Even under the best of circumstances, wxFRED would not be ready for release until many months from now. Targeting what's currently well supported when there won't be anything releaseable any time soon doesn't make much sense to me.
This touches on the usability factor that we discussed in the internal thread. :p We need to target what's well-supported because we want wxFRED to be accessible to a wide population. We don't want to target the cutting edge because few people will be there with us.
This will remain true even taking into consideration the months until the wxFRED release. Only a small percentage of the wxFRED userbase will upgrade their systems or otherwise be able to take advantage of the latest and greatest.
WxFRED's goals are different from a commercial game's goals or a media pack's goals. We are not concerned about having the latest and greatest. We are concerned about being available to, and usable by, a large number of platforms.
-
This touches on the usability factor that we discussed in the internal thread. :p We need to target what's well-supported because we want wxFRED to be accessible to a wide population. We don't want to target the cutting edge because few people will be there with us.
This will remain true even taking into consideration the months until the wxFRED release. Only a small percentage of the wxFRED userbase will upgrade their systems or otherwise be able to take advantage of the latest and greatest.
WxFRED's goals are different from a commercial game's goals or a media pack's goals. We are not concerned about having the latest and greatest. We are concerned about being available to, and usable by, a large number of platforms.
Just to make sure we're all clear on what's under discussion, the only users who are affected by the decision of which version of wxWidgets to use are those who depend on third-party builds of the wxWidgets libraries, namely Linux users using the pre-compiled wxWidgets packages in their distros' repositories. Windows and Mac users are unaffected, since the wxFRED team would always include their own build of the wxWidgets libraries with the downloads for those platforms (assuming that the wxFRED build system would be similar to wxL's).
I'd be interested in hearing from Linux users, especially SCP coders using Linux, on whether having to build wxWidgets from source to use wxFRED would be reasonable. Having to build libraries from source yourself is certainly not unheard of on Linux, even if it might be unusual. The issue might be too off-topic for this thread, however. Also note that wxWidgets 2.8 binary packages are not necessarily available in every distro's repo, so there may be Linux users who will have to build wxWidgets from source no matter what.
In any case, as I mentioned just above your post, "my first steps on this project don't even involve coding but rather understanding how to use FRED and how FRED works." After I get a better understanding of FRED and consequently of the needs of the project, I'll be in a better position to say whether wxFRED needs 2.9+, and if so, why.
-
The way I originally set up the wxFRED project in 2004, and the way I think is best to distribute it, is as a static library embedded in the executable. In other words, there wouldn't be a separate DLL or library; the wxFRED executable itself would contain all the necessary wxWidgets dependencies.
-
If static linking were used for wxFRED on all platforms, as you seem to be recommending, then the usability concern that you raised before would disappear, no?
-
There would only be a usability issue for those Linux users who want to build their own binaries, I guess - and they are smart enough to get the correct version of wxWidgets, too. I'm all for static linking - FSO's dynamic linking with OpenAL is enough of a tech support issue as it is.
Have there been thoughts about the wxFRED backend yet? Re-use the "giant unwieldy" :v:-FRED code as much as possible, or take the opportunity to make it more object-oriented?
-
as far as i see this stuff, anyone savvy enough to compile by himself under linux, can handle compiling an additional lib/installing a dev-package of said lib.
also, wxwidgets does not conflict with FSO's license i take it?
-
I'd be interested in hearing from Linux users, especially SCP coders using Linux, on whether having to build wxWidgets from source to use wxFRED would be reasonable. Having to build libraries from source yourself is certainly not unheard of on Linux, even if it might be unusual. The issue might be too off-topic for this thread, however. Also note that wxWidgets 2.8 binary packages are not necessarily available in every distro's repo, so there may be Linux users who will have to build wxWidgets from source no matter what.
Building from source can range from slightly irritating (i.e. the OS no longer deals with updates for you) to extremely painful (when you trigger a cascade of dependencies (http://en.wikipedia.org/wiki/Dependency_hell) that also need to be built from source). From my playing tonight, wxWidgets 2.9 is probably towards the OK end - while my 10.04 system doesn't have gtk2.4 that wxWidgets requires, my 11.10 VM has gtk3.2 (not supported yet) and gtk2.24 (which let a configure complete OK)
Of course, if you distribute a statically linked wxFred binary then this is all moot anyway.
-
Might it perhaps be a good idea to reevaluate if WX is the framework to be had? Qt4 appears to be at leats on par with WX nowadays, and more importantly its development and UI layout tools are readily available.
-
Might it perhaps be a good idea to reevaluate if WX is the framework to be had? Qt4 appears to be at leats on par with WX nowadays, and more importantly its development and UI layout tools are readily available.
WX is what SCP has experience with, it is what wxLauncher is done with, which are now our primary reasons to use wxWidgets. (Personally, I like the look and feel of wxWidgets apps better than qt ones as well).
Qt4 at the time the original decision was made had a license that conflicted with FSO's which would require that QT be distributed separately like OpenAL. That is it would not allow for static linking against FRED because of our license.
also, wxwidgets does not conflict with FSO's license i take it?
No. wxWidgets has an exception in its license that allows it to be staticly linked with code that is under any license, propriety, odd ball (FSO), or otherwise.
Have there been thoughts about the wxFRED backend yet? Re-use the "giant unwieldy" :v:-FRED code as much as possible, or take the opportunity to make it more object-oriented?
Yes, SCP has discussed it on internal. I will not elaborate beyond stating SCP is discussing the merits of both approaches. There is a general leaning to "cleaning it up", though what exactly will entail is still up for debate.
-
IF SCP leans towards rewriting wxFred to use non-FRED code. Would they attempt to structure wxFred to support other game engines other than FreeSpace2? VegaStrike could benefit massively from a 3D game level editor and I have been investigating a similar effort to writing a Fred2 knockoff for crossplatform use.
-
IF SCP leans towards rewriting wxFred to use non-FRED code. Would they attempt to structure wxFred to support other game engines other than FreeSpace2?
There is a huge leap in complexity between these two concepts. So probably not.
-
Not to mention that VegaStrike almost certainly doesn't use sexps or use the same mission file format. So you'd basically have an editor where you could place things and name them and then save them in the wrong format.
-
Actually I am looking to implement a SEXP style scripting system into vegastrike. Massaging the output of FRED2 to match what Vegastrike expects isn't the hardest thing to do from what I know of both engines. I'm more curious at this stage about where wxFred is at, and whether I should bother using it or just blatantly ripoff the FRED UI and make my own program.
-
Massaging the output of FRED2 to match what Vegastrike expects isn't the hardest thing to do from what I know of both engines.
Actually, speaking as someone who semi-recently went all over the mission-saving code, altering the output format of FRED2 is a very involved process (unless you want to do something relatively trivial, like swapping two sections, or changing a label).