I don't use ImageMagick on Windows myself, but assuming you can properly install the binary on your system, the 'montage' command Stefan provided above should work fine.
EDIT: For the sake of posterity, ImageMagick isn't available on OS X by default either; I installed it on my OS X system via MacPorts, although you could also manually compile it from source (haven't tried that route myself though). With Linux, depending on the distro you're using, ImageMagick may come installed by default, otherwise you'll have to grab a copy from a repo, or compile it yourself.
As far as I can see, the SDLMAIN_LIBRARY variable is never set prior to the code at lines 178-180, so cmake always ends up assigning an empty string to the variable, no matter what.
The only way I can think of to get around this without having to go in and manually edit the CMakeLists.txt file every time would be to filter for what OS we're installing on, i.e. something like:
If (APPLE)
Set (SDLMAIN_LIBRARY "SDLmain")
Endif (APPLE)
This should work if the core SDL library has already been successfully located, as SDLmain should be in the same location as the other SDL files. Frankly though, I'm rather surprised that cmake doesn't automatically include SDLmain if appropriate when locating the core SDL library.
The problem seems to be that CMake, for whatever reason, fails to automatically locate SDLmain on OS X (see line 177-180 in CMakeLists.txt), so you have to link it explicitly in the list of target link libraries. Like I said above, I'm not familiar enough with CMake to know why or how CMake fails to find SDLmain, but the solution above works correctly for me.
Hm, interesting... I tried compiling with the -g switch enabled (and again the executable compiled and linked without any visible problem or error, even when running gcc with the -v option) and ran the executable through gdb, but when I tried generating a backtrace I got "No stack." I tried recompiling/reinstalling the most recent SDL and all the satellite libraries from source, but no change. I should note here that I've successfully compiled/linked/run various SDL projects before using gcc directly on this same system, but I've never encountered this problem before, so I'm rather mystified.
Next I tried building with XCode as Clint suggested, and that build runs perfectly, even with the 1.2.15 SDL.framework. So I guess I'll be using XCode after all, although I was hoping to avoid that since the apparent lack of git SCM support in XCode 3.2.6 means I'll have to manually add new files from my local copy of the repository to the XCode project.
I'm still going to play around and see if I can't find and fix whatever silent problem is causing the abort trap when using gcc directly, but for now XCode works fine.
@Stokrotka: Sure thing! Since all the sounds are CC0, you can do pretty much whatever you want with them, including using them in a commercial project, without having to give attribution. If you'd like to credit me I'd appreciate it, but it's certainly not a requirement. Good luck with your project! :)
I've actually been loosely fooling around with the idea of forking the FLARE engine to implement a turn-based combat system (something like the system used in Spiderweb Software's Geneforge series, where turns/action points only apply in combat and not when simply moving about the world), but I'm not terribly familiar with the current codebase, so I can't say whether it would be worth attempting or not. A turn-based system certainly wouldn't fit in with the current direction of the project, but it could definitely be an interesting experiment on its own.
@VWolfdog: 'montage' is a command from the ImageMagick suite, which has a binary available for Windows: http://www.imagemagick.org/script/binary-releases.php#windows
I don't use ImageMagick on Windows myself, but assuming you can properly install the binary on your system, the 'montage' command Stefan provided above should work fine.
EDIT: For the sake of posterity, ImageMagick isn't available on OS X by default either; I installed it on my OS X system via MacPorts, although you could also manually compile it from source (haven't tried that route myself though). With Linux, depending on the distro you're using, ImageMagick may come installed by default, otherwise you'll have to grab a copy from a repo, or compile it yourself.
As far as I can see, the SDLMAIN_LIBRARY variable is never set prior to the code at lines 178-180, so cmake always ends up assigning an empty string to the variable, no matter what.
The only way I can think of to get around this without having to go in and manually edit the CMakeLists.txt file every time would be to filter for what OS we're installing on, i.e. something like:
If (APPLE)
Set (SDLMAIN_LIBRARY "SDLmain")
Endif (APPLE)
This should work if the core SDL library has already been successfully located, as SDLmain should be in the same location as the other SDL files. Frankly though, I'm rather surprised that cmake doesn't automatically include SDLmain if appropriate when locating the core SDL library.
@Soren: I've played around a bit with CMake, and I've come up with a non-ideal but working solution to the problem. In line 182 of CMakeLists.txt:
Target_Link_Libraries (flare ${CMAKE_LD_FLAGS} ${SDL_LIBRARY} ${SDLMIXER_LIBRARY} ${SDLIMAGE_LIBRARY} ${SDLTTF_LIBRARY} ${SDLMAIN_LIBRARY})
replace ${SDLMAIN_LIBRARY} with SDLmain:
Target_Link_Libraries (flare ${CMAKE_LD_FLAGS} ${SDL_LIBRARY} ${SDLMIXER_LIBRARY} ${SDLIMAGE_LIBRARY} ${SDLTTF_LIBRARY} SDLmain)
The problem seems to be that CMake, for whatever reason, fails to automatically locate SDLmain on OS X (see line 177-180 in CMakeLists.txt), so you have to link it explicitly in the list of target link libraries. Like I said above, I'm not familiar enough with CMake to know why or how CMake fails to find SDLmain, but the solution above works correctly for me.
Hm, interesting... I tried compiling with the -g switch enabled (and again the executable compiled and linked without any visible problem or error, even when running gcc with the -v option) and ran the executable through gdb, but when I tried generating a backtrace I got "No stack." I tried recompiling/reinstalling the most recent SDL and all the satellite libraries from source, but no change. I should note here that I've successfully compiled/linked/run various SDL projects before using gcc directly on this same system, but I've never encountered this problem before, so I'm rather mystified.
Next I tried building with XCode as Clint suggested, and that build runs perfectly, even with the 1.2.15 SDL.framework. So I guess I'll be using XCode after all, although I was hoping to avoid that since the apparent lack of git SCM support in XCode 3.2.6 means I'll have to manually add new files from my local copy of the repository to the XCode project.
I'm still going to play around and see if I can't find and fix whatever silent problem is causing the abort trap when using gcc directly, but for now XCode works fine.
Hehehe, the link to this page kept popping up in the wesnoth IRC channel all afternoon. :p
@Stokrotka: Sure thing! Since all the sounds are CC0, you can do pretty much whatever you want with them, including using them in a commercial project, without having to give attribution. If you'd like to credit me I'd appreciate it, but it's certainly not a requirement. Good luck with your project! :)
I've actually been loosely fooling around with the idea of forking the FLARE engine to implement a turn-based combat system (something like the system used in Spiderweb Software's Geneforge series, where turns/action points only apply in combat and not when simply moving about the world), but I'm not terribly familiar with the current codebase, so I can't say whether it would be worth attempting or not. A turn-based system certainly wouldn't fit in with the current direction of the project, but it could definitely be an interesting experiment on its own.
daneeklu: Thanks! :)
Updates:
Not a whole lot to show here, but unfortunately I have less free time than I'd like to have. :(
North-facing and the ghoul thingie are still WIP'
.
Quick sketch. Been waaaaay too long since I sat down and banged out some pixel art...
Dress still needs lots of refining, but I'm pretty happy with the hair.
Pages