New trunk revisions problems

International board Development
#4

Done.

#5 
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

#6

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

#7

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

#8

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.

#9

@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)

#10

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)
#11

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)

#12

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

#13

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?

#14

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

ldd client/.libs/vcmiclient

I get

#15

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

#16

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.

#17

You’re right:

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

#18

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)

#19

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

#20

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

#21

Not only he didn’t but someone populated the same issue elsewhere (I was looking at diffs at sourceforge) so maybe check all files for " WIN32" pattern and modify to " _WIN32" if it’s in #ifdef/#ifndef section
EDIT: i haven’t see you just added the commit, I’ll check how it compiles…

EDIT:
CLIENT COMPILING:

...
1>CMusicHandler.cpp
1>CMT.cpp
1>CMessage.cpp
1>n:\dev\__vcmii\trunk\client\cmt.cpp(136) : error C2512: 'CVideoPlayer' : no appropriate default constructor available
1>Client.cpp
1>CHeroWindow.cpp
1>CGameInterface.cpp
...

It doesn’t compile. I don’t checked why
All but client compiles well.

EDIT
Sdlframerate.h suffers the “win32” issue

EDIT
WIN32/_WIN32 stuff isn’t reason of not compiling, I do some further when issue would be fixed

#22

it doesn’t compile cconsolehandler.cpp

use WORD before definied

typedef WORD TColor;
was before
#include<windows.h>
but should be after

(windows.h defines WORD)

the output from MSVC yelds strange things but those the reason

EDIT: after applying attached fix it compiles properly

EDIT: added link to compiled fixed986 version of vcmi
vcmi 986 fixed build
here it is
986-fix.zip (1.22 KB)

#23

Fixed.