FRAME mode rendering and screen positioning

[rickgaiser]

This fixes:

• the problem of FRAME mode only rendering half the screen.
• FRAME mode and FIELD mode having different X/Y offsets on the screen
• X/Y offset is compensated for the size of the framebuffer
• 1080i frame mode not pwoperly initialized by SetGsCrt
• Add DTV 576P mode
• Add .gitignore

[sp193]

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? You will get half the resolution, which is already being halved by a lack of VRAM.

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.

[rickgaiser]

I will remove the 1080p mode define, agreed. The 576p I think should really be in gsKit. It is up to the application using gsKit to decide to use it or not. The current situation requires ugly hacks to make 576p work. Like for instance this one https://bitbucket.org/ifcaro/open-ps2-loader/src/58888dfb9488e934b902b72f988627d78ab0f9b2/src/renderman.c?at=default&fileviewer=file-view-default#renderman.c-340 in OPL.

Yes, I really want 1080i FRAME mode to work. Becouse interlaced FRAME mode does not half the resolution, it doubles it! FIELD mode: 1920x1080 framebuffer -> resulting in 1x MAGV -> half of the lines in the framebuffer used FRAME mode: 1920x540 framebuffer -> resulting in 1x MAGV -> all lines used So this mode requires only half the memory. During rendering the odd lines need to be offset by half a pixel, to compensate for the offset of the odd lines.

I increased the DH values to be the maximum height (like 480 for NTSC and 576 for PAL), this was already the case for all other modes, like 1080i and 720p. The old code was only able to handle fixed magnitudes from the DH value, so for NTSC, only 448/224/... could be used. Now it is freely adjustable. To fill my screen, I need to use a height of 460 for NTSC, and 550 for PAL.

The old DY values where based on the old height values. The new values could be recalculated as: newDY = oldDY - (newHeight - oldHeight) / 2; But... I didn't do that, and instead based them on what looks good on my monitor. I did the same for the DX values. If you like, I can stay compatible with all the old values, and just recalculate them based on the old values? But really... those values are terrible on al of my monitors and tv's. Another thing missing in gsKit is to be able change the offset. Would it be nice to have a "void gsKit_screen_offset(int x, int y);" in units of pixels? So we no longer need to hack around it like this https://bitbucket.org/ifcaro/open-ps2-loader/src/58888dfb9488e934b902b72f988627d78ab0f9b2/src/renderman.c?at=default&fileviewer=file-view-default#renderman.c-349 .

Yes, FRAME mode was not woking in ALL modes (PAL, NTSC and 1080i). So I wonder if this mode was ever used? I also used the same Height values, but please note that this will result in a different MAGV value. I used: FIELD mode: 1920x540 framebuffer -> resulting in 2x MAGV -> DH = 1080-1 FRAME mode: 1920x540 framebuffer -> resulting in 1x MAGV -> DH = 1080-1

Please let me know how you like to have it, and I will make the changes and rebase them for this pull request.

2016-10-15 5:17 GMT+02:00 Liu Woon Yung notifications@github.com:

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? You will get half the resolution, which is already being halved by a lack of VRAM.

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, you were supposed to.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ps2dev/gsKit/pull/6#issuecomment-253959254, or mute the thread https://github.com/notifications/unsubscribe-auth/AEfm3_ZYzRzuU7sup4OlZm8K7MfT9T-Pks5q0EXSgaJpZM4KXYo6 .

[rickgaiser]

Any updates?

[sp193]

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.

[sp193]

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. Just letting you know that it exists. Since I know about this, I may make this adjustment to gsKit in the future.

[rickgaiser]

The memory allocated for the framebuffer must be a multiple of 32 lines in 32bit color, and 64 lines in 16bit color. So for instance a 640x480x32bpp framebuffer would fit perfectly into memory, but a 640x480x16bpp framebuffer would actually require the space of 640x512x16bpp.

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]

This is the second attempt, changes:

• 1080p mode removed
• Screen positions exactly the same as original code
• FRAME mode fix in separate patch
• Maximum width also expanded for PAL/NTSC (to 720 pixels, just like the 480P/576P modes)
• Function for positioning the screen added

[sp193]

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. The aspect ratio for the 480P mode of the PS2 is 3:2 (720x480), as it is actually a DTV mode.

[rickgaiser]

https://en.m.wikipedia.org/wiki/Standard-definition_television They can be both 16:9 and 4:3 aspect ratio and in both cases, the pixels are not square. The visible area (resolution) is always 704x480[ip], or 704x576[ip]. This is the same for both sdtv and edtv.

Please note that using a framebuffer of 640 or 512 width will still result in the original magnification levels. And the DX value will be recalculated as 2560. So no harm is done and old applications will still look exactly the same.

What this adds is the ability to choose a 704 width framebuffer and loose the black borders on the left and right, as was already possible for the edtv modes.

Op 7 nov. 2016 6:30 a.m. schreef "Liu Woon Yung" notifications@github.com:

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. The aspect ratio for the 480P mode of the PS2 is 3:2 (720x480), as it is actually a DTV mode.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ps2dev/gsKit/pull/6#issuecomment-258750600, or mute the thread https://github.com/notifications/unsubscribe-auth/AEfm35DHF5QmkhKlgDSsOY5loxX8PxG7ks5q7reAgaJpZM4KXYo6 .

[rickgaiser]

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?

[Jay-Jay-OPL]

@rickgaiser , yes that would be great. Please create a test app.

[sp193]

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. I'm concerned about these changes because I do have some games that have their UIs (specifically, the top and button) cut off on my previous TV, in progressive-scan mode. So I concluded that my SAMSUNG TV from back then, was one of those that won't display more than 448 lines and hence such TVs do exist. So I don't want to approve of some change that might not work well for everyone (i.e. not suitable as the defaults). Sorry, but I want to be able to sleep well at night. :/ We've got really few people left around who will test, report and fix problems. So any issues will likely stay around for a very, very long time.

Besides, most existing software were made to support a more common resolution like 640x480. Supporting 720x480 would require different art assets. Even OPL doesn't actually use 720x480 for the progressive-scan mode.

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. But on the other hand, I'm willing to accept your other changes that aren't related to the display parameters.

[Jay-Jay-OPL]

@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.

[spielvan]

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.

[sp193]

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. It's just that it is not the default. Even if I went with his suggestions, you will still have to adjust the frame buffer width and height anyway because changing all that (the default frame buffer width and height) will break compatibility with existing software.

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). Not only will that not alter the behaviour of the existing interlaced video modes, it is possible to set 720x480/720x576 as the default frame buffer resolution.

Sent from my Sony Xperia™ smartphone

[doctorxyz]

Hi mates, I would like to hear @BoGanon / Ragnarok2040 opinion about this too - Since it seems he was one of gsKit ancient contributors. It would be great to see his point of view. Nika (https://nika.osask.tk/?FrontPage) could contribute with his impressions on this too - He made an amazing launcher called LbF (https://nika.osask.tk/?appli/LbFn and http://psx-scene.com/forums/f19/lbfn-intro-english-documentation-work-progress-62196/), inspired on Mirakishi's LaunchELF v3.41 ; Its GUI has several built-in VGA and DTV modes (up to 1080i), moreover, all source code (with DW, DH values etc) are avaliable (commented on Japanese ;-). Nika seemed to not speak/write in English some years ago, but who knows now he speaks/write? It's just a matter of some Japanese speaker invite him to join us. Now I gotta go. See u!

[rickgaiser]

I've added an example. Both in source and binary (.elf) form. So please go ahead and test all modes.

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

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.

[sp193]

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.

[rickgaiser]

Yes, there are two borders. The first border is red and 4 pixels wide. The second border is white and 12 pixels wide. So in total the border is 16 pixels wide.

I forgot to mention:

• the width can be adjusted by pressing left and right in units of 64 pixels (becouse gsKit does not handle other magnitudes)
• the height can be adjusted by pressing up and down in units of 2 pixels The width I think I can make flexible also, if needed.

I have preset the values for all modes so the height fits my tv exactly (a full-hd 2015 sony) (use up/down to change). And the width is equal to or bigger than what my tv can display (use left/right to change). Fun fact: my tv displays every pixel in 1080i mode, no overscan. Yes, in sd modes it is cut off at both horizontal ends on my tv also. But when selecting 640 width I get black borders. So for my tv (and I think most tv's) the visible width is somewhere between 640 and 704 pixels. Given that both borders are not visible, the width must be somewhere between 640 and 672.

Please note that it is impossible to get these modes pixel perfect. You simply have to choose between: 1 Every pixel is visible, but most tv's will also show black borders 2 Not every pixel is visible, but there will be no black borders IMO an application (like OPL) should choose option 2, but have all text and buttons in the visible area. So the background can be rendered to for instance a width of 704, and the rest can be rendered to the center 640 pixels of the 704 width buffer. That way there will be no black borders, and no information lost.

Also take a look at the enormous x/y offset values for 720p and 1080i. I think the defaults in gsKit are wrong, becouse an offset of over 100 or 200 pixels should not be needed.

2016-11-11 2:10 GMT+01:00 Liu Woon Yung notifications@github.com:

Thanks for the binary. Is it supposed to draw a box in both test modes? If so, the larger one is cut off at both horizontal ends on my TV.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ps2dev/gsKit/pull/6#issuecomment-259854884, or mute the thread https://github.com/notifications/unsubscribe-auth/AEfm3w2Kmge6hWOcEFj8EeD-9UYe5T6Kks5q88BvgaJpZM4KXYo6 .

[sp193]

I would rather have Ragnarok2040 approve this... but because somebody keeps taking behind my back, I'll just accept your work. It'll make everyone happier, I guess.

Please make whatever changes you like and I'll just press the merge button. Thanks for your contributions.

[Jay-Jay-OPL]

@rickgaiser I'm able to test your modetest.elf -- nice work.

So far on my 1080p NTSC HDTV these work great: 720x480i 720x480p 1280x720p (did not fill the screen--it was a perfect square on my HDTV) 1920x1080i -- filled the screen, wow!

The R3 control was too sensitive. A tiny stroke and the blue screen would disappear from the screen. :) But I could adjust the screen using the DPad controls. Until I was able to see the white border around 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

[rickgaiser]

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.

[spielvan]

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.

[sp193]

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.

[sp193]

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.

[doctorxyz]

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).

[doctorxyz]

Hi mates, thanks to the insomnia + holiday, I was able to run modetest.elf.

My setup (for this test):

• PS2 SCPH-30001 R v4 NTSC 1D BIOS v1.60 NTSC console
• PS2 Component (Y Pb Pr) cable
• LG Time Machine 32" 32LB9RTA LCD HDTV

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.

[sp193]

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.

[rickgaiser]

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?

[sp193]

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

[rickgaiser]

Could you merge everything except for the binary?

[uyjulian]

You can do interactive rebase, remove the binaries, then force push.

[uyjulian]

Looks good to me!

[rickgaiser]

Ok, I've rebased to the latest ps2dev/gsKit/master, and removed the binary.