Let's correct FCEUltra screen aspect ratio?

cospefogo · Post by **cospefogo** » Sat Dec 12, 2009 9:42 pm

Gentlemen,

Recently I found out about FCEUltra on PS2 and I am pretty amazed by this awesome emulator, however it has a severe problem - the screen aspect ratio is not correct! On Xbox emulator we are able to change the screen size until we reach the correct 512x448 (256x224*2) size. On this size every pixel is perfectly correct and there is no distortion on the graphics, specially on the screen scrolling.

If you take - on FCEUltra 0.9.3 - the game ABADOX (U) and move the spaceship up and down it will be easily noticeable the wrong aspect ratio problem. If you take CASTLEVANIA 3 (U) and walk forward and backward, scrolling the scenery you will notice also the wrong aspect ratio.

But please not, you must have the FILTERING turned OFF.

Now, the main point of the topic - Is someone able to help me to correct the screen aspect ratio of the FCEUltra emulator? I have the source code here but I am not able to work on it since I'm not a PS2 developer and I am not able to compile PS2 binaries.

I am just looking forward to find a partner interested in have the emulator working on a real perfect way!

Thanks guys!
Cospefogo.

ragnarok2040 · Post by **ragnarok2040** » Sun Dec 13, 2009 2:15 am

I'm the original author of PS2 FCEUltra, and the port was really my first coding project. I didn't use a vsync interrupt handler, so the sound buffer underruns a lot, since each frame is locked between vsyncs. Plus, I didn't know how to correctly map the framebuffer to the right texel coordinates, so the texture filtering was always enabled. The only way to disable the filtering is to map the original framebuffer to the correct texel coordinates.

I've learned a lot since then and I'm working on porting an updated version. I've just been busy updating and optimizing libraries of ps2sdk that deal with the DMAC/GS/GIF, adding stuff to deal with the VUs, and updating some libc code so I can also port other emulators, like Snes9x. The next version will be great, once I can get back to it, :D.

cospefogo · Post by **cospefogo** » Sun Dec 13, 2009 12:59 pm

Dear Ragnarok2040,

Thank you very much for your attention on this. I think it is very important to keep the screen on a correct aspect ratio, so it will be wonderful if you couls spend some special care on this matter on your next releases.

On the Xbox-Scene world I have a extensive research on this subject - the correct screen aspect ratio for emulators - and if you have more interest on it, feel free to visit my website here:

http://fancyxbox.info/?doc=1&secao=screen

Thank you very much again!
If you need any help on testing a newer version to check the screen aspect ratio adjusments, please let me know. It will be a pleasure to provide help!

Cospefogo.

ragnarok2040 · Post by **ragnarok2040** » Mon Dec 14, 2009 3:30 am

The good thing about the PS2's GS, is that the framebuffer can be "magnified" without the use of a scaler or filter, allowing for the original resolution to be used and should be without any type of distortion.

I will also add other optional filters like nearest-neighbor/bilinear, for scaling to a higher resolution, for people who want that. There'll also be a flicker filter for interlaced mode that can be turned on/off. For 16:9, I'll support forms of pillarboxing and windowboxing, as well, for keeping the original aspect ratio and resolution. There's also an option to use digital or analog output, but that's still in the experimental stage, since it deals with the low-level video hardware.

I have a lot of features planned, but it's just taken me a while to add the required code in ps2sdk. I'm nearly done with that now, since I've finally managed to get past my current hurdle with separating out and setting the drawing environment registers. Now I just need to glue the parts back together, heh.

cospefogo · Post by **cospefogo** » Mon Dec 14, 2009 7:36 am

ragnarok2040 wrote:The good thing about the PS2's GS, is that the framebuffer can be "magnified" without the use of a scaler or filter, allowing for the original resolution to be used and should be without any type of distortion.

Yes, Mister!
This is really fantastic.
Please keep us updated of your progress!

Thanks!
Cospefogo.

protomank · Post by **protomank** » Tue Dec 15, 2009 4:27 am

Maybe you can add those video tools to SDL port in the future ragnarok?
It would help porting a *lot* of software to PS2 ;)

protomank · Post by **protomank** » Sun Feb 07, 2010 11:14 pm

Hey Ragnarok, do you know if it is possible to anyway, disable bilinear filtering in gsKit? Or I need to wait for your drawlib then port SDL to use it?

Thanks.

ragnarok2040 · Post by **ragnarok2040** » Mon Feb 08, 2010 2:27 am

It's kind of complicated. You have to map the texture onto your primitive, so that the texture's texels map correctly on your primitive so that the DDA thinks the texture doesn't need to be scaled.

Jbit made a couple of examples of it: http://www.jbit.net/ps2/gs-linear-sprite.html

Some background information:
The framebuffer deals only with whole pixel coordinates (0 <= 640, 0 <= 448) for NTSC. The primitive coordinate system is in 12.4 fixed point, so you have (0.0000 <= 4095.9375, 0.0000 <= 4095.9375). The framebuffer is "mapped" onto the primitive coordinate system by essentially translating its origin onto the primitive coordinate system at some point. For gsKit, it's at (2048.0f,2048.0f). Then there's the texel coordinate system in 11.4 fixed point, which are the coordinates of the texture data that gsKit uses.

Now, depending on the primitive, the starting (top/left-hand) coordinates will either round down to the previous whole coordinate, or round up to the next whole coordinate. The ending (bottom/right-hand) will always round down to previous coordinates. This is to prevent overlapping when drawing 3d objects.

For sprites, I think the top/left-hand always rounds up, and the bottom/right-hand always rounds down. The texel coordinates should be mapped to (0.5,0.5) to (W - 0.5,H - 0.5). But, jbit seemed to have better results using -0.375.

My understanding might be wrong somewhere so corrections are appreciated :D.

It might be better to just wait until the new libraries are done. I'll need your help with modifying SDL to use the new libgraph/libdraw code, after I get it finished.

It's taking me a while because I have an ATI gfx card on ArchLinux, which is a rolling release distro (latest updates are released consistantly). Since AMD hasn't supported the latest version of Xorg 1.7 or the Linux kernel, I had to quit installing updates. Then when I needed a good IDE for integrating my changes into ps2sdk, I ran into so many problems trying to upgrade that it left my computer without a desktop environment, so I tried using a laptop with Vista, which had its own issues. I eventually gave up on that and got Arch up and running again.

protomank · Post by **protomank** » Mon Feb 08, 2010 2:51 am

ragnarok2040 wrote:It might be better to just wait until the new libraries are done. I'll need your help with modifying SDL to use the new libgraph/libdraw code, after I get it finished.

It's taking me a while because I have an ATI gfx card on ArchLinux, which is a rolling release distro (latest updates are released consistantly). Since AMD hasn't supported the latest version of Xorg 1.7 or the Linux kernel, I had to quit installing updates. Then when I needed a good IDE for integrating my changes into ps2sdk, I ran into so many problems trying to upgrade that it left my computer without a desktop environment, so I tried using a laptop with Vista, which had its own issues. I eventually gave up on that and got Arch up and running again.

Great news, any help on the SDL front is welcome :)
I am currently trying to fix SDL_Delay and SDL_Timer using the timer code that was published here in the forum by shawn_t.
As SDL/PS2 is no longer maintened, and have lots of issues, I am planning just to use it's functions as wrappers for native PS2 code instead of trying to just hack around it. I hope my fixes in SDL_Delay can fix the thread and mixer somehow, because there were a lot of calls to SDL_Delay on the code, and it was not really working, but I still not tested it.

Once I get cosmito mixer (or any other replacement for playing music/sounds in PS2) working, I'll try to port it to SDL_mixer, in case the fix for SDL_delay did not helped it.

As for threas, that is way beyond my free time to investigate, so I'll have to live with it. My only real problem in PS2 front is that when I do a loop to read user input, the sound is choppy, as I am not using threads at this time (it make harder to code the parts I am really interested in). So it kind of is really working fine, what is great news :)

As for the SDK, I am using ubuntu 9.10, it works fairly well and I can just use apt-get to upgrade it to new version without reinstalling the SDKs. I am using a VM with windows XP inside it to compile to win32, by using mingw+sdl+qtcreator (I love it as an IDE), on linux, qtcreator, gcc and SDL. And I have installed and tested with OpenXDK (xbox SDK) and Nintendo DS SDK, besides the PS2 SDK. All working fine in the same linux box :D

cosmito · Post by **cosmito** » Mon Feb 08, 2010 8:42 am

protomank wrote:As for threas, that is way beyond my free time to investigate, so I'll have to live with it. My only real problem in PS2 front is that when I do a loop to read user input, the sound is choppy, as I am not using threads at this time (it make harder to code the parts I am really interested in). So it kind of is really working fine, what is great news :)

My sound engine runs on a thread on the EE, so you must take care of switching threads to avoid the sound issues. Take a look at the cosMix "simpleTest" example. For every loop at your program, you must call RotateThreadReadyQueue() with the defined thread priority.

In the above example you have :

Code: Select all

	while&#40;IsPlaying&#40;&#41;>0&#41;
	&#123;
		RotateThreadReadyQueue&#40;42&#41;;
	&#125;

the while is/represents a loop, of course.

the example "simpleTest_with_thread_switching" use an automated thread switching (clever trick, thanks EEUG!) therefore not needing the RotateThreadReadyQueue calls but needs some tweaking.