Any emulator using this (3D) filtering method?

kick · Post by **kick** » Sat Jan 13, 2007 6:41 am

http://www.hiend3d.com/smartflt.html

Looks like a 3D version of HQxX,judging from the demo.

The best I saw in emulators like ePSXe/PJ64,etc. was 2xSAI filtering.

Deathlike2 · Post by **Deathlike2** » Sat Jan 13, 2007 8:39 am

Most aren't using it probably because you would have had to render in 3D to begin with. I could be wrong, but most emus render in some form of software rendering in 2D (even if you are using OpenGL/Direct3D, including PSX emus and such), and then apply software post filter effects like 2xSAI. Applying a 3D filter is significantly more intensive than 2D, because you have to factor in the Z direction. I think I've tried one Doom engine port that uses said filter, and it was massively slow. Strict trilinear+aniso performed better than this filter.

Firon · Post by **Firon** » Sat Jan 13, 2007 9:12 am

How exactly do the PSX emus render in 2D? Because it looks like it works in 3D to me, considering it makes use of the hardware for T&L, higher res model rendering, texture-only filtering (instead of the entire screen), AA and so on.

Maybe I'm misunderstanding something.

Deathlike2 · Post by **Deathlike2** » Sat Jan 13, 2007 9:17 am

Hey, I could be wrong. In any case, HQx for 3D would be significantly CPU intensive (and video card intensive I believe, for memory bandwidth) just on the simple fact that you are not hardware accelerating it (3D hardware has been made to hardware accelerate bilinear filtering like forever).

funkyass · Post by **funkyass** » Sat Jan 13, 2007 9:17 am

not all PSX games are 3D, but thats neither here nor there.

this filter is a solution in search of a problem, as not many games use the style of artwork as textures this filter is designed to be used on.

its like asking for tri-linear or anisotropic filtering for zsnes.

Deathlike2 · Post by **Deathlike2** » Sat Jan 13, 2007 9:19 am

funkyass wrote:not all PSX games are 3D, but thats neither here nor there.

this filter is a solution in search of a problem, as not many games use the style of artwork as textures this filter is designed to be used on.

its like asking for tri-linear or anisotropic filtering for zsnes.

That would explain why DKC doesn't look much better with most filters.

blackmyst · Post by **blackmyst** » Sat Jan 13, 2007 5:19 pm

Firon wrote:How exactly do the PSX emus render in 2D? Because it looks like it works in 3D to me, considering it makes use of the hardware for T&L, higher res model rendering, texture-only filtering (instead of the entire screen), AA and so on.

Maybe I'm misunderstanding something.

AFAIK the PSX hardware could only render flat polygons. It didn't have a zbuffer or 3D transformation matrix or anything, so developers pretty much had to write their own engine in software. That's why you still get texture warping in PSX emulators even though they use your 3D card - the game is only rendering polygons in a 2D plane so it's impossible to have perspective correct texturing.

But even with flat polygons, any sort of texture filtering would work. I personally don't see the point, but then, I don't see the point of HQxX either. But that's just me.

Clements · Post by **Clements** » Sat Jan 13, 2007 5:56 pm

HQxX is available with certain of N64 and PSX plugins, but particularly in the case of N64 it more often than not does more harm than good compared to 2xSAI, creating numerous artifacts.

Arbee · Post by **Arbee** » Fri Jan 19, 2007 12:43 am

[quote="blackmyst"]AFAIK the PSX hardware could only render flat polygons. It didn't have a zbuffer or 3D transformation matrix or anything, so developers pretty much had to write their own engine in software. That's why you still get texture warping in PSX emulators even though they use your 3D card - the game is only rendering polygons in a 2D plane so it's impossible to have perspective correct texturing.[/quote]

Not quite. The PSX has a real 3D engine (including hardware T&L) and can draw tris in any orientation you please, but it's based on 12.4 fixed point math (hence the vertex wobble you see in many games) and does not implement perspective correction or Z-buffering (most games after the first generation ones did dynamic subdivision of large surfaces to hide the warping).

Nightcrawler · Post by **Nightcrawler** » Fri Jan 19, 2007 2:21 pm

You have shined light on something I've been wondering about for years. I always wondered why on a static 3D screen on the PSX, some objects would still be wobbling ever so slightly. Now I know.

kieran_ · Post by **kieran_** » Fri Jan 19, 2007 2:25 pm

Nightcrawler wrote:You have shined light on something I've been wondering about for years. I always wondered why on a static 3D screen on the PSX, some objects would still be wobbling ever so slightly. Now I know.

It's horrible in FFIX, as far as I can remember.

darkbenny · Post by **darkbenny** » Fri Jan 19, 2007 4:45 pm

kilivipin wrote:
Nightcrawler wrote:You have shined light on something I've been wondering about for years. I always wondered why on a static 3D screen on the PSX, some objects would still be wobbling ever so slightly. Now I know.
It's horrible in FFIX, as far as I can remember.

yeah, a lot of rpgs really

blackmyst · Post by **blackmyst** » Sat Jan 20, 2007 8:36 pm

Arbee wrote:
blackmyst wrote:AFAIK the PSX hardware could only render flat polygons. It didn't have a zbuffer or 3D transformation matrix or anything, so developers pretty much had to write their own engine in software. That's why you still get texture warping in PSX emulators even though they use your 3D card - the game is only rendering polygons in a 2D plane so it's impossible to have perspective correct texturing.
Not quite. The PSX has a real 3D engine (including hardware T&L) and can draw tris in any orientation you please, but it's based on 12.4 fixed point math (hence the vertex wobble you see in many games) and does not implement perspective correction or Z-buffering (most games after the first generation ones did dynamic subdivision of large surfaces to hide the warping).

Really? Well, I realise there must be a good reason why emulators don't exploit that to show textures correctly. Any idea?

sweener2001 · Post by **sweener2001** » Sun Jan 21, 2007 10:40 am

this question always pops up at least once a year, i think.

Ichinisan · Post by **Ichinisan** » Sun Jan 21, 2007 6:20 pm

It has always been my impression that the PS1 had no dedicated 3D graphics processing unit (GPU), and thus the 3d calculations and game rendering engine must be done on the CPU. Because every game must have their own engine that renders polygons and textures differently, it would be difficult or impossible to translate the polygons and textures to run directly on your PC's GPU via high-level emulation (HLE).

I also assumed that the warping textures and "loose" polygons were due to imprecise math calculations (think of rounded numbers), which would be much easier to process for a CPU that was never made for the kind of calculations a GPU is good at.

Just my guess, I've never created a program in anything but BASIC.

The N64 was the first game console with a GPU. Because GPU programming was unfamiliar to game console programmers, many N64 developers claimed that it was "too hard" to develop for and were driven away. The N64 and it's 90Mhz "Reality Co-Processor" proved to be ahead of it's time, because GPUs became an absolute requirement for ALL game consoles afterward. It's too bad that it was largely responsible for the N64's lack of third-party support.

Experts, I would appreciate any corrections.

MisterJones · Post by **MisterJones** » Sun Jan 21, 2007 7:17 pm

wikipedia seems to provide an explanation about the n64 development difficulty: http://en.wikipedia.org/wiki/Nintendo_6 ... evelopment

Firon · Post by **Firon** » Sun Jan 21, 2007 7:31 pm

Ichinisan wrote:It has always been my impression that the PS1 had no dedicated 3D graphics processing unit (GPU), and thus the 3d calculations and game rendering engine must be done on the CPU.

It does have one. The "geometry transformation engine" handled 3D. It's included in the main CPU (as is the MDEC), but was separate for all intents and purposes. It also had a GPU on another chip to handle 2D stuff, including texture mapping and shading.

As far as the N64 goes, the architecture had major problems (slow RDRAM, too small texture cache), there was no audio processor, and the default microcode was too slow.