Sponsored Links

Sponsored Links

Page 19 of 68 FirstFirst ... 9171819202129 ... LastLast
Results 181 to 190 of 680



  1. #181
    Senior Member squarepusher2's Avatar
    Join Date
    Sep 2010
    Posts
    157
    Sponsored Links
    Sponsored Links
    OK, here is a version with a 'Quit ROM shortcut'. As always, the binary and the source are included.

    This kinda negates my earlier promise not to release any more unsubstantial updates, but the inability to quit a ROM and having to manually exit the emulator everytime using Quit Game in the XMB surely irritated the crap out of everyone, so there.

    ROM Quit: Press R2 + L2 simultaneously to go back to the ROM browser menu.

    This shortcut will likely change as more features are added.

    SNES9x-PS3 Squarepusher Build 4.2.1 (with Source)

    http://www.ps3news.com/forums/attach...chmentid=21802
    Attached Files Attached Files

  2. #182
    Senior Member squarepusher2's Avatar
    Join Date
    Sep 2010
    Posts
    157
    Sponsored Links
    Sponsored Links
    OK, noticed another problem with this ROM switching method that I've implemented in build 4.2.1 - after having quit a ROM and selected a ROM for five times or so, eventually the next ROM you will load will just render a black screen and you'll have to reset the PS3.

    At first I thought that maybe I should 'quit' Snes9x properly and deallocate all memory assigned to it. So after going out of the 'is_running' loop, I called the following Snes9x callbacks:

    Memory.Deinit();
    S9xGraphicsDeinit();
    S9xDeinitAPU();

    I also read here that after you've called Memory.LoadROM, you should call S9xReset() after that:

    [Register or Login to view links]

    So also added that. But it did not seem to fix the problem.

    I figured that maybe there is something in the display code that is not properly handling this reinitialization of the screen.

    I really hope Eiz will come back at some point and look at the state the emulator is now in and perhaps revisit the display code and all the other parts that would need some work - I'm mainly building on his code at the moment.

  3. #183
    Registered User zeromx's Avatar
    Join Date
    Dec 2008
    Posts
    221
    Sponsored Links
    Sponsored Links
    squarepusher2 - You the man, great work with all the updates...

    +REP for all your work so far...

    Ps, your exit function L2+R2 works flawlessly
    Last edited by zeromx; 09-24-2010 at 08:55 PM Reason: Automerged Doublepost

  4. #184
    Registered User limnique's Avatar
    Join Date
    Jun 2006
    Posts
    59
    squarepusher2, thx, work nice, but have black screen problem

  5. #185
    Senior Member squarepusher2's Avatar
    Join Date
    Sep 2010
    Posts
    157
    Quote Originally Posted by limnique View Post
    squarepusher2, thx, work nice, but have black screen problem
    Yeah, it does that after having swapped five or so ROMs. A good rule of thumb at the moment is to select 'Quit Game' from the XMB after having loaded the third ROM or so until I can figure out the source of the problem.

    It sucks that S9xExit() doesn't really do what I would have expected it to do - according to the Porting manual, this callback is only called when something majorly bad happens (with the emulator), or when the debugger stops the emulator (the debugger which is not enabled at the moment). I could perhaps try to implement S9xExit() as a callback and then have it go back to the ROM screen - perhaps that can get around the black screen after having loaded the fourth/fifth ROM or so.

    EDIT: Just tried that - didn't seem to fix the black screen problem. Perhaps eisz might want to check out my code - he should PM me and I will give him the source of the latest changes I made.

    All the changes have been made in cell.cpp.

    Here's what I changed to implement the Quit ROM functionality:

    First I have declared a global int variable called 'mode_switch'.

    In the main loop, I have split off the entire block of main code into separate functions - so you now have 'start_display', 'rom_menu' and 'start_snes9x'.

    start_display

    I've simply moved over a lot of the code inside main to a separate function that I can then call from the infinite main loop whenever I need to re-render the rom_menu (you don't need to explicitly call this before calling rom_menu, but whether you call it again or not, it will still give a black screen after loading 4/5 ROMs.

    Code:
    void start_display()
    {
    	init_display();
    	init_shader();
    
    	dma_label = cellGcmGetLabelAddress(dma_label_id);
    	*dma_label = dma_label_value;
    
    	is_running = true;
    
    	uint32_t buf_size = sizeof(color4_t) * color_buf[0].width * color_buf[0].height;
    	buf_size = (buf_size + 1024 * 1024) & (~(1024 * 1024 - 1));
    
    	color4_t *buf = (color4_t *)memalign(1024 * 1024, buf_size);
    	cellGcmMapMainMemory(buf, buf_size, &display_back_offset);
    
    	memset(buf, 0, buf_size);
    	display_back = buf;
    
    	buf = (color4_t *)memalign(1024 * 1024, buf_size);
    	cellGcmMapMainMemory(buf, buf_size, &display_offset);
    
    	memset(buf, 0, buf_size);
    	display = buf;
    
    	setDrawEnv();
    
    	set_render_state();
    	setRenderTarget(frame_index);
    }
    The following changes has been made in rom_menu:

    rom_menu


    Code:
    			if (buttons & CTRL_CROSS) {
    				if (is_dir[current_index]) {
    					sprintf(path, "%s/%s", path, file_names[current_index]);
    					needs_update = true;
    					continue;
    				} else {
    					sprintf(rom_path, "%s/%s", path, file_names[current_index]);
    					[b]mode_switch = 1; //new[/n]
    					return;
    				}
    			}
    start_snes9x

    Code:
    void start_snes9x()
    {
    	bool snes9x_loaded = false;
    	if (!(snes9x_loaded = init_snes9x())) {
    		Settings.Paused = TRUE;
    	}
    
    	int count = 0;
    	
    	init_sound();
    	S9xSetSoundMute(FALSE);
    	S9xReset();
    
    	memset(display, 0, color_buf[0].height * color_buf[0].pitch);
    	memset(display_back, 0, color_buf[0].height * color_buf[0].pitch);
    
    	while (is_running) {
    		read_pad();
    
    		if (!Settings.Paused) {
    			make_noise();
    			if (S9xSyncSound())
    				S9xMainLoop();
    		}
    
    		if (debug_text)
    			debugOutStr(100, 100, debug_text);
    
    		render(false);
    	}
    
    
    	if (snes9x_loaded)
    		Memory.SaveSRAM(S9xGetFilename(".srm", SRAM_DIR));
    	snes9x_loaded = false;
    	Memory.Deinit();
    	S9xGraphicsDeinit();
    	S9xDeinitAPU();
    	is_running = true;
    
    }
    Then near the end of the main loop, I run an infinite loop where the mode switching will occur. The code is basically trapped inside one of either functions (rom_menu or start_snes9x) as long as no user input takes them out of it (in-game, this is achieved by pressing L2 + R2, which sets mode_switch to 0 and is_running to false, and will return the code from the start_snes9x body back to the infinite loop inside main().

    Main

    Code:
    int main (void) {
    	cellSysmoduleLoadModule(CELL_SYSMODULE_FS);
    	cellSysmoduleLoadModule(CELL_SYSMODULE_IO);
    	cellSysmoduleLoadModule(CELL_SYSMODULE_AUDIO);
    
    	cellSysutilRegisterCallback(0, sysutil_exit_callback, NULL);
    
    	cellPadInit(7);
    	start_display();
    
    	rom_menu();
    
    	while(1)
    	{
    		switch(mode_switch)
    		{
    			case 0:
    				start_display();
    				rom_menu();
    				break;
    			case 1:
    				start_snes9x();
    				break;
    			case 2:
    				return 0;
    		}
    	}
    
    	return 0;
    }
    S9Exit callback

    Was previously empty, now takes care of the deinitialization process. Not sure if it is actually called though - or whether the 'black screen' even constitutes an error occurring in Snes9x, or whether it's the display code.

    Code:
    void S9xExit (void) {
    	Memory.Deinit();   // new
    	S9xGraphicsDeinit(); // new
    	S9xDeinitAPU(); //new
    	is_running = false; //new
    	mode_switch = 0; //when set to 0, will go to the ROM menu
    }
    The following changes has been made in rom_menu:

    rom_menu
    [/quote]

    Forgot to add the following change:

    Code:
    			S9xReportButton(MAKE_BUTTON(pad_id, BTN_RIGHT), (buttons & CTRL_RIGHT) != 0); //old
    // below is new
    			if ((buttons & CTRL_R2) != 0 && (buttons & CTRL_L2) != 0)
    			{
    				is_running = false;
    				S9xExit();
    				mode_switch = 0;
    			}
    The following changes has been made in rom_menu:

    rom_menu
    [/quote]

    Forgot to add the following change:

    Code:
    			S9xReportButton(MAKE_BUTTON(pad_id, BTN_RIGHT), (buttons & CTRL_RIGHT) != 0); //old
    // below is new
    			if ((buttons & CTRL_R2) != 0 && (buttons & CTRL_L2) != 0)
    			{
    				is_running = false;
    				S9xExit();
    				mode_switch = 0;
    			}
    Slight typo there - S9xExit(); should not be in there since it should not be called before we've got the chance to do the Memory.SaveRAM call.
    Last edited by squarepusher2; 09-25-2010 at 12:05 AM Reason: Automerged Doublepost

  6. #186
    Senior Member BwE's Avatar
    Join Date
    Apr 2010
    Posts
    709
    this actually works quite well.. sound, video everything.. played a game i haven't played in about 10 years.

    <3 cheers to the guy who made this

  7. #187
    Senior Member squarepusher2's Avatar
    Join Date
    Sep 2010
    Posts
    157
    Just wanted to inform you guys on the latest build:

    * It crashes on a black screen after loading the fifth ROM using the Quit ROM feature (L2+R2 in-game). So, basically, after having loaded the fourth ROM using the Quit ROM shortcut button (L2+R2) - if you want to play another ROM, click on the PS button and select Quit Game - then, restart the emulator.

    If you don't, the fifth ROM will crash the emulator and you will have to reboot and hook up your PSgroove device to the machine to get it back into Jailbreak mode. Major hassle, and it can be easily avoided at the moment this way until I've figured out what is going wrong here.

    I think this is some kind of bug with the RSX and the libgcm display code - it's really hard to debug this stuff without Sony's own debugger setup - but perhaps output some kind of debug string to try to pinpoint at least where it goes wrong. It doesn't help either that libGCM basically assumes you have a total understanding of how the RSX operates - and therefore doesn't permit any kind of screwups. I don't think any homebrew programmer at the moment is at the point where they can honestly say they understand totally how the RSX needs to be operated using libGCM, and all the things that can potentially go wrong.

    In that sense, I think switching to PSGL would be preferable because there are less opportunities to screw up.

    EDIT: Just knocked up a quick (and ugly) hack that will simply exit the emulator and return you back to the XMB after having loaded the fourth ROM. Of course, the real priority is getting this issue sorted out - perhaps eisz might want to help out on this one. In the interim, this is better than it simply crashing on a black screen.

    SNES9x PS3 Build 4.2.2 (with source)

    CHANGED: Exits the emulator and returns back to the XMB after having loaded the fourth ROM to prevent black screen upon trying to load the fifth ROM from the ROM browser menu.

    cell.cpp

    Code:
    static bool is_running; //old
    static int mode_switch = 0; //new (as of build 4.1.1)
    static int rom_loaded_count = 0; //new (as of build 4.1.2)
    Code:
    			S9xReportButton(MAKE_BUTTON(pad_id, BTN_RIGHT), (buttons & CTRL_RIGHT) != 0); //old
    //rom quit shortcut
    			if ((buttons & CTRL_R2) != 0 && (buttons & CTRL_L2) != 0)
    			{
    				is_running = false;
    //rom_loaded_count is a global int variable - gets incremented 
    // everytime a ROM has been loaded (and exited using L2+R2)
    				rom_loaded_count++;
    //will change this to:  if(rom_loaded_count++ == 4) - saves one line
    				if(rom_loaded_count == 4)
    				{
    // mode_switch with a value of 2 will trigger a 'return 0' inside the
    // switch loop of main()
    					mode_switch = 2;
    				}
    				else
    				{
    //mode_switch with a value of 0 will trigger 'rom_menu()' - you can select another ROM
    					mode_switch = 0;
    				}
    
    			}
    Attached Files Attached Files

  8. #188
    Senior Member squarepusher2's Avatar
    Join Date
    Sep 2010
    Posts
    157
    Coincidentally, I think I have implemented something that might count as an improvement, video-wise.

    I was noticing on certain games like Donkey Kong Country - when the screen was really moving fast, that it was still skipping over a frame or so even though V-Sync is enabled.

    Byuu himself (bsnes creator) commented on the PS3news forum that, in order to get perfect video/audio synchronization, there are a couple of hurdles to overcome - and he says it all comes down to the discrepancy between the SNES's video output frequency vs the PS3's.
    Quote Originally Posted by byuusan View Post
    The right way: trial and error. Keep adjusting the input sample frequency. That has the effect of speeding up or slowing down emulation to match the video frequencies. It's by less than .1% so you won't notice it. There's no way to detect it, each person will have to play with the input value until they find the one that works for them alone. It does not matter whether your audio driver is blocking or not, if you do this right. It would probably be easier to convert your users to another religion or switch political ideologies than get them to understand all this though

    The lazy way: you add or drop video frames, like most desktop emulators do. Say your PS3 is running at 60hz, the SNES at 60.09hz. So every ~11 seconds, the SNES creates and extra frame. Since you can't resample video, skip it. It will cause a jerk in scrolling animation for one frame every 11 seconds. But the nice part here is nobody has to adjust any values. To skip the frame, you have to triple buffer.

    Every time a frame is ready from the SNES, queue it up in one of your two buffers, and make that your active buffer. Every time it's time to present a screen, show the most recently drawn one. If you run too fast, it overwrites a screen and you miss it. If it runs too slow, it draws the same old screen, duplicating it. You may have to implement your own TB system using areWeInVsync() calls, if you have a piece of shit API that blocks when you have two frames pending so as to stop you from ever dropping one. Better to use page flipping than blitting here if possible.
    I think I have fiddled around enough with the SoundInputRate at this point - it sounds close enough to perfect for most games - and video seems good too - might want to tweak it some more though.

    Anyway, I found a couple of functions that libgcm provides that are directly related to the Vsync frequency discrepancy:

    cellGcmSetVBlankFrequency

    Set a VBlank interrupt and V frequency to be used for a flip

    Unfortunately, from the way I see it, there are only two macros I can select from -

    CELL_GCM_DISPLAY_FREQUENCY_59_94HZ, and
    CELL_GCM_DISPLAY_FREQUENCY_SCANOUT

    The 'scanout' frequency basically takes the refresh rate from your monitor/output device, while the 59.94Hz one fixes it to 59.94Hz.

    Then, I found another function, which allows you to do two V-sync passes:

    cellGcmSetSecondVFrequency

    Set second V interrupt frequency

    So, what I've done is the following - at the place in cell.cpp where it previously just set VSYNC on, I've now done this:

    Code:
    cellGcmSetVBlankFrequency(CELL_GCM_DISPLAY_FREQUENCY_SCANOUT); // Default value
    cellGcmSetSecondVFrequency(CELL_GCM_DISPLAY_FREQUENCY_59_94HZ); 
    cellGcmSetFlipMode(CELL_GCM_DISPLAY_VSYNC);
    So, what this does is the following - do two vertical blanks at different frequencies after one another - the first will Vblank at the frequency of your monitor output, while the second will Vblank at the fixed 59.94Hz frequency.

    The SDK document says the following about this:

    Example: Output a video encoded with 59.94Hz by first converting it to a frequency of 50Hz for a 50Hz video output.
    Set as follows.
    So it has a definite use, but I'm not sure whether I'm using it here in the manner I'm supposed to use it - all I know is that the SNES according to byuu renders at 60.09hz, while the PS3 seems to run at whatever the monitor/TV you've hooked it up to can natively support at that resolution. So, I then do a second Vblanking at 59.94Hz, and that seems to take care of the odd frame that looked like a skip.

    Another thing I could try is this:

    Code:
    cellGcmSetVBlankFrequency(CELL_GCM_DISPLAY_FREQUENCY_SCANOUT); // Default value
    cellGcmSetSecondVFrequency(CELL_GCM_DISPLAY_FREQUENCY_SCANOUT); 
    cellGcmSetFlipMode(CELL_GCM_DISPLAY_VSYNC);
    That would do two Vblanks at the refresh rate your monitor supports - not sure which is better - haven't yet tried it.

    Anyway, it sure seems a lot smoother. I might release a new version with this tweak in it and let people decide if it's better. In case you're going to test it with PAL games and complain that it's screwed up - well, don't - since PAL ROMs have been borked ever since I applied those APU patches from the post-SNES9x 1.52 patches. I think it has something to do with the way the screen is rendered using libgcm inside the Snes9x display callbacks.

    I think for PAL games, there would have to be a way of setting both Vblanks forcibly at 50Hz or something.

  9. #189
    Banned User byuusan's Avatar
    Join Date
    Sep 2010
    Posts
    6
    I've posted a completed bsnes v069, and Ver Greeneyes has volunteered to try and port it to C++98. That's in-progress as we speak, though help would be appreciated. Very hopeful to see bsnes on the PS3.

    > So it has a definite use, but I'm not sure whether I'm using it here in the manner I'm supposed to use it - all I know is that the SNES according to byuu renders at 60.09hz, while the PS3 seems to run at whatever the monitor/TV you've hooked it up to can natively support at that resolution.

    SNES video is tricky. In progressive (99% of games), it's 60.09hz, in interlace it's 59.97hz. PAL has different timings as well for both modes.

    I would recommend you use the PS3 59.94hz mode for having more consistency, but don't forget that nothing's perfect. Even though it says 59.94hz, some will be closer to 59.93, some to 59.95, etc. Who knows how much variance there is. There will never be a perfect InputFrequency, so let users adjust it

  10. #190
    Senior Member squarepusher2's Avatar
    Join Date
    Sep 2010
    Posts
    157
    Quote Originally Posted by byuusan View Post
    I've posted a completed bsnes v069, and Ver Greeneyes has volunteered to try and port it to C++98. That's in-progress as we speak, though help would be appreciated. Very hopeful to see bsnes on the PS3.
    Great to hear. I'm also going to check out bSNES 0.69 BTW ASAP - I'm curious to learn whether I can finally achieve 60fps in all games on my lowly Windows box which is sitting next to the Linux box (which is running an Intel Core Duo 1 T2300 @ 1.66GHz and 1GB of RAM).

    It would drop to 45fps or so on the map screen of Yoshi's Island.

    BTW, on that same topic - I also noticed that there is one particular effect in Yoshi's Island that Snes9x seems to slow down massively on - there is this one stage where if you touch one of these enemies, the screen becomes all swirly (as if Yoshi is on LSD). That slows down massively on SNES9x - it's really evident.
    Quote Originally Posted by byuusan View Post
    > So it has a definite use, but I'm not sure whether I'm using it here in the manner I'm supposed to use it - all I know is that the SNES according to byuu renders at 60.09hz, while the PS3 seems to run at whatever the monitor/TV you've hooked it up to can natively support at that resolution.

    SNES video is tricky. In progressive (99% of games), it's 60.09hz, in interlace it's 59.97hz. PAL has different timings as well for both modes.

    I would recommend you use the PS3 59.94hz mode for having more consistency, but don't forget that nothing's perfect. Even though it says 59.94hz, some will be closer to 59.93, some to 59.95, etc. Who knows how much variance there is. There will never be a perfect InputFrequency, so let users adjust it
    Alright, great to hear that. I think I'll have a go with two Vblanks at 59.94Hz mode then and see how it looks. So I take it given these new conditions, I have to basically try my luck again with the SoundInputRate? Because I left it at the InputRate I have been using up until now which managed to fix most of the sound pops I used to hear on other SoundInputRates. I take it adjusting the value further might lead to near-perfect video/audio synchronization - because I still noticed a slight distortion every so often when I had two Vblanks running at the refresh rate that the monitor supported (the CELL_GCM_DISPLAY_FREQUENCY_SCANOUT macro).

    I didn't seem to notice it in Donkey Kong Country 2, but it was a bit apparent in Super Mario World. It's not really deal-breaking though - you have to really squint and be very pedantic to even care about this I reckon.

    EDIT:

    Alright, with some guidance from byuu I've now got the video/audio timing just right. The key to it was setting the refresh rate right so that it matched the SNES' own (more or less). NTSC is covered now - PAL will be my next priority.

    Those who just want to play - here are the links, here are the changes - you're free to ignore the rest, as it's only interesting to those who want to contribute or are interested in exploring the SDK.

    SNES9x Square Build 4.3 (With source)

    Code:
    Build 4.3 CHANGES:
    * Aspect ratio set to 4:3
    * Better colors
    * Runs now at native 480p resolution @ 59.94Hz - together with SoundInputrate (31942), takes care of all audio/video glitches. Basically runs and performs like a native SNES now - or at least close.
    OK, now onto what I changed and what I have explored with some success:

    Credit should go to byuu for pointing me in the right direction here:
    I would recommend you use the PS3 59.94hz mode for having more consistency, but don't forget that nothing's perfect. Even though it says 59.94hz, some will be closer to 59.93, some to 59.95, etc. Who knows how much variance there is. There will never be a perfect InputFrequency, so let users adjust it
    Basically, the way libGCM previously defined the resolution, refresh rate and aspect ratio was all automatically and according to the specs of the monitor/TV you've connected the PS3 with.

    Unfortunately, while it may strive to select the highest refresh rate, it is not the best judge when it comes to running SNES emulators - the highest refresh rate (which I assume to be 60Hz) did not seem to gel with Snes9x.

    So, what I did here in cell.cpp (inside the function init_display()) was to define a couple of instance variables of video_state (of type CellVideoOutState):

    Code:
    video_state.displayMode.resolutionId = CELL_VIDEO_OUT_RESOLUTION_480;
    video_state.displayMode.scanMode = CELL_VIDEO_OUT_SCAN_MODE_PROGRESSIVE;
    video_state.displayMode.refreshRates = CELL_VIDEO_OUT_REFRESH_RATE_59_94HZ;
    video_state.displayMode.conversion = CELL_VIDEO_OUT_DISPLAY_CONVERSION_NONE;
    video_state.displayMode.aspect = CELL_VIDEO_OUT_ASPECT_4_3;
    
    Then add to the following (new line is in bold):

    Code:
    video_config.resolutionId = video_state.displayMode.resolutionId;
    video_config.format = CELL_VIDEO_OUT_BUFFER_COLOR_FORMAT_X8R8G8B8;
    video_config.aspect = video_state.displayMode.aspect;
    video_config.pitch = resolution.width * 4;
    Here's the thing - the reason (according to my assumption) that PAL games currently have such bad video and audio timing is because we need to set the PS3 videomode accordingly - namely, at a PAL resolution @ 50Hz or some other opportune refresh rate.

    Therefore, we need a way (before we launch the SNES9x emulator) to determine whether the ROM we have just loaded is a PAL or an NTSC ROM. Based on that, init_display() will then be called, except the video_state will be configured differently depending on whether a PAL ROM is about to be loaded or an NTSC ROM.

    I might have to search in the Snes9x documentation for a way to get at the region/videomode of a ROM before actually starting Snes9x.

    Also, the init_display function will probably have to be modified.

    Now, if we wanted to be pedantic - you'll notice that it's possible to even set the scan mode:

    Code:
    video_state.displayMode.scanMode = CELL_VIDEO_OUT_SCAN_MODE_PROGRESSIVE;
    The other value you can use is CELL_VIDEO_OUT_SCAN_MODE_INTERLACE; certain games (such as Seiken Densetsu 2/Secret of Mana and Seiken Densetsu 3) use high-res, 512x448 / 512x478 interlaced modes for some of the menu and text screens. If we wanted to, we could trigger a call to init_display() (once it has been modified to allow us to easily switch resolutions on the fly) inside:

    S9xDeinitUpdate (SNES9x callback)

    S9xDeinitUpdate is called once a complete SNES screen has been rendered into the GFX.Screen memory buffer, as per the 'porting.html' document.

    This is for resolutions: 256 x 224 (PAL), 256 x 239 (PAL) , 512 x 224 (NTSC), 512 x 239 (PAL)

    S9xContinueUpdate (SNES9x callback)

    This is the equivalent of S9xDeinitUpdate, except it's only meant for interlaced high-res resolutions (such as 512 x 448 (NTSC) and 512 x 478 (PAL).

    Basically, this callback is triggered once a screen at one of those two resolutions has been rendered into the GFX.Screen memory buffer.

    We could use this callback to call init_graphics and trigger a videomode with scanmode CELL_VIDEO_OUT_SCAN_MODE_INTERLACE - but I dunno, perhaps it's not worth the hassle.

    Colors

    BTW, another thing I changed that eisz might not be aware of - in his code, he did the following:

    Code:
    S9xSetRenderPixelFormat(RGB565);
    This tells SNES9x to use the pixel format RGB565. So far, so good. But then when it comes time to set up the PS3 display, he chooses the following pixel format:

    setRenderTarget

    Code:
    CellGcmSurface sf;
    sf.colorFormat 	= CELL_GCM_SURFACE_A8R8G8B8;
    This did not make sense to me. So, instead, I chose the same color format as the one he selected for SNES9x:

    Code:
    //set to same value as S9xPixelFormat
    sf.colorFormat = CELL_GCM_SURFACE_R5G6B5;
    This made the colors look a lot better. Might even have had other beneficial effects, I dunno.

    Anyway, I think this is the key to getting the display just right - we need to do the same explicit resolution initialization for PAL games, but we also have to keep in mind that if someone with an old NTSC television set (that does not support 50Hz PAL) tries this, that it wouldn't do anything funny - I'm not even sure of what would happen. Perhaps still read which resolutions and refresh rates are permissible - there are function calls in the SDK for that.
    Attached Files Attached Files
    Last edited by squarepusher2; 09-26-2010 at 05:12 AM Reason: Automerged Doublepost

 

Sponsored Links

Page 19 of 68 FirstFirst ... 9171819202129 ... LastLast
Affiliates - Contact Us - PS3 Downloads - Privacy Statement - Site Rules - Top - © 2014 PlayStation 3 News