forums.ps2dev.org

With the right libraries, you can do all this today on a PC.
The PS3 is not some kind of magic machine.

Pointless, or at least off-topic, thread.

You're also missing that you need to render 60 or 30 times per second, not 1.

chp wrote:Another surprise (for me atleast) is when using 16-bit or 32-bit textures, VRAM->VRAM blits is FASTER when using linear textures, than when using swizzled textures.

This changes when you are doing a rotated blit, I assume? It seems to...

Oops, too tired, sorry :P

Been a while since I looked at that sample, is it using a swizzled and mipmapped texture? If not, the texture cache is most likely destroying the performance.

Not exactly hard to crack though :)

PSP has palettized textures and they are very fast, faster than 16-bit direct color formats because of the lower bandwidth and texture cache requirements. Just stick with your original bitmap data, maybe swizzle it.

Another difference is that retail games etc are not prerelocated, while PSPSDK generates elfs that are prerelocated to 0x08900000.

mrbrown wrote:If I had a way to detect if the EBOOT loader was running, then I could fixup SDL to skip over the kernel calls and call _init() manually to initialize any other static classes.

Wouldn't it be better to politely ask Fanjita if he could add a fix to the loader? :)

Your light attenuation values are kind of weird. Try changing them..

Nice one mrbrown.

Oh and mICrO, your x86 code may have been optimal on the 486, but since the Pentium other methods are much faster than rep movsd, especially for block sizes over a few hundred bytes.

The docs may be wrong :)

The sceGuDrawArray has some overhead, it might be faster if you fill larger arrays of coordinates and draw multiple sprites per call.

I'm wondering about the weird type of your "buffer" variable. Try to cast it into a char* perhaps?

WinXP does not cache USB "disks" by default, so if you're having problems you're probably still on 2K :)

I'd recommend an upgrade and then turning off all useless eyecandy. Stripped XP is better than 2K in every way.

Yep, looks like a hardware bug, and similar to what can happen in burnout.

Weird, I'll have to try this later.
Swizzling shouldn't affect mipmap selection, but WILL give you a big speedup.

And that's why there's a flag you can pass D3D to not change the FP control word. The reason D3D changes the control word by default is because some very "clever" (*cough*) people change it to raise exceptions on bad floating point values. Some graphics drivers are badly written and may ca...

N64? PSX? :)

Your problem is that the CLUT memory on-chip is only 512 (or possibly 1024?) bytes as far as I can tell. Should be at least 1024, otherwise you wouldn't be able to have a 256x32bpp colour table. So does that mean the CLUT is uploaded when you execute command 196, rather than simply setting a pointe...

I can confirm that the specular is "LOCAL_VIEWER". I ran the lights sample on the real psp and the specular reflections in the ground really looks like local_viewer. I then implemented lighting in my experimental PSP emulator, using the local viewer approach, and arrived at an essentially ...

Your problem is that the CLUT memory on-chip is only 512 (or possibly 1024?) bytes as far as I can tell.
You can't use a 65536-color palette.

Do you really gain much by putting display lists/command buffers in VRAM? Mine are in main memory and i'm getting decent perf..

Besides that, creating a VFPU-based thread incurs considerable overhead during a context switch. If you force the VFPU everywhere, then all threads would be required to maintain a VFPU context. Almost correct, unless I'm misunderstanding you and you're 100% right but not clear enough :) Most platfo...

Well, you can't specify a ninth mipmap level so you simply can't go down to 1x1 on 512x512 textures. Unless you can abuse the mipmap size parameters and have the last two being 4x4 and 1x1 .. dunno if that'd be much use though.

The max size is actually 512x512, despite the 8 mipmap levels. The mipmaps don't go all the way down to 1x1 in that case, it stops at 2x2 :)

Most parts of the menu app is encrypted. We cannot encrypt replacements. That's it. The only way would be some buffer overflow in reading one of the non encrypted files.

0xff is full value, as far as I can tell.

1.52 does not do homebrew. Although you can easily upgrade it to 2.00 and then use the downgrader to get to 1.50. Watch out for 2.01 though - you don't want that.

I don't think it has aniso, you'll have to make do with trilinear (which is better than what the ps2 has :) )