FRAME mode rendering and screen positioning #6
Conversation
|
There is no 1080P mode. 576P mode is not supported by a lot of older consoles, so IMO I don't know if we can/want to support it in gsKit. The code 1080I within the kernel doesn't seem to support the FRAME mode. Do we really want to add support for that? I see that you have increased the DH values for NTSC and PAL. If it is to allow developers to go beyond 448 lines for NTSC and 512 lines for PAL, it makes sense I suppose. The original SONY libgraph design allowed developers to go beyond those as well and your code would make things backward-compatible, so it should be a good thing. Where did you get your DY and DX values from? The originals appear to be close to the SONY libgraph originals, while yours seems to be quite different. The old code would double the DH and DY values, if you specify both INTERLACED and FIELD modes. I don't remember that the FRAME mode only resulted in half the screen being rendered, but you had such a problem? Did it affect all video modes? Did you specify the same Height value as for FIELD mode? If you did not, I think you were supposed to. |
|
I will remove the 1080p mode define, agreed. The 576p I think should really Yes, I really want 1080i FRAME mode to work. Becouse interlaced FRAME mode I increased the DH values to be the maximum height (like 480 for NTSC and The old DY values where based on the old height values. The new values Yes, FRAME mode was not woking in ALL modes (PAL, NTSC and 1080i). So I Please let me know how you like to have it, and I will make the changes and 2016-10-15 5:17 GMT+02:00 Liu Woon Yung notifications@github.com:
|
|
Any updates? |
| @@ -702,6 +706,13 @@ | |||
| ((u64)(SLBG) << 7) | \ | |||
| ((u64)(ALP) << 8) | |||
|
|
|||
| /// CRTC Video Settings: PAL/NTCS, Interlace, etc. | |||
There was a problem hiding this comment.
NTSC is spelled wrong and the SMODE2 register has no way to identify the video mode. You could only differenciate NTSC/PAL videomode based on the CMOD value from SMODE1.
There was a problem hiding this comment.
Thanks, I will correct this to the same text as used in ps2sdk/common/include/gs_privileged.h: "Setting For Modes Related to Video Synchronization".
There was a problem hiding this comment.
The GS manual documents that SMODE2 contains settings related to "PCRTC video synchronization".
INT is the interlaced setting, FFMD determines the drawing mode in interlaced mode, while DPMS is the VESA DPMS setting. It has nothing to do with NTSC/PAL.
|
|
||
| // Recalculate the offsets based on the actual width/height | ||
| gsGlobal->StartX += (BufferWidth - gsGlobal->DW) / 2; | ||
| gsGlobal->StartY += (BufferHeight - gsGlobal->DH) / 2; |
There was a problem hiding this comment.
Shouldn't StartX/StartY be calculated based on the DX/DY bit fields?
There was a problem hiding this comment.
No, we need to calculate the value to set DX/DY to, just as the old code did. Where DX is in VCK units (subpixels), and DY is in units of pixels. They are used to position (center) the framebuffer on the display.
The code first sets DX/DY to fixed values. These values should center a framebuffer with the same size as the display.
But if the framebuffer size (BufferWith/BufferHeight) is smaller than the display size (gsGlobal->DW/gsGlobal->DH), it will no longer be centered, but in the top-left corner.
These two lines of code will compensate for this, moving a smaller framebuffer to the center of the display.
|
I don't know what to say, really. I don't have too much experience with working on the GS and I spent time looking at libgraph instead... so I have to say that gsKit's current design only works up to the standard resolutions while the SCE code allows that to be changed (e.g. above 448 lines for NTSC) and this new design is better. I think that I used FRAME mode with libgs instead, so I don't know whether it works in gsKit. If it's broken, then your fix is welcomed. Unless you have a lot of screens to test the new parameters on, I think that we shouldn't differ too much from the originals. You're not the only one who thinks that 448 lines for NTSC leaves a rather large black border though. Documentation on why SCE chose those values in the first place is not very great. But because they do have R&D, it's likely there was some reason for it. Therefore, I feel that you should remain compatible with the old values unless there is some clear reason (i.e. SCE's statement that most TVs can't display more than 448 lines was always wrong) to deviate from the originals. A function that allows the display parameters would be great. But it should perhaps allow the developer to change the values for height, width, startX, startY because adjusting the width and height currently requires the same method as the how startX and startY are adjusted. |
|
BTW, earlier consoles do not have a syscall for getting some offsets from the kernel. libgraph retrieves values (i.e. DY, DX) from that syscalls on newer consoles, so that might be necessary to factored in. I don't remember what sort of values are used, however. |
|
The memory allocated for the framebuffer must be a multiple of 32 lines in 32bit color, and 64 lines in 16bit color. So 448 and 512 lines (both multiples of 64) make a lot of sense when trying to optimize a game for the limited amount of memory. But they don't make a lot of sense when we don't need a lot of memory, for instance for playing dvd movies, user interfaces or applications. |
rickgaiser
force-pushed
the
master
branch
2 times, most recently
from
5a1f493
to
299a3cd
Compare
|
This is the second attempt, changes:
|
|
Why did you increase the width of NTSC and PAL? It's supposed to be 640 pixels and have a aspect ratio of 4:3. |
|
https://en.m.wikipedia.org/wiki/Standard-definition_television Please note that using a framebuffer of 640 or 512 width will still result What this adds is the ability to choose a 704 width framebuffer and loose Op 7 nov. 2016 6:30 a.m. schreef "Liu Woon Yung" notifications@github.com:
|
|
Would it be helpfull if I add a test application to examples folder, so you can test these changes? I can make a simple test where you can cycle through all resolutions, and play with the x/y/width/height values? |
|
@rickgaiser , yes that would be great. Please create a test app. |
|
It's not that I don't understand what you're suggesting. I do. It's just that it's not something that was done by SCE. And because of that and because I don't know why they didn't choose to do such a thing, I don't like that idea that there could have been a good reason for it. Besides, most existing software were made to support a more common resolution like 640x480. Supporting 720x480 would require different art assets. Right now, it's not impossible to change the DW and DH values. If you knew what you are doing (and you do), you can already change the DH and DW values. So if you don't mind, I would appreciate it if you wouldn't deviate from the standard values. Someone else who understands the intentions of the gsKit developer(s) better might be in a better position to give comments on what is acceptable here and will maybe accept these changes to the values. |
|
@sp193, but we won't know the end results until we test it. If things start to fail left and right, then we can simply revert back the changes. At least give change a chance. It's homebrew. This is not a product that is sold to customers and that we should fear that the company may get a backlash (drops from sales). C'mon, give it a chance. If it fails, then you were right for the record and then we revert the changes, and go back to the drawing board. Unless there is another way to achieve the same goal, then please offer a solution, instead of countless reasons of why we shouldn't. If we don't explore, then we won't ever discover that the world isn't really flat. Really? What's the worst that can happen? Fall off the edge of the flat world? Perhaps we can test a fork version and see what the end results are? I'm game for testing. I got one SLIM that I really don't care too much about. -- Used to belong to my neighbor's kid. :) And about ART and Skins, well, we can study SMS (Simple Media System) on how it readjusts the custom skins and GUI when changing scan modes. Ideas are there. We just need braver souls. :) My .02 cents and no, I'm not trying to pick a fight nor have an endless debate. You already know I hate debating something to death. |
|
Uma coisa maravilhosa, o fim das benditas tarjas laterais seria uma coisa fantástica visto que a imagem não fica ruim quando jogo em uma tv full hd samsung 32", só que fica com as tarjas laterais e quando abro o OPL em 480i a imagem fica deslocada para direita da tela, o popstarter mesmo já é possível nesta ultima versão apos um pedido que eu tinha feito criar no CHEATS.TXT um X e Y personalizado permanente, o que anularia o processo de toda vez que eu for jogar ter que abrir o GSM antes configurar, para somente depois poder usar o popstarter. A wonderful thing, the end of the blessed side stripes would be a fantastic thing since the image does not look bad when playing on a full hd samsung 32 "TV, only it has the side stripes and when I open the OPL in 480i the image gets shifted To the right of the screen, the same popstarter is already possible in this last version after a request that I had made to create in the CHEATS.TXT a permanent X and Y custom, which would cancel the process every time I play to have to open the GSM Before setting, so that you can only use the popstarter. |
|
He wants to change the values, to allow a 720x480 screen, for example. That is a different aspect ratio on its own, so you will not see many homebrew software made to support it (in fact as of now, none). Even OPL does not support 720x480 for progressive mode; it uses 640x480, centered. Right now, I negotiated for him to use the dx and dy values for the old resolution, so it likely isn't centered for 720x480. So he will have to change dy and dx, along with the width and height of his frame buffer. It is not as if you (or anyone) cannot choose to use 720x480 for NTSC. You always could. And you never needed to recompile gsKit to do that. I don't exactly fear a backlash from anyone. I don't know if you already realized it, but some of the more obscure problems are usually left undiscovered and unreported for years. Those who discover it, sometimes simply work around it or avoid the problem entirely. So there is a pretty good chance at this point that new problems will simply get left there for years to come. He has already given an example: FRAME mode doesn't work in gsKit. Nobody discovered it. Nobody fixed it. But if you feel very strongly that somebody will eventually attempt to use these "native" resolutions, I do have a suggestion: create a new set of virtual modes that simply have different DW, DH, DY, DX, width and height parameters (I.e. Beginning from mode 0x80). Sent from my Sony Xperia™ smartphone |
|
Hi mates, |
|
I've added an example. Both in source and binary (.elf) form. So please go ahead and test all modes. How to use: Use ps2client to see the debug output, for example: These changes really should's change or break any existing software, and only gives developers the possibility to remove the black borders we are all seeing on the ps2 when using a modern tv. If anything needs to be changed to get this accepted please let me know and I'll change it. |
|
Thanks for the binary. Is it supposed to draw a box in all test modes? If so, the larger ones (i.e. those SD modes with width = 704) are cut off at both horizontal ends on my TV. |
|
Yes, there are two borders. The first border is red and 4 pixels wide. The I forgot to mention:
I have preset the values for all modes so the height fits my tv exactly (a Please note that it is impossible to get these modes pixel perfect. You Also take a look at the enormous x/y offset values for 720p and 1080i. I 2016-11-11 2:10 GMT+01:00 Liu Woon Yung notifications@github.com:
|
|
I would rather have Ragnarok2040 approve this... but because somebody Please make whatever changes you like and I'll just press the merge |
|
@rickgaiser I'm able to test your modetest.elf -- nice work. So far on my 1080p NTSC HDTV these work great: The R3 control was too sensitive. A tiny stroke and the blue screen would disappear from the screen. :) I will go share this elf test to the community at PS2-Home, so others can test it as well. I will later edit this post to include the URL of that thread. http://ps2home.freeforums.net/post/12134/thread |
|
I've updated the modetest (source and binary). R3 was indeed way too sensitive. Lets wait for Ragnarok2040 just a little longer. In the mean time I'll try to add this functionality to OPL. |
|
Testei aqui também e tive os mesmos resultados, seria interessante que alem de ter este sistema acoplado ao OPL, tivesse um ELF separado para poder usar ele com outros aplicativos no ps2 tais como: Pico drive, Popstarter, Snes Station... e já falei com o mano morpheussd vai abrir um leque de oportunidades para novos temas para o opl. I tested it here too and I had the same results, it would be interesting that besides having this system coupled to the OPL, had a separate ELF to be able to use it with other applications on ps2 such as: Pico drive, Popstarter, Snes Station .. And I already spoke with the morpheussd mano will open a range of opportunities for new themes for the opl. |
|
Guys (other than those who already understood this, like Rick and
doctorxyz): this has nothing to do with games, won't open a range of
new video modes for existing software and isn't the cause of a lack of
true widescreen/HD themes in OPL.
It is an amendment to gsKit, to allow homebrew developers to go beyond
the traditional NTSC/PAL resolutions. You (the developer) must still
recompile the software to use the new version of gsKit and you must
make your software compatible with the new resolution. As it is meant
to allow you to maximize the usage of the screen, you might also want
to have some sort of screen adjustment (alignment + size) facility
because the display range varies between TV sets.
Other than getting your existing software to initialize gsKit for the
new resolution(s), your art assets must also be suitable. It is a
different aspect ratio, so simply using your art assets for 4:3 (i.e.
640x480) will cause it to get stretched horizontally. It was for this
very reason that OPL's 480P mode is 640x480, so that the themes will
still look right.
Although, as Rick mentioned, you might not be able to get a 720px
width because the limit varies between 640px and 704px for most TVs.
That also means that this will not affect retail games and existing
software. For existing software and games, GSM exists for that
purpose. But because it controls the video output at the
software-hardware interface, it cannot adjust the frame buffer size.
Therefore, this set of changes isn't going to affect what GSM
can/can't do.
GSM could not, and will continue to be unable to adjust the frame
buffer size of existing software, unless its design gets changed. But
really, IMO changing the frame buffer size is not a good idea anyway,
as the graphics likely aren't made for any other resolution.
For OPL, it already supports the progressive-scan mode. As a result,
it can already do HD video output, but your themes have to be all
changed in order for it to really support HD.
I wanted to come up with a new HD format, but put that off because a
LOT of work has to be done (i.e. coming up with a new standard). A lot
of things weren't documented for the current format, so there are also
a lot of things to sort out first.
|
|
For the record, my testbed TV is a HDTV as well, although it is a
couple of years old by today. It is a SAMSUNG 26" LCD TV, from 2009.
|
|
Sure, this is nothing to do with games. Yes, please, let's wait a little more for Ragnarok 2040 experienced and neutral opinion - I kindly invited him by PM for contributing here. Sorry but I can't test anything for now (due to real life stuff). |
|
Hi mates, thanks to the insomnia + holiday, I was able to run modetest.elf. My setup (for this test):
This modetest.elf is a very interesting POC (proof-of-concept), since it shows that we can reduce and/or get rid of black borders depending on the settings/setup; it would be great if some additional info could be displayed in middle of screen (ex.: current video mode, frame/field mode, DW, DH, MAGH, MAGV, DX, DY, FBW, PSM, DBX, DBY, etc), but no problem, I can live without it ;-) As expected, my old PS2 BIOS (v1.60) isn't able to show DTV_576P (but gsKit could be take care of it for both old NTSC and PAL consoles simply by adding a DTV_576P and DTV_480P SetGsCrt replacement code for BIOS < v2.20; the related source code can be found on GSM core code. I commented it as much as possible. In fact, I borrowed/adapted it from the great SP193's VModeTest tool/idea). For users reading this pull request comments, it is important to mention (again) that it has nothing to do with games, but only with homebrew (I just circumstantially mentioned GSM on previous paragraph) okay. |
|
Hi Rick, The SONY add-on code to licensed software that adds support for video modes like 720P, 1080I etc has additional code that sets the FFMD field of SMODE2 accordingly, if the developer either specifies the use of non-interlace, or specifies frame and interlaced mode. |
|
Now what? Are we still waiting for Ragnarok2040 to make a decision? It's been 2 months and I think it's time to move on and close this pull request? |
|
Well, as mentioned before, you can wrap up any last changes that you like and I will merge them.
Sent from my Sony Xperia™ smartphone
|
|
Could you merge everything except for the binary? |
|
You can do interactive rebase, remove the binaries, then force push. |
The calculation: gsGlobal->DH *= 2; gsGlobal->StartY = (gsGlobal->StartY - 1) * 2; Needs to be done for both interlaced modes.
Screen position is unchanged. The new StartX values are calculated as: 492 = 652 - (2880 - 2560) 520 = 680 - (2880 - 2560) The new StartY values are calculated as: 34 = 50 - (480 - 448) 40 = 72 - (576 - 512)
How to use: L1/R1: Cycle through all video modes R3: Change X/Y offset of screen X: Switch between FIELD and FRAME mode LEFT/RIGHT: Change width in units of 64 pixels UP/DOWN: Change height in units of 2 pixels Use ps2client to see the debug output, for example: Mode: 480i 576x452 GS_FIELD offset: -6, 0 memory: 576KiB
|
Looks good to me! |
|
Ok, I've rebased to the latest ps2dev/gsKit/master, and removed the binary. |
This fixes: