VOGONS


First post, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

PDCurses for SDL has some features not found in the non-SDL Win32 version, so I thought I'd check it out for the DOSBox debugger.

The library (libpdcurses.a) is built similarly to the non-SDL library, which seems to work OK, but then all of the SDL functions referenced by the library are unresolved when the DOSBox executable is linked. The non-SDL library has no problem because it has no references to functions in SDL.DLL.

I've been searching for some way (compile switches or so) that will make the objects in the library understand that the SDL functions are resolved at runtime (dynamic), not at link time (static), but so far haven't figured it out. The included README has not shed any light on the matter. I'd prefer not to have to resort to statically linked SDL for my little experiment, so I'm hoping someone knows of a solution.

I'm using the current (supposedly stable) 3.4 version of PDCurses with MinGW.

Reply 1 of 3, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Managed to get DOSBox to successfully link by putting -lpdcurses before -lSDL in the list of linked libs; the configure script puts it after. Not sure how that is an important difference...

However, the debugger is displayed over the main DOSBox window, perhaps because SDL 1.2.x can only manage one output surface. So it seems the SDL variant of PDCurses is not going to be useful here.

Reply 2 of 3, by jomalin

User metadata
Rank Newbie
Rank
Newbie
ripsaw8080 wrote:

the debugger is displayed over the main DOSBox window, perhaps because SDL 1.2.x can only manage one output surface. So it seems the SDL variant of PDCurses is not going to be useful here.

Incoming SDL 2.0 can manage multiple output surfaces.

What is the advantage using PDCurses library on Dosbox? Wich library is currently using DosBox for console?