GSdx

[willkuer]

gregory you are my hero.

This almost qualifies to get a new stable release.... Then the black lines issue threads in the forum would die...


Can you maybe explain how you solved it? What is the difference in vertical and horizontal lines?

[Bible Black]

Sasuga Gregory. Being able to play AC etc. properly made me postpone the planned Frühlingsoffensive.

Now I only have to find Drakengard 2 and test that one as well, after I just played through D3, playing through D2 as well would be reeealy nice. (In case no one tested it, I will definitely report back.)

Edit: btw Any other games that need testing? I only know of the ones that already have been tested - Tekken, SC and AC.

[ssakash]

It also fixed some random irritating lines on Naruto Shippuden : Ultimate ninja 5 while upscaling at the sand desert and rainbow field locations also, it works for the shop scenes on Bakugan battle brawlers.

Awesome work, It would also be great if, you could explain how it managed to fix the issues ?

[mirh]

It also fixed some random irritating lines on Naruto Shippuden : Ultimate ninja 5 while upscaling at the sand desert and rainbow field locations also, it works for the shop scenes on Bakugan battle brawlers.

Awesome work, It would also be great if, you could explain how it managed to fix the issues ?

Ehrm.. I'll try to post the relevant IRC log:

gregory38: I'm currently looking the black vertical line of mana khemia
gregory38: when doing upscaling
gregory38: I don't think it is related to the size of the vertex primitive (the correct number of fragment is sampled)
gregory38: but the way texture is sampled
gregory38: For example, GS send texture coordinate of X=8 (vertex 0) and X=264 (vertex 1)
gregory38: Which mean 0.5 to 16.5 in 12:4 (instead of short)
gregory38: Texture is 16 pixels that means in native latest pixel will be 15.5
gregory38: If you enable upscale (x4), last pixel sampled will be 15.5 15.75 16.0 16.25
gregory38: In bilinear mode, those pixels will fetch invalid data outside the texture (hence black data)
gregory38: GS is so strange
gregory38: I don't know how to fix neither. Well fix is maybe the wrong word, it could only be a hack
gregory38: on my case, screen is drawn by vertical strip of 16 pixels (40 times to reach the 640 pixel width)
pseudonym: gregory38: uh, in game or what? Because gust has a thing with that engine that we know exactly the cause of
pseudonym: Which is used in their ar tonelico 2 too
gregory38: mana khemia 1
gregory38: first video
pseudonym: Ah video.
pseudonym: That'll be different then
gregory38: yes surely. I don't know
gregory38: but that make for video
gregory38: they must stream texture to the GS
gregory38: so they send it strip by strip
gregory38: instead to send the full texture at once
gregory38: make *sense* for video
gregory38: Anyway, for the video case, there is maybe a possibilitie to improve the situation
gregory38: either we increase the texture scaling so texture take value in [0.5, 15.5] range instead of [0.5, 16.25]
gregory38: Either we add a new pixel column (row?) to texture
gregory38: actually duplicate latest column
gregory38: to reduce random wrong behavior, maybe limit to texture uploaded at position 0 with a size of 16
gregory38: or disable bilinear filtering for video
gregory38: ARG I try to copy latest column
gregory38: but I was wrong texture contains 16 pixels of data + 8 pixels of black frame
gregory38: so I don't know which column I must copy
gregory38: the question is "does all game that have black line in video use the same broken streaming method"
gregory38: @pseudonym: how is video working in PS2
gregory38: EE send data to IPU, which in turn send it to GS directly?
gregory38: So increase the scaling value seem to do the trick. The question is when enable it?
gregory38: (for a 4x scaling)
gregory38: GSVector4 black_line_offset(4.0f, 0.0f, 0.0f, 0.0f);
gregory38: vs_cb.TextureScale = GSVector4(1.0f / 16) / (WH.xyxy()+black_line_offset);
pseudonym: IPU doesn't have a direct line to the GS
gregory38: GIF?
pseudonym: Nor to GIF
pseudonym: In the first place, IPU doesn't decode MPEG
pseudonym: Well it decodes the bitstream
pseudonym: It doesn't do the actual processing except for a few bits
pseudonym: There's an IPU in and IPU out dma channel
pseudonym: It's all done by dma
gregory38: how does it reaches the GS in the end
pseudonym: GIF path 3 normally
gregory38: And are the black lines in video always vertical or horizontal sometimes/
gregory38: ?
gregory38: Ok

gregory38: http://s16.postimg.org/krmc36zmd/after.png
gregory38: http://s16.postimg.org/f263ivtg5/before.png
gregory38: it is not perfect, besides I'm afraid that will break various texture
gregory38: if you look carefully the circle is not continuous
gregory38: http://s11.postimg.org/4qe33gl03/copy_pixel.png
gregory38: latest one, if we copy pixel of colum 15 to column 16 (note all picture taken with a 4x upscaling)
gregory38: Much more accurate
gregory38: pseudonym: how is bilinear filtering done when FST mode is 1?
gregory38: Formulae seem to be iu0 = Integer part of (s*USIZE-0.5)
gregory38: Normally U = s* USIZE but I'm not sure the PS2 actually does bilinear for FST coordinate
gregory38: never mind it seems the same of point sampling
gregory38: without the 0.5
gregory38: but where is the -0.5 in the shader?
gregory38: maybe the HalfTexel variable

gregory38: Hello
gregory38: Does DX9 have less black line issue than DX11?
gregory38: If I don't upscale the extra pixel offset, black line in colin 3 dissapears
gregory38: However in DX9, the extra pixel offset is 0
mirh: no [...]
gregory38: is it an issue of upscaling or black line are always present ?
gregory38: never mind. Native res fix the issue but strangely upscale = 1 is bad too
gregory38: is clearly another issue. As pseudo said, there is small hole between vertex [0;1016] [1024;2040] [2048;3064] ....
gregory38: upscaling increases the size of the hole (that purpose of upscaling)
gregory38: I don't see lines with native resolution
gregory38: yes. It is my fault. Native resolution is not equivalent of upscale with a factor of 1
pseudonym: gregory38: well at a glance the principle looks okay
pseudonym: However...
pseudonym: Hmm.
pseudonym: I'm trying to think if there's any reason not to extend ALL sprites to cover full pixels
pseudonym: When the hack's on of course as that does mean extra processing
pseudonym: Could that affect rendering in native resolution, that's what I'm wonderi.... yes it can
pseudonym: It affects interpolated parameters such as texture coordinates
pseudonym: I'm not 100% sure your logic is completely correct but if it works I think we can assume it's fine, and it's an optional hack so it's not a big deal
pseudonym: I'm a little concerned about the accesses maybe going out of bounds though
pseudonym: This doesn't necessarily look safe
pseudonym: Yeah I'm looking at this and you're going past m_vertex.next
gregory38: well that possible I need to look at that carefully
pseudonym: Let's say m_vertex.next is 4 (two sprites), if it's left to right it'll access m_vertex.buff[4], if it's rtl it'll access m_vertex.buff[5] and even write it potentially
gregory38: in this case i will be 0
gregory38: because I check i < (count -2)
gregory38: mean i < 2
gregory38: and I do i+=2
pseudonym thinks
pseudonym: Okay you're right
pseudonym: I'm being dumb
gregory38: I need to leave. I will check the code later. See you
pseudonym: Since m_vertex.next is necessarily even it's safe

gregory38: [20:07:07] <@pseudonym> I'm trying to think if there's any reason not to extend ALL sprites to cover full pixels
gregory38: [20:07:18] <@pseudonym> When the hack's on of course as that does mean extra processing
gregory38: [20:07:39] <@pseudonym> Could that affect rendering in native resolution, that's what I'm wonderi.... yes it can
gregory38: [20:08:01] <@pseudonym> It affects interpolated parameters such as texture coordinates
gregory38: In this case the first primitive cover pixel [0;127] and the 2nd start at 128
gregory38: there is nothing in ]127;128[ which is bad for upscale
gregory38: sorry! s/127/63.5/ and s/128/64/
gregory38: Maybe I can extend it to 63.5 to 63.9375. This way it would be very close to current rendering even in native mode
gregory38: However I don't know what will be the impact to extend all sprites to the full pixel
gregory38: Maybe it will improve some games
gregory38: @pseudony1: the idea to extend it to full ack might also solve the issue with Colin 3
gregory38: In this game, offset is a bit wrong so first primite is rendered as [-0.5;127] (in 12:4 windows coordinate)
gregory38: Therefore it misses the ]127;128[ part
gregory38: Initially I wanted to update the context to add +0.5
pseudony1: gregory38: well I can tell you that it'll result in more blurry sprites when bilinear filtering is used and more aliasing when it isn't
pseudony1: The devs used the specific coordinates they did in order to ensure good interpolation
gregory38: Hum it also improves my mana khemia video testcase
gregory38: http://pastebin.com/NMkum76c (replacement of my previous hack)
gregory38: I agree with you for interpolation correctness but upscale breaks everything
pseudony1: Well kinda
pseudony1: Depending on the upscale it may at least INCLUDE the correct pixels
pseudony1: gregory38: don't you want to set 1.0, not 0.F for the right side?
pseudony1: Check figure 3-9 in the GS manual
gregory38: nope
gregory38: well I don't know
gregory38: it is complicated because it depends on the way GPU rasterizer work not the GS
gregory38: I think 0.5 (wil be enougt) for 2x, 0.75 for 4x
pseudony1: We should already be taking that into account in our hw renderers
pseudony1: And besides it's the same rule that every modern gpu uses
pseudony1: Just do & ~15 + 16, it'll work
pseudony1: Er well no, that won't
pseudony1: Um
gregory38: well maybe but 1 pixel on GS isn't 1 pixel on the GPU
pseudony1: (x + 15) & ~15
pseudony1: That's fine, the point is to get rid of gaps
pseudony1: This gets rid of gaps
pseudony1: Or do right side = (right & ~15) | (left & 15)
pseudony1: That's probably best
gregory38: what is right and left?
pseudony1: Should mess with the interpolation a little less than the alternatives
pseudony1: Okay I'll write actualy code you can put in
pseudony1: v[i+1].XYZ.X = (v[i+1].XYZ.X & ~15) | (v[i].XYZ.X & 15);
gregory38: This gets rid of gaps << just to be sure, there is gap in ace combat but mana khemai and colin3 are different issues
pseudony1: Errrr that said I think you can draw inverted sprites
pseudony1: Well, just try it?
gregory38: nah doesn't work at all
pseudony1: The hell?
gregory38: it need to be relative to the offset
pseudony1: No it doesn't
pseudony1: This is just turning the width into a number of full pixels
gregory38: nah, you do in absolute coordinate
gregory38: not in the real windows coordinate
pseudony1: I'm only changing the width
pseudony1: The width is the same in window or absolute coordinates
gregory38: that why you need to have the offset
gregory38: Let's me give you 2 example
gregory38: with an offset of 16, and a pixel of 16.5
gregory38: in window coordinate, full integer pixel will be ceil (16.5-16) = 1
gregory38: which is equivalent to ceil(16.5)-16
gregory38: ceil (I mean above rounding)
pseudony1: Why ceil? That's not how GPUs work
gregory38: well or floor if you prefer that not important
gregory38: What I mean is that: wx = x - offset
gregory38: if you want to have an exact pixel of wx => floor (wx) == floor(wx-offset) which is not equivalent to floor(wx) - offset
pseudony1: That isn't what I was trying to do
pseudony1: I wasn't trying to move the edges of the primitive to pixel boundaries at all
gregory38: sorry I didn't understand you. So what you're trying to do ?
pseudony1: I was merely altering the width of the sprite to make it a number of full pixels from the start coordinate
pseudony1: On the basis that surely the strips at least start on the same fraction of a pixel for every one
pseudony1: Did you actually try the code before saying it doesn't work?
gregory38: yes
gregory38: I copy past it
pseudony1: Okay ***** it do whatever then
pseudony1: In the end it's just a hack to make another hack less ugly
gregory38: that a correct summary
gregory38: My hack give a sligh distortion on the sprite
gregory38: boundary
gregory38: but I don't think we can be pixel accurate anyway. Upscaling breaks everythings, I'm surprise that it is working actuall
gregory38: actually*
pseudony1: That's how I feel every time I look at the upscaling code and actually think about it
pseudony1: It has no right to work half as decently as it does
gregory38: yes. I think it will be good entry for the dev blog
gregory38: I already found 3 differents cause of upscaling issue by design
gregory38: Mana khemia video line is very interesting. Because the vertical line "exists" in native resolution. It is nearly invisible for human eyes.
gregory38: However upscaling increase details so the line because much more visible
pseudony1: Typical GUST programming
mirh: http://pastebin.com/1av84W5b should I compile with this patch then?
gregory38: yes try it

mirh: speaking of which [ace combat], I just wanted to report WildArmsOffset hardware hack seems to hide weird horizontal lines in transparent parts of UI (albeit text is a bit misaligned)
pseudony1: mirh: that would be impressive because we don't actually know all the reasons

gregory38: Hello All
aphirst: ooh, lilypad
gregory38: I need some volunteers to test my just committed hack. It works very nicely for 2x scaling in particular for 2D games (gust game)
phirst: I don't think I have any PS2 2d games to hand
gregory38: it still misses the configuration gui
gregory38: and a lots of test

mirh: gregory38: do you need tekken gs dump? (or ace combat with new hack)
gregory38: yes for tekken dump
mirh: gregory38: http://www89.zippyshare.com/v/I5dOgHon/file.html
gregory38: no don't worry I can do it
gregory38: same for upscaling For the story, the dump register all command send by the EE to the GS
gregory38: all gsdx processing and rendering will be done later
mirh: and.. I must be dumb.. but UserHacks_stretch_sprite=1 doesn't seem to work
gregory38: no for this game
mirh: oh, ok
mirh: I meant, in ace combat
gregory38: as I already said there are several issues related to upscaling
gregory38: same for ace combat
mirh: fine fine
gregory38: I didn't commited my others hack
gregory38: I want to do the most generic hack as possible
mirh: seems fair
gregory38: UserHacks_stretch_sprite restore texture sampling accuracy for several games. Actually I think it can be always on
gregory38: hum UserHacks_align_sprite_X seem to fix the issue (at least my latest version here)
gregory38: OK same issue as ACE combat
gregory38: I redo the ack a bit differently
gregory38: I need some time to add the option in the linux gui
gregory38: and then I will push the fix
[...]
regory38: issue will be complex to fix [referring to his last commit]
gregory38: I'm guessing it sample wrong texel again
gregory38: the hack UserHacks_stretch_sprite is based on 1:1 vertex/texture size
gregory38: which is very often the case for 2d rendering
gregory38: here texure is smaller: 10.875 whereas primitive is 16

this is last week log, and different days are separated by an empty line

[Blyss Sarania]

Gregory is GSdx God.

[karasuhebi]

If I have my Greek mythology straight, he's Kronus. Except for he didn't cut off Gabest's penis. XD

[Blyss Sarania]

Ooooookayyyy then.

[willkuer]

Nice that pseudonym is participating in this.

pseudony1: That's how I feel every time I look at the upscaling code and actually think about it
pseudony1: It has no right to work half as decently as it does

Hilarious

[tsunami2311]

Gregory is GSdx God.

is he gona take over gsdx for gabest?!! atlest we getting some graphic glitch fixed

[ssakash]

wow, Thanks for posting it mirh. to fix it the right way, we must first understand how the sampled pixels vary in upscaling. anyway, this Hack is also a great temporary fix for the upscaling issues.

Hail ! , Gregory the Genius of GSdx !