forums.ps2dev.org

Just in case you haven't realised this already, you don't need to dump your firmware to make homebrew games or applications.

I would avoid doing anything firmware related until you're more knowledgeable about the PSP, and programming in general.

Glad it works now - yes, the fact that order is important in linking really is a pain sometimes.

I wonder if this feature actually has any practical use...

You're welcome.

Pete

You've typed "syn.ps2dev.org" there - is that a typo?

The line I gave should work - it worked for me, I tested it before posting.

Pete

Open up a cygwin window and type:
svn co svn://svn.ps2dev.org/psp/trunk/lua

Sorry, I didn't realise that.

I think it's available on the PS2Dev Subversion server:
http://svn.ps2dev.org/listing.php?repna ... rev=0&sc=0

Pete

I know it's not what you want to hear, but you really really really should learn C on a PC compiler with a real time debugger before trying on the PSP.

You will save yourself many frustrating late nights. It cannot be understated.

Check out http://www.lua.org and download the source, and the docs.

Hope this helps,
Pete

Is it something that needs fixed? I'm quite happy for functions to maintain an internal buffer, as long as they don't leak each time they're called.

I don't think all the 32MB is available for allocation. Depending on your memory usage and global/static data size you'll probably find it's closer to 20-25MB.

Which kinda sucks...

The difference between NULL in C and C++ is quite interesting (if you're dorky like me...) In C, NULL is defined as (void*) 0, in standard-conforming compilers, and conversions from void* to X* are implicit (which can lead to all kinds of problems) so you can do X* p = malloc(sizeof(X)) etc. In C++,...

In C++, NULL is zero (because Stroustrup says so).

I think "if (!ptr)" is a bit nicer to type, and possibly has clearer semantics ("is this a valid pointer?") than explicitly comparing to NULL.

If there was an automatic compaction scheme you'd need the user to get called back about it so they can update their pointers. i.e.: vcompact(MyCallBack, myUserData); ... void MyCallBack(const void* oldPointer, void* newPointer, void* userData) { // traverse ...

Cool, I'm glad it works.

Here's the code I used when I tried streaming an mp3 from the memory stick. It works, but it's pretty slow (maybe about 25% of the CPU time? I never benchmarked). Read the code from the bottom of the file to the top (high level to low level) and it'll be easier to follow. #include <stdio.h> #include...

Please someone correct me if I'm wrong, but I really don't think it's possible to use pixel shaders on the PSP. It just doesn't support them. Just like they're not supported on all graphics cards that support OpenGL. e.g. TNT, Voodoo, etc. You should probably check out the GU samples that come with ...

AFAIK the PSP doesn't have pixel shaders, just fixed-function render states which you can twiddle with.

I mix C and C++ in my Quake port, and that's with a pretty recent SDK - about a week old.

I really think the problem is with your makefile.

Pete

What errors do you get? (copy and paste please)

A few of the PSPSDK functions seem to take or return ints when there are appropriate enums or other types. I guess it doesn't matter too much. Anyway, the thing that confused me when trying semaphores for the first time was that waiting for one implicitly subtracted 1 from its value, so if you wait ...

Why are you posting official Sony SDK material here?! Can a moderator please delete this?

Here's how I've done it, and it seems to work correctly: // Create the mutex. SceUID mutex = sceKernelCreateSema("myMutexName", 0, 1, 1, 0); // Wait until the mutex is available. (Implicitly decrements its value) sceKernelWaitSema(mutex, 1, 0); // Do your protected stuff here... // Unlock ...

There are also PSP-specific (nonportable) threads and semaphores in "pspthreadman.h".

I really wouldn't recommend learning C or C++ programming on a PSP - try writing some small command line programs first.

Yep I must have done something very silly - I'll go back and recheck.

It's no big deal now, since clock() works fine in Quake, but I assume that clock() probably just calls sceRtcGetCurrentTick() internally.

I must be doing something wrong there - I really didn't expect a high res timer query to take so long!

chp wrote:sceRtcGetCurrentTick()

I've no idea why, but when I tried using this function (before giving up and switching to clock()), it was taking a long time to finish (around .2 seconds per call!)

Perhaps I was doing something silly, but I'm pretty sure not.

I don't think quads are supported yet ( http://www.goop.org/psp/gl/#immediate ).

I think I fixed the problem - it wasn't related to my use of sceGuTexFlush. Quake was moving the image memory around, causing me to be using memory which it had stomped over... Oops. Now I make my own copy of the textures, which seems to have solved the problem. I was using cached addresses (initial...

Hello, I've been trying without much success for the last few days to use the limited VRAM space available as a LRU (least recently used) cache for textures stored in system memory. In case anyone is wondering why, it's because I'm continuing my port of Quake to the PSP by replacing Quake's software...