forums.ps2dev.org

Although they are decompressed into 32-bit in the texture cache and as such are slower than for example 4-bit paletted anyway... though the quality increase over 4-bit for the same space cost could be worth it

I suspect your problem was that main() calls control() and control in turn calls main? :)

The current libgu pretty much assumes you create a single large command buffer, you fill it up, submit it, and synchronously wait for it to complete. No, this is not how it works. Have you seen the function sceGeListUpdateStallAddr? This tells the Gu that it can begin drawing, up to this address. S...

That's an old problem that has been fixed. Don't use the "Beta" psp sdk, just get oopo's toolchain script from http://www.oopo.net/consoledev/ and run it to install the toolchain and pspsdk.

Yeah now that's what I'm talking about. Nice work.

You should arrange the buttontexts physically like the buttons sit on the psp, it's much easier than trying to remember whether square is the left or the top button..

Not even converting to floating point will solve that since you still only have 5 outputs from the rand() :)

In other news to some people here, the standard C rand() returns a number from 0 to 32767, not the full 32 bits. That's another thing to be aware of.

You still don't get it. Read my above post again. It has nothing to do with zero. The problem is that modulo is not generally an exact n->1 mapping with the same n for each input number. In my example with a rand function that gives output 0-5 and use modulo 4, 0 and 4 will map to 0, 1 and 5 will ma...

Krevnik, read cyod's post again. The bias comes DIRECTLY from the modulo. Modulo is not some magic range restricting function. If you have an RNG giving you numbers 0-5 and use a modulo 4, you will get on average twice as many zeros and ones as twos and threes. The same problem scales upwards althou...

Yup, cyad has the right explanation there.

A more correct way is rand() * yourRange / RAND_MAX.

Although for most purposes and small ranges, % yourRange is good enough.

It's funny how noone ever seems to note that rand() % yourmaxvalue is biased toward lower values...

Poke around in crt0 or .. use the main arguments? Why not?

Yeah unaligned accesses are to be avoided :) Strange that your struct method is so much faster. I must be too used to MSVC whose memcpy implementations (yes it has several, from just inserting MOVs to various unrolled loops). Maybe GCC isn't as good at memcpy intrinsic optimization, or something is ...

memcpy() should beat that silly struct method of yours.

To copy stuff insanely quickly inside vram, set up a render target at your destination, your source as texture, and draw a quad.

I haven't heard of any hardware directly supporting a matrix palette the way you imagined PSP did, except possibly the Geforce6800 where you can use fp textures read in the vertex shader as matrix palettes. I meant using indices stored per vertex to address matrix in the array. That functionality w...

I haven't heard of any hardware directly supporting a matrix palette the way you imagined PSP did, except possibly the Geforce6800 where you can use fp textures read in the vertex shader as matrix palettes. Yes you have to split your meshes up, but that's true for everything from PC to Xbox to NDS t...

Probably has more to do with 22khz vs 44khz than bitrate.

Also, this type of app is very boring to write...

Non-cached.
And how much are you writing? It's only 2MB, you know.

You didn't forget to set max mip level?
and make sure that it's the minification filter you set to a mip filter.

Mipmapping with trilinear filtering and everything works fine but you have to generate and supply your own mipmaps. My texture tool can help you with this. http://www.dtek.chalmers.se/~tronic/PSPTexTool.zip.

Easily. It runs the same speed as the main CPU, unless I have misunderstood something.

SaNIK, i think it's more likely that your ratio between far and near is WAY too high. try 0.1 and 500 or something.

is the pointer you use to patch the entries noncachable?

SNES? :)

Yes.
And yes. :)

float width = right-left; float height = bottom-top; float depth = near-far; //depth is reversed on psp m[0*4+0] = 2.0f/width; m[1*4+1] = 2.0f/height; m[2*4+2] = 2.0f/depth; m[3*4+0] = -(left+right)/width; m[3*4...

pyrosama wrote: What I meant was what should I be looking at in the updater.

Disassembly, what else?

Get a MIPS manual, find how to disable floating point exceptions, and disable floating point exceptions. Or find a way to catch floating point exceptions and deal with them.