forums.ps2dev.org

Did you turn off the pagefile in Windows? Don't do that.

That's it, I want one (I guess the Go! Cam is the exact same thing?) :)

But I can't find it in the stores in Zurich... Any idea where to order one cheaply to Switzerland? Or should I just order a Chotto Cam from playasia?

Yeah slightly OT, sorry about that...

Oh, you can absolutely modify swizzled images... It's just a tiny bit trickier :)

Did you flush the data to memory, to make sure it's just not sitting in the CPU cache?

Wow, noxa, you seem to be a bit more ambitious than me (even though I'm the only one of us who can run games...) ;) Feel free to rip and steal as much as you want from Potemkin, I'll even grant you a personal license so you don't have to follow the GPL if you don't want to for some reason (I see you...

Yep, I released it yesterday, have fun :) It's a user mode only MIPS emulator with a bare bones implementation of the PSP OS. No hardware registers are emulated, but display lists are parsed and executed. The name comes from so-called Potemkin villages http://en.wikipedia.org/wiki/Potemkin_village ,...

At the presentation at BP2005, if I remember correctly, the presenter mentioned that there is a hardware bug that causes scratchpad RAM to be way slower than was intended. If it is separate from the CPU and actually is on the bus however as Tyranid says, I would call that bad design, not a bug :)

Space Invaders!

http://www.emutalk.net/programming/3817 ... aders.html

If you don't need alpha you might as well use DXT1, since DXT5 ~= DXT1 + alpha.

Although it's likely that T8 will still be faster since the DXT format occupy a lot of texture cache (it's decompressed into the cache) and thus cause more cache thrashing.

Avoid double precision numbers, perhaps?

phytoporg, are you invalidating the instruction cache before trying to execute newly generated code? Doing this is essential.

Two things: 1/10th of a second is a way too large timestep for smooth animation, and the PSP screen really is that slow when one of the colors involved have components (R G B, one or more) close to zero. Why, I don't know, but try brightening up your images a bit.

... games with full debug symbols sitting on the UMD ...

If you scale down a 256x256 texture to 64x64 WITHOUT using mipmaps and swizziling, you are completely destroying all the work the texture cache is doing for you. Think low-level. It likes to cache blocks. And if you're texturing from RAM without the aid of the texture cache, it's just going to be PA...

Well you haven't given much details to go on :)

But the essence is, anything you want the graphics processor to see, you NEED to make sure that it's in main memory and not just sitting in the CPU cache.

As many others around here you're getting bitten by the cache. Search around, I'm too lazy to explain it all again :)

Hey, you're using memalign backwards! The blockalign parameter (16) should be first.

That should explain most of your problems :)

Of course, there could be more problems, I didn't spend a lot of time reading your code.

If changing the optimization setting "fixed" it, you have a bug somewhere...

Exactly the same way, in Cygwin :)

If you're writing games, you don't need doubles. If you think you do, you're wrong :) That's why there is no hardware support.

Kojima wrote:Here's a pspgl font engine I use, the texture class just creates a gl texture, which i'm sure you can manage.

You could pull glBegin/glEnd out of that loop and instantly maybe double your speed...

The compiler isn't THAT buggy. If you're having bugs that disappear when turning off optimizing in such a simple program, it's far more likely that you have some kind of broken edge case or alignment bug in your code, than you actually running into a real compiler bug. I recommend trying to get the ...

Do not ever draw your sprites or triangles one by one, always submit lists of triangles or sprites. You will get huge speed improvements compared to sending them off one by one.

Well, if you're going to do manual clipping, you'll want to do it in 3D space.

But I think that you should just subdivide all your triangles into smaller ones, since the PSP can handle quite a lot of them without problems.

Kojima wrote:Will it require any other software besides the psp to run it?

You still need GTA, just like on every firmware above 2.0.

Also, newer GTA:s are patched, so find a used one...

Actually, you get something very close to an FFT inherently while decoding MP3, which is why WinAMP has always had that visualisation, even back when doing just the decoding took 90% CPU. No time for a separate FFT just for viz...

Of course, not every MP3 playback library will expose this.

If you prefer to do your debugging on PC, you can just enable floating point exceptions on the PC instead (they're disabled by default) and do your debugging there...

My guess would be that it's the huge converted 68k asm->c file that's using most of the CPU power. Getting rid of OpenGL wouldn't be hard at all, gu can do textures too you know, but probably won't give you much in the way of additional speed, unless you're building new textures every frame unnecess...

No modern MIPS CPU:s that I know of have this limitation. They all added forwarding, fixing this problem, in something like 1992. What documentation are you reading?

Maybe you're accidentally declaring some brutally huge variables on the stack in the function tree that is calling this function? Maybe you passed in a too small value for stack size when you created the thread that's running this?