Open GoogleCodeExporter opened 8 years ago
Cant reproduce it here, cant you post few screenshots of such "distorted faces"
?
Original comment by 0vet...@gmail.com
on 27 Jul 2014 at 7:24
Fair. I provide the images - you (hopefully the fixes), this is a deal! :) And
please do - demul is already so close to perfect on many games that further
generations with high probability will experience the old gems on this
emulation and its an oversight of the highest order if you provide them with a
(slight but cringeworthy) distorted vision of the original.
Game is Shenmue 1 Pal, played in 60HZ (its a pre start menu option)
In both images you are seeing the game being run in a 720*576 window,
- on the left with aspect ratio 4:3 enabled (notice the black bars, game is
rendered with 480 vertical resolution) >this is the output you are also getting
in fullscreen mode
- on the right with aspect ratio "stretch" (which adjusts the content to 576
lines, because of the window size chosen) > stretch is not a workable
workaround for fullscreen mode to achieve 576 line scaling
Settings are: 1x internal scaling, 1x FXAA enabled, no vsync, dx11 plugin;
The problem is quite obvious:
http://harlekin.me/fileups/dcemu1.png
http://harlekin.me/fileups/dcemu2.png
http://harlekin.me/fileups/dcemu3.png
Interestingly the (/some) graphic overlays (clock in Shenmue, menu items f.e.)
aren't distorted to begin with. I have no clue at what stage they are
"applied", but thats the argument for "maybe not just stretch the output in the
end", but to "let it render in the correct (or at least a user setable)
resolution/aspect ratio" (if auto detect should turn out to be a problem. (
Also, if they should turn out to be distorted in the original (Pal version at
576) - leave them be. ;) )
Short reminder - Shenmue 2 will be only playable for most people in the Pal
version - this needs to be fixed. Think of the cultural heritage! ;)
And thank you so much in advance.
ps: If you need the games image for comparative reasons, look out for the
magnet link in here:
http://www.shenmuedojo.net/forum/viewtopic.php?f=3&t=45623&start=15
Original comment by harlekin...@gmail.com
on 27 Jul 2014 at 10:45
720/576 = 1.25
4/3 = 1.33333333333
720/1.333333333 = 540
576 - 540 = 36
36 / 2 = 13
13 lines from top and 13 lines from bottom, that's ecactly what you must expect
using nonstandard resolution with 4:3 forced aspect ratio...
Original comment by cah4e3
on 28 Jul 2014 at 6:57
Thank you for this entertaining calculation example - but it fails to
acknowledge the problem entirely, while also showing a lack of understanding.
The second is the harder accusation, so lets handle it first.
-"nonstandard resolution". It might not have come to your attention, but
720*576 was the STANDARD for Broadcast as well as Dreamcast Games for one third
of the world. Its called PAL - and its A STANDARD. Dev, meat standard, standard
meet dev. Enchanting.
Now back to the problem.
- I never complained about black bars.
- I never complained about 4:3 not working correctly in theory
I complained about PAL games not being displayed in demul according to the
creators intent.
Next, let me introduce you to PAR (Pixel aspect ratio):
http://en.wikipedia.org/wiki/Pixel_aspect_ratio
>For example, a 640 × 480 VGA image has a SAR of 640/480 = 4:3, and if
displayed on a 4:3 display (DAR = 4:3) has square pixels, hence a PAR of 1:1.
By contrast, a 720 × 576 D-1 PAL image has a SAR of 720/576 = 5:4, but is
displayed on a 4:3 display (DAR = 4:3).
In short, there is a difference between (legacy) PAL 4:3 and 4:3 as used in
your calculation.
The insert "legacy" is important, as today our viewing standard even in Pal
Land shows a Pixel Aspect ratio of 1:1.
The problem here is that games got adopted to being displayed on (legacy) Pal,
before they were sold. Demul doest take this into account > warped faces.
Original comment by harlekin...@gmail.com
on 28 Jul 2014 at 9:36
Or possibly the other way around - games compensated for 576 vertical
resolution "as if the pixels were square" (PAR of 1:1) and thereby messed up
the internal aspect ratio handling. (?)
Original comment by harlekin...@gmail.com
on 28 Jul 2014 at 9:41
New Term: "Preferred square pixel size":
http://www.artbeats.com/assets/articles/pdf/aspect_ratio_2.pdf
Original comment by harlekin...@gmail.com
on 28 Jul 2014 at 9:48
dreamcast uses always 640x480 or 640x240 or less divisible by 2, the display
signal output generated by the video DAC, not by the dreamcast itself. it can
just "compensate" the pixel aspect with compressing or shrinking the picture in
the same 640x480 window, so you could see on demul. we don't emulate TV system
signals not how it displayed on the TV, but you have all controls to make it
look right, and you used it to take your pictures (hint: stretch mode). so I
just can't see a problem. even more, I can't see a problem in 13 pixel
distortion to overall gameplay itself, and just don't understand what you mean
about "only playable in PAL version" for most people... lol
Original comment by cah4e3
on 29 Jul 2014 at 11:07
Original comment by cah4e3
on 29 Jul 2014 at 11:09
Original comment by cah4e3
on 29 Jul 2014 at 11:10
Original comment by cah4e3
on 12 Mar 2015 at 8:21
I'm yet to see a developer that understands what aspect ratio is and the
importance of it. Dolphin and Retroarch are also plagued with this issue
(developers look the other way around). And yes, it affects gameplay. On a 2D
plane if you shoot 45º high, you are expected the bullet go straight 45º, but
with stretching involved the trajectory path will draw more like 40º or less
depending on the stretching ratio, this is a basic example, gameplay (and in 3D
environment) suffers worse than this (let alone the visual fidelity we are
expected to see for the game).
Original comment by muramura...@hotmail.com
on 25 Jul 2015 at 3:00
Original issue reported on code.google.com by
harlekin...@gmail.com
on 27 Jul 2014 at 7:09