forums.ps2dev.org

Swizzling is independent of where the texture is. Reading and writing to VRAM should be slower than to main RAM, but rendering from VRAM should be faster. Other than that, you can do it however you want.

There's no automatic heap compression in any of the memory managers supplied with the pspsdk, so pointers becoming invalid behind your back is not an issue. If you create your own memory manager for vram and implement heap compression, you probably want your vram resource class (which stores the poi...

Sounds like you have a corrupted math.h. You may want to reinstall the whole thing, or paste here the lines in math.h near the error, so we can see where is the problem and maybe suggest a fix.

ok now this is even more weird If I call my drawsprites() function twice, it seems the problem doesnt occur.. is there some kind of write-delay that I need to be aware of??? Possibly, the GE chip can't read stuff from the CPU's cache, so try calling sceKernelDcacheWriteback() (check name in header ...

sceGuStart(GU_DIRECT,list); this takes in an array of ints. What does the array contain? is it all of your commands which will then get executed when sceGuFinish() is called? sceGuOffset(2048 - (SCR_WIDTH/2),2048 - (SCR_HEIGHT/2)); i dont see the point of this? The list will be used as a buffer whe...

Thanhda wrote:i didnt even touch the code, but renamed it to a cpp file

That's what I'm saying, C++ has stricter type requirements than C in many cases, and thus some C code that relies on relaxed type checks will not compile if treated as C++.

C++ has stricter type requirements than C. Check the types you're passing to pspDebugInstallErrorHandler(), I bet you're converting one of them to (void*) and you shouldn't.

71M wrote:Hmm, after further tests, it seems that the alpha component isn't being cleared correctly.

Ahh yes you can't use the texture alpha from a rendertarget unless you do some extra work. If I remember correctly, the alpha channel of a rendertarget contains the stencil buffer.

That's what I have in PSPGL. The 1,2,3,0 order doesn't make much sense to me. I think the PSPGL code is still wrong, but that doesn't look like the fix. The alpha block in DXT3 contains explicit alpha values. DXT5 contains two alpha values and a block of interpolants for the pixels. In the PSP that...

71M wrote:Oh, by the way I don't have a Z buffer, hence only 2 frame buffers are currently reside in VRAM.

The Gu init will set a ZBuffer up for ya, so make sure you explicitly disable Z writes and Z compares. Check the source code code for sceGuDrawBuffer() if you want to see exactly what it does.

JoshDB wrote:copied makefile.cygwin to the parent dir of libpng and renamed it to Makefile

You tried to compile libpng for Windows / Cygwin, not for PSP.

This is interesting... one of the reasons I had trouble with the DXT5 conversion seems to be a GCC compiler bug. Unfortunately it stopped happening on its own. Anyway, I don't think the DXT5 conversion is correct also for DXT3: // copy alpha converted[4] = src[1]; con...

Texture formats 9 and 10 are indeed DXT3 and DXT5. There is another thread that has a pretty good discussion of this titled "DXTn texture format" ( http://forums.ps2dev.org/viewtopic.php?t=3034&start=0&postdays=0&postorder=asc&highlight= ) Bah I hate forum search, it didn'...

As I commented in the DXT thread, I think DXT textures can't be swizzled. When I enable swizzling, I see lots of 4x4 blocks that appear repeated, which should never happen. However, the data inside each block is still correct. If you got your DXT textures working, I'd appreciate some help over in th...

Well, I confirmed format 8 is definitely DXT1. The only thing needed to make it show up properly on the PSP is to swap the color info and pixel info on each block. Each of those is a 32-bit value, so if you load a DDS texture straight to memory, just do something like this: void PostProcessDXT1&...

Hi! I read that PSP supports "compressed textures", and from older posts I gather that they are DXT textures. However, there seems to be little info about this topic, no mention at all in the Gu library and etc. Assuming that DXT formats are an extension of the current 5650, 4444, 8888 etc...

Thanks a lot man, not just for the port (which I play often) but for pointing out the original site... that dude is a genius.

I don't see anything wrong with that code. Alpha testing (you're NOT! doing alphablending) is working here, but I use 4444 textures, so it's not identical to yours.

// Choppped up sizediff = size; int tsize = size*size; ramaddr = &#40;unsigned int&#41;malloc&#40;sizediff&#41;; for &#40;x=0;x<tsize;x++&#41; &#123; You are allocating "size" bytes and then filling "size*size*4" bytes of memory. That's very wrong.

Make sure you set up the DrawBuffer format before calling sceGuDisplayBuffer or whatever the name is... the pixel format for the video mode in the Display call is taken from the (previous) call to sceGuDrawBuffer().

The choice of colors makes some effects look like they are coming out of the little screen. Good stuff.

I believe the lines sendCommandi&#40;157,&#40;&#40;&#40;&#40;unsigned int&#41;gu_draw_buffer.frame_buffer&#41; & 0xff000000&#41; >> 8&#41;||gu_draw_buffer.frame_width&#41;; sendCommandi&#40;159,&#40;&#40;&#40;&#40;unsigned int&#41;g...

I see... But my code fails to agree. :( Some more questions: - I tried to #define ALIGN_16 __attribute__((aligned(16))), and I would get different results if I used the macro (crash exactly as if the macro wasn't there) or the actual __attribute__ (things worked). Is this normal? - I understand VFPU...

As posted in the GetMemory() thread, I keep having random problems if I don't make sure that all my Gu-related data is aligned to 16 bytes: matrices, vertex arrays, display lists... When I dont align them with __attribute__((aligned(16))), rendering tends to fail depending on how many commands have ...

So GetMemory is fine for on-the-fly rendering of quads, debug traces and such (assuming it's not a lot of them)? I was having problems with that in my beginnings, had to insert some dummy commands like repeating some sceGuEnable() before I got my GetMemory-allocated vertex array to show up, when I m...

the .bashrc file should be in your home directory, but won't show up on ls listings normally. If the file is not there, just create one with the PSP vars and see if that works for you. Add some "echo Im .bashrc" command to make sure it is run when you start a shell.

I guess don't use it except for quick & dirty apps. Also you may run into alignment problems, I think GetMemory gives dword-aligned memory but the vertex arrays need to be 16-byte aligned (not 100% sure of this).

Yes you can double buffer fine in 8888. The PSP keeps a "visible" framebuffer, but you can change the address to a different address in VideoRAM after you're done drawing your stuff there. Check the samples to see how they do it.

If you already have the 3D files in a given format, say 3DS, you'll need a piece of code that reads .3DS files and is able to prepare them for PSP rendering. Alternatively, you can load these files in a 3D modelling package and create an "exporter" that converts them into a PSP-ready forma...

The stuff in #include <pspdebug.h> comes in quite handy for debugging purposes.