forums.ps2dev.org

For the cache problem, see the first paragraph here: http://wiki.ps2dev.org/psp:ge_faq

sceGuGetMemory() should work fine. I would address this issue instead of allocating vertex memory and clearing the cache.

The GU expects a relative pointer, not an absolute pointer. You can get the relative pointer using vrelptr(). ie. void *fbp = (void *)valloc(FRAMEBUFFER_SIZE); sceGuDispBuffer(SCREEN_WIDTH, SCREEN_HEIGHT, vrelptr(fbp), PSP_LINE_SIZE);

Everything that is kernel level can be handled in an external kernel level PRX.

You can then load this kernel PRX from your regular user-mode PRX and have access to the function 'wrappers'.

I think this method still works, there were a few bits of sample code about too...

Your code is littered with calls to kernel level functions. All the USB code you have is kernel level. Think I spotted a few in Kernel.cpp too. As a general rule, any functions in a *_kernel.h or *_driver.h file are kernel level. I'll take a small look at it later after work if I get 10 minutes. [ED...

Tables.

Check you're not overflowing the display list.

Check the alignment of everything you're passing to the GU (ensure you're vertex structs are 16 byte aligned by using __attribute__((aligned(16))))

There's libpspvram on the svn.

Confirmed working, thanks.

Something's broke: Making clean in base make[2]: Nothing to be done for `clean'. Making clean in audio test -z "libpspaudio.a libpspaudio_driver.a libpspaudiolib.a libpspaudiocodec.a" || rm -f libpspaudio.a libpspaudio_driver.a libpspaudiolib.a libpspaudiocodec.a rm -f *.o Making clean in ...

What's the makefile look like?

Specifically the -G* flag.

You need to include the pthread header (also assuming you have the PSP pthread port installed too).

It's in the SDK samples...

Use sceUtilityLoadModule() from psputility_modules.h to load the modules you need in user mode.

Use 0x1000 in your PSP_MODULE_INFO instead of 0x1006 or 0x1007.

Run the code that comes in the sample under the 3.71 M33 kernel or later.

If that still doesn't work then there's something you're not telling us.

We need the rest of the code you use to draw.

My original statement still stands.

You're either using un-aligned memory which should be aligned, or you're trashing your display list somehow.

Show some code.

jojojoris is correct, anything which uses libtool fails to build since we updated the gcc version.

You could look at pgeFont, which uses TrueType fonts and is fast http://www.psp-programming.com/forums/i ... 458.0.html

intraFont is base on the code of pgeFont.

I'm unsure why you're getting such a slowdown with intraFont, unless you're doing something fundamentally wrong.

I don't know what changed, but freetype fails for me too and should fail for anyone who tries to install it.

Read the readme-ubuntu.txt file that comes with the toolchain.

Something like this may help: sceGumMatrixMode(GU_MODEL); sceGumLoadMatrix(model->initialTransform); sceGumPushMatrix(); sceGumTranslate(model->position); // draw mesh sceGumDrawArray( GU_TRIANGLES,     model->mesh->vtype | GU_T...

The script doesn't install libgmp and libmpfr. So, no. Also, installing them into /usr/local is generally a better idea. got it. gmp needs to be compiled with "ABI=32", else it will not match mpfr et al. Ahh yes, on Leopard that is true. I forgot that step. If you don't, it compiles it as...

When I installed libgmp and libmpfr on Leopard I had to run configure passing the path to install to, instead of the default /opt/local.
I think that was it.

It's in Sakya's lightMP3 source code IIRC.

Archaemic wrote:Because pspsh won´t compile on a Mac due to it using some readline methods that seem to only exist on Linux or something (I forget)

Mac's come with there own version of readline. What you need to do is install readline from http://tiswww.case.edu/php/chet/readline/rltop.html and it will work fine.

I think those functions are from PSPPet's original adhoc sample code, which is almost 3 years old. You would be better to update your SDK, I've added lots of adhoc goodies over the past months. The code from PSPPet's sample uses PDP (similar to UDP) and it is possible to send in both directions. If ...

I re-committed the patch for libcglue and performed a full install of the toolchain from scratch to test (revision 2446).

Worked fine for me.

That depends on what protocol you're using.

Are you using PDP, PTP or GameMode?

I've reverted back libcglue.c to how it was before the recent patch.

Should work fine now.