Building Without Visual Studio

[UnFleshed One]

I guess it will be best to make two devpacks, so that you can use one of 'em even if there is no other one present. (In case there will be some unexpected changes to one or another). Even if it means there will be two identical copies of most files. Edited September 30, 2005 by UnFleshed One

[reist]

Whoever will write the rest of the multiplatform compatibility page can add this:

 

VC's run-time library is UNIX compatible...or more exactly POSIX compatible.

http://msdn.microsoft.com/library/default....mpatibility.asp

 

This means that writing paths should be done with '/' and not '\'.

For example:

"data/schema/shortcuts-default.xml" will work on any *nix AND on windows

while:

"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.

[red knight]

Reist can you send to Azrael by PM what you want to be published/grammar edited/formatted to put in that page?

 

Greetings

Red Knight

[reist]

Ok, I'll do that.

[reist]

How to tell all programmers not to do "ms_Singleton = 0" any more?

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.

http://docs.projectxenocide.com/index.php/Code:Singletons

Edited October 6, 2005 by reist

[UnFleshed One]

Oh, it is linking errors...

 

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 October 6, 2005 by UnFleshed One

[reist]

Just to be complete, here is what's happening with the only two problems I had:

 

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)

[UnFleshed One]

Commited. I always knew that windows was more robust platform Edited October 8, 2005 by UnFleshed One

[reist]

Is that why the next one will have an RSOD in addition to a BSOD? "So robust we add features you will never see!"

[UnFleshed One]

Diversity is always good!