As many know and have been told we a missing T1 and Frame Buffer support, but many don't know what they are. I'm going to give an example of each, tell you what they are and the difficulty in implementing them.

T1 also know as Texel1 is used as a part of multi-texturing. See the attached pic for an example. Currently we only show T0 as the PSP can't combine the two in hardware. This can be used to create multiple effects like animated textures(OoT's flames) and texture variations(dust, mud, etc...) based on how they get combined. There has been talk of a few possible method to get around the hardware limitation, but it will be a difficult task.

The frame buffer is where the actual rendering(drawing) happens. It's also known as the off-screen drawing surface (the screen is the on-screen drawing surface). The PSP use three total drawing surfaces(2 off-screen known as double buffering, and 1 on-screen). The N64 also had three drawing surfaces, but sometimes the developers would either copy 1 surface to the other and use the second as a texture on the first(we'll call this method 1) or they could render something else entirely to the second buffer and use that as a texture(and this method 2). This creates a sort of PIP (Picture In Picture)effect. This can be seen in Luigi's Raceway for the video screen before the tunnel on MarioKart64(using method 1) and on OoT where link is suppose to show up in the pause menu(that uses method 2). There are methods to support this in software but this will slow us way down(As it takes and extra rendering pass to create and use these on the fly created textures).

I hope this clears things up.

Kreationz

Good luck Kreationz. Will the T1 support fix the Power Stars in Super Mario 64?

That's is either T1 (to make it Shiny) or FrameBuffer (For reflection) I can't remember which. The examples I gave above aren't the only uses of each.

not to nitpick (okay I am) but shouldn't the combined version have the blues and purples reversed?

Also, great descriptions. I honestly can't even think of a way to reduce the frame buffer issue. Is Daedalus even using the second buffer at all currently?

If you manage to fix this, get the ME move done etc, will games still full speed on daedalus, or will they run "50% and up"?
Would love to see both things fixed.

@Narrus - It uses it when in Double Display mode.

@Larsy - It all depends on implementation and how much it's used and how much the speed-ups give us.

Is there no way to approximate/emulate this with psp's hardware ?

There is. It'd just be moderately slow.

Care to explain how? xD
His question was if there was any way to do it with hardware, so the correct answer is no, no way since the PSP hardware can't.

Only way that can be done is with software, but will be slow as :-S as explained.

Oh, sorry, misunderstood the question xD

oh so that's why some things don't look quite right

I guess we'll have to go on without this feature, for now. Daedalusx64 is more geared for practicality/playability and not accuracy, so I don't think that this severe performance loss is acceptable. That's my impression as a user anyway.

in that case, T1 because it shines with a bright white sparkle as it rotates.

metal mario in Super Smash Bros on the other hand, reflects close-proximity textures / lighting, although that has been commonly diagnosed as T1 throughout the past year or so.

i think the cars in Lamborghini are supposed to reflect the sun's position too.

Sometimes a game uses a combination of both to make the final texture output (Frame buffer for Reflection place in T1 with another Texture in T0. Then you can have some like a car with custom paint (T0) that also shows some environmental reflections (Frame Buffer in T1). Many current graphical glitches would be fixed by some sort of T1 and Frame buffer implementation. T1 will have to be 100% Software emulated. We'll like have to combine T0 & T1 in software then store it as a 3rd Texture (which will waste some VRAM, but with 16-bit mode and eventually texture compression we should have the room even on the phat). The PSP has two frame buffers as it is. One is a Display Buffer (what you see on screen) and the other is a normal frame buffer(the drawing the PSP is doing in the background). We can create a 3rd buffer to do some things in hardware, but it's going to be tricky emulating all the frame buffer effects. Not even the best N64 emus/video plug-ins on the PC get it all 100% and full emulation there is a heavy resource hog.

Update Edit: It seems there may be a way to use the GU(AKA Hardware) at least partially to approximate multi-texturing (AKA implementing T1). We are looking at this with the new info we have.

So I have been listening, but is it planned (or can it be implemented)soon? the torches look weird on zelda