AHX player

[bbear]

my main problem is how to use cpp functions into main.c with VC6 :

the functions tune_init(),tune_stop()... are in an external cpp with include ahx.h and windows.h.
But I can't call them from my main.c (unresolved external symbol)
I removed static declaration, I tested with extern, but it doesn't work...

I renamed main.c in main.cpp to put functions in main but I get "unresolved external symbol" with ptc_open and ptc_update...

If you want to test, I use the TinyPTC DX9 framework (see in C/C++ coding forum)

[Jim]

Yup, fixable.

In the C++ file do this

Code: [Select]

extern "C" tune_init();
extern "C" tune_stop();
Then you can call it from C.  The extern "C" tells the compiler to make that function callable from C.  Don't use static.

->Va!n: thanks for the tunes.  There's a standalone player I put together hanging around in this thread somewhere!

Jim

[bbear]

i'm desperate...it doesn't work
I tested with a main.cpp : now I have 4 unresolved external symbol : ptc_open/update and tune_init/stop!

[Jim]

Take it easy dude - it's something simple enough to fix .  It's not working because you're guessing at the fixes.  Mixing C and C++ can sometimes be tricky.

In your code where you're trying to call ptc_open(), at the top of that file afer the includes, add

extern "C" void ptc_open();

basically anywhere in your file before you call it.

Next, what compiler are you using?  and is is possible for you to post your code?

Jim

[bbear]

VC6
I started with this sample
it's tinyptc with devcpp. It works fine with VC6. 

extern "C" void ptc_open();

it's ok now for that

but not yet for tune_init...

[bbear]

argll
having put tune_xxx functions in my main.cpp and extern "C" = no more "unresolved external symbol" 
But now it crashs (at tune_init() ? but also without ahx) I tested the module tab char with your front end, and it's ok

Edit : it's seems to be the multithread. I set with DLL, and it works fine now !! 
phew...
But if you have better way, let me know

[Jim]

Glad it's working ...it does sound a little more like luck than judgement though - changing from static library to dll shouldn't really change anything.

Jim

[bbear]

hmm...I think I missed something when I compiled with static lib : MSVCRTD.lib 

[bbear]

I made a little intro with Ahx with multithread static lib, but cause big crash on Windows 98 (pagination error) and ask for a dll.
perhaps it's only msvcr71.dll ?

or is it possible to use only single thread, like with minifmod ?

[Jim]

Yes, but that makes it difficult to time the delivery of new samples in to the buffer when the buffer becomes empty.  You have to make sure you check for the buffer being empty at the right points in your game loop.  Difficult, but not impossible.

But it's not that that's causing your trouble.  You have something wrong in the way you're building the program.  If you post your code and project files (either here or in a PM), I will take a look, if you like?

Jim

[bbear]

thanks
the whole project (but VC6)

sorry for the crappy and ugly code

If you have any comments, advices, update, enhancement, debug...feel free

[Jim]

Thanks for that.
I can't see anything obviously wrong (code review, my VC6 is on a PC I can't get at until tomorrow), but can you try something?  Remove all the #pragma stuff, that's not the best way to do this.  Make sure you turn off the option in the project settings which disables default libraries.  In the extra linker dependencies add winmm.lib.  If you need the other stuff to work you can add ddraw.lib in there too.  In the settings for the runtime library, make sure it's set for Multithreaded Static library.  Delete the winmm.lib from your folder - you want to be using the one that comes with VS6 (probably the same one, but best to be on the safe side).  If it can't find it, you need to add the path to the platform SDK in the Tools->Options menu.

Then fix the debug version - you need to be able to trace where this is going wrong.  Does it work if you use tune_init() with a .ahx file rather than with the include file version?  Does it crash in tune_init2 or further on?

Your code's not so crappy, I was able to see what you're up to without building it in a few minutes.  I'm sure you'll tidy it up when you're closer to getting everything the way you want

Jim

[bbear]

in multithreaded mode, vc add libcmt.lib, but if I miss msvcrt.lib, exe crash :
"instruction 0x77f47bd2 (ntdll) use address 0x00000010. memory can't be read"
if I use MD, no problem. If I use MT, no warning, but crash

libcmt is for static multithread and msvcrt for dll multithread, no ?

In another program, I also use Ahx and it doesn't need msvcrt in static multithread. works fine in both mode.
phew...there's something wrong here...

I tried to remove pragma, checked runtime lib, etc... but I can't test now because I haven't win98, it's a friend of mine. so I'm waiting his test 

[bbear]

is it possible to change the code and use API CreateThread ? no more need libcmt.lib in static

[Jim]

If you use CreateThread() instead of beginthread() then the runtime library isn't initialised properly for the new thread.

If you just let VC6 manage what libraries it needs and set the settings right in the project properties, you will never have to worry about whether it needs libcmt, msvcrt etc.  If it needs the DLL then some setting is wrong somewhere and this is almost certainly why it's crashing.  I'll try to have a look at it this morning.

That crash indicates you passed some crap (probably NULL) into a Windows function.

Jim

[Jim]

I've found the problem.  In your project you have tinyptc.c with this in it...

Code: [Select]

//
// TinyPTC by Gaffer
// www.gaffer.org/tinyptc
//

#include "tinyptc.h"

//----------------------------- windows mode
#ifdef __PTC_WINMAIN_CRT__

    extern int main();
    void WinMainCRTStartup()
    {
        main();
    }

#endif

//------------------------------ console mode
#ifdef __PTC_MAIN_CRT__

    extern int main();
    void MainCRTStartup()
    {
        main();
    }

#endif

That's bad.  It means that instead of calling the code that sets up the C runtime library (WinMainCRTStartup()), it calls this function instead.  This function then calls in to main() in tinyptc_stars.cpp.

So basically as soon as it hit the 'new' inside tune_init2() the memory allocator hasn't been initialised and it blows its brains out.

You need to remove tinyptc.c from your project, and change
int main() in tinyptc_stars.cpp to

Code: [Select]

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
which is the proper startup function for Windows programs.  You need to add a couple of return 0s too.

You also need to remove libtinyptcwin.lib and msvcrt.lib from the link options and add winmm.lib.  You don't need any of the #pragma stuff.

The reason it works with the dll but not static is that the very act of loading the dll means the C runtime gets initialised.  But it's still naughty to override MainCRTStartup().

Have fun!

Jim

[Jim]

I guess the reason it's doing this is because you (or whoever wrote the original sample) really wanted to make the program very tiny.  You can only do that if you have /nodefaultlib set, but that means NO CRT AT ALL, including the use of 'new'.  AHX is written to use Windows API instead of CRT.  I suppose you could overload the new/delete operators to use GlobalAlloc/GlobalFree.

Jim

[bbear]

ok, thanks
the compilation is ok now
I hope that it will work fine on win98 now

 

[Jim]

Let  us know!
Cheers!
Jim

[bbear]

It's OK now 
the old version asked for msvcrt.dll and the big crash was from fsg packer!

but some questions about timing/fps with tinyptc/directx/opengl:
my friend have an old pc (400 mhz). He have tested 2 progs : this one, with tinyptc/ddraw, and that one using OpenGl and he say me that they run very very slowly !
It's strange because I remember on my P166 Mhz to have run 3Dmark99 and 3Dmark2000 with a good speed on 3dfx and riva tnt cards. Unfortunately, my p166 is dead, and I can't test my 2 progs. Edit : ok, he have a S3Trio...but it's strange for the simple ddraw intro.

I think the problem is the timing fixed to 60 fps. and I think it's a wrong way.
what are the better ways to adapt fps ?