ATI Truform?

[KyJelly]

any way to impliment it in chankast or possible other emulators as well?

 

[AndreaSpooky]

any way to impliment it in chankast or possible other emulators as well?

:huh:

 

[Clements]

The problem with that is, emulated games were never designed with Truform in mind. Implementing it is not beyond any plugin author by any means, but the problem is making it look decent without everything being distorted. Orkin toyed with it, but found that it looked crap in most situations.

 

[mezkal]

I don't think that tesselation SHOULD work within a Tile Renderer. The two are at opposite ends of the poly processing spectrum. One adds triangles, while the other takes them away.

Who knows tho - personally I never thought the DC's graphics lacked in any way. Certainly not in terms of 'roundness' potential.

Cheers,

mezkal

 

[jdsony]

Certainly not in terms of 'roundness' potential.

Yeah look at Dead or Alive 2. Doesn't get any rounder than that :bounce: :bounce:

 

[KyJelly]

the reason i asked was i was playing ready to rumble and thought that the "joints" could move together better

 

[Jabaturbo]

I don't think that tesselation SHOULD work within a Tile Renderer. The two are at opposite ends of the poly processing spectrum. One adds triangles, while the other takes them away.

Mezkal,

I don't mean to be an ass, but a tile based renderer won't really "take away" any triangles. It just avoids rendering the ones that won't show in the final rendering of a particular scene. For all practical purposes, occluded or not, the triangles are still there... no matter how the scene was rendered.

 

[mezkal]

Jabaturbo,

I don't think you come of as an ass so that's no problem. We're not talking abt a real Tile Renderer here we're talking abt an emulated implementation. I know exactly how Tile Renderers work and obviously you do not. So let me clarify my point of view on this subject. The main function of a tile renderer to optimize the render pipeline by removing from scene any occluded surfaces, textures and/or shaders PRIOR to them reaching the poly and texture alignment engines.

In the case of Chankast it is emulating the PVR's Tile Render functions. That is too say, it is implementing Tile Rendering on cards that basically don't do it (well not as much as the Katana at any rate). My point is that, if tessellation is implemented within Chankast I think we will so obvious drops in perforrmance as the triangle delta increases. Truform generally tessellates by a factor of 1 to 2 that means in terms of triangle date we will see at minimum a 50% increase of 'triangle traffic'.

I don't believe, however, that it isn't possible. Just that I don't think it will work within a plugin implementation. The whole renderer would need to be rewritten to compensate for the increase in triangles.

Cheers,

Mezkal

 

[Nightmare]

The problem with that is, emulated games were never designed with Truform in mind.

Clements is right... chankast is an emulator... i mean chankast only use our gfx card to show an already calculated result by the dreamcast games... so truform is useless here, and in all emulators...

see here to see what is truform :
http://www.ati.com/developer/truform_faq.html

 

[MasterPhW]

see here to see what is truform :
http://www.ati.com/developer/truform_faq.html

THX, now I had read what it is... but I don't really understand it... can say somebody in a simple way?
And if it's a ATI feature, why it couldn't be used in the (near future) graphic plugin system. Somebody could use the features for a gfx plugin, couldn't he?
THX if sb would reply.

 

[Nightmare]

can say somebody in a simple way?

to make short : it's a specific ATI feature, basicaly it add specific instructions to treat polygons in a different way, to otain a different result (a beter result in theory).
but you can't seriously use this feature with an emulator, because in that case you have to intercept the classic instructions calls, and use these specifics instructions instead... (and after lot of cpu work)... so it will dramatically slow down the emulator...

Edit* anyway, if it allowed convincing result, be sure that nvidia would have added his own instuctions set, a year ago (truform is an old stuff now)... and it's not the case...

 

[mashakos]

My point is that, if tessellation is implemented within Chankast I think we will so obvious drops in perforrmance as the triangle delta increases.

That's correct but it's not the real reason. If truform was used to tesellate all the polygons on screen without game programmers sticking their hand in, there will be a drop in performance anyway wether it's an emulator or a PC game like Quake 3. Truform cannot be used on all the polygons in a game or it will overload the gfx card. The only way to use truform is by customizing how it will run - by using it on some polygons.
Truform is a technique for game designers, they specify where truform will be used in the game and when. If the game is made of large outdoor environments, then game designers will not use truform on the ground as it doesn't need too much detail and they also won't apply truform on faraway objects as they won't be too noticeable.
So to make truform work you have to program it to work at certain times and on certain objects.

The problem with an emulator like chankast is that the emulator coders can't tamper with the game code itself, they don't have a say on how soulcaliber characters animate or what outfits they should wear so they can't program truform to react to the emulated games. They can't tell the gfx plugin for example: "Use truform on sonic's head but leave his sneakers" because there is no way for the emulator to crack the game's program code and show the gfx plugin where sonic's head is or where his sneakers are.

In the end, if Truform was used in chankast it would just tessellate or add detail to the whole screen which is too slow.


and by the way...

The main function of a tile renderer to optimize the render pipeline by removing from scene any occluded surfaces, textures and/or shaders PRIOR to them reaching the poly and texture alignment engines.In the case of Chankast it is emulating the PVR's Tile Render functions. That is too say, it is implementing Tile Rendering on cards that basically don't do it (well not as much as the Katana at any rate).

Seems you bought into sega 's marketing hype :whistling


Let me say 1 thing: Every 3D engine in existance uses the hidden surface algorithm. Every one. And the technique is usually called backface culling. Backface culling is the technique in which polys/textures that are not visible don't get processed. PVR's 'engine' isn't cutting adge anymore and emulating it isn't too hard. Anyway the main thing that slows down emulation is how different the original machine's architecture is from the emulator.

You can't say that the Saturn wasn't emulated for so long because it had a great graphics engine

Dreamcast is basically a PC with it's PowerVR and WinCE. The more complicated the original machine's architecture, the harder it is to emulate. That's why the saturn wasn't emulated for a long time and why PS2 emulation is facing problems (because the PS2 uses a system that was deliberately designed with GPU'S, FPU'S,SPU'S and even an intel 233MHz pentium MMX by sony to be too complex to emulate - but the emu authors aren't giving up!)


The dreamcast has pretty standard Directx 7 based hardware features and some of them are: Bilinear/trilnear filtering (dreamcast's "cleaner than psx" textures), antialiasing, chrome/sphere mapping (the water effect in ecco, the whale's skin in sonic adventure), alpha blending transparency, vertex buffering (the rippling clothes of soulcaliber fighters).

 

[Nightmare]

Dreamcast is basically a PC with it's PowerVR and WinCE. The more complicated the original machine's architecture, the harder it is to emulate.

it's not really true mashakos... the dreamcast had been designed to be easily programmed, like a pc, yes... and a ps2 has his own particular architecture, yes again, but in fact, it's not the complexity the problem, the problem is how you are documented...

 

[mezkal]

Seems you bought into sega 's marketing hype :whistling

Man...heh...I know exactly how hidden surface removal works. I was explaining to a noob (or so I thought). However complex a way you wish to explain what I had already stated quite clearly and succintly, Mashakos, (for I too knows lots of jargon - wish to parry me old bub?) the bottom line is that my statement still stands...Truform (ie triangle tesselation by nth scaled factor) will not work in a plugin implementation. It will be just too late in the render pipeline and will add an imbalance and therefore delay in the emulated DC's pipeline.

As you so correctly stated in bold so that it sounded IMPORTANT (see caps does that and less code), Truform is a tool used by game designers. This is very much the case. When and if they do use in MODERN games such as Unreal Tournament 2004 (I bet you never trawled the INI file - go look monkeynutz) it remains part of an ongoing design process - adding triangles adds CPU overhead (for Truform is all software) and therefore game designers need to make sure that their engines can cope or compensate when it is in use.

History has shown that implementations of Truform AFTER THE FACT (ie not as part of the said games design but implemented in the driver by tesselating ALL screen polys) was a general failure and in many cases deformed objects (a la counterstrike on ATI pre catalyst drivers) and made games unplayably slow (a la Wolfenstien - pre Truform - I think 1.2 maybe).

I don't need any lessons in computer technology. But thanks for the offer Mashakos

Maybe you do? :0

Cheers,

Mezkal

PS : For the record TILE RENDERING and Backface culling are not related. Don't throw in red herrings. Tile rendering very specifically culls based on Z buffer distance in relation to camera and scene. Of course every engine backface culls, even engines on Apple II E (Arctic Fox) did that in 1986! I did also state that Katana just did it MORE. and it does. The latest ATI and NV chipset still don't TILE RENDER in toto like the PVR 1 and 2 did. They implement Z culls but in only specific areas of screen space and not the whole area at once. Furthermore, due to the advent of SSE many of these such features are implemented in software (in the driver) so that the gfx vendors can scale them better (and therefore customers have even experiences) and change features as necessary. Truform is one such example. :bye3:

 

[Jabaturbo]

Ok people,

I anyone is interested of some GOOD explanation about tile rendering on the PVR2, here is the deal: http://www.beyond3d.com/articles/tilebasedrendering/index1.php

As a bonus, you don't need to go through smart-ass coments as you read about it...

 

[mezkal]

good point

 

[mashakos]

Hey mezkal,

Read the explanation of PowerVR's engine and well, turns out I don't know much about it lain:

:akuma: BUT :akuma:

I don't think chankast emulates tile rendering. If it did, then I wouldn't be seeing 'unnecessary' polys and models displaying on-screen when i stretch the chankast window to a larger size. If tile rendering was emulated chankast wouldn't display games that way.

So we're both guessing

Haven't played Unreal Tournament 2004. I don't really care about 'high poly' games after seeing Doom 3, Half Life 2. The characters in these games have a maximum of 1400 polys but the gfx still look more awsome than Unreal Tournament 2004.The new buzz words are shaders and normal mapping.

Then again Unreal Tournament 2004 isn't just about slick gfx...

 

[mezkal]

"more awesome" is a highly subjective point. For example the characters in UT have far more variety than those in HL 2 (as far as the footage has shown). Anyway....

My 5900XT is a DX9 class card. Infact it supports Shader Model 3 (please stop posting buzzwords as if they mean anything) which means that later games such as UT 2004, Far Cry and XMP get to show off same lovely usage of realtime shader and model instancing (once approriately updated). This alone allows for many more "texture-like" effects to be employed. The technology is often reffered to as Multi-Dude Instancing. Look it up.

I prefer to go on empirical experience before I make any value judgements. That way, at least, I know that my value judgement is based on some experirence and historical data. Gives me some comfort I guess.

Cheers,

Mezkal

 

[S0LAR]

poly count doesn't matter a lot nowadays, especially in games like UT2004. characters move very fast, usually they aren't extremely close to you, and adding poly detail to them wouldn't really make much difference during game play... at this point, any extra detail added to characters would only make a difference in cinematics...