Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: z64555 on March 11, 2013, 01:21:02 am
-
wxFRED2 WIP builds (Windows)
wxFRED2d_13-3-10.exe (http://dl.dropbox.com/u/97612992/FreeSpace2%20Open/SCP/wxFRED/wxFRED2d.exe) - Debug build, requires MSVC debug libraries
wxFRED2r_13-3-26.exe (http://dl.dropbox.com/u/97612992/FreeSpace2%20Open/SCP/wxFRED/wxFRED2r.exe) - Release build
wxFRED2 patch file (vs. r9565)
wxFRED2d_13-3-23.patch (http://dl.dropbox.com/u/97612992/FreeSpace2%20Open/SCP/wxFRED/wxFRED_13-3-15b.patch)
(Scroll down for pic's)
Well, it's been about 2 months since I started on the wxFRED project, and I thought it might be a good idea to say something about it.
First off, some good news: I've managed to get most of the editors (down to Mission Specs Editor, starting from the top of the Editors menu list) graphics implemented. Bad news? well...
Today, I did an OS theme switch to test whether or not wxFRED would match the color theme of the OS (it does by default). However, when I was doing this I had wxFormBuilder still open. There was no indication that anything was wrong until I tried to save my changes, at which point it decided to crash.
No big deal, right? Kinda is. wxFormBuilder crashed while it was doing the save, thereby nuking the project file completely and trashing whatever saves I had made, along with all progress I had made up until that point. Clumsy me, thinking that such a thing would never happen, did not think it was pertinent to make backups, so I'm basically back to where I started as far as the project file goes...
The silver lining, however, is that I still have a copy of the C++ code that was generated by wxFormBuilder, and I can still compile it in MSVC and get wxFRED to run and show up. It's just that I'll have to completely redo the project file before I can make any more progress.
Attached:
Notable changes:
I've switched from using the generated XRC files to generated C++ files (wxFRED_base.cpp and wxFRED_base.h). This should allow coders to create their own versions of the wxFRED windows and dialogs by using class inheritance and OOP techniques. This should come in handy whenever a custom or less common widget is needed, such as a floating point spin control (spin controls are usually only integers) and a listbox tool on the FRED toolbar (the new ship type selection).
Windows, frames, and dialogs are named accordingly, so a dlgSomeEditor is expected to be something that has at least an OK button while a frmSomeFrame is something that has more oomph, same thing basically goes for all of the controls, such as btnOK, chkSomeFlag, etc.
All windows and editors are currently restricted to an initial size max of 800x600. It is expected that a number of frames and dialogs will be re-sizable, especially those with multi-line text boxes, such as the Mission Specs editor.
I currently have it setup so that child windows are referenced by their parent windows by way of pointers. The child windows themselves are instanced in heap memory, and should technically be able to run alongside other windows, such as highlighting waypoints in the main FRED window when you're using an editor on them, or real-time updating the position and orientation of selected object(s) from the Object Position/Orientation editor. Oh, and it should allow for better memory management in the future.
The home screen of wxFRED as designed in wxFormBuilder (note lack of the ship listbox):
(http://dl.dropbox.com/u/97612992/FreeSpace2%20Open/SCP/wxFRED/wxFRED_001.gif)
The home screen of wxFRED, as seen on the first .exe:
(http://dl.dropbox.com/u/97612992/FreeSpace2%20Open/SCP/wxFRED/wxFRED_003.gif)
Ship Editor:
(http://dl.dropbox.com/u/97612992/FreeSpace2%20Open/SCP/wxFRED/wxFRED_004.gif)
Background Editor:
(http://dl.dropbox.com/u/97612992/FreeSpace2%20Open/SCP/wxFRED/wxFRED_005c.gif)
Asteroid Field Editor:
(http://dl.dropbox.com/u/97612992/FreeSpace2%20Open/SCP/wxFRED/wxFRED_006.gif)
Mission Specs Editor:
(http://dl.dropbox.com/u/97612992/FreeSpace2%20Open/SCP/wxFRED/wxFRED_007.gif)
Mission Specs Editor's Sound Environment child dialog (is also the progress photo just before the crash):
(http://dl.dropbox.com/u/97612992/FreeSpace2%20Open/SCP/wxFRED/wxFRED_007b.gif)
-
Looking good! Sounds like you should get an SVN or Git repo, though.
-
Looks good to me too.
-
Alright, now it just needs a back end :D Pity about the project files though... Is there no way to regenerate them from the source or something?
I'll test the patch on Ubuntu as soon as I can find the time.
Looking good! Sounds like you should get an SVN or Git repo, though.
wxFRED is on the FSO SVN... Not sure if it would be sensible to split the two, given that some of the code will likely be shared (I think?)
-
Unfortunately, I was never able to compile wxFRED2. Not back when it was started and not now with the patch.
make always says:
make[1]: Entering directory `/home/maniac/Desktop/sources/fs2_open/code'
CXX wxfred2.o
wxfred2/wxfred2.cpp:7:23: fatal error: wx/wxprec.h: No such file or directory
compilation terminated.
make[1]: *** [wxfred2.o] Error 1
make[1]: Leaving directory `/home/maniac/Desktop/sources/fs2_open/code'
make: *** [all-recursive] Error 1I also tried to symlink the files in question into the fs2-source. Worked for a few of them but not everytime.
Other wxWidgets-projects compile fine, though...
-
Alright, now it just needs a back end :D Pity about the project files though... Is there no way to regenerate them from the source or something?
Most of the RAD tools & WYSIWYG editors for wxWidgets that I've heard about feature the ability to generate a project file from a .XRC, which is a filetype integral to the wxWidgets libraries. In addition to generating C++ files, I'll set up the new project file so that wxFormBuilder will also generate an .XRC, so that when a better designer is found we can switch over to it. :D
Looking good! Sounds like you should get an SVN or Git repo, though.
wxFRED is on the FSO SVN... Not sure if it would be sensible to split the two, given that some of the code will likely be shared (I think?)
Yes, wxFRED2 is on the FSO SVN, as is the original FRED code. I believe the intention concerning the SVN is to get wxFRED working before making any official commits... While this does prevent any potential "fruitless" commits from the wxFRED project, it does hinder development by other members a bit.
Unfortunately, I was never able to compile wxFRED2. Not back when it was started and not now with the patch.
make always says:
make[1]: Entering directory `/home/maniac/Desktop/sources/fs2_open/code'
CXX wxfred2.o
wxfred2/wxfred2.cpp:7:23: fatal error: wx/wxprec.h: No such file or directory
compilation terminated.
make[1]: *** [wxfred2.o] Error 1
make[1]: Leaving directory `/home/maniac/Desktop/sources/fs2_open/code'
make: *** [all-recursive] Error 1I also tried to symlink the files in question into the fs2-source. Worked for a few of them but not everytime.
Other wxWidgets-projects compile fine, though...
That has to do with the precompiled headers, MSVC's compiler isn't bother by the fact that they're not really needed, but apparently make is bothered. Try using the attached patch on wxfred2.cpp to see if it helps...
[attachment deleted by a basterd]
-
Thanks for the patch but somehow my system doesn't like wxFRED2 (?), because now it won't even find wx.h...
A few days/weeks ago I tried many things: Cusomizing the C(XX)FLAGS, LDFLAGS and whatnot, copying the header-files into the code-directorys of fso, but nothing really helped. There were always header-files it didn't find.
wxLauncher, on the other side, compiles fine and I couldn't find any major differences in the way CFLAGS were set or the header-files were included... Strange...
Maybe I'll experiment a bit more.
As for SVN, can't you get a wxFRED2-branch in the FSO-Repository?
EDIT
Okay, the patch worked. It didn't find the wx.h because the path was written with a backslash in other files (<wx\wx.h>). Now it fails with this
In file included from wxfred2/frmFRED2.h:36:0,
from wxfred2/wxfred2.cpp:22:
wxfred2/frmTeamLoadoutEditor.h:30:8: warning: extra tokens at end of #endif directive [enabled by default]
wxfred2/wxfred2.cpp:37:2: warning: identifier 'nullptr' is a keyword in C++11 [-Wc++0x-compat]
wxfred2/wxfred2.cpp: In member function 'virtual bool wxFRED2::OnInit()':
wxfred2/wxfred2.cpp:37:18: error: 'nullptr' was not declared in this scope
make[1]: *** [wxfred2.o] Error 1
make[1]: Leaving directory `/home/maniac/Desktop/sources/fs2_open/code'
make: *** [all-recursive] Error 1Maybe the -Wc++0x-compat CFLAG alredy will fix this, but for now I won't try it.
-
Which IDE or toolset are you using? Currently I have a MSVC 2010 project that I'm working on, but I can also make a code::blocks project file.
It'll ultimately be committed to trunk, but for now I'll be making forum posts with attached .diff's or .patch's. As soon as I can grab a copy of Git, I'll have it setup so that I can make a local repo and not worry about manual backups.
Edit: Ok, yeah. The -Wc++0x-compat flag should work. MSVC 2010 snuck in a few keywords and other goodies from the C++10 language spec while the ISO folk were finalizing things.
-
Yes, wxFRED2 is on the FSO SVN, as is the original FRED code. I believe the intention concerning the SVN is to get wxFRED working before making any official commits... While this does prevent any potential "fruitless" commits from the wxFRED project, it does hinder development by other members a bit.
Whose intention is this? I don't think there would be a problem if you committed your changes. WxFRED isn't subject to the FSO code freeze.
-
Which IDE or toolset are you using? Currently I have a MSVC 2010 project that I'm working on, but I can also make a code::blocks project file.
No IDE at all ;)
Under Linux, I only update the code (svn trunk), configure and make.
Under Windows I download the binaries. But most time I play FS2 in Linux.
-
Yes, wxFRED2 is on the FSO SVN, as is the original FRED code. I believe the intention concerning the SVN is to get wxFRED working before making any official commits... While this does prevent any potential "fruitless" commits from the wxFRED project, it does hinder development by other members a bit.
Whose intention is this? I don't think there would be a problem if you committed your changes. WxFRED isn't subject to the FSO code freeze.
I honestly don't know whose intention it was, it might've been some hair-brained idea I came up while I was half asleep (not particularly healthy).
(Also kinda difficult to commit to the SVN since I don't have commit rights...)
-
(Also kinda difficult to commit to the SVN since I don't have commit rights...)
Ah. Well let me see about changing that.
-
It didn't find the wx.h because the path was written with a backslash in other files (<wx\wx.h>).
Ugh, yeah, it seems all the generated headers and CPP files are using Windows-style backslashes :ick:
-
No IDE at all ;)
Under Linux, I only update the code (svn trunk), configure and make.
Under Windows I download the binaries. But most time I play FS2 in Linux.
u hardcore programma. :yes:
It didn't find the wx.h because the path was written with a backslash in other files (<wx\wx.h>).
Ugh, yeah, it seems all the generated headers and CPP files are using Windows-style backslashes :ick:
Those, are... actually not the generated files. :nervous:
New patch attached to OP and this post, built against SVN r9565. This should correct the filepath backslash issue, in addition to setting up the wxFRED2.vcxproj to something useable, and omitting the precompiled header #include from wxfred2.cpp (since it's the only file that actually uses it, and I don't see a point in doing precompiled headers at this time).
wxFRED_13-3-15.patch (http://dl.dropbox.com/u/97612992/FreeSpace2%20Open/SCP/wxFRED/wxFRED_13-3-15.patch)
-
Seems wxFRED_base.h is missing from the new patch? :P
-
:|
New patch uploaded!
wxFRED_13-3-15b.patch (http://dl.dropbox.com/u/97612992/FreeSpace2%20Open/SCP/wxFRED/wxFRED_13-3-15b.patch)
-
Hmm, still no dice. There's another backslash include in frmFRED2.cpp:25. But after fixing that, g++ fails to locate the #includes from wxFRED_base.h. All of them: if I comment one out, it simply fails on the next one.
Now, I know that my WX is set up correctly, as I can compile PCS2 with no problem. Also, WX is just a package download, it's hard to mess that up. So I don't think that's the cause here.
Something that might be related: on running FSO's configure script, I get the following warning:
No config found to match: /usr/bin/wx-config --static --libs
in /usr/lib/x86_64-linux-gnu/wx/config
This, presumably, because the static WX libs are not in the Ubuntu repos (http://ubuntuforums.org/showthread.php?t=937810&p=5907768#post5907768). And I'm guessing wxFRED is currently set up for static linking? I'm not familiar enough with Makefile to see for myself :nervous:
Either way, given how ridiculously easy compilation is on Linux (as well as the binary incompatibility of distros), I'd say we can push compile-it-yourself as the primary way of obtaining wxFRED on Linux - which probably most users will be doing anyway. And then dynamic linking seems the best option, as it won't require people to manually download and compile the static WX libs.
-
Sounds like you should get an SVN or Git repo, though.
Indeed z64555, I'd very much recommend firing up a local Git repo on your own machine.
It only requires a copy of Git, and the entire history data simply sits in a subfolder of the source tree, easy to exclude from SVN.
Then you can locally track changes, branch, revert etc and when you have something you consider Worthy, commit it to the 'real' SVN.
- I do this at work, because one of my projects is still on Visual SourceSafe (run for the hills) and thus essentially useless, and for the others it gives me somewhere to work on 'proof-of-concept' (and unofficial) tasks quite easily without cluttering up the 'real' repo with branches that will never go anywhere.
-
Hmm, still no dice. There's another backslash include in frmFRED2.cpp:25. But after fixing that, g++ fails to locate the #includes from wxFRED_base.h. All of them: if I comment one out, it simply fails on the next one.
Hey, that's exactly what happens for me, too! :lol:
Well, I copied the include-statements from the WX_CFLAGS to any other CFLAGS and CXXFLAGS (CFLAGS and FS2_CFLAGS in Makefile and code/Makefile) and then it worked... Almost...
Now I had to paste -std=c++11 into the CXXFLAGS, FS2_CXXFLAGS and WX_CXXFLAGS and NOW there are stray-characters in wxFRED_base.h in line 1538. Seems to be some invisible characters at linefeed...
AND (it just won't stop ;) ) ONLY wxfred2.cpp should be compiled with -std=c++11 because otherwise, fsmemory.cpp fails to compile!
And if I managed all that, linking fails with a very long list of "undefined references". Oh man, I need more C++, configure and make knowledge...
But I wonder: Are the WX_*-flags used at all? It seems only the standard- and FS2_*-flags are used. Okay... Maybe I will experiment a bit more later on.
But anyway: Good work! Just concentrate on getting it working like it should in your environment and then we/you/someone can port it to other building-environments.
-
Hmm, still no dice. There's another backslash include in frmFRED2.cpp:25. But after fixing that, g++ fails to locate the #includes from wxFRED_base.h. All of them: if I comment one out, it simply fails on the next one.
Those are all referenced via <someFile.h> instead of the local reference "someFile.h", there should be some way of adding the WX include paths to something like WX/include/msvc; WX/include/;. If you have a compiler specific folder (such as MSVC does), reference your compiler to that directory first.
Something that might be related: on running FSO's configure script, I get the following warning:
No config found to match: /usr/bin/wx-config --static --libs
in /usr/lib/x86_64-linux-gnu/wx/config
This, presumably, because the static WX libs are not in the Ubuntu repos (http://ubuntuforums.org/showthread.php?t=937810&p=5907768#post5907768). And I'm guessing wxFRED is currently set up for static linking? I'm not familiar enough with Makefile to see for myself :nervous:
Yes, wxFRED is currently set up for static linking, since I was having problems with the dynamic linking not getting setup quite right. I also didn't know if Linux builds would properly run a .dll or not, so I scheduled tackling that whole problem for a later date.
Either way, given how ridiculously easy compilation is on Linux (as well as the binary incompatibility of distros), I'd say we can push compile-it-yourself as the primary way of obtaining wxFRED on Linux - which probably most users will be doing anyway. And then dynamic linking seems the best option, as it won't require people to manually download and compile the static WX libs.
Since the wxFRED project is already setup, all the MSVC developers have to do is batch build the Unicode and Unicode Debug wxWidgets libs (and also make the WXWIN environment variable). I'll definitely have to get in contact with people that have the other compilers and IDE's.
Well, I copied the include-statements from the WX_CFLAGS to any other CFLAGS and CXXFLAGS (CFLAGS and FS2_CFLAGS in Makefile and code/Makefile) and then it worked... Almost...
Now I had to paste -std=c++11 into the CXXFLAGS, FS2_CXXFLAGS and WX_CXXFLAGS and NOW there are stray-characters in wxFRED_base.h in line 1538. Seems to be some invisible characters at linefeed...
Quite likely that the line endings got garbled, try opening up wxFRED_base.h in something like Notepad++ and see if you can convert or otherwise clean the line endings.
ONLY wxfred2.cpp should be compiled with -std=c++11 because otherwise, fsmemory.cpp fails to compile!
And if I managed all that, linking fails with a very long list of "undefined references". Oh man, I need more C++, configure and make knowledge...
But I wonder: Are the WX_*-flags used at all? It seems only the standard- and FS2_*-flags are used. Okay... Maybe I will experiment a bit more later on.
Hmm, you may want to attach your makefile so we can see what's going on.
Thanks for the feedback guys, I should have some more progress with it on Monday and Tuesday, (my days off from work).
-
Hmm, still no dice. There's another backslash include in frmFRED2.cpp:25. But after fixing that, g++ fails to locate the #includes from wxFRED_base.h. All of them: if I comment one out, it simply fails on the next one.
Hey, that's exactly what happens for me, too! :lol:
Well, I copied the include-statements from the WX_CFLAGS to any other CFLAGS and CXXFLAGS (CFLAGS and FS2_CFLAGS in Makefile and code/Makefile) and then it worked... Almost...
Small heads up on this one: I got it fixed by changing configure.ac:211 from
FS2_CXXFLAGS="$FS2_CXXFLAGS $WX_CXXFLAGS_ONLY"
to
FS2_CXXFLAGS="$FS2_CXXFLAGS $WX_CXXFLAGS"
Warning: this is based on hacking and experimentation, and may not be the preferred solution.
Yes, wxFRED is currently set up for static linking, since I was having problems with the dynamic linking not getting setup quite right. I also didn't know if Linux builds would properly run a .dll or not, so I scheduled tackling that whole problem for a later date.
I'm not 100% certain, but it looks like the Makefile is set up for dynamic linking with the WX libs. As it should be :)
BTW, .dll are Windows-only binaries, *nix has a different format for shared objects.
EDIT: Oh, and frmTeamLoadoutEditor.h is missing a comment sign on the last line.
EDIT2:
ONLY wxfred2.cpp should be compiled with -std=c++11 because otherwise, fsmemory.cpp fails to compile!
Hmm, how exactly did you do that? I edited -std=c++11 into code/Makefile manually for wxfred2.cpp, and am seeing it on the command line when I run make (like it should), yet still I get 'nullptr not declared in this scope'. g++ 4.7.2.
-
Hmm, how exactly did you do that? I edited -std=c++11 into code/Makefile manually for wxfred2.cpp, and am seeing it on the command line when I run make (like it should), yet still I get 'nullptr not declared in this scope'. g++ 4.7.2.
I simply compiled everything without -std=c++11 until make failed. Then I added the flag and ran make again ;)
-
I simply compiled everything without -std=c++11 until make failed. Then I added the flag and ran make again ;)
Hmm, I'm not an expert in the matter, but I wouldn't be surprised if that, ah, 'unconventional' setup might be related to your very long list of undefined references :P
Is FSO written for a specific C++ standard (e.g. C++11)? Adding compiler flags on a file-by-file basis is gonna get very messy very quickly...
-
I had a brief chat about this on IRC with z64555 a few days back, IIRC the only C++11 code is the use of the nullptr keyword and he was going to remove that, so maybe don't expend much effort on trying to get it working on Linux until he makes and posts those changes :)
-
Made the changes wxfred2.cpp and frmFRED2.cpp to include <globalincs/pstypes.h> and replace the nullptr keyword with the standard NULL macro.
I'll see if I can upload it to the dropbox and fix the OP download links appropriately, but for now I've attached it to this post using HLP's server.
I found that MingW32 has the same api as g++, so I'll see if I can use it for a build or two and find out which pitfalls the code may have for *nix users... maybe even modify the Make file accordingly, too.
[attachment deleted by ninja]
-
OK, here's how I tried to compile it on g++:
- fs2_open/configure.ac:211: changed $WX_CXXFLAGS_ONLY to $WX_CXXFLAGS (see also reply #20)
- fs2_open/code/Makefile.am: from line 828 on, change
wxFRED_SOURCES = \
wxfred2/wxfred2.cpp \
wxfred2/wxfred2.h \
wxfred2/fredframe.cpp \
wxfred2/fredframe.h \
wxfred2/wxfred_xrc.cpp \
wxfred2/wxfred_xrc.h
to
wxFRED_SOURCES = \
wxfred2/wxfred2.cpp \
wxfred2/wxfred2.h
And then, behold... The linker fails on a very long list of undefined references :D Here's an excerpt:
libcode.a(keycontrol.o): In function `game_do_end_mission_popup()':
keycontrol.cpp:(.text+0x3211): undefined reference to `game_stop_time()'
keycontrol.cpp:(.text+0x3216): undefined reference to `game_stop_looped_sounds()'
keycontrol.cpp:(.text+0x32a4): undefined reference to `game_start_time()'
libcode.a(keycontrol.o): In function `button_function_demo_valid(int)':
keycontrol.cpp:(.text+0x41da): undefined reference to `Game_time_compression'
keycontrol.cpp:(.text+0x4202): undefined reference to `Time_compression_locked'
keycontrol.cpp:(.text+0x421b): undefined reference to `change_time_compression(float)'
keycontrol.cpp:(.text+0x4232): undefined reference to `Game_time_compression'
keycontrol.cpp:(.text+0x4242): undefined reference to `Time_compression_locked'
keycontrol.cpp:(.text+0x425b): undefined reference to `change_time_compression(float)'
libcode.a(keycontrol.o): In function `game_process_keys()':
keycontrol.cpp:(.text+0x5329): undefined reference to `game_poll()'
libcode.a(keycontrol.o): In function `game_do_end_mission_popup()':
keycontrol.cpp:(.text+0x32bb): undefined reference to `game_flush()'
libcode.a(readyroom.o): In function `build_campaign_mission_list_do_frame()':
readyroom.cpp:(.text+0x2e2): undefined reference to `game_find_builtin_mission(char*)'
libcode.a(readyroom.o): In function `build_standalone_mission_list_do_frame()':
readyroom.cpp:(.text+0x57a): undefined reference to `game_find_builtin_mission(char*)'
libcode.a(readyroom.o): In function `sim_room_build_listing()':
readyroom.cpp:(.text+0xe7b): undefined reference to `game_find_builtin_mission(char*)'
readyroom.cpp:(.text+0x1048): undefined reference to `game_find_builtin_mission(char*)'
libcode.a(readyroom.o): In function `readyroom_continue_campaign()':
readyroom.cpp:(.text+0x142e): undefined reference to `Game_current_mission_filename'
libcode.a(readyroom.o): In function `sim_room_commit()':
readyroom.cpp:(.text+0x151a): undefined reference to `Game_current_mission_filename'
libcode.a(readyroom.o): In function `sim_room_do_frame(float)':
readyroom.cpp:(.text+0x2610): undefined reference to `game_find_builtin_mission(char*)'
libcode.a(readyroom.o): In function `campaign_room_build_listing()':
readyroom.cpp:(.text+0x2808): undefined reference to `game_find_builtin_mission(char*)'
libcode.a(readyroom.o): In function `sim_room_init()':
readyroom.cpp:(.text+0x413a): undefined reference to `Game_current_mission_filename'
libcode.a(missiongoals.o): In function `mission_show_goals_close()':
missiongoals.cpp:(.text+0x118e): undefined reference to `game_flush()'
libcode.a(missionhotkey.o): In function `mission_hotkey_close()':
missionhotkey.cpp:(.text+0x304d): undefined reference to `game_flush()'
libcode.a(fictionviewer.o): In function `fiction_viewer_init()':
fictionviewer.cpp:(.text+0x290): undefined reference to `Fred_running'
libcode.a(fictionviewer.o): In function `mission_has_fiction()':
fictionviewer.cpp:(.text+0xa53): undefined reference to `Fred_running'
libcode.a(fictionviewer.o): In function `fiction_viewer_close()':
fictionviewer.cpp:(.text+0xb41): undefined reference to `game_flush()'
libcode.a(fictionviewer.o): In function `fiction_viewer_load(char*, char*)':
fictionviewer.cpp:(.text+0xbfe): undefined reference to `Fred_running'
fictionviewer.cpp:(.text+0xc1b): undefined reference to `Fred_running'
libcode.a(missioncmdbrief.o): In function `cmd_brief_close()':
missioncmdbrief.cpp:(.text+0xcd1): undefined reference to `game_flush()'
libcode.a(missionpause.o): In function `pause_close()':
missionpause.cpp:(.text+0x3ab): undefined reference to `game_flush()'
libcode.a(missionpause.o): In function `pause_debug_init()':
missionpause.cpp:(.text+0x49b): undefined reference to `game_single_step'
libcode.a(missionpause.o): In function `pause_debug_do()':
missionpause.cpp:(.text+0x651): undefined reference to `game_single_step'
libcode.a(missionpause.o): In function `pause_debug_close()':
missionpause.cpp:(.text+0x73b): undefined reference to `last_single_step'
missionpause.cpp:(.text+0x74d): undefined reference to `game_flush()'
libcode.a(missionscreencommon.o): In function `common_select_init()':
missionscreencommon.cpp:(.text+0x35b8): undefined reference to `Game_current_mission_filename'
libcode.a(missionscreencommon.o): In function `draw_model_rotating(int, int, int, int, int, float*, vec3d*, float, float, int, bool, int)':
missionscreencommon.cpp:(.text+0x5031): undefined reference to `flFrametime'
missionscreencommon.cpp:(.text+0x528b): undefined reference to `flFrametime'
libcode.a(modelinterp.o): In function `model_interp_get_texture(texture_info*, int)':
modelinterp.cpp:(.text+0x770d): undefined reference to `game_get_overall_frametime()'
libcode.a(modelread.o): In function `model_load_texture(polymodel*, int, char*)':
modelread.cpp:(.text+0x20e4): undefined reference to `Fred_running'
modelread.cpp:(.text+0x2111): undefined reference to `Fred_running'
modelread.cpp:(.text+0x213d): undefined reference to `Fred_running'
modelread.cpp:(.text+0x216b): undefined reference to `Fred_running'
libcode.a(modelread.o): In function `submodel_rotate(model_subsystem*, submodel_instance_info*)':
modelread.cpp:(.text+0x8f3e): undefined reference to `flFrametime'
libcode.a(modelread.o): In function `model_rotate_gun(int, model_subsystem*, matrix*, angles*, angles*, vec3d*, vec3d*, int, bool)':
modelread.cpp:(.text+0xb470): undefined reference to `flFrametime'
libcode.a(neb.o): In function `neb2_post_level_init()':
neb.cpp:(.text+0x7f0): undefined reference to `Fred_running'
libcode.a(neb.o): In function `neb2_render_player()':
neb.cpp:(.text+0x3550): undefined reference to `flFrametime'
libcode.a(neblightning.o): In function `nebl_render_all()':
neblightning.cpp:(.text+0x2a03): undefined reference to `game_flash(float, float, float)'
libcode.a(neblightning.o): In function `nebl_init()':
neblightning.cpp:(.text+0x2fd1): undefined reference to `Fred_running'
neblightning.cpp:(.text+0x3185): undefined reference to `Fred_running'
libcode.a(multi.o): In function `standalone_main_init()':
multi.cpp:(.text+0x3a0c): undefined reference to `game_hacked_data()'
multi.cpp:(.text+0x3a69): undefined reference to `game_flush()'
FSO itself compiles fine though.
-
Since I don't really have much time to throw around, I'm going to focus on re-building the project file and getting it to work under MSVC 2010. Even though I would love to learn how to use gcc and make, doing so will take up time that I simply don't have.
I've already taken out the C++11 keywords (it was just nullptr) in the 13-3-23.patch, but I'll need your help in making sure I don't make any more goofs in the .cpp and .h files that would bung up the compile process on *nix distros.
Thanks again guys. :)
-
Since I don't really have much time to throw around, I'm going to focus on re-building the project file and getting it to work under MSVC 2010. Even though I would love to learn how to use gcc and make, doing so will take up time that I simply don't have.
Too bad... but fair enough :)
I've already taken out the C++11 keywords (it was just nullptr) in the 13-3-23.patch, but I'll need your help in making sure I don't make any more goofs in the .cpp and .h files that would bung up the compile process on *nix distros.
Most of the code appears to build now, so good work so far :yes:
Looking at the 'undefined reference' error messages (see two posts up) and code/Makefile.am, it turns out that many of them originate from freespace.* and levelpaging.*, which are not included in libcode.a (presumably because they're the 'root' FSO source files) and therefore not in wxFRED. I got around it by defining a new libwxFRED in code/Makefile.am, which encompasses libcode, freespace.h, freespace.cpp, levelpaging.h and levelpaging.cpp. This of course leads to main() being defined double (for freespace as well as for wxFRED), but it as far as I can see g++ can pick the right one.
Now, though, it's still not linking back into WX properly. Looking at the linker command, it appears that the libs are entered ahead of the .o files - which leads me to suspect this issue (http://forums.wxwidgets.org/viewtopic.php?p=134800). So I changed configure.ac:212 to put WX_LIBS in FS2_LIBS rather than FS2_LDFLAGS. That appears to do the trick.
One error remains now: an undefined reference to frmFRED2::frmFRED2(). Hmm... So should I put that in libwxFRED or directly in wxFRED_SOURCES? Educated guess: put it in wxFRED_SOURCES (since I previously removed the fredframe.* files from there, see two posts up). Hmm... Multiple WX errors compiling frmFRED2; same thing happens if I add it to libwxFRD instead. Here's the error messages:
wxfred2/frmFRED2.cpp:38:63: error: call of overloaded ‘wxString(const char [9])’ is ambiguous
candidates are:
wxString::wxString(const wxWCharBuffer&) <near match>
wxString::wxString(wxChar, size_t) <near match>
wxString::wxString(const wxString&) <near match>
wxString::wxString(int) <near match>
wxfred2/frmFRED2.cpp:43:88: error: cannot convert ‘const char*’ to ‘const wxChar* {aka const wchar_t*}’ for argument ‘2’ to ‘int wxSprintf(wxChar*, const wxChar*, ...)’
wxfred2/frmFRED2.cpp:57:37: error: ‘wxSTB_DEFAULT_STYLE’ was not declared in this scope
wxfred2/frmFRED2.cpp:59:1: error: ‘wxFRED_xpm’ was not declared in this scope
wxfred2/frmFRED2.cpp:78:36: error: invalid conversion from ‘const char*’ to ‘wxChar {aka wchar_t}’ [-fpermissive]
wxfred2/frmFRED2.cpp:78:54: error: invalid conversion from ‘const char*’ to ‘wxChar {aka wchar_t}’ [-fpermissive]
wxfred2/frmFRED2.cpp:106:138: error: conversion from ‘const char [25]’ to ‘const wxString’ is ambiguous
candidates are:
wxString::wxString(wxChar, size_t) <near match>
wxString::wxString(int) <near match>
wxfred2/frmFRED2.cpp:674:182: error: cannot convert ‘const char*’ to ‘const wxChar* {aka const wchar_t*}’ for argument ‘2’ to ‘int wxSprintf(wxChar*, const wxChar*, ...)’
It is kinda strange that these only pop up for frmFRED2.cpp, but I'm not sure whether it's the source file (what version of WX are you working with, Z? I'm on 2.8.12) or my hacking.
-
I'm working with wxWidgets 2.9.4, which probably adds the wxString overload of wxString( const char[n] ), where n is the location of the first null terminator. It's my guess that it's actually implemented as wxString( char const * const), but I digress. :)
-
Hmm, that's probably the cause of (at least some of) the issues then - I remember similar errors when I made my modpack cleaner tool compatible with 2.8 (coming from 2.9). In my experience it is possible to support both 2.8 and 2.9 with a single codebase, but there's quite a few catches to it; deciding on a single WX version is probably more convenient.
As for which version, that's been discussed before (http://www.hard-light.net/forums/index.php?topic=79889.msg1583360#msg1583360), but without satisfying resolution. Personally, I'm in favour of 2.8, since 2.9 is still an in-dev release (and has been for a few years now, it seems). And also because most Linux repos contain 2.8, making for significantly easier installation :D
-
I'm also in favor of using wxWidgets 2.8.12... but I only have 2.9.4 set up and my dialup connection seems to be uncooperative when it comes to downloads lately. Not only is it slow, but the server keeps terminating the transfer for no apparent reason. :banghead:
Luckily, I've figured out how to get my wireless card working again on the laptop, so I can mooch off the public library's connection soonish and will get the lib's and doc's for 2.8.12.
I might have mentioned this before, but I'll state it again. I'm currently in favor of doing static linking, because for some reason I haven't been able to get dynamic linking to work right on my machine (mainly during compile time). I am deferring the final decision on whether wxFRED should be statically or dynamically linked to when wxFRED is actually ready for the general public. Both have their pro's and con's.
-
Ok, tried to download wxFRED2d 13-3-10.exe, but ran into norton not playing nice. Why the heck does (norton) think this file is a threat :nono: I know the file is safe, but am confused. Any imput would be appreaciated.
I`ll wait for a reply before giving it another go.
-
Ok, tried to download wxFRED2d 13-3-10.exe, but ran into norton not playing nice. Why the heck does (norton) think this file is a threat :nono: I know the file is safe, but am confused. Any imput would be appreaciated.
I`ll wait for a reply before giving it another go.
Yeah, all antiviruses are like that as far as I can tell. It's mainly because it's a "rare" .exe that hasn't been tested on Norton's network, nor is it published by any well-known software publisher, and therefore presumed dangerous.
It creates a real headache whenever I try to run a test build I had *just* compiled, and my AV yells at me "UNKNOWN ORIGIN." :rolleyes:
-
Thanks for the reply z64555
Downloaded, and will give it a go..
Norton :lol:
-
Uploaded the release version of the .exe a little while ago. The debug version requires .dll's that are installed whenever you have MSVC installed... so if you don't have MSVC you probably should try wxFRED2r.exe instead.
-
Downloaded, Thanks.
-
ShivanHunter confirmed via IRC that the provided .exe's, in fact, only work on Windows OS's. Sorry about that. :nervous:
Hopefully by next month I'll have Debian installed on my laptop, and have some sort of cross-compiler system setup.
In other news, I've sussed out the mechanics of swapping out widgets. Possibly not the best method, but it allows developers to use widgets in wxFormBuilder as placeholders (such as wxSpinCtrl) with the intention of replacing it with the desired widget in the child class (such as wxSpinCtrlDouble).
I tried downloading wxWidgets 2.8.12 the other day, but my tired brain moved the mouse cursor over the link to 2.9.4 before clicking, and instead got a nice backup copy of 2.9.4. I'll have to wait until Monday to try again (can't do it today because of work, and the library isn't open on Saturdays and Sundays).
-
Just a heads up to all followers.
I've got a major examination on the 13 (next Saturday) that determines whether or not my engineering classes sunk into my memory. It'll be the FE (Fundamentals of Engineering) exam, which will basically say "hey, I know most of my ****" to potential employers looking for an EEEN.
A side effect of this though, is that I'll be off-grid all this week and next week, so the April '13 Progress Report will have to wait until the 19'th or so.
Thanks for understanding. :)
-
Uuuuuuugggghhhhhhhhhh, man, good luck. The FE isn't particularly that hard as such, at least I didn't think so, it's just that it takes literally ALL DAY. Have fun.
-
Life's a matter of priorities :) Good luck on the exam!