New trunk revisions problems

rev 947:
guiclasses.cpp/guiclasses.h uses boost::mutex but there [boost namespace]/[boost namespace element] undefined
so compiler error

I use BOOST_1_38_0 version of boost if that helps

EDIT:
theres boost::shared_mutex but no boost::mutex

it’s probably a typo

in guiclases.h
shared_mutex once:
#include <boost/thread/shared_mutex.hpp>

in guiclases.h
boost::mutex once

class CIngameConsole: … {
private:

boost::mutex texts_mx; // protects texts

}

so what is valid? boost::shared_mutex and boost/thread/shared_mutex.h or simple boost::mutex and boost/thread/mutex.h

changed

boost::mutex texts_mx; // protects texts

to

boost::shared_mutex texts_mx; // protects texts

and works perfectly
so console flood error is really fixed in this revision ! :mrgreen:
(look at bugz 7.2)

EDIT: please fix the typo in SVN !!!

Done.

void CMusicHandler::init()
{
	CAudioBase::init();

	if (initialized)
		Mix_HookMusicFinished(musicFinishedCallbackC);
}

VERSUS

void CSoundHandler::init()
{
	CAudioBase::init();

	if (initialized)
		// Load sounds
		sndh = new CSndHandler(std::string(DATA_DIR "Data" PATHSEPARATOR "Heroes3.snd"));
}

after init
CGI.musich.sndh
is NULL
and console info
Unable to Play… was NULL
maybe problem with either Hook catching from init or not initialized Csndhandler sndh

probably that is reason of not working MusicHandler

I’m no more able to build current trunk (r948) with previously working procedure (./configure --with-boost-libdir=/usr/lib64 and make):

The code is correct. I suspect your installation is wrong. The intro music is “Mp3/MAINMENU.MP3”. Make sure it is exactly that.

I can run that same command (cut&paste) without error.
However it seems your libtool has been regenerated. That shouldn’t be necessary. Try to use the file from svn. Use “svn st -q” to see which files have changed. You can then remove them and do a svn up, or use svn revert.

@NUG
some programs for compilation you are missing

@ubuntux
of course i have it properly

I think the hook start working after binding a music on some PCs which makes nothing because hook not start working yet and sndh is null
probably if bind a few seconds silence just before starting a hook and after initializng audiobase should make it working (the silence should be new mp3)

Yeah, you’re right, I run bootstrap.sh and I was not aware it may cause such issues. Maybe it should be deleted?

About intro music it also doesn’t play for me:

Unable to load music file (Mp3/MAINMENU.MP3). Error: Couldn't read from 'Mp3/MAINMENU.MP3'                                                     
Unable to play music (music parameter was NULL) 

because I had it in ‘mp3’ directory not ‘Mp3’, when I renamed it to such vcmi still couldn’t load it (r951):

Unable to load music file (Mp3/MAINMENU.MP3). Error: Module format not recognized
Unable to play music (music parameter was NULL)

What are first bytes of your MAINMENU.MP3 file? Is it FF FB or something else?

“Module format not recognized” is an error of MikMod part of SDL_mixer. It shouldn’t be used at all, since we try to play MP3 file. It seems that SDL_mixer has a bug that makes it unable to properly recognize mp3 file if it has ID3 tags or modified first “magic” bytes from any other reason.

Cf. the check for MP3 file type in SDL_mixer 1.2.8 sources:
[music.c lines 606-609]

	if ( (ext && MIX_string_equals(ext, "MPG")) ||
	     (ext && MIX_string_equals(ext, "MP3")) ||
	     (ext && MIX_string_equals(ext, "MPEG")) ||
	     (magic[0] == 0xFF && (magic[1] & 0xF0) == 0xF0) )

(ext is file extension and magic is a char table with first bytes from file)

there is
FF FB
at start of maimenu.mp3
but in 951 it says that it cant find smpeg.dll and its the reason

EDIT:
i got smpeg.dll from
dsource.org/projects/arclib/browser/downloads/dll/smpeg.dll?rev=474
and put into vcmi directory and music works in pregame

SUCCES !!!

so the issue was that we haven’t some dll and vcmi wasn’t informing that needs it…
now it does and work when it have smpeg.dll

PS: i scanned this file on virustotal.com and was clean,
though on some site was warning about worm hiding in generic smpeg.dll files,
but it means my copy wasn’t infected but keep attention when downloading the file from unknown source

Now what about my case? Indeed it starts with FF FB, but maybe it also has sth to do with smpeg, which I have installed:

/usr/lib64/libsmpeg-0.4.so.0 -> libsmpeg-0.4.so.0.1.4
/usr/lib64/libsmpeg-0.4.so.0.1.4

How to compile-in them in vcmi?

You shouldn’t have to do anything. It’s linked by default. Try:

ldd client/.libs/vcmiclient 

I get

Now I know why it doesn’t work for me, it’s not linked to libsmpeg…

That dependency should come from SDL_mixer. Try:

I get:

If it’s not there it means the sdl_mixer has not been compiled with mp3 support.
May be your distribution has a “codec” or “restricted” version of it.

You’re right:

No mp3 support in sdl-mixer, so I’m in search for nonrestricted packages, thanks for help.

there is a typo in include files
it asks about WIN32 but should ask about _WIN32
could be resolved by giving preprocesor definition in compiler, but this means every time when downloading project mark this or every time rebuilding we got strange errors

it’s because windows compilers defines _WIN32 automaticaly and WIN32 not

EDIT:
wrong definition of handlers in csndhandler.cpp
CVidHandler::CVidHandler(std::string fname) : CMediaHandler::CMediaHandler(fname)
should be
CVidHandler::CVidHandler(std::string fname) : CMediaHandler(fname)

the same with csndhandler class
(gives compile error)

EDIT: I’m submiting repaired files

AFTER-EDIT: thanks for dismissing compile error with csndhandler.cpp, but could anyone add missing underscore in cvideohandler.h ? its shown in the second file from package (WIN32 should be _WIN32)
package for vcmi team.7z (3.03 KB)

BUMP
(about “WIN32” and “_WIN32” issue)

Sorry. I thought Tow did that too. The change is commited now.