Updates (did some more testing):

Hyperspeed:
- Played the easy cluster through to the end. Worked great. I was using Roland sound instead of Adlib and it sucks though. Not DosBox's fault.

Budokan:
- I forgot to set the Tandy option to true in dosbox.conf, but when I did the game still said "this is not a Tandy 1000" when I tried to select it as the sound output device. Not a big deal to me, but I thought it might be worth mentioning.

Solar Winds 1 (Epic, VGA):
- Still locks up in the intro (without an error and with music still playing), just like in 0.57 and VDMS+WinXP. I tried disabling EMS and XMS and telling the game not to use sound (via the /NOSB command line parameter), joystick nor mouse, and it still froze. Perplexing.

As far as I know is tandy sound not done. I could be mistaken.

Btw I couldn't find the exe you are talking about (dosbox 0.58rc1)

Are you sure it's posted here somewhere....
(found it.)
And why don't I know that it's posted outside the betaboard ?

Well not a too big deal. but i would hate to see it going public before the real release. Some people might even file bug reports against it. Then the people on SF will really be bothering us abouting releasing it. (the Source isn't ready yet! Still some issues left I want to have sorted out before releasing)

I'm glad you tried to sound a bit more positive 😀

Grtz Peter

Could always be more careful to label the version as a prerelease when you make install packages. It says 0.57 in some places and 0.58 in others, but nothing indicates that it's somewhere in between. I know better of course 😉

Yes, I'm more positive now. 0.57 was unusable, and the multithreading was obviously NOT enabled in the CVS code I downloaded and built a few weeks ago. I can now play Hyperspeed, and almost play Wiz7 (I could if I wasn't so picky).

I didn't mean to badmouth DosBox so much. I think it's a great project and it seemed to work great for a lot of people. 0.57 just wasn't at all usable for me, and having people insult me and my system when I tried to find out why on the sourceforge forum didn't help any.

Any ideas for what's coming up in 0.59? 😉

Whoah, not so fast. 0.58 will be the next release. 😀

Multithread was re-enabled in 0.58. Just RTFM. 😉

Peter, I posted .58RC1. I know I had a damn good reason at the time...I just can't remember it. I don't think very many people will be able to find it here, in any case, as you probably discovered. (Most people don't even care that much.) I can remove it if you want but this thread just goes to show you that it isn't always a bad thing to leak releases. And if anyone gives you guff just add me as an admin for the DOSBox project and I'll sort through the fluff for you. 😀

By the way, how do you define the version number in the source? I would hope that you use a variable, in which case it should be simple to change it for everything in the program, you know? 😀

DosFreak wrote:

Whoah, not so fast. 0.58 will be the next release. 😀

Yes, I know. I know what will be in 0.58, so I'm wondering if the team knows anything that will be new in 0.59 😜

Multithread was re-enabled in 0.58. Just RTFM. 😉

Yes I know that too. It wasn't enabled in the CVS code I got around a month ago though, and it *is* enabled in this prerelease that Snover leaked. And I've seen all over the place that the final release of 0.58 will have it still enabled. I was just saying how it was in the other versions I tried and why I was frustrated.

Eheh, I feel naughty.

Are you taking responsibility for that leak too? 😉

Just for the record: the multithreaded code was enabled in the cvs a month ago. I think a bad compile was the reason.
as you stated dosbox used 100 % when starting up:this means every game will run bad.

Colin: well leave it here. The people here are concerned with old games so I don't mind. (this time 😉 rc2 is on the way though so 😀

For HunterZ: Solarwinds will run in that version. But I hope you don't get it for the real release 😀

Just for the record: the multithreaded code was enabled in the cvs a month ago. I think a bad compile was the reason.

What could I have been doing wrong when compiling? I was using MSVC++ 6.0. I had to download all those libraries and add their path to the project, but it compiled fine. It just didn't run so well. Do you have to change a flag somewhere to get it to compile well or something? Or maybe it was enabled just a few days after I tried to compile it? It was right around a month ago.

as you stated dosbox used 100 % when starting up:this means every game will run bad.

0.57 used 100% too. In fact my compile worked exactly like 0.57 (and so did the 0.573 debug version Snover posted). This is why I suspected that the multithreaded code was not being used in any of those builds, and that is still the most reasonable explanation.

For HunterZ: Solarwinds will run in that version. But I hope you don't get it for the real release

RC2 will run it you mean? Hey Snover leak it ASAP! 😉 What was the problem? I'm curious because WinXP's NTVDM hangs in Solar Winds at the same spot.

Oh, I did some more testing on RC1 last night:

Wizardry 6 (Sir-Tech, EGA):
- I'm not sure if the sound effects are PC speaker or soundblaster in this version, but they're too-low pitched again. They're the old 1-bit-at-a-time, non-DMA-using type of sounds.
- Lowering CPU cycles to 600 helped get the bell sound to sound better, but not the rest of the sounds.
- Game seems to work fine otherwise, but I didn't play it much.

Barbarian 2 (Epyx, CGA/EGA):
- Can't hear intro music (PLAY.EXE). It uses weird PC speaker tricks. I tried different CPU cycles settings but it didn't help.
- In-game sounds were almost recognizable.
- Seems playable otherwise.
- I used to have this game but it was called Axe of Rage. WTF is up with that? I had Barbarian 1 as well, but it was called Death Sword!

Well, quite an easter hunt! After unsuccesfully trying to get dosbox to compile last night I was amazed to see a post about an rc1. Thanks a lot for the quicksearch option here, but even with that it was not that easy 😀

Btw., I really wish it would be easier to compile dosbox with mingw. Asking for help for this on the SF forum is not fun at all especially considering the answers others got...

I've never actually seen anything compile successfully with MinGW 😜

he he, daily snapshots of exult (http://exult.sf.net) and scummVM are compiled with mingw.
At least Exult has been succesfully compiled by myself 😀

Edit:
As soon as compilation requires automake, configure, autoconf I haven't been able to compile anything as it would crap out more sooner than later.
But when there is a maintainer of a makefile for mingw/msys it works quite fine (exult,scummvm,xu4,uwadv,pentagram (all SourceForge projects) are good examples).

Hunter:
The game resetted the put timer (or pit) and it still read data from it afterwards. This is possible on a real pc but we emulated it wrong and so does ntvdm.

Dom: Hmm I've really compiled it numerous times with mingw.
No problems there. Well maybe i used a regular source archive as there the automake autoconf requirement is dropped.
on irc.freenode.net #dosbox there are some people compiling dosbox with mingw as well

Peter

Qbix: I'll try to get a hold of someone on IRC to get help with it.

Builds fine here with mingw now.

I'll try as soon as SF's cvs allows me to update the source again...

Edit:
I take everything back now. Dosbox compiles now fine without hitch (though some warnings but that's "normal", I guess).
Works also (wow unstripped Dosbox is 15 MB big)