Edited by UnFleshed One, 30 September 2005 - 02:56 PM.
Building Without Visual Studio
Posted 30 September 2005 - 02:56 PM
Posted 02 October 2005 - 06:39 AM
VC's run-time library is UNIX compatible...or more exactly POSIX compatible.
This means that writing paths should be done with '/' and not '\'.
"data/schema/shortcuts-default.xml" will work on any *nix AND on windows
"data\schema\shortcuts-default.xml" will work on windows ONLY.
This also removes unneeded code duplication (hopefully)
And a request: put an empty new line at the end of .h and .cpp files. This causes a warning with some compilers, is really easy to fix and really annoying to look at (especially with repeating warnings for headers) when looking for warnings about real possible problems.
I already did it for all the existing files in the submited patch, so it's a request for new files only.
Posted 02 October 2005 - 11:03 AM
Visit my blog at: flois.blogspot.com
Pookie cover me, I am going in.
Posted 05 October 2005 - 06:28 PM
It is totally unneeded. Moreover it causes duplicate symbol linking errors.
All the commented out lines in cpp files can be deleted. I only commented them out because I wasn't 100% sure that everything will compile on MSVC with no problems.
Edit: Just noticed it in the docs too.
Edited by reist, 05 October 2005 - 06:33 PM.
Posted 06 October 2005 - 12:34 AM
Then I still don't like removing them. I'll do some debugging...
I'll did some debugging and it seems that line really isn't necessary. All ms_Singletons seems to be initialised to zero in singleton.h, as they should.
Unless, of course it wasn't some debug initialization. Then again it wasn't 0xadadad or whatever pattern debuggers use to fill in the memory...
Yeah, don't do it
Edited by UnFleshed One, 06 October 2005 - 12:36 AM.
Posted 07 October 2005 - 10:54 AM
Text on buttons - was caused by CEGUI 4.0, so it works fine now.
Audio and stalling - my kernel, compiled with multi-processor support, locks audio commands and that's what caught the bug (and it is a bug, pitty there's no real fmod documentation with a warning not to do that).
Fading out is handled in a thread, so the call to an audio function (Stream_Stop) from inside it deadlocked just that thread. That caused the music in planetview to never play.
The next time any synchronous audio command was called - switching music, changing volume - the main game thread deadlocked too, locking the gfx driver with it.
I removed Stream_Stop - it will always get called later anyway. I also changed fading out a bit to not try to play beyond volume 0 at all...or at least not care about it if it happens. No one will hear it anyway
(patched sent to UnFleshed One for testing)