forums.ps2dev.org

I have realized that some functions, when used from .prx modules, get too much RAM (sprintf function, printf function). What do you mean by "get too much RAM"? Another problem is that, when removing the PSP_HEAP_SIZE_KB(-5*1024); (which reserves 5MB of the memory for loading PRXs) from th...

Memory leaks do not cause program crashes, unless your program comes to the point where it trys to allocate more memory which then fails and your program not handling that case properly. If you are really concerned about memory leaks, a debug memory manager will help you detect those. One can be fou...

pspsdk/samples/gu/clut/

A library that provides a list of GUI elements (sometimes called 'widgets'), like buttons, checkboxes, textboxes, menus, etc.

No best practice, but here is a good reading on how to achieve bump mapping or similar per-pixel-effects via paletted texture mapping:
http://vcg.isti.cnr.it/activities/geome ... pping.html

Basically every available graphics engine (OSL, triEngine, JGE, ...) and even a lot of graphics sample codes have a swizzling function included. Doing a search on the forum would have helped too.

Hi there, is there a way of having bump mapping on an object rendered with a texture using GU ? I've seen that on Windows DX and OpenGL are capable of, but was unable to find a way on PSP. Have any one of you solved this issue ? Regards, anmabagima The psp gu does not support hardware bumpmapping o...

So I'm helping improve the JGE engine that we either broke or didn't work to begin with. Either way I'm trying to add volume control to SFX. if I set volume straight on here without calling anything or using vars it works... But we cant do that... JMP3::init(); pspAu...

Draan wrote:

mohh eloader wrote:devs ONLY WHAT THA FUCK.....i guesse u arnt the answer to 5.5X ofw >.>

m0skit0 wrote:I'm the answer to nothing. I only do as I please. Don't like it? Make the eloader yourself, whining boy.

See? :)

This wasn't reply to willow :D

lol, now I'm confused :) Thx4clarification

m0skit0 wrote:I'm the answer to nothing. I only do as I please. Don't like it? Make the eloader yourself, whining boy.

I guess willow was more likely referring to "mohh eloader"... so no need to take it personal for you :)

Dr Watson posted here about the issue http://forums.ps2dev.org/viewtopic.php?t=9244&highlight=&sid=e8bc0671b3a19e7eeafd59bde2bd9537 This was in '07. Willow, you said that SDK changed around that time? What do you guys know about that? Could that have caused this bug? I took a quick look int...

yeshua wrote:http://wololo.net/forum/viewtopic.php?f ... 8089#p8087

You may want to respond to this Raphael...

I'll respond to this today evening, as I don't have my personal e-mail account login with me at work.
Thanks for the notification :)

- JRenderer::Destroy() is not a safe destruction of all objects involved (see below) [...] Regarding the new test method, which basically creates a new JRenderer every time SQUARE is pressed - the error is obviously, because the JRenderer::Destroy() function doesn't safely clean up everything, just...

Yes. It's just that the cause auf the SDK bug would be if the PSM register is overwritten actively by use of sceDrawBufferList (I don't know any other function that writes to that register...). But JGE++ didn't seem to use it anywhere, so the question remains why it happened there anyway. I'm sill s...

I noticed, since sceGuDrawBufferList changes the psm hardware register, but is supposed to be non-permanent (ie changed back to value given with sceGuDrawBuffer when a new display list is started with sceGuStart) it makes absolute sense to add that command in sceGuStart, since it already resets the ...

Thanks, I believe this fixes the issue. My HelloWorld Program has the "fix" in the svn. Well, then I guess the only question left is: when and what causes this hardware register to be overwritten?... At least it might be worth-while putting that "fix" into pspgu directly, since ...

yeshua wrote:What header file do I include to use that command you posted above. It doesn't compile by simply just adding it...

It's in pspgu.h... oh wait, it's actually called sceGuSendCommandi. My fault :)

have you added this line: sendCommandi(210,BUFFER_FORMAT); to JRenderer::StartScene()? EDIT: I see, you only changed JRenderer::Destroy() for engine->End(). This will not solve the problem of JGE not freeing up the vram allocations ANYWHERE, ie it will always cause problems unless yo...

Well, there is no "more current version", as the library was never updated from it's release (didn't have to :). There are just the two different versions (valloc.c old one, vram.c new one), and I still recommend using vram.c, as it doesn't depend on malloc (no dynamic sysram allocations) ...

I took a look into JGE render setup and everything that happens in the hello world sample. Some things I found: - The initial render setup is very rudimentary, a lot of modes aren't set explicitly. These include: * GU_CULL_FACE and GU_CLIP_PLANES not disabled in 2D mode (but enabled, which is defaul...

I checked the intraFont code and in fact it disables depth testing for it's own render then re-enables it (ie, it just assumes that depth testing was on before). I didn't find it doing that for blending though, so I guess that's pretty much out of the question, yes. PS: Might happen I stumble upon #...

I believe the bug lies in the library I use (JGE++), as one of our devs (Yeshua) was able to reproduce the issue with the hello world sample that comes with the library. There were also reports more than 2 years ago about such behavior with the library. Can you provide the code and/or instructions ...

Steps to track down the error: - does the intraFont draw/draw correctly? - disable lighting - disable blending (each frame, as intraFont will probably enable it again) - disable depth testing (each frame, as intraFont will enable it each time) - set GU_TRANSFORM_2D to check if your projection is wro...

On the initial problem: This random behaviour suggests that you somewhere have some kind of overflow in the code, that can carry on to the gu rendering (since all gu context information is stored in sysram actually). However, this can be insanely hard to track down, and I'd already to give up on som...

To add up on a_noobs reply (hi there btw :): the swizzle function doesn't know, nor care about pixelformats. It only works on raw bytes and "swizzles" them around, hence it needs a byte-width as parameter, rather than pixel-width... everything else is cared for by the GU when unswizzling f...

Short answer: No, sceGuGetMemory won't return unaligned data if your initial display list provided in sceGuStart was aligned properly. In detail: This is made sure, by aligning the allocated size on 32bit (first 3 lines in the code, size = ((size + 3) >> 2) << 2), hence every following allocation wi...

The crash must be caused by some other error in your program, but the texture not showing has to do with the CPU cache:

http://www.goop.org/psp/cache-howto.html

You need to writeback the cache after the conversion to make sure the data is in RAM, so the GPU reads the proper values.

Also take a look at the supported texture pixel formats. There is no RGB888 24bit format.

OK, a little longer answer to make it clear: You can't write to alpha on PSP (hardware limitation unless SDL would use a software method for blended blitting which is just slow), hence why you can't save the alpha part of png1 into png2 and then blit that to screen. You have to do as ne0h suggested ...

Short answer: you simply can't on PSP