The above video goes away if you are a member and logged in, so log in now!
http://psx-scene.com/forums/showpost...&postcount=875 (GS Mode Selector: Development & Feedback)
I'm going pick on the change log for now
1- Added a coloured border for the entire GUI screen
3- Added outline rectangle to the screen edges in OSD section
9- Changed NTSC and PAL display offsets (yet again) to be optimized for quality direct-video cables (SCART or Component) rather than the crappy composite cables. (Let the 'flame wars' begin...)
Since this is a program intended for people who want improved viewing, optimizing for worst case cables makes no sense...
1- I hope know just colored the overscan area (click here for info).
3- You are just hiding OSD mess/problems
9- You changed "NTSC" vaules to "NTSC2PAL with X Fix" values for PAL TV only (like mess around with NTSC users specially with lee4)
GSM programmers can post their personal opinions but lee4 cannot.
EDIT: DX - 700 (for PAL TV) vs 632 (USA TV), now I know why video off center, dlanor change DX and DY for PAL TV only, which is wrong because newer TVs should auto detect vmode ratios
you playing on pcsx2 different from actual TV set
Originally Posted by yangjuniori
if you look close its says Interlaced (field)
Last edited by lee4; 01-04-2010 at 01:59 AM.
I am using GSM and it enables me to use HDL without disc boot(via FMCB) on my LCD monitor, thank you very much! GSM is great!
How can I configure GSM(and my system) in order to get better images for my PS2 titles? Since they are rather glitched now. I am using:
Philips 170x5 17' LCD Monitor(with SOG)
PS2 Console SPCH 30000(J)
GSM 0.23r beta
My title in trial is :
Super Robot Taisen Z(NTSC-J)
I forgot which VGA modes I had tried but the results were more or less the same except the screen sizes.
Thank you very much!
When quoting it is improper to modify the quoted material in any way.
Originally Posted by lee4
Doing so changes it from a proper quote into a construct of your own.
Even if it is just to add an emphasis that was not present in my original text.
If you have any objection to the sections you emphasized in color, then please state those objections in clear. But I stand by every word I wrote. The kind of cables that use a modulated carrier for the color information are indeed 'crappy', as is the quality of the pictures they produce. They are indeed the 'worst case' cables for a PS2, and optimizing our software for such cables would indeed 'make no sense', as it will then be unoptimized for all who have more decent cables.
You don't want to go there. Just take my word for it.
I'm going pick on the change log for now
***lee4 being VERY Sarcastic***
So far I have never really shown my sarcastic side in these forums, and I never intended to, but if you ask for it like this I might change my mind.
Please speak clearly. I have no idea what you meant by that overscan reference, or how this relates to the modification described in my point 1 (and 3)
The new screen objects are drawn by the same gsKit primitives as before and in the same coordinate space too, so there is no way this constitutes some new 'overscan' effect like you imply by that link.
I fail to understand the significance of that rephrasing.
In fact points 1 and 3 of my changelog for v0.23t both refer to one and the same change, but in my haste to get the release out I accidentally left both those points in, instead of removing point 3 (and renumbering) when I replaced it with point 1.
The change is that I modified the display of the status bar at the bottom of the logical screen and added two sidebars for the right and left edges of the logical screen (not the physical screen). This is mainly a cosmetic change, and I fail to see how this merits an accusation of trying to 'hide' any problems.
Btw: The bottom bar still needs some additional work, as there are some cases when it doesn't get redrawn correctly.
Like mentioned below, all PAL and NTSC settings were optimized for CRT TV sets
9- Changed "NTSC 4:3" vaules to "NTSC 16:9" values for widescreen TV only (like mess around with NTSC users specially with lee4)
I don't know what that was in reference to.
GSM programmers can post their personal opinions but lee4 cannot.
I never limit how others express their personal opinions, though anyone doing it in an offensive manner must expect a response of similar kind.
Quite wrong. This DX=700 setting is what gives ideal display of NTSC vmodes on my old CRT TV sets (I have two identical), both of which have 24" screens with 4:3 aspect ratio and which lack any trace of widescreen compatibility.
EDIT: DX - 700 (for 16:9) vs 632 (4:3), now I know why video off center, dlanor change DX and DY for widescreen TV only, which is wrong because newer TVs should auto detect vmode ratios
Their only semi-advanced features are that they come with SCART interface and full compatibility to both PAL and NTSC. I use these sets to establish screen positioning precisely because I want to AVOID the mistake you accuse me of, of making it depend on an HDTV set.
Also, for an HDTV set the precise DX value shouldn't matter anyway, since it should be able to display the entire screen of any 4:3 picture regardless of DX, as there is plenty of room to spare on either side of the used screen area.
On the other hand, the DX=632 value that you seem to love can only be useful with a composite or S-Video signal, as it is bound to place the left edge of the display off-screen when used with either RGB or component signals.
Best regards: dlanor
Few time here... :-(....
I am grateful that a big gun programmer like dlanor is back. No problem with this. And two coders can be better than one. ;-)
I've already seen that answer from you. Let's forgive that and go on on our common goal ;-)
You're always welcome here again!
Last edited by doctorxyz; 01-03-2010 at 04:49 PM.
Reason: Typos, English
doctorxyz's PS2 & PS3 stuff: (http://psx-scene.com/forums/f257/doctorxyzs-ps2-ps3-stuff-101348/)
Hey, I just found out about this program and I am a little confused. I have a PS2 with the PS2 component cables, I want to upscale ps2 games. So I tried to run this program from uLE but I just get a blank screen! Am I doing something wrong? Is it even possible to do this?
I'm pretty new to the PS2 scene, but I have been able to use GSM to load games on my 19" (1440 * 900) SOG monitor. I've been keeping up with this thread since the very beginning, just observing. I have essentially no coding background so forgive me for that.
Anyways, I'm able to get decent output on all but one of my games on HDL, that game being Final Fantasy XII. I've tried a multitude of the VGA presets, but they are all looking pretty similar to each other, just stretched differently. So far from what I've seen, the 1024*768 resolutions on my 19" monitor are stretched to fit horizontally but squished to half the screen vertically, but centered. Most outputs look the same though... The games working for VGA were Tales of the Abyss, FFX, and Dark Cloud.
I am a little disappointed, kind of like faifai442. I wasn't really expecting much, having a program force VGA output on a game that doesn't naturally do it, but still... I'm still getting better output through basic composite cables on my 20" CRT TV. The games are all completely playable, so that is still very good for me. I also tested the HD modes on my monitor, getting the very green image I was expecting. These modes did not look that much better either however... Overall, good job! Thanks for your work
Some GSM versions have weird initialization problems, and unfortunately this includes the v0.23t that I most recently released. After that release I discovered that it only works as intended on my fat PS2 consoles, but on the slim consoles it fails to initialize on its own. I can use an older version of GSM, exit from that program to uLE and then restart the new GSM version which then starts correctly, so it is some marginal error in the initialization. Try v0.23s2 as released by doctorxyz instead (all releases are in the first post of this thread). That version does initialize correctly on my slim consoles too.
Originally Posted by rlbond86
Strangely enough my own compilation of v0.23s2 sources gets the same init problem as v0.23t, so I think I need some other version of the PS2SDK or gsKit libs.
Can you please check which SVN versions of the libs you use, so I can ensure using the same for compiling GSM at my end. I have been using the latest SVN 1663 and 1664 respectively, which work fine for "Open PS2 Loader", but possibly we need some older libs for GSM. Like I said above, my own compilation of your v0.23s2 source does not behave like your binary does, so I'm pretty sure there is some crucial difference in our libs.
The above means that v0.23t is a bad version that you should avoid. When I know what lib revisions I need I will release a new version with those changes, plus some new improvements.
I'm not sure exactly what happens with gsGlobal, but it seems that some of its struct elements can change dynamically, in ways we do not expect. In many cases this causes the status bar display to be drawn in incorrect parts of the VRAM, with various unwanted side effects. I think I have a cure for that particular problem, which is to not use gsGlobal->Height for the drawing coordinates, instead using a normal variable initialized to the correct height value at each vmode change, which makes us independent of any mutilation of gsGlobal that gsKit may do. But at present I am unable to make a reliable new release due to my lib version problem.
Best regards: dlanor
Yes, FFXII is an odd one, and that is partly because it is more advanced in its control of video display format than most other games. This means that FFXII probably handles more GS registers directly, rather than trusting the standard Sony drivers to do the job like most games do. And if FFXII handles some of those registers with traps disabled, then there is nothing GSM can do about it, as we can never catch those manipulations. It is also likely that FFXII controls some registers we have not yet implemented in GSM, which is another reason why we would miss those manipulations as well. And whenever we catch only some of the manipulations attempted by the game, the result will be a mixture of register changes enforced by GSM for the enforced vmode, and other register changes made suitable for the original vmode, which might conflict with the enforced mode...
Originally Posted by Armoredraven
There is also a huge difference between PAL and NTSC versions of FFXII, which respond very differently to GSM operations.
This is a generic problem caused by the fact that we can only apply integers as multiplication factors for both horizontal and vertical scaling. For a game resolution of 448 pixels height (NTSC-I standard) the closest fit to 1024*768 would be somewhere between 640*448 and 1280*896. There is simply no way for us to rescale the game to fill out 1024*768 exactly. Even the horizontal fillout you did get must be a zooming effect of the monitor itself, because GSM has no way of doing that.
I've tried a multitude of the VGA presets, but they are all looking pretty similar to each other, just stretched differently. So far from what I've seen, the 1024*768 resolutions on my 19" monitor are stretched to fit horizontally but squished to half the screen vertically, but centered.
We may eventually be able to use floating point scaling for horizontal axis though, if we can find out how to gain precise control of the pixel clock. But as yet we can't do it.
Indeed. Many people misunderstand the purpose of GSM, and think that they can get games to display more detail than normally just because the physical mode is HDTV. But this is not so, as the higher HDTV resolution is filled out only by integral scaling, not by adding any new pixel data.
Most outputs look the same though...
The real purpose of GSM is not to enhance the graphic detail (impossible for any program of this kind), but to enable display where the unaided game would have been unable to do it. Like when playing a normal game on a VGA monitor, or a PAL game on a purely NTSC TV set and so on.
The only enhancements of picture quality that GSM can achieve are of two kinds:
1: Eliminating interlace flicker by displaying PAL/NTSC games in progressive vmode instead
For most NTSC games the best mode is 480p and for most PAL games the best mode is 576p, since those vmodes give game timing and screen proportions similar to the original.
2: Eliminating black borders for PAL games with graphics originally designed for NTSC versions of those games, by enforcing either NTSC mode or 480p mode to regain original screen proportions.
I think you are trying to use the wrong resolutions, and then you are naturally disappointed as there will then inevitably be both squashed proportions and black borders.
I am a little disappointed, kind of like faifai442. I wasn't really expecting much, having a program force VGA output on a game that doesn't naturally do it, but still...
You have to be joking. With composite cables it's practically a guessing game what colours you'll get, and there will be luminance fuzziness as well due to the colour carrier effects.
I'm still getting better output through basic composite cables on my 20" CRT TV.
Any half-way decent VGA monitor should support at least one of the traditional 'bog standard' 640*480 resolutions, which are ideal for playing most NTSC games. And by playing around with the DX,DY,DW,DH parameters you can also force PAL games to be properly adjusted for using the same screen area. (So as to play PAL FFX without the huge top and bottom borders, for example.)
The key to using PAL games that way is to understand that proper centering requires DW and DH values that at least match the resolution-1 of the target game. So for a PAL game you normally need to fake a DH value of 511 (PAL Height(512) - 1), and then compensate with a lowered DY value to make the useful part of the screen well centered.
Right, but that has nothing to do with GSM.
The games are all completely playable, so that is still very good for me. I also tested the HD modes on my monitor, getting the very green image I was expecting.
On a VGA monitor they wouldn't, because it can't scale them properly. But on a real HDTV set it is a different story. But their usefulness is still limited by the integral scale factors.
These modes did not look that much better either however...
For example, 720p is almost useless, except for NTSC lorez games of 320x224, as that allows integral scaling to 1280x672, which fills out the screen quite well, and is fine for games where natural proportions don't matter much. And 1080i can be ideal for some PAL games, as its real visible height is around 1024 pixels which is an integral multiple of the PAL height both for interlaced and lorez modes.
A good understanding of how the integral scaling and screen centering works can help you make the most of the GSM capabilities.
Best regards: dlanor
In fact I now have two separate Cygwin setups, each with two different PS2Dev lib setups, with each of the two Cygwin setups stored as separate snapshot branches of a VMware virtual machine. The dual lib setups are because I need one for uLE, and another for projects that require later lib versions, like "Open PS2 Loader" and GSM both do. And the dual Cygwin setups are due to my searching for the optimum version. (The best updated one before compatibility to ps2dev stuff was lost.)
Originally Posted by E P
Later on I naturally plan to install the stuff on a physical machine instead, but for the present experiments VMware is ideal, as I can migrate between different snapshot branches for comparison tests in a matter of seconds. Doing the same with a physical machine would require HDD backup and restoration at each such switch, with a time loss on the order of half an hour at least each time.
The Cygwins I currently have are from December 2004 and July 2005, and they are both working fine. It is interesting to note that I re-compiled uLE v4.40b, originally compiled and released by you, and the result with the latter Cygwin version was byte for byte identical with your "uncompressed BOOT.ELF", so this setup must be very close to yours.
The ones I used are much larger (around 500MB each), as I've been downloading complete Cygwin packages from the 'fruitbat' site. The odd thing is that not all of those are complete or even working for an install. I've tried over half a dozen of them, and so far only these two worked acceptably.
I did take a look at my ps2dev stuff on my CD-RW disc. It contained a little more than 50 megs of the Cygwin setup files and another 50 MB of ps2dev setup packages.
Both of mine have done that, though not by running the downloading script, as that seems to depend on some linux features not supported by Cygwin. But I did have a full set of the ps2dev toolchain sources archived from earlier installations, and this compiled fine for both of my Cygwin setups.
Keep in mind though that my Windows XP Cygwin setup was never able to compile a working ps2dev setup from scratch under Windows though.
I may try a linux setup sometime later too, but for now I decided to go with the stuff I was more familiar with.
At least, under Linux I have been able to build the toolchain from scratch.
Yes this is clearly the init problem at work. It is very strange that this never happens on my v7 PS2 though, whether I boot by Dev1 or by FMCB (with modchip disabled). On that console the init works every time.
Okay on to GSM. I have been unable to run your new build like your previous released version. Even compiling my own led to a black screen. I've ran it via ps2link and even ran the ELF file from hard drive using LaunchELF's loader. No splash screen was shown either and judging from all the pics in the thread, I'll assume I should have at least seen it.
So it looks like possibly another or a similar initialization issue at hand.
But on the slim consoles it only works if I first run an old version, and then exit from that to run the new version. I suspect some lib update of PS2SDK or gsKit to be responsible.
Well, the "s2" version of doctorxyz also works for me, even though it is a bit messy with those 11 redundant vmodes.
Looks like it's back to the working "r" version in the meantime for some of us.
I certainly hope to fix it shortly, as it relates to the integrity of my ps2dev setups.
Although I'm pretty sure this issue will be short lived as fast as this project tends to move.
But their basic integrity was pretty much proven by the identical binary produced for uLE v4.40b, so I am not too worried about the Cygwin setup. It is probably just a matter of downgrading an SVN revision or two for some lib.
I agree. Probably both model and mod differencies can affect this.
Edit: Should have refreshed the page before replying.
Let me just add that it's not working on my fat v4 PS2 so models may vary.
Best regards: dlanor
View Tag Cloud