rcblanke:

Further testing:

C&C - You were dead right on C&C. Dynamic core was the culprit there. Switching to normal core fixed that one. This game ran no better or worse with the scaler changes. Still too slow for me to play. And upping the cycles caused too much sound stuttering for me to enjoy the game.

System Shock - For me, both cores gave me the same "Files=" etc etc error message. Even on the AEP build.

`Moe` wrote:

Kronuz wrote:

I suppose it should be typedef as a RECT in Windows and probably to other datatype in other platforms.

Don't do that. Your code should not contain any #ifdef's or platform-specific code in any way. SDL is meant to be your cross-platform toolkit, so only use SDL data types, otherwise you won't get a portable DOSBox. Portability is more than "runs on windows and linux".

Yeah, I know... but I don't know where to define that RECT struct (maybe SDL already has a RECT struct... I'll check)

rcblanke wrote:

@kronuz: I can live with your temporary(?) solution most certainly! Unfortunately, your latest build displays the dreaded "This application has failed to start because the application configuration is incorrect" message again...

That's interesting... my latest build mostly changed as the cvs changed, perhaps there were some issues at the time I checked out the cvs... I'm updating now.

[edit]
Not really, it doesn't look like it was a cvs thing, what's exactly the message displayed and when?

Kronuz wrote:

Yeah, I know... but I don't know where to define that RECT struct (maybe SDL already has a RECT struct... I'll check)

SDL has a rect SDL_Rec, but it's defined somewhat differently from RECT (and only sdlmain.h include sdl headers so it's only valid there). I don't see the problem with current define, it just has to be named something else. 😁

gulikoza wrote:

Kronuz wrote:

Yeah, I know... but I don't know where to define that RECT struct (maybe SDL already has a RECT struct... I'll check)

SDL has a rect SDL_Rec, but it's defined somewhat differently from RECT (and only sdlmain.h include sdl headers so it's only valid there). I don't see the problem with current define, it just has to be named something else. 😁

well, "named someting else" and also probably put somewhere else 😜

Hey, gulikoza, also, in my latest patch (from yesterday) could you please check if the double buffer works for D3D and OpenGL, 'cause I'm not sure if it does... I don't have D3D in my builds and for some weird reason my computer freezes when I try to use OpenGL (that's been a problem ever since I got my computer, it's not DOSBox related)

Kronuz wrote:

That's interesting... my latest build mostly changed as the cvs changed, perhaps there were some issues at the time I checked ou […]
Show full quote

rcblanke wrote:

@kronuz: I can live with your temporary(?) solution most certainly! Unfortunately, your latest build displays the dreaded "This application has failed to start because the application configuration is incorrect" message again...

That's interesting... my latest build mostly changed as the cvs changed, perhaps there were some issues at the time I checked out the cvs... I'm updating now.

[edit]
Not really, it doesn't look like it was a cvs thing, what's exactly the message displayed and when?

Happens to me too(BTW, great patch, thanks.):

Og wrote:

Happens to me too(BTW, great patch, thanks.):

hmm... it seems it has something to do with the compiler... I'll have to check that later 🙁
Anyway, gulikoza's cvs build now has my patch (hopefuly that one does work for all of you, as he has a lot more experience compiling DOSBox)
I don't know if he has updated the build with my ltest patch (from yesterday, Dec 03)

First, I'll be the next to say this change is great work.. kind of a gutsy optimization to attempt too 😀

I've tried out gulikoza's dosboxcvs-051202 build (which includes the optimization that was available at that time). I noticed that things ran much improved of course. Beyond that, I noticed two things:

1. When normal3x is selected, a mode switch to 320x200 (eg. mode 0x13 -- certain because I ran an old program of mine) results in a surface that is stretched vertically 3x, and not stretched horizontally at all. This happens both fullscreen and in a window. It may be relevant that my LCD is 1280x1024, and that is what I set my fullresolution to in dosbox.conf. Maybe someone has an explanation for this. A related note: a normal4x scaler could be of some use for LCD users, since 4*(320x200) is 1280x800.. fits pretty nicely.
Edit: I've noticed that in 'surface', it gives me 3x height surface. If I choose 'direct3d', then it actually gives me a 2x height surface. In 'ddraw', it simply crashes out (!).

2. Enabling aspect correction is pretty devastating (I have a 1280x1024 LCD, so I enable it sometimes). I hadn't noticed that before, because most newer programs weren't running okay under any settings anyway. However, since plenty of things now run great with the aspect correction disabled, it's quite noticeable 😀

those reports might be related to the fact that dosbox uses the 2 time scalers internally a lot and some of the code in this thread adds 3x to the general scaling code of 2x.

augnober wrote:

A related note: a normal4x scaler could be of some use for LCD users, since 4*(320x200) is 1280x800.. fits pretty nicely.

2. Enabling aspect correction is pretty devastating (I have a 1280x1024 LCD, so I enable it sometimes). I hadn't noticed that before, because most newer programs weren't running okay under any settings anyway. However, since plenty of things now run great with the aspect correction disabled, it's quite noticeable 😀

My solution for both of these may be of some interest to you. None of my games ever go above 640x480, if you use higher in games this'll cause issues. Fullfixed is on and set to my 1280 x 1024. I use normal2x as my scaler and openglnb for the output (even on my Radeon it's a bit better surface), and hardware stretch it to 2.0. The result is that the image always fills up the screen nicely without distortions.

Ah, quick responses. That means I better re-post the edits I made to my post 😀

I noticed this about normal3x after my original post:
- I've noticed that in 'surface', it gives me 3x height surface.
- If I choose 'direct3d', then it actually gives me a 2x height surface.
- In 'ddraw', it simply crashes out (!).

neowolf: Thanks for the suggestion. When I'm actually playing or running some app, I normally use direct3d with the 'none' pixelshader to get it to fill the screen with no filtering/blurring. Up until recently, I've been allowing aspect correction to be set as well.. but that's gotta change. I'll try it out 😀

Edit: (slightly off-topic stuff) Thought about this a bit -- commonly noted knowledge, but good to have here. My display is 1280x1024 with square aspect. 320x240 on a 4:3 display also has square aspect. (my LCD is slightly taller than 4:3 -- it's 5:4 instead). So, scaling 320x240 mode up by a fixed factor and drawing on my display is fine (keeps correct aspect). However, with 320x200 mode, scaling both dimensions by the same fixed factor will never have a good result, because the pixel aspect will never match. Scaling to fill the screen doesn't correct it either, because my display dimensions are 5:4. So currently, I need to enable the aspect correction for it. If the hwscale option was separated into hwscalex and hwscaley, then I'd be able to fix it. Anyway.. back to the topic now.

@Og and rcblanke: I've found what the problem is, I was linking dynamically (again 😜) sorry about that.

@augnober: I'm checking the Hardware 3x scaler right now, I hadn't checked it since gulikoza added it... I already found a small bug so that might be it.

In the meantime, check this new build of mine
Qbix: Attachment removed

This is the same binary as above (almost) this one also has other option in the DOSBox configuration file: "tvmode" which lets you tell DOSBox that you want to use TV scanlines for *all* the scalers (whenever this is possible) including the command line.

Edit: well, not all scalers, I've currently just added support for: TV, TV2x, TVAdvMame2x and TVHq2x. Note that you can also leave tvmode set to false and use any of the TV scalers and it will work as it used to work (TV scanlines only when that specific scaler is used and not any other)

Edit: Okay, the patch is up both in sourceforge and here at the forums. I've made it simpler and it's now even a bit faster; I have put duplicated code in macros, as Qbix suggested, and the scalers are now much more readable. It should be very easy to add new scalers now.

Qbix: Attachment removed

I notice one new problem in the new build (as compared to the dosboxcvs-051202 build by gulikoza).

If I have select output=ddraw with fullfixed=true, and switch to fullscreen, whatever was currently in the window gets scaled up to fill my screen... but then, any further display is in a small rectangle (window-sized) in the top-left (leaving the rest of the scaled-up image intact/untouched). Starting up in fullscreen mode has the same effect. It's sort of cool to watch in some cases.. It makes it easy to see the areas that are really being updated after the switch 😉

It seems the other output modes don't have this problem.

augnober wrote:

I notice one new problem in the new build (as compared to the dosboxcvs-051202 build by gulikoza).

If I have select output=ddraw with fullfixed=true, and switch to fullscreen, whatever was currently in the window gets scaled up to fill my screen... but then, any further display is in a small rectangle (window-sized) in the top-left (leaving the rest of the scaled-up image intact/untouched). Starting up in fullscreen mode has the same effect. It's sort of cool to watch in some cases.. It makes it easy to see the areas that are really being updated after the switch 😉

It seems the other output modes don't have this problem.

Indeed, I hadn't checked this... it seems the problem is also there when DOSBox changes the resolution. This is a minor issue of too much "not updating" 😜 I'll look into it later 😀

Indeed, I hadn't checked this... it seems the problem is also there when DOSBox changes the resolution. This is a minor issue of too much "not updating". I'll look into it later.

Ah. For a minute I thought you'd misunderstood me, but I think you're kind of right. What I'm seeing may be related to the fact that I have an LCD. When displaying a small surface in fullscreen, my LCD/driver normally displays it at the center of the LCD... but because the scaled-up stuff never got cleared, the surface is large, and so it must display the whole thing (even though the only part that matters anymore is the small surface at the top-left). Well, maybe that's what's happening... I don't know if my LCD considers the contents of the surface, or just looks at the dimensions of the surface. (This kind of LCD behaviour is a mystery to me.) Anyway, it's a fairly low priority fix if it's specific to LCD+ddraw.. could fix it myself probably if it gets into cvs.

Kronuz, You... Just... Plain.... ROCK. Thanks man. Seriously.. Thanks.

Has anyone looked into putting the SMART TEXTURE FILTERING that is listed in a link from this post?
Magnification Filter

Thraka wrote:

Kronuz, You... Just... Plain.... ROCK. Thanks man. Seriously.. Thanks.

Has anyone looked into putting the SMART TEXTURE FILTERING that is listed in a link from this post?
Magnification Filter

That filter aside from being VERY CPU intensive, is about mapping a texture properly onto a model without distortion. The relevant filter for scaling low res things is the HQXX series, which we have in this patch! 😀

Ok thanks for clarification 😀 It's just so purty.. 😀

One thing I noticed with the EXE he has compiled and supplied on the fourm (latest post with his exe) is that launching it (i renamed it) doens't tickle the windows firewall and prompt me to block or unblock it, while a renamed normal 0.63 exe does.

Has the modem\tcp\ipx emulation stuff been disabled in his build??

Smart texture filtering as linked in that post is essentially OpenGL-HQ (see patches forum). Of course, OpenGL-HQ doesn't do any 3D stuff, but as far as DOSBox is concerned, it's equivalent.