[GC] Star Wars Rogue Squadron II: Rogue Leader

[Fiora]

EFB2Texture pretends to copy the EFB to RAM, and then watches texture addresses to see if the EFB gets passed back as a texture. It works if the game only uses the EFB as a texture and doesn't modify it. EFB2RAM actually copies it to RAM, because the game actually is going to do things with it from the CPU (generally).

Overclocking might help in co-op, where the game does actually lag on the real Wii, but I'd think for a game this slow you'd be better off underclocking.

[slarlac249]

(01-07-2015, 03:22 AM)Fiora Wrote: EFB2Texture pretends to copy the EFB to RAM, and then watches texture addresses to see if the EFB gets passed back as a texture. It works if the game only uses the EFB as a texture and doesn't modify it. EFB2RAM actually copies it to RAM, because the game actually is going to do things with it from the CPU (generally).

Overclocking might help in co-op, where the game does actually lag on the real Wii, but I'd think for a game this slow you'd be better off underclocking.

can you explain why underclocking would help? i don't understand

forget what i said about heat haze in cockpit, safe instead of fast fixes that but drops fps some more.

[magumagu]

(01-06-2015, 11:32 PM)slarlac249 Wrote: might sound like a dumb question but is efb2ram called that because it puts the textures into your systems ram? is that why it causes so much slowdown?

Yes, exactly.  The GameCube/Wii have a unified memory architecture; all textures are stored in system memory (with some minor exceptions).  So to emulate the system correctly in the general case, we have to make sure that the emulated CPU can access the results when the emulated graphics chip writes a texture to memory.

Most games don't actually access textures this way, but some do... the most common usage is for screenshots (e.g. the Wind Waker Picto Box).  Also, our efb-to-texture implementation doesn't handle all the cases it should; efb-to-ram is sometimes used as a workaround.

[slarlac249]

(01-07-2015, 03:30 AM)magumagu Wrote:

(01-06-2015, 11:32 PM)slarlac249 Wrote: might sound like a dumb question but is efb2ram called that because it puts the textures into your systems ram? is that why it causes so much slowdown?

Yes, exactly.  The GameCube/Wii have a unified memory architecture; all textures are stored in system memory (with some minor exceptions).  So to emulate the system correctly in the general case, we have to make sure that the emulated CPU can access the results when the emulated graphics chip writes a texture to memory.

Most games don't actually access textures this way, but some do... the most common usage is for screenshots (e.g. the Wind Waker Picto Box).  Also, our efb-to-texture implementation doesn't handle all the cases it should; efb-to-ram is sometimes used as a workaround.

ah i see.

[Fiora]

(01-07-2015, 03:26 AM)slarlac249 Wrote:

(01-07-2015, 03:22 AM)Fiora Wrote: EFB2Texture pretends to copy the EFB to RAM, and then watches texture addresses to see if the EFB gets passed back as a texture. It works if the game only uses the EFB as a texture and doesn't modify it. EFB2RAM actually copies it to RAM, because the game actually is going to do things with it from the CPU (generally).

Overclocking might help in co-op, where the game does actually lag on the real Wii, but I'd think for a game this slow you'd be better off underclocking.

can you explain why underclocking would help? i don't understand

Underclocking means the emulated CPU is slower and thus easier to emulate.

[Link_to_the_past]

I have found that  SafeTextureCacheColorSamples = 4096 is sufficient for a proper targeting computer along with efb to ram. Might be a bit faster than using SafeTextureCacheColorSamples = 0 to not have any issues for anyone interested.

[slarlac249]

(01-07-2015, 04:04 AM)Link_to_the_past Wrote: I have found that  SafeTextureCacheColorSamples = 4096 is sufficient for a proper targeting computer along with efb to ram. Might be a bit faster than using SafeTextureCacheColorSamples = 0 to not have any issues for anyone interested.

is that an ini setting?

[Link_to_the_past]

(01-07-2015, 04:29 AM)slarlac249 Wrote:

(01-07-2015, 04:04 AM)Link_to_the_past Wrote: I have found that  SafeTextureCacheColorSamples = 4096 is sufficient for a proper targeting computer along with efb to ram. Might be a bit faster than using SafeTextureCacheColorSamples = 0 to not have any issues for anyone interested.

is that an ini setting?

Yes and it is a bit faster than using the far left setting in the gui, while more compatible than setting it in the middle.

[slarlac249]

it actually made my framerate worse, now dips to 18-26fps, is it meant to put the slider to safe and lock it there?

[Echoes]

This is slightly off topic, but I made some textures for the HUD and space to commemorate finally being able to play this great game, and as a thank you to everyone working and testing around. I haven't made a thread for this yet because I'm waiting for this to be included in the official builds in the downloads section, and this pack may just cause some odd glitch or bug that I haven't noticed yet.

Comparison pictures: Before and After.

Download.

Note that Texture Cache is set all the way to Fast. Should I change this?

Also, the Space textures are basically optional, since I got them from editing Image searches and such. The Hud is supposed to be the main draw.