I tried that SDL removexial of that // line in SDL_windx5yuv.c and it screws up window mode and makes it look blurred on my computer so I'm not gonna change that. Although I did recompile my SDL.DLL so I dunno maybe it'll look better. My SDL.DLL is 290 kbs when i use the full source compile
which is 60 something kbs larger than the one I had originally.

Maybe it has something better. I dunno. Since I see no hinderances when using the commented line version of Overlay I think I'll just include it when I do get a fully patched/compiled version of DOSBox out. I'm kinda holding back and I feel like taking it a bit slower than I usually do.

Plus, I just feel really lazy about DOSBox right now.

hmm, I also just seemed to have gotten a proper SDL_net.dll to compile so it's only 10 kbs now. 😀

Also if anybody is able to compile a new libpng.dll for me. I just can't seem to get it to come through anyway i try it. I need to update it according to there home page here -> http://www.libpng.org/pub/png/libpng.html .

hmm...ddraw doesn't work for me even with your build. At first I thought my builds might have something screwed-up but it seems this is not the issue. So d3d still remains the best option for me 😁

strange, must be a comp or card issue?

gulikoza,
You need to modify SDL_dx5video.c somewhere at line 1464 or so to make DDRAW work. I am using the CVS version of SDL. You'll see something like this:
#if 0 /* FIXME .....*/
....use hardware surface if requested....
#else
....always use software surface
#endif
Just change the "#if 0" to "#if 1" to make hardware surface available. If DOSBox output is set to ddraw, it requires hardware surface, or it will spit out error and fallback to surface. With the above changes, even the "output=surface" will be a lot faster, due to hardware surface. But when using ddraw, you'll get some additional speed boost because DOSBox no longer need to do scaling, hence less work during screen update.

But Ieremiou's builds already have this enabled? Or DDraw wouldn't work for anyone, right? I'll take a look and try to recompile SDL...

Ok, I gave your new build with D3D a shot.

I'm playing Star Trek A Final Unity in Dosbox. It's the only way to get the game stable on today's systems. (I don't even think pure DOS bootdisk would work.)

Dynamic core crashes the game on startup so I'm using normal core.

Your latest Dosbox build from your site (with D3d, SSE, 3DNow (could SSE2 help too?)) is definitely a bit faster than the "stable" build from the dosbox site. I'm running a Athlon 64 3000+ and can run about 14000 or so cycles without sound problems. That's up from 12,500 - 13,000 with .61.

However, I'm not sure if D3D gained me anything. I'm running a Radeon 9600 with the latest drivers. Overlay and D3D seem very similar in speed, and look identical as far as I can tell (havent tried ddraw yet). Odd thing too is I couldn't see a difference between normal2x and advmame2x.......Speed was the same too. This game may just be weird or something.... I'm using a hardware scale of 1.5 (my screen is 1280x800.) I am running windowed....i did read that that is slower.

Does the included SDL.dll have overlays going in hardware?

BTW, I am extremely interested in your TIE Fighter SVGA goal. Please keep us informed on that, and remain vigilant!!!!

Well, since you are using my version you can start the game with normal core and then switch to dynamic (ctrl-3) as soon as the intro video starts playing. I only played it for a short time, but the game seems to be working ok with dynamic core. Also - sometimes it helps if you use a dos32a extender instead of dos4gw (don't remember, I found link somewhere around here), most games will then start with dynamic core as well (not sttng though, it has dos4gw already in the executable - sttng.ovl which is ran by sttng.exe after it sets it's paging stuff)

The scalers are as far as I can tell only used if the game is low-res (320x240). Didn't study the code really, but it seems if the resolution is high enough dosbox will not use scalers (if the resolution is 640x480, advmame2x should give output 1280x960, right, but this does not happen). That's why you don't see any difference.
Well, overlay is sometimes blurry in my games. Again, this should be more apparent with low-res games. I explain this blurriness as hardware bilinear stretching so I guess overlay is hardware accelerated (The builds are all SDL-1.2.7 I got already compiled from the page, if anyone is really interested - see the code 😁). I really must get to recompile SDL with modifications kjliew suggested...

It's weird gulikoza but with my builds and my computer overlay is the crispest I've seen. Especially with pixilations. When I use anything else, I get a blurriness. I am using the standard SDL libs and everything.

Note: You'll have to update your patches btw gulikoza cause the CVS has just included a new core called Simple. And your Direct3D-Vanilla.patch is not up on your server. I just tried it a few minutes ago.

And to swaaye. I first played Star Trek: A Final Unity on my P2 back at home and that's the machine I've had it play the best on. No other machine has played it as good even DOSBox still needs a LOT of work to be even close to comparable.

btw I tried what kjliew sugguested gulikoza and it appeared to screw up my overlay screen. I'm not sure but it didn't play the same as before. It also seemed to start causing problems with other peoples machines so I don't find it acceptable.

Also I used fullfixed with my scallers and you have to make it comparable to your screen resoultion to have it look like the games originally resolution of 320x200 or 320x240. For instance my screen is 1280x1024 (because it's a flat screen)
So i have my settings to
fullfixed=true
fullwidth=1280
fullheight=1024
and it looks prefectly on my machine.
Exactly the way (it should look) even if it shows black on the top and bottom because the pixels are correctly drawn. Otherwise the pixels may become Stretched without that black space.

(Btw, this is only in fullscreen) the reason for the word FULL before each setting there.

EDIT: Ddraw Works on my system with my builds so far. I don't see why it isn't working for anybody else. Everything works on my system... 😮 My system must be whacky or something.. cause I don't get why everybody else has so many problems... Also I'm using the official Win32 Compile DLLs provided by libSDL.org. I don't trust my compiled DLLs anymore...

priestlyboy,
Overlay by nature is a bit blurry, due to hardware scaling and filtering. Same thing happens to ddraw if you got it to work correctly. The color from a true hardware overlay will also look a bit different due to color space conversion. Overlay is not RGB. DDRAW, however, does not have this kind of color issue. Did you check your DOSBox log? Are you sure that you're actually using overlay/ddraw as DOSBox will fallback to surface if something failed?

Can you post your system specs? I wonder why you didn't notice the difference in CPU utilization if you don't get overlay or ddraw working properly.

This is what I have experienced speedwise, from various DOSBox output as well as 2 different systems.
Matrox G400 - ddraw, overlay, surface, opengl. D3D doesn't work.
ATI Mobility Radeon 7500 - ddraw, surface, d3d, opengl, overlay.

Another way to check for true hardware overlay is that DOSBox window when using overlay, cannot be overlapped by other windows. If your DOSBox window can be overlapped, it's not an overlay.

swaaye,
You should try dynamic core for protected-mode games. Normal core doesn't give you any speed after 10,000 CPU cycles, and it sucks on CPU utilization, too, which in turn causes sound problem. Your system should be able to handle more than 20,000 cpu cycles. It's not very difficult to replace DOS4G/W stub. A lot of free DOS4G/W replacement DOS-extenders come with tools to re-bind the EXE with new stub.

CPU - Gateway Pentium 4 - 2.4 gHz
Graphics card - Nvidia GeForce 4 Ti 4200 w/ 128 DDR
Memory - 256 mbs of RDRAM.
OS - Windows XP SP1a w/ DirectX 0.9c.
Monitor - LCD Screen Display (might be interesting to note)

As I see it we are coming from two sides graphics card vendors.
Primary settings:
fullfixed=true
fullwidth=1280
fullheight=1024

When in fullscreen:
1) Overlay looks the cleanest to me;
***(much brighter colors) and has --- black bands on the top and bottom of the screen which would of course not be there if it was a "properly dimension" 320x200 screen but since we live in the improperly dimensioned 320x240 kinds of screens the black bands SHOULD be there for proper scaling.
2) ddraw draws the image in the upper right part of the screen;
***|_ <- the left most and bottom most sides have a thick black band.
3) direct3d works and looks good but takes up the whole screen from top to bottom unlike overlay that draws in proper deminsions;
***(proper being enlarged 320x200 and 320x240)
4) Surface draws as a little box no matter what in fullscreen; (unless fullfixed=false)
5) Opengl looks and draws like openglnb and overlay but is much blurrier. (darker looking)
6) Openglnb looks much like overlay but draws a touch blurrier. (darker looking)

I used to stick with openglnb until I found how good overlay started working for me on my system and I've stuck to how overlay is working for me.

Problem is.. I don't think it is possible to show you what it looks like in fullscreen.
And this is where I'm coming from in all this.
In fullscreen, to me overlay looks the most proper of showing the true image (even if as a window it allows other windows to be placed over it.)
I don't thinkg overlay works that way in DOSBox anyways. And when i did your customizations like in this thread. It messed up what overlay was doing for me in DOSbox.
I'm not talking window in any of this. To me any of these look the same in window.
In overlay they look like real pixel blocks.
I wish there was an easy way of showing this besides having you come to my room in NYC. 🤣.

BTW: I don't see any speed difference for using any of the scalers in my opinion. I guess I'm not looking hard enough for it. CPU usage of course is annoying but .. aren't you just wanting to play just the game?

If you're talking about drawing from window to fullscreen then overlay takes probably the longest to draw but when you're actually playing I see no difference in speed.
The quickest I've seen from window to fullscreen is openglnb.

Maybe I'm lucky. I dunno. This is how it's been for me since I've used DOSBox.

gulikoza, I replaced STTNG AFU's ancient DOS4G with DOS32A 😀

DOS32A comes with a utility that will unbind an existing extender from a DOS app (friggin amazing!!!). You are right, the STTNG.OVL file contains the extender. It is an executable as well.

So, you get the DOS32A package from http://dos32a.sourceforge.net/. Just decompress the all the files to a directory, maintaining the paths in the ZIP. Open up a XP DOS box and set an environment variable for DOS32A. "SET DOS32A = c:\DOS32A" for example, wherever you unzipped it. Put SB.EXE from the zip file's BINW directory in the STTNG folder.

Now, run "SB /R /BNsttng.new sttng.ovl"in that dos box.

You now have a new sttng.new file that has the massively better extender built in! Backup the old STTNG.OVL just in case you need it, then rename the .New file to .OVL.

I haven't played the game much yet, but it will now load in Dynamic core mode. It also loads a lot quicker. The game is MUCH snappier with load screens, say going from bridge to tactical. No more pauses between dialog lines. This just seems too good to be true, and I imagine it will bring more stability to the game.

edit* - kjliew, I just noticed that you suggested this, 🤣.....btw, how does the 'ol G400 look compared to the 7500? I'm a former MURCer and still have my G400 and G200 around. Your site is a wonderful resource, btw.

Well...I thought there must be a utility to change the dos exender, but I didn't bother to check 😁.
This is turning into quite interesting discussion. I recompiled SDL yesterday (but not dosbox, so some problems might be because of that) and I also was not pleased with the results. It was rather late, so didn't have time to check everything 😀. Both ddraw and overlay are extremely blurry. Even in the starting dos window where there should not be any scaling. I don't know what overlay is doing when #define USE_DIRECTX_OVERLAY is commented out (I've checked SDL 1.2.7 sources, it is commented out) - it's not hardware since the window can be hidden, yet it's a lot faster then surface (and less blurred than overlay with modified sdl code). kjliew?
priestlyboy, less cpu for graphic display is more cpu for cycles 😁. That's why lowest cpu usage output is prefered! As for fullscreen D3D, it's a feature not a bug 😉. This is one thing D3D is different from other outputs, it will always display image to the borders in fullscreen. Since most monitors are 4:3, this will always give correct aspect ratio and if you're using 1280x1024 there's gonna be scaling no matter what. I prefer 4:3 image rather then squashed graphics. Unless somebody persuades me otherwise that's how it'll stay 😀. Of course the patches are going to be updated as soon as I have some time, I can't follow every cvs update 😁 (and the broken link to the vanilla d3d patch is there on purpose, well...kinda, I was too lazy to update it at my last update 😉)

(mental note: cut down the smileys)

hmm that dos32a bit sounds pretty cool. I'll have to check it out myself when i get back from work.

EDIT:
silly man.. gulikoza. get it straighten out... 🤣

Anyways yeah, I personally am not too worried about cycles... since I feel like I have a decent enough computer to handle this.

Reason I use 1280x1024 is my lcd screen sucks and I have to be at the highest available resolution for it to work. *need a better LCD screen*

All LCDs are only made to display their native (==highest) resolution. All other modes are just scaled-up (which LCDs do a pretty poor job, you're better off with dosbox scaling I guess). What I was trying to say is, no matter what resolution you use in fullscreen IMO all games should be exactly the size of your screen since this is how they were run in DOS...

There you go...I've updated all the patches (including the missing one to apply to clean cvs 😁). But I think I lost sfx in Doom. This might be related to harekiet's patches...or I've messed something else up...

aight, cool man guli. Yeah LCD are screwy but they do take up less space. But from my prespective every other Output rendering scretches or blurs the pixels. The only one the works for me (not for everybody it seems) is Overlay. It looks "near prefect." Bright colors and sharp pixels. I like how it looks and that's how I am going to stick with my compiling. So I'm gonna continue to use the standard DLLs provided by libSDL except for the rare one that I picked off of somebody elses program. (thanks for that goes to them majorly)

If somebody thinks that they can provide a better build for a different set of computers and graphics cards. Go ahead. I'll continue to support the crowd at mypixels.dk/forums.