Killzone: first pics

I am not good at explaining things but I'll try to explain it. Just suppose these two cases:

Full Frame Buffer. You render internally a 640*480 screen.
Half Frame Buffer. You render two fields: a 640*240 for the odd lines and a 640*240 for the even lines.


The whole point comes from the fact that Guerrilla hinted that they used the half frame buffer in order to save space on the VRAM. Then Fafalada replied it was not a very good idea since you only save 500 kb.

640*480*24*8/1000 vs 640*240*24*8/1000

The math clearly states you are only saving ~500 kb. However if we take into account textures, there is a thing I don't get. If we are rendering a 640*240 screen, why do we need to use the same textures we would use if we rendered at 640*480 ??? The vertical resolution is the half !!!
However Marconlly pointed that not always the textures have the same orientation so sometimes the resolution that we have dropped to the half in the vertical axis, would be dropped to the half in other axis (lineal combinations of the other axis).
So that's the reason why we shouldn't use them.

Then Fafalada replied that you would need two sets of half size textures. One for the even field and another for the odd field. So at the end the whole space would be the same.
However I don't see it to be the same.

Case 1. Render at 640*480 with a texture of 300 kb (imaginary case).

Case 2. Render at 640*240 with a texture of 300 kb. (both fields are rendered using the same texture).
2.a. Render the 640*240 (odd).
2.b Render the 640*240 (even).

Case 3. Render at 640*240 with two sets of textures (one for each field).
2.a Render the 640*240 (odd).
2.b Render the 640*240 (even).

If we consider that every field is rendered at a different step, then in case 3 the texture only uses 150 kb per step while in case 2 we are using 300 kb in both cases.


I know you have proven me that it is not useful (Marconelly problem) but I just didn't get the problem of them needing the same space.
 
Half Frame Buffer. You render two fields: a 640*240 for the odd lines and a 640*240 for the even lines.

if this is the front buffer then you prolly field render and reproduce the same lines.


Case 3. Render at 640*240 with two sets of textures (one for each field).
2.a Render the 640*240 (odd).
2.b Render the 640*240 (even).

If we consider that every field is rendered at a different step, then in case 3 the texture only uses 150 kb per step while in case 2 we are using 300 kb in both cases.

again I ask where are u storing the textures? seems to me ur trading space for bandwidth transer and additional computation cycles.

which is fine if mem is really scarce and bandwidth and processing are so fast as the be redundent.
 
again I ask where are u storing the textures? seems to me ur trading space for bandwidth transer and additional computation cycles.
Aren't the textures ready to be rendered (on the actual frame) stored on the 4MB VRAM ?
 
NOPE. still dont get it.

i dont see the connection between texture size and resolution. at the end of the day, even if we are rendering at low resolution, having higher resolution textures will always look better than "half frame" textures. whatever the resolution we are rendering at.

if we r rendering at 640x480 we will have MANY different sets of textures, some as small as, say, 32x32. while others can be of up to, say, 512x512... and whether u render at 640x240 or 640x480, the higher the texture res the better...

having the textures at half the resolution will only give u more blurry textures....

am i missing something? :?
 
ShinHoshi said:
again I ask where are u storing the textures? seems to me ur trading space for bandwidth transer and additional computation cycles.
Aren't the textures ready to be rendered (on the actual frame) stored on the 4MB VRAM ?


alright then you are wsting bandwidth both on the GS and in the transfer from VU1.

in that you must send the next tecture to be rendered quickly (in sync) for hte next frame. or am I talking BS?
 
london-boy you are right. When I said that I didn't took into consideration how textures are placed on a frame. Using half size textures would indeed give you a worse quality, unless you dropped the resolution in the axis where texture is placed.
 
My grasp of graphics programming is limited to say the least but they way i see it is that you have two buffers, a front buffer and a back buffer. The image is constructed on the back buffer and then flipped onto the front buffer. There image on the front buffer is then sent to the screen and displayed. While the front buffer is being displayed the next frame is being constructed on the back buffer, and so on and so on.

Now as I understand in interlace mode only half the front buffer is displayed at a time so by having a half height front buffer on an interlaced screen your not loosing anything as each time the full height back buffer is flipped onto the half height front buffer only the coresponding odd or even lines are flipped alternatley.

Now because the back buffer is full height, full height textures are required. The only other way I could think about it working and save space would be to have a half height back buffer too and full height textures and only render half of them each time? do thay do that?

EDIT:
Doh! I feel so stoopid, just removed very silly paragraph :rolleyes:

How far wide of the mark am i?
 
ShinHosi, you seem to be seriously confused. So seriously confused that I really don't know where to start explaining, but I just have to say something...

The only time lower framebuffer resolution equals lower texture resolution is for HUDs. For normal textures this is not the case. Think about it, it's not like the odd lines from a texture is only shown on the odd lines of the framebuffer. If you lower the resolution of the framebuffer it only means that you have to move closer to the texture to see it clearly.

Any texel from any texture can end up on any pixel in any framebuffer.

ShinHoshi said:
Then Fafalada replied that you would need two sets of half size textures. One for the even field and another for the odd field. So at the end the whole space would be the same.
However I don't see it to be the same.
No he didn't. He said "if the 'half height' textures could work as you thought, you would need two sets of them". But they don't work that way.
 
ShinHosi, you seem to be seriously confused. So seriously confused that I really don't know where to start explaining, but I just have to say something...
Jejeje. Sure I am confused but I think I begin to see the light. I think I hadn't understood very well the concepf of framebuffer from what I read in Sir Doris post since I didn't know the back frame buffer always had to be full size.
I only thinked in one buffer (half or double).

Sorry if also confused you. Sometimes one should better shut up if he doesn't understand sth.

:cry: :cry: :cry:
 
Thowllly said:
ShinHosi, you seem to be seriously confused. So seriously confused that I really don't know where to start explaining, but I just have to say something...

The only time lower framebuffer resolution equals lower texture resolution is for HUDs. For normal textures this is not the case. Think about it, it's not like the odd lines from a texture is only shown on the odd lines of the framebuffer. If you lower the resolution of the framebuffer it only means that you have to move closer to the texture to see it clearly.

Any texel from any texture can end up on any pixel in any framebuffer.

ShinHoshi said:
Then Fafalada replied that you would need two sets of half size textures. One for the even field and another for the odd field. So at the end the whole space would be the same.
However I don't see it to be the same.
No he didn't. He said "if the 'half height' textures could work as you thought, you would need two sets of them". But they don't work that way.


yeah alright he got it in the end! no need to go all patronismo on him... :LOL:
 
ShinHoshi if you haven’t understood yet, read this:
Remember in PSone games, and even older games like Wolfenstein and DOOM, when you walk up close to an object, and it looks like the surface is made of a patchwork of small squares?
Well, those small squares are called texels.
In today’s games, they are blurred when drawing the texture to make them less noticeable (a VPU/GPU can do that, because it has higher fillrate than the VRAM bandwidth can "satisfy", but that’s another story).
Those texels can be rotated along four axes and be zoomed in on until one of them fills the entire screen, or out so far away that you can't see it.
Texels are stored in memory in a 2d coordinate system (or 1d or 3d in rare cases) to form a texturemap, where every coordinate set in the map stores a colour value.
It doesn’t matter if the map of texels is up close or far away, they take up the same amount of memory (at least if you are not using mip-mapping, but again that’s another story)

So if you take away every other line of a 640 x 480 frame that wouldn’t affect the texture requirements, as texture is a completely separate thing from the framebuffer (again that's not entirely true in PS2s case :)
)
If you took out every other row of texels from a texture, it wouldn't look right.
Hope you understand now :D
 
Some new screenshots by videogamerx
01.jpg

02.jpg

03.jpg

04.jpg

05.jpg
 
It seems they are using some sort of motion blur on fast moving objects. That could be really cool looking in motion.
Was this ever done before? Were there other games with this feature?
 
ChryZ said:
It seems they are using some sort of motion blur on fast moving objects. That could be really cool looking in motion.
Was this ever done before? Were there other games with this feature?

MGS2 comes to mind. Best looking motion blur I've seen in a game! FF X did it nicely too, but somewhat rarely. Like everything (in cutscenes) got the MB treatment in MGS2.
 
MGS2 motion blurred the entire scene, not just "fast moving objects".

I think the only time i've seen that was from a voodoo5 demo, it even had a patch for Quake3 iirc.
 
Back
Top