VOGONS

Common searches


Reply 100 of 145, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

You could at least try frameskip 1 in order to compare software scaling to openglhq. That would show if it's something specific to your machine or if it's the same behaviour I see here.

Also, do you have some other CPU-heavy game? I don't have any game of the TES series, so I can't compare/test myself.

Reply 101 of 145, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

I'll see what I can do. In the meantime, TES: Arena is available for free on Bethesda's web site: http://www.elderscrolls.com/downloads/downloads_games.htm

Reply 102 of 145, by 3803

User metadata
Rank Newbie
Rank
Newbie

Graphics sure are looking crisp now. 😎

But I do notice that the latest build(27-4)filtering looks different...(a bit messy) The build before that looked like in the screenshots posted...the difference is very clear at the dosbox console.

It looks a bit like inaccurate scaling and that some pixelrows are being skipped.

Reply 103 of 145, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Strange, I just disabled the problematic NV extension. Do you have a screenshot? Probably just a bad build, though. Sometimes the tables are not generated correctly while cross-compiling. You shouldn't use my binaries anyway - I know how to program, so I could make dosbox send me all of your mp3's 😉

Reply 105 of 145, by 3803

User metadata
Rank Newbie
Rank
Newbie

Weird, I remember swapping between the two last builds and having this problem (so with the same config) Guess what, it doesn't seem to happen anymore. Sorry for the possible false alarm.

Anyway I did some performance testing.
On a 1.7Ghz I found that mame3x was not significantly (but somewhat) slower then mame2x. Both filters had some glitches in the 3D-game I played (objects that were steady on screen are being altered all the time because of the filtering.

Openglhq had a lot less of these artifacts, and runs a bit faster in fullscreen. But it looks so much better for sprites 😀 Performance is comparable with mame2x while it looks better than mame3x and it works at the dosbox "console" too.

Great job!

Too bad these filters don't work very well for 3D games but it is still a major step forward. Pixelshaders are the way to go for sure.

Reply 106 of 145, by 3803

User metadata
Rank Newbie
Rank
Newbie

Another thing, for some reason, there's this filtering thing that has been playing in my mind lately, and I would like to get it of my chest.
I've been thinking about a new filtering technique that more relates to 3D games. (while I'm not that much of a programmer, it's just an idea)

Since a lot of old dos 3D games are fully or partly made out of flat polygons these could be detected and converted to straightline-shapes. The areas are probably quite easy to detect because most games are 256 colours, and simply because the polygons are flat. This way the outlines remain.

The next step is to do the same for textures. Extracting (rather large) texture areas, optionally convert them to straightline shapes and blur these, while the outlines remain. Also optionally, the blur should be dynamically. The bigger the texelareas are on the texture(for instance when a texel is rendered from a very near distance), the more it gets blurred. Some stuff is possible on nowadays cpu's. This dynamic blur thing is not.
Possibly, the outlines could remain while nothing is blurred, I'm not sure.
Because in both flat and textured techniques, straightline shapes are being used...the new image could be of any resolution.

In both cases, accuracy should be adjustable in many ways. Because in most cases a palette/256 colours or less are being used it might be easier(faster) to detect areas.

However, it's just an idea, it would be nice to see this kind of stuff in action some day.

Reply 107 of 145, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Sorry, there's no way to do that. DOS games are not 3D. Never ever. They render to a 2D screen. Some have internal 3D calculations (surprisingly, DOOM does _not_ do that), but that's something that is part of the game being run. DosBox only sees 320x200 pixels. You're right, if it's flat shading, we could detect the outlines. And guess what: that's what OpenGL-HQ does. But if you add texturing to that (nice example: Frontier: First Encounters), we're basically screwed. How can we distinguish a line on the texture from a polygon outline? In addition, just because it is texture doesn't mean it may be smoothed.

In short words: forget it, not possible 😀

Reply 108 of 145, by 3803

User metadata
Rank Newbie
Rank
Newbie

You are right, in some cases, it is simply NOT possible. But I was thinking, if a human can make up a somewhat misinterpreted 3D environment out of 320*200 pixels, why couldn't a high end pc do so? (same goes for hq2x, 2xSAI in a 2D environment) This filter, like hq2x should only use the outputted image. Any improvement on this would be nice. It's not like hq2x does everything "like it should", but it looks a lot better.

I noticed that hq2x is somewhat able to detect the outlines of flat polygons.
But it only works well for small complex shapes. (e.g gamecharachters), not for a (even flat) white polygon that consists out of 4 points. The edges would be screwed,-you get these rounded pixels-, and so would the 3D illusion. The textures don't have to be smoothened...but in any case the outlines (only those that are detected the fastest by a human eye) should be. In doom games the most essential outlines would be those of floor, ceiling, walls...Outlines should be converted to vector so thay can be scaled to any resolution. Vector-outlines should be used as a clipping-mask when the texture is redrawn to it. it would be very hard to distinguish monsters from those but I doubt if any improvement isn't impossible.

But I'll cut it out now...since I have kind of killed this great topic.

Reply 109 of 145, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

You know, seeing things like humans do is an astonishing difficult task. For any given 2d picture of a 3d object, there can be multiple 3d representations. Humans usually choose the right one (not always: check out my favourite artist Escher), but computers can't - they lack real life experience.

On-topic: Can nvidia users please test today's build? I've found another bug and reenabled NV_pixel_data_range. Please tell me if you see any crashes (go to/from fullscreen mode often to trigger the crash, if present).

Reply 110 of 145, by 3803

User metadata
Rank Newbie
Rank
Newbie

Thanks for the reply,

Newest build: probably not relevant since I have ATI hardware but yes, switched between fullscreen and window several times, no crashes as usual.

Though, it takes a while to switch between them, thus it takes a while to refresh the windows GUI. (game images on open windows)

Reply 111 of 145, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Indeed, not terribly useful but still nice to hear it works 😉

The refresh delay seems to be an ATI peculiarity, I see it too. There's a lot of memory freed and reallocated on a resolution/fullscreen change. I guess that takes some time when the GPU is involved.

Reply 112 of 145, by priestlyboy

User metadata
Rank Oldbie
Rank
Oldbie

*hmm* well I get no segfaults or anything but I'm getting rather nasty CPU banging when I try to run any game when using Opengl/nb. I tried it on Ultima6, ROUND.COM, Sierra games, and others.

The sound/video skips but there's no reason for it to skip my cycles are at their everyday normal level.
A couple times when trying it on Ultima 6. I get a Microsoft abnomarl runtime termination and memory read error. I'm guessing there might be a memory leak somewhere in this latest build?

Note: There are no problems in the console but only when trying to run any game or program. *weird*

Ieremiou
----------
Helping Debug DOSBox.

Reply 113 of 145, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Is the speed problem better in earlier builds? If so, can you tell me which build introduced it?

Guess I'll have to get inside and see what opengl calls can be moved to the init section. Unfortunately, OpenGL-HQ needs more initialization calls, but that shouldn't affect opengl/openglnb.

And yes, I have also seen another memory issue, I can reproduce it a little bit, so expect a new build soonish.

Reply 114 of 145, by Jiri

User metadata
Rank Member
Rank
Member
`Moe` wrote:

Jiri, what app is that, and is it freely distributable? It sounds a bit like it's trying to use 15-bit graphics in a 16-bit mode. Or my VESA info struct may be buggy.

The game has a strange name D (Acclaim, 1995). It is not freely distributable although it can be found at abandonware site. But it is a big download (CD ISO) so I think the best option is to wait for Harekiet´s VESA code.

Reply 115 of 145, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

priestly, I was unable to get any crash anymore, not even the one I thought I was seeing. Can you find out more? Do you get a decent backtrace when you run it in gdb?

EDIT: I am also unable to see performance problems of any kind. A quick non-representative check with the X-Com intro movie shows these numbers (highest cycles without sound dropouts):

overlay: 23000
opengl: 23000
openglhq: 18000 (78%)
surface with normal2x: 16000 (70%)
(all with frameskip=0, hwscale=3.33)

Out of curiosity, here are some alternatives to openglhq:
surface with advmame2x: 15000 (65%)
surface with hq2x: 11000 (48%, but frameskip=1)
opengl with advmame3x: 6000 (26%)

Which is all just as expected (well, that slow surface is strange, but who cares). Note that I run sound at 48kHz, ATI Radeon Mobility 9700 on Linux, Athlon64 3700+, 32bit desktop, windowed mode.

If you see drastical different performance, please test multiple alternatives ofr comparison, like I did and post it, including game(s) tested.

EDIT2: I have just checked against a clean CVS compile, and plain opengl was slower. It only made 11000 cycles using otherwise the exact same options (which is mostly expected, as multi-threading makes better use of the available hardware).

Reply 116 of 145, by bkman

User metadata
Rank Newbie
Rank
Newbie

Hi,

I would very much like to try your gpu scaling method with dosbox, Moe, but so far I have been unable to because it crashes when starting dosbox with openglhq set. I have a Radeon 9550 with the latest Catalyst drivers, and I have tried both your and guilikoza's recent windows builds.

Do you think that you can possibly fix this problem?

Reply 118 of 145, by bkman

User metadata
Rank Newbie
Rank
Newbie

Wow, thanks! That did the trick.

My card is not the best, but I can run games at 3X scale with a frameskip of one quite well, and it looks fantastic! I'd imagine that cards with more powerful shaders would have no trouble with this. Also, it definitely faster than the software hq2x by about 40% on my card.

Btw, I was wondering if the same optimisation that the Zsnes hq?x uses can be applied to the shader version: that is I'm talking about how it checks if a pixel has changed from the previous frame, and does nothing if it hasn't, resulting in big speedup in still scenes.

Reply 119 of 145, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

* Split the topic into DOSBox and SDL version threads *

SDL version thread is here: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Hope you don't mind, Moe - I thought it would make things easier to separate things a bit.