Final Fantasy XII / FF12 revealed [!=56K]

coff, coff...Linux kit...coff, coff
But anyways, you are right since there are no chances for the average gamer to get the HDD. But the point I wanted to reach is that they changed many things that require code alteration while the 60Hz support wasn't even considered. And I still remember the poor excuse they gave...


Just another thing. A mere curiosity. Do you remember RR Type 4 ? On the PAL version, the Pocket Station support was kept. Why ? No idea... And it was also kept on FF 8, if I remember well...
 
go figure..... i guess all these examples go onto the X-files department of videogame decisions mysteries... :LOL:

oh my god i just had a fab idea for a thread!!!
 
rabidrabbit: Lol ahh that quote about 70% less polys is wrong. I think u mixed up the amount of the game that is complete which is 70% with how much polys they are using in the game. They never said anything about 70% less polys. Only that their graphics engine is using about half the polys of ff10 and better textures, shading, and lighting.
 
OMG!

Tidus, you are SO dethroned as the cutest videogame guy ever! *eeek!*

What a cutie, hahaha!

Now I HAVE to get this game just to check him out. LOL!


*G*
 
LiMuBai said:
Are they us saying that the problem of bad textures is a limit of main RAM ???
After constructing various draw buffers you are normally left somewhere around 1-2MB of VRam for texture buffers.
Games typically use quite a lot more then that, with the mileage varying depending on available main memory and rendering requirements.
Reducing geometry for example can serve to free up more available memory - but it can also mean more drawing time for texture uploads.
 
After constructing various draw buffers you are normally left somewhere around 1-2MB of VRam for texture buffers.
Games typically use quite a lot more then that, with the mileage varying depending on available main memory and rendering requirements.
Reducing geometry for example can serve to free up more available memory - but it can also mean more drawing time for texture uploads

(note: I know that everything I say is a well-known fact for you)
Yes, I know...But these 1-2MB of VRam are per frame and you can update them several times. And the fact you change polygonal models, only makes rendering faster since you make less geometric transformations through VU1 but the amount of textures in the VRAM is the same unless you change the size of the framebuffer or just don't use a Z-Buffer (just an idea I had, would be possible to render sth on PS2 by just sorting polygons manually and using the Z-Buffer space as more texture space).
So the amount of memory it relates to is main RAM where you have 32 MB... I find incredible that Square doens't have enough room for textures due to high polygonal models. You can do a lot of things to save room: like use paletted textures, use special codification for models (for example strips instead of triangles...).[/quote]
 
ShinHoshi said:
(just an idea I had, would be possible to render sth on PS2 by just sorting polygons manually and using the Z-Buffer space as more texture space)

And lose perspective correction? No, thanks, I think most developers would pass up that opportunity.
 
Um, to my knowledge a Z-buffer isn't neccessary to do perspective correction.

*G*

PS: Vaan's my desktop image now... *drool*
 
ShinHoshi said:
I am not really sure about this...DC didn't use Z-Buffer and it deffinitelly had perspective correction.

I think DC was a special case due it using tile based rendering.
 
AFAIK a Z-buffer is "only" to make sure that pixels that are supposed to stay non-visible, are not drawn on top of pixels that should be visible.

About not using Z-buffer: There is the classic Painters Algorithm, where you sort all the polys and draw the furthest away first.

ShinHoshi said:
I am not really sure about this...DC didn't use Z-Buffer and it definitely had perspective correction.

Dreamcast probably has a small Z-buffer only for the tile, but alternatively, it does Z-sort all the polygons before rendering, so maybe a Z-buffer wouldn’t be needed, and it could just draw front to back in the tile?
(You could PM SimonF about that, he should know (and then post the answer here :D ).
 
Yeah...I was thinking in that. Just using the painter-algorythm...But that's quite inefficient when doing non-static scenes...
 
Z-buffer is required for perspective correction. The algo requires correct Z values.

DC uses a Z-buffer, just not an *externally stored* one, it's kept on the chip at all times. My old Kyro II did the same thing. It only holds enough Z information on chip to work on the tile it's currently running.

And if you want to see Painter's Algorithm, go fire up a PS1 game. Notice the utter lack of perspective correct texturing? Also the incredibly amusing texture alignment, warping, and swimming problems? (play Tony Hawk 2 for one of the most extreme examples)
 
Tag, the PS has swimming textures NOT because it doesn't have Z-buffer, but because it lacks the per-pixel divide for perspective-correct texture mapping.

Look at Saturn games, I haven't seen any saturn game with texture warping like in PS games. Also, some old DX demos I got on my harddrive (DX5 era) have separate toggles for Z-buffering and perspective correct TM, and they do work. You can enable perspective correction without having to enable Z-buffer.

*G*
 
Back
Top