forums.ps2dev.org

Well, the big problem is that intraFont cannot detect when a glyph that is about to be overwritten has already been rendered by the GU, so you'd have to insert a preventive GU sync at that place, even though it might not be needed most of the time but still dragging execution speed of the applicati...

But I'm missing some important info here: does sceGuTexImage actually copy the texture in a "save" place (GU texture cache) or just merely remember the adress of the texture? (in which case my caching-scheme is obviously flawed) sceGuTexImage() just takes the pointer you give it and uses ...

sceGuTexSync() synchronizes the sceGuCopyImage() since it runs in parallel with any GE operation that you do. You call it before you use the copied data on the GE, so that you could wait for a memory buffer in GE memory to become available for re-use (if you blit from one and draw into another).

Very nice! Excellent work, guys!

Lukasz wrote:No and you wont be the first to develop on a pink pstwo, both chip and emoon do it.

You're asking for it. :P

Are you loading anything into the projection matrix? Without initializing that one, I think anything can happen.

Nope, but you have the linkorder for pspgum and pspgu wrong. Look at the samples for the correct order.

If you use sceGum*()-functions for matrices, you must also switch to sceGumDraw*() instead of sceGuDraw*(), or call sceGumUpdateMatrix() before you call sceGuDraw*(), otherwise the library won't know when to flush the matrices to the hardware.

Parameter 2 is the texture width Parameter 4 is the texture buffer width. There's a big difference between the two... The second parameter is required to be a power of 2, and describes how to address inside the texture. Parameter 4 describes how the texture is layed out in memory, and is required to...

Good to see that you fixed it! And I don't get pissed off as long as it's proper development stuff which this was, so no worries there. :)

swizzle_fast() should be ok, considering that I wrote that code back in the day.. :) But you don't need to swizzle textures if you don't want to, but performance will suffer if you don't (and preferably you should use sceGuCopyImage() to copy the texture to VRAM before you use it, but that's only if...

Do you flush the cpu caches after swizzling the textures? Otherwise the last texture might still be in the data cache since GU operates on uncached memory when it's writing to the display list.

No, memory grabbed with sceGuGetMemory() is already uncached.

You should always use the SDK from subversion, the old releases are really ancient. and I hadn't submitted the fix, must have missed that when this issue was brought up the last time.

Hm, thought I submitted a fix for this a long time ago... Fixed in revision 2310.

If you're just writing to the vertexbuffer every time you should do your memory accesses uncached, which should give you much better performance than flushing the cache. You do this by ORing the pointer with 0x40000000. That makes sure that writes are pushed to memory directly and won't linger in th...

Don't forget to install the -dev packages for the corresponding dependencies since it will need to build code depending on them.

Also, a printf(char* buf, ...)-style function is a varargs-function, which will store the value before '...' on the stack, because it will need to get the address to 'buf' before it starts processing the format-string. I assume it was a function similar to this that you were using?

Either order your libraries properly (gcc ld will only find symbols imported from libs earlier in the linking process, so -la -lb isn't the same as -lb -la), or you can group all your libs like this: gcc -o executable.elf -Wl,--start-group -lone -ltwo -lthree -Wl,--end-group That will tell the linke...

The lowlevel function returns a negative representation of what should be put in the errno variable when it fails (for example -EBADF). If you want to properly shape this up, you should also store that value in errno (converted into a positive value first of course) before returning -1.

And if you don't want to spend all day just to see wether it works or not, the vista-toolchains I gave to Lukasz (so they are on the tutorial hp) are built with candidate and should give you a quick path to testing this.

The question is why it is not looking up the directories relative to the gcc executable. I have used the cygwin-build without issues with no cygwin-installation (just a few dlls in the correct location), but from what I can see in procmon it does not even try to look at the relative paths... As a te...

I started looking at updating some of the ps2sdk and increasing general code quality. I started with updating the newlib-patch from 1.10.0 to 1.15.0 (still testing it, wait a few days) and also updating the custom ps2 code in there... While doing that I noticed that the crt0.s in there really, reall...

To get it building under Vista (x86, haven't tested x64), you need to do a few things: First, you need to use candidate instead of current for reasons that come later. If you have installed with current, uninstall and install again with candidate, and follow Lukasz's instructions as normal. Then, do...

Do note that because of the way the PS2 works you need to swizzle the data before compressing it (since you'll be rendering 8-bit into 32-bit but then read the resulting data as 8-bit).

Decoding DXT is a bit too much for the GS. It can do it, but you will need to derive it yourself (it's a lot of passes since there is no hardware functionality), and in the end the cost of decoding is not worth it. There are alternatives though: * Use 4-bit CLUT whenever you can, then you get the co...

But that pointer is relative to VRAM start, and it's not what he wanted. sceGeEdramGetAddr() will return the address to the video memory. sceDisplaySetFrameBuf() will set where the LCD should fetch its data from. Look up their functionality in the SDK.

First, you do no initialization of the GU system at all, so calling sceGuSwapBuffers() will have undefined behaviour. Look at the PSPSDK samples how to start the GU library. If you don't want to use that library, use the proper methods in pspdisplay to flip buffers instead. Second, you do no yieldin...

I know that sprintf() failed as well when I attempted to use it 2 years ago, I would guess that it's broken in the rom. Including your own version would be the easy way out, debugging the broken function is the hard way.

1) Since non-pow2 textures is done by abusing the system a little bit (by setting them up as a bigger texture than they really are), you cannot use wrapping with these textures, you would have to split them at UV borders to safely wrap them around. 2) Are you sure you're not offsetting incorrectly i...