forums.ps2dev.org

You're doubling something up in both your main and decrypt files. Either declare them static or kill one of them.

You might want to brush up on your basic C skills...
You're after a character array.
Your formatting for the printf is correct. Note that your character array can also go in place of the formatting string.

As far as I know, in most devices the headphone/speaker connection is mechanical - if something is inserted into the headphone port, the speakers are physically disconnected. I've seen nothing to indicate that the PSP works otherwise.

Could you use psplink or something to check what the error is? I'm guessing bus error, but better not to waste time on the wrong problem...

Anyway, how is tmpObj declared?

There's no definition of gumCrossProduct in pspgum_vfpu.c, so no, it's not accelerated. The time to load your figures onto the VFPU would probably negate any speed advantage, anyway.

1) USB version makes no difference. USB 1.1 is 12Mbps; USB2 is 480Mbps (yeah right...). psplink will work.

2) Your error sounds like memory getting trampled on. Take a careful look around. You're probably overrunning an array or something.

Well... the hardware specifications say the PSP can do a vector * 4x4 matrix multiply in 22 cycles... two 4x4 matrices should then be 88 cycles. Look at the vfpu_gum code in the sdk to see how to do it - you'll need to load both matrices into the vfpu, multiply them, then pull out the one you want. ...

Basically: it would be nice if projects on the pspdev sdk could employ something similar to Sony's game sharing, so that multiplayer games may be played even if not everyone has the game installed. We can't use Sony's game sharing, so a loader in the form of a homebrew app is needed. I'll probably t...

There's no memory management provided for the graphics memory. It's up to you how to handle that. I think somebody wrote a basic dynamic memory allocation thingo for vram, you might want to search for it. sceGuCopyImage just does the transfer faster than if you were to do it on cpu, and also means y...

That last argument, the address of the framebuffer and then some, is where you're dropping the image into. Pass that address to sceGuCopyImage, and don't forget to sceGuTexSync() before you try to draw using it.

What exactly do you mean by "assign"? If you want to place a texture from system ram into vram, use sceGuCopyImage. If you want to set a texture to use from either vram or system ram, use sceGuTexImage.

The reason you write back the cache stuff is so that when the GU tried to read out of system ram, what's in system ram is what you actually wrote there. You want to place your sceKernelDcacheWritebackAll just before where the GU should be reading out the data. Generally, put them before sceGumDrawAr...

There's one thing that comes to mind here, looking at your code - do you realize that the psp uses cooperative multithreading, and are you accounting for it? If yes, you can ignore the rest of what I have to say. The psp won't take control away from your threads - you have to give it up. There are a...

Someone more knowledgeable should probably follow this up, but I don't think you're going to get much of a performance gain by going to 16 bit. Most of the PSP's internal hardware should be 32 bit - it's going to take the same time to process 16 or 32 bits. It makes a difference to the GU for textur...

It would help if you actually explained why it doesn't work, i.e. what happens and what goes wrong. After looking over it quickly, I don't see anything problematic in the code you've given.
-ReK

w.kosma: I don't know what your specific problem is, but pspDebugScreenPrintf is, as its name would suggest, meant for debugging. It's writing directly to what it thinks is the video ram (not the back buffer), and that probably conflicts with whatever the GU is doing. You probably want to find a cle...

erm... why would you want to do that? Most likely, the answer is no because then you'd need a text terminal emulator or something... I'm fairly certain that nobody's even bothered to look into porting it.

-Rek

This is kind of a hack, but if you really can't get it working, do psp-strip test.elf -o EBOOT.PBP The resulting EBOOT goes in the TEST directory (as opposed to TEST%) on the psp... it's doing the same thing as make kxploit, just without the directories. Still weird that it doesn't work properly, th...

Could you elaborate on why you can't install it? I haven't heard of a single installer like that, and there's really no way it could be considered small (depending on your definition of small). By the way, your English is better than many so-called native speakers, you don't need to worry about that...

It looks like it's trying to connect to an X11 display, which isn't going to work under windows. Don't bother with emulators, you're not going to get anywhere. Use a real psp.
-ReK

Get an editor with auto indenting or something - or use indent. For some reason your main function is inside the repeat() function (which should have been obvious from all the }'s down the bottom)... I'm guessing you were seeing errors about unclosed brackets, and just stuck them down the bottom. By...

Somehow, I don't think this is going to work. The psp has no MMU. I can't think of any feasible way to fake one...
-ReK

Yes, relative paths work fine. Everything goes into the directory *without* the %. The directory with the % is just to make the psp think that the data is valid, then it loads from the other directory.
-ReK

I think your math is messed up. 2mb of vram = 0x200000, 512 * 280 * 4 * 3 = 0x1a4000, 0x200000 - 0x1a4000 = 0x5c000 = around 380kb. You're probably out of vram.
-ReK

It's not going to work unless you emulate the x86 architecture. x86 code will not run on MIPS.
-ReK

Tremor was set to low accuracy because it was being used to port noiz2sa to psp - otherwise it was even slower and more unusable. As it is, it's still not that good. One solution will be to move audio decoding to the second cpu, but I don't think any progress has been made on that just yet. For now,...

Heh, I didn't spot that in your code before... ints are 32 bits, not 16. That's why the hardware didn't like your vertices... Also, regarding your issue with the colours - why are you shifting right then left? If you want to clear unneeded bits then just AND them with whatever mask you need, otherwi...

This is all over the forums already, but flickering is usually due to cache issues. Either write to uncached memory (see the wiki for the address to OR your addresses against) or flush the cache before you flip buffers (sceKernelDcacheWriteBackAll). Regarding the what MikeDX said, the sceGu function...

If you mean, "does the hardware optimise them for you," the answer is no. It's a fairly expensive operation. You'll have to do it beforehand if you want that... two libraries to do it are actc and stripe. Process your models beforehand, then only use the psp to draw them.
-ReK

The prices are extortionate, but if you're desperate you can get one from here. Could you tell me if you manage to get your part from somewhere else? I still need my new dpad.
-ReK