Well, I'm compiling with -march=athlon-xp in order to use 3dNOW! and SSE support so I'd guess this cpu is required. I don't want to support every cpu type out there (and using correct cpu flags when compiling will gain at least a few % of speed for free) since everybody can compile dosbox to their needs. But - I will make a i686 version just for the sake of testing my patch 😁. So, try this one out...I think it should work:

dosboxcvs-040802-i686.zip

Gulikoza, I have to say, I'm flabbergasted!

It seems to be even faster then overlay on my radeon 9000 - without the ugly blurriness overlay gives.
Compiling with -march=athlon-xp's not causing troubles since your builds work flawlessly on my Intel P4 (haven't tried your i686 build though.)

@kjliew: just because of using Directx9-headers and libs doesn't mean, that you're required to use DX9 hardware, my radeon isn't either.

@Iron: you said, the version from 06.06.04 works for you, the others don't.
Have you tried a clean recent cvs build? (You can get one here: http://cvscompile.aep-emu.de.)
You should also check, that you're using gulikozas sdl.dll, it's version 1.2.7, stable dosbox uses an elder version...

Ok I tried this i686 version and it starts up fine. Maybe it's the SSE thing that causes the problems if it runs fine on a p4? Well hard to say. I dont want to start building anything on this windows box anyways and this is the only one fast enough for dosbox anyways.

Hmmh yeah I was comparing to a few days old cvs and this was a bit slower. Death rally is now getting playable on my box on the plain cvs, but it was bit more jerky on your d3d build with any settings and even everything new disabled.

The d3d mode seemed to be working fine though and wasn't noticeably slower than surface. The computer speed patch is cool too especially with the death rally menus, since it seems that the hardest part of running the game is the menus where sound always cuts if you try the same speed settings as ingame.

Just keep on working, it's cool!

It seems to work fine here, but it is quite slower in some games, like wolf3d. but i had no trouble with mk1 and 2....
Keep working on it! 😁

Another update on my page. It makes D3D mode a whole lot faster on DX8.1+ hardware and it works with any scaler. Unfortunately, all those of you with older graphics card this is somewhat of a bad news, since it makes D3D quite slow. I don't know yet how to solve this...any feedback appreciated.

1. I have noticed that there is fulldouble=true in your dosbox.conf. I wonder whether you have any reason for using it, cause it slows down fullscreen a lot.

2. There is also aspect=true in your dosbox.conf.
(aspect=true is only for some strange situations - mostly with shitty LCD monitors or shitty gfx drivers)
I am not sure whether your patch even uses it. Nevertheless it seems that your patch doesn't need it as your patch always rescales the picture to height and width you set in .conf.

1. fulldouble=true turns on tripple buffering (since double buffering is always used anyway). This should improve framerate when vsync is set, since the application can render to a third buffer while waiting for vsync. For now, vsync is disabled and this option is merely there to do something 😁. If it's slower then by all means disable it.

2. aspect=true...hmm. This option seems to set some scale values and d3d obeys them when set. If I for example start Tie Fighter in VGA, it will create a 320x200 drawing surface and dosbox will write the virtual framebuffer to this surface. When aspect is set to false, this will also be the size of the window. Now, 320x200 has the aspect ratio of 1.6:1 and since the game is supposed to run in fullscreen the aspect ratio should be 1.33:1 so the game graphics look squashed. When set to fullscreen, the monitor will change to 640x400, which has the correct AR of 1.33:1. When aspect ratio is set to true, dosbox will also create a 320x200 drawing surface, but set the scaley to 1.169. D3D will then resize the window to 320x233, which is closer to 1.33:1 and the game looks much better to me...anyway this is my understanding of the aspect option, so that's how I implemented it.

I have noticed now that you have modified aspect=true with direct3d so that it works only in a window. Nice 😀

gulikoza wrote:

D3D will then resize the window to 320x233, which is closer to 1.33:1 and the game looks much better to me.

If you want the game to look even better (actually perfectly) in a window, just switch your desktop to 1.6:1 (for example 1280:800) 😀

Question... just where do I add the refrences to the Include and Libs directories and in which Makefile for that DirectX 9 SDK that I installed in my MingW directory. I get this as an error and I assume it's because I haven't added the refrences to the Include and Lib directories...

1gui/libgui.a(sdlmain.o)(.text+0x388): In function `Z7InitD3DP6HWND(int, int, bool, bool)':
2f:/src/src/dosbox/src/gui/direct3d.h:110: undefined reference to `Direct3DCreate9@4'

Well, I have the headers in c:\MinGW\msys\1.0\include\dxinc and copied the .lib files to c:\MinGW\msys\1.0\lib. My compiling line looks something like this:

1CXXFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer" CPPFLAGS="-I/usr/include/dxinc" ./configure; patch -p1 < ../dosbox_direct3d_makefile.patch; make

and the dosbox_direct3d_makefile.diff modifies the LIBS = line in src/Makefile and src/gui/Makefile. See the patch attached. Debug builds have a bit different Makefiles so it won't apply cleanly, but you can modify them later...I know, this is all kinda strange, but moving all the stuff to configure would require re-running autogen.sh. That's why the whole code is just included to the sdlmain, so that only libs have to be added to the Makefiles...

I can rerun autogen.sh. I use Cygwin to do it. And I compile with MingW.
Strange reasons but I can do it.

but I'll check your make.diff thank you gulikoza.

Also have you checked out this ddraw thing that has been added into the CVS Currently?

EDIT:
ThankYou. I first took a look at the diff and instaed of patching it. I just added the -ld3d9 -ldxguid to end of the LIBS= in the two makefiles. 😀 The reason is that I can build the CVS with all options. That's why I can't patch with your makefile.diff 🤣.

Well...I haven't checked all this configure stuff, so I don't know how to properly add it...fixing Makefiles seemed like a better and faster idea to get it running 😊
Yes, my builds are compiled with ddraw, but all I'm getting is Failed to create ddraw surface, back to normal surface.

I updated my post above yours and I can do ddraw with no problems running it in my builds.
It just looks.. weird in fullscreen. It's seems the graphic output sticks to the upper right corner...?
so there is like some black space to the left and bottom about an inch? wide I guess.
I don't think I can't confirm by screenshot because it happens in fullscreen and doesn't show up in window mode.

EDIT: okay, I think Direct3D broke how overlay is suppose to work because now overlay acts just like surface. D'oh.
I compared Overlay with a clean, unpatched build with a Direct3D patched build.

Also Direct3D stretches the pixels a bit to achieve the fullscreen effect so if you type EDIT for instance some of the lines aren't balanced with the rest of the word. I would appreciate for adding a blank space above and below the graphics output because that preserves the original look of the graphics. I hate distortion.

EDIT 2: Ack nevermind. I should have done a make clean and rebuilt using the two changes in the makefiles because overlay works fine now. Sorry Guli. 😅

EDIT 3: I have added to my build the patches by ih8regs, moe, toz, and Guli and I know that Guli's, toz, and moes work succesfully. I can not confirm ih8regs since I don't own a joystick. But I will see if a couple of my mates can test this out. Toz as usual with the coreswitch and timesync patch works prefectly as far as I can tell. Moe's HQ2x patch keeps getting better and more sophisticated and Guli's is neat and hopefully works for more cards if you don't mind a little extra stretching in the pixels.
I also edited the conf outputs in various places to display the ddraw, direct3d options in output and also shows all available options for the scalers.

I looked into that ISO + Wav/MP3/AFF Cue Sheet Thing by Martin Bättig and I can patch DOSBox with this but it won't compile for Windows because it uses librarys from Linux. The one i run into when compiling is LibGen and I am not a really good programmer and mostly work off of other peoples stuff to figure things out. But I know nothing about linux and its libraries so I can't do this or look into how to make it work with Windows.

EDIT 4: Gee I just can't stop reediting... anyways, Also my builds are default builds which are -i686 builds. I don't do optimized builds yet because I want to be able to support a wide base right now without having to make various builds. (Also I use a P4 to build this)

EDIT 5: Also, dir /ad /p seems to work prefectly in the new build. Thanks Qbix, now it just makes DOSBox fell more and more like the DOS I loved.
🤣

EDIT 6: I will upload these eventually but I need to rewrite some documentation here and there that I've been trying to keep up to date with everything that is going on with DOSBox. Also Direct Serial is now being built with Win32 binaries thank you Qbix for enabling it. I wondered why there was some of that in Harekiet's builds but not in mine.

And I appologize for the delay in making a new DOSBox CVS but I just had to wait. Lol, I wanted this one to be an extra special build 😀.

heh...haven't even noticed all the edits :p

If you haven't compiled yet, could you reapply my patch? I have made some code cleanups, fullscreen is handled a bit different (not sure if stretching you noticed has been fixed - AFAIK without fullfixed D3D should display fullscreen AS IS) and the mouse locking in fullscreen has been fixed. There are still some issues with toggling fullscreen, I don't know if it's SDL or D3D failing. I have added the code to re-acquire lost D3D device (when alt-tabbing from fullscreen) in the latest version, but SDL always crashes when alt-tab is used in fullscreen - even with other outputs.

@gulikoza:
I've already tried to send you a mail, but that couldn't be delivered or so. Anyway, to may question about your direct3D build:
I've tried out your latest CVS compiled version (040806) with Direct3D. It gave me a nice speed up! 😁 - Now I'm able to run Wing Commander 3 with up to 50000 cycles for videos and ~up to 40000 for gameplay (that's 10000 more than before). But to the prob:
The prob now is, my Joystick (Sidewindeder Precision Pro, USB) is not recognized anymore by Dosbox. It did work correctly with your 090704 release, though. Did you maybe change something in the joystick support as well?

Good to know it works 😁
hmm...it might be I forgot to apply the joystick patch. In any case...there are some changes being implemented currently to joystick support to work with the mapper. I might apply ih8regs' patch in the next build...

Joystick is broken in current CVS as far as I know (I did not test it). Hopefully before long this will change (somebody already submitted joystick patch, QBIX is testing it).

Mirek

Ah, thx for the info 😀 I already guessed that it might be broken in general ^^
At least now I know it's not my fault. Looking forward to the next release 😉

The "current" cvs uses the workaround patch developed by gulikoza just to at least calm the wave of irritation.

gulikoza: I'll give it another go. Don'tcha worry 🤣.