[ Каскадный ] · Стандартный · Линейный Аппаратные различия, PS1 VS N64

[sergi]

Довольно много различий написано про снеску и сегу, а ведь был и другой может чуть менее эпичный но не менее кровавый бой между любителями N64 и PS1 - первыйх 32-64 битных машин на RISС процессорах, с похожими или одинаковыми играми, давайте их попробуем сравнить

[arhern]

Вот считай официальное подтверждение всех слухов:


Это цитата Keiichiro Toyama, директора SH1, источник:
http://www.silenthillmemories.net/sh1/arti...98_xmas_047.jpg

---
А так подобная проблема с полигонами встречается даже в аркадных аппаратах, например тут показано:
https://www.youtube.com/watch?v=zqCLnv9k5mM

Не то это. Косяки с Z-буфером к дёрганью отношения не имеют, они проявляются тогда, когда он ЕСТЬ и низкого разрешения.

Судя по анализу писателями эмуляторных плагинов, это в результате появления его замены получается - софтовая проверка низкого разрешения, там даже до 8 бит далеко и корректируется не order, а именно координаты чтобы попадало в сетку очень низкого разрешения.

The lack of z-buffer and perspective correction have nothing to do with the wobbliness. As mentioned before, the wobbly polygons was caused by insufficient precision combined with all calculations being done using integers instead of floating point values.

The PSOne has a co-processor called the Graphics Transform Engine, which is meant to perform many 3D operations like matrix-vector multiplication, lighting and fog. It was fixed-point[*] (aka: integer) based and couldn't work with floating point numbers. The X, Y and Z coordinates of vectors are stored as 16-bit values: 1-bit for sign, 3-bits for integral part and 12-bits for the decimal part. It only supported 3x3 rotation matrices with translation being a separate operation using vectors with 32-bit XYZ integer components (no fractional parts).

This seems to be one reason behind the wobbliness: while drawing a scene, the objects's polygons must be transformed from their local space into world space (at the very least one rotate and one translate command) and then from world into camera space (another rotate and translate). Since translation is integer-only (no fractional), it will "snap" around, the severity depending on the scale of the the scene elements. Also, if you have multiple rotations and translations stacking on top of each other, the precision errors will build up quickly.

Finally, the GTE will output the result of perspective transform as integer pixel coordinates (no fractional), which are to be fed into the GPU for drawing. This means it cannot display any subpixel movement: the polygon will snap in place until one of it's vertices moves enough to snap into a different pixel.

The DS, for example, was also integer-based but had subpixel movement since the final 2D output coordinates had fractional parts (the DS has edge antialiasing which wouldn't work otherwise). While there was some degree of wobbliness due to fixed point math, it was much less because the matrices on the DS had 32-bit components (1-bit for sign, 19-bits for integral, 12-bits for fractional) and were 4x4, so translation and perspective transformation could be done in the same operation. Translations also had 12-bit fractional, so they accumulated less errors.

То бишь ровно как я предположил - 16битные integer трансформации, только из координат в игре в координаты на экране ещё при трансформации косяки добавляют, и они основные, а даже не само пространство. И эффект этот - snapping points/polygons, а не wobbling. Их банально трясёт между координатами точек в сцене камеры коих весьма мало. Интересно было бы написать технодемку которая показывает кучу точек координатной сетки этой, да лень SDK искать.