Advertising (This ad goes away for registered users. You can Login or Register)

The state of libraries on the PSP.

Forum rules
Forum rule Nº 15 is strictly enforced in this subforum.
ChaoticXSinZ
Posts: 49
Joined: Sat Jan 22, 2011 11:37 pm

Re: The state of libraries on the PSP.

Post by ChaoticXSinZ » Tue Mar 01, 2011 11:59 pm

Kasumi wrote: Honestly, I'm looking to write functions to do three things:

1. Loading pngs.
2. Blitting small Xpixel by Ypixel areas of the png to the screen. (Tiles) (Fast, so I could draw thousands of tiles each frame)
3. Blitting small Xpixel by Ypixel areas of the png to the screen with Alpha Channel. (Sprites)

Text would be nice, but could be accomplished with #3. I do wish there was a magic solution, but I suppose I'm all for learning. The genesis deadline isn't getting further away, though. :
1. Well if you don't mind not using libpng you can use this: http://members.gamedev.net/lode/project ... icopng.cpp.

It is a single function which loads most any PNG file. The pixels it gives you will ALWAYS be 32-bit RGBA. Use is simple:

Code: Select all

std::vector<unsigned char> outPixels; // A vector to store the loaded pixels
unsigned long outWidth, outHeight; // Somewhere to store width and height of loaded image
const unsigned char* buffer; // The actual image data encoded as PNG from file, network etc
size_t imageSize // The size of the image data
decodePNG(outPixels, outWidth, outHeight, (const unsigned char*) buffer, imageSize, true);
2/3. As for blitting only a part of your image, I came up with this function to do so for me. You'll probably need to adapt it for yourself. As for its performance, I'm not sure I don't exactly need to blit thousands of tiles per frame (probably don't even need 100 :P)

Code: Select all

        /**
* Render an image onto the screen.
*
* @param float x X position to render to.
* @param float y Y position to render to.
* @param const ImageClip* clip Src blitting region.
*/
        void Image::draw(float x, float y, const ImageClip* clip) {

            unsigned int w, h;
            int offsetX, offsetY;

            if (clip != NULL) {

                w = (clip->width == 0) ? this->segments[0].width : clip->width;
                h = (clip->height == 0) ? this->segments[0].height : clip->height;

                offsetX = clip->x;
                offsetY = clip->y;

            } else {

                w = this->segments[0].width;
                h = this->segments[0].height;

                offsetX = 0;
                offsetY = 0;

            }

            //printf("[%d] pos: (%f, %f) \noffset: (%d, %d)\ndimensions: (%d, %d)\n", this->segments.size(), x, y, offsetX, offsetY, w, h);

            // Enable 2D textures
            sceGuEnable(GU_TEXTURE_2D);

            sceGuTexMode(GU_PSM_8888, 0, 0, this->isSwizzled());
            sceGuTexFunc(GU_TFX_REPLACE, GU_TCC_RGBA);
            sceGuTexFilter(GU_LINEAR, GU_LINEAR);
            sceGuTexScale(1.0f, 1.0f);
            sceGuTexOffset(0.0f, 0.0f);

            // Apply texture
            sceGuTexImage(0, this->segments[0].p2Width, this->segments[0].p2Height, this->segments[0].width, &this->segments[0].pixels[0]);

            Vertex2 image[2] = {
                { // Top-Left point
                    (offsetX / (float)this->segments[0].p2Width), (offsetY / (float)this->segments[0].p2Height),
                    x, y, 0.0f
                },
                { // Bottom-Right point
                    ((offsetX + w) / (float)this->segments[0].p2Width), ((offsetY + h) / (float)this->segments[0].p2Height),
                    x + w, y + h, 0.0f
                }
            };

            sceGumMatrixMode(GU_MODEL);
            sceGumLoadIdentity();

            Vertex2* finalImage = (Vertex2*) sceGuGetMemory(sizeof(Vertex2) * 2);
            memcpy(finalImage, image, sizeof(Vertex2) * 2);

            // Draw the quad
            sceGumDrawArray(GU_SPRITES, GU_TEXTURE_32BITF | GU_VERTEX_32BITF, 2, 0, finalImage);

            // Disable again
            sceGuDisable(GU_TEXTURE_2D);

        }
With that I can draw say, a 64×64 segment starting at the offset (32, 32) in a 128×128 image on to the screen at (100, 24) like so :

Code: Select all

ImageClip clip = {32, 32, 64, 64};
Image myImage;
myImage.loadFile("blabla.png");
myImage.draw(100, 24, &clip);
Just ask if you need clarification.
Advertising

RNB_PSP
Posts: 138
Joined: Mon Jan 17, 2011 9:18 pm
Location: In your dreams.....

Re: The state of libraries on the PSP.

Post by RNB_PSP » Wed Mar 02, 2011 6:42 am

Kasumi wrote:
It is often nice to know it's not you. :) This only really bothers me because I'm a genesis contest hopeful, and I worry about who could run my game. It probably won't be a problem though, I don't anticipate many judges only having original firmware.

Honestly, I'm looking to write functions to do three things:

1. Loading pngs.
2. Blitting small Xpixel by Ypixel areas of the png to the screen. (Tiles) (Fast, so I could draw thousands of tiles each frame)
3. Blitting small Xpixel by Ypixel areas of the png to the screen with Alpha Channel. (Sprites)

Text would be nice, but could be accomplished with #3. I do wish there was a magic solution, but I suppose I'm all for learning. The genesis deadline isn't getting further away, though. :(
I started learning about the GU by reading the sdk samples and oslib mod's source. About drawing text, intraFont does a very good job.
Advertising
Image
Image

ChaoticXSinZ
Posts: 49
Joined: Sat Jan 22, 2011 11:37 pm

Re: The state of libraries on the PSP.

Post by ChaoticXSinZ » Wed Mar 02, 2011 12:44 pm

Oh yah, if you're gonna use intraFont you're gonna need to reset some stuff as intraFont mucks with the GU state >.< Such an annoying problem if you don't realize this is happening. To be safe, I reset these after drawing with intraFont:

Code: Select all

            sceGuScissor(0, 0, SCR_WIDTH, SCR_HEIGHT);
            sceGuEnable(GU_SCISSOR_TEST);
            sceGuDisable(GU_DEPTH_TEST);
            sceGuFrontFace(GU_CW);
            sceGuEnable(GU_CULL_FACE);
            sceGuShadeModel(GU_SMOOTH);
            sceGuEnable(GU_CLIP_PLANES);
            sceGuEnable(GU_BLEND);
            sceGuBlendFunc(GU_ADD, GU_SRC_ALPHA, GU_ONE_MINUS_SRC_ALPHA, 0, 0);
            sceGuDisable(GU_TEXTURE_2D);
            sceGuTexMode(GU_PSM_8888, 0, 0, 0);
            sceGuTexFunc(GU_TFX_REPLACE, GU_TCC_RGBA);
            sceGuTexFilter(GU_LINEAR, GU_LINEAR);
Adjust however you need it.

Strangelove
Posts: 286
Joined: Thu Nov 25, 2010 6:32 pm

Re: The state of libraries on the PSP.

Post by Strangelove » Wed Mar 02, 2011 6:07 pm

ChaoticXSinZ wrote:Oh yah, if you're gonna use intraFont you're gonna need to reset some stuff as intraFont mucks with the GU state >.< Such an annoying problem if you don't realize this is happening. To be safe, I reset these after drawing with intraFont:
Interesting, but wouldn't it be better to pinpoint what gets altered and send a path (or a decent bugreport) to BenHur, assuming he's still alive and kicking?

I make a point out of contributing bugfixes back to the community, and I take this opportunity to recommend that people follow the example. Remember: If more people helps with a project the more YOU benefit from better tools or libraries!

And if the maintainer isn't available, I'm sure Jetdrone aka. Heimdall wouldn't mind taking a patch.
"If you have specific questions ... don't hesitate to ask as the more generic the question is the more philosophic the answer will be" - PSPWizard

Kasumi
Posts: 20
Joined: Sat Feb 19, 2011 3:53 am

Re: The state of libraries on the PSP.

Post by Kasumi » Wed Mar 02, 2011 7:17 pm

This might have fixed it. It worked for me, no crash during loading. I actually tried something with PSP_HEAP_SIZE_KB like this before I gave up, but this exactly seems to work. I realize you seem to no longer be using "graphics.c", but it may help other lurkers.

Thanks for that post, ChaoticXSinZ. The image clip thing is like SDL_BlitSurface, so I understood it. I may stick with graphics.c in light of the above, though. Complaining about libraries, and the problem is me. :oops: I still do plan to REALLY learn how to use the GU, but not in a time crunch.

I'm still working from a zombie slave of "graphics.c", but I removed some things that were set every frame. "sceGuTexMode" doesn't need to be run each time, does it? That seems to slow it down more than the other GU functions. For now I've settled with running it before each large loop of blits. I'm basically counting on fewer things being dynamic, so I'm hoping to get away with setting some things once, and not touching them. From the discussion, intrafont would seem to interfere with this.

I can now blit ~1767 16x16 tiles and still run at around 71 FPS. I must have been confused with 8x8 tiles, because graphics.c can blit a whole screen of 16x16 with 3 layers in a frame.

Now I hunt for audio. Thanks for all the help and posts, guys, and sorry for any hijacking.

ChaoticXSinZ
Posts: 49
Joined: Sat Jan 22, 2011 11:37 pm

Re: The state of libraries on the PSP.

Post by ChaoticXSinZ » Wed Mar 02, 2011 11:32 pm

Strangelove wrote:
ChaoticXSinZ wrote:Oh yah, if you're gonna use intraFont you're gonna need to reset some stuff as intraFont mucks with the GU state >.< Such an annoying problem if you don't realize this is happening. To be safe, I reset these after drawing with intraFont:
Interesting, but wouldn't it be better to pinpoint what gets altered and send a path (or a decent bugreport) to BenHur, assuming he's still alive and kicking?

I make a point out of contributing bugfixes back to the community, and I take this opportunity to recommend that people follow the example. Remember: If more people helps with a project the more YOU benefit from better tools or libraries!

And if the maintainer isn't available, I'm sure Jetdrone aka. Heimdall wouldn't mind taking a patch.
Well usually I attempt to submit bugs reports and if possible solutions, like the emails I posted for Jetdrone earlier on in this thread (here). As for this specific problem, I didn't really look much into it at the time. I was focusing on another part of my application and this was just holding it all up, thus I just wanted a quick fix.

One thing I do remember for sure which needed to be set was sceGuDisable(GU_TEXTURE_2D); (thanks to hardhat). As for the others, I'm sure some do matter, some don't.

JJS
Big Beholder
Posts: 1416
Joined: Mon Sep 27, 2010 2:18 pm
Contact:

Re: The state of libraries on the PSP.

Post by JJS » Thu Mar 03, 2011 12:06 pm

I'd say that a developer using Intrafont always has to check what states it modifies and adapt to that (easys because it is open source). There is no general rule as to what GU featues should be enabled or not and especially somethink like GU_TEXTURE_2D will more often than not be used by the homebrew anyway. So the only right thing to do in Intrafont would be to save the GU state, do the drawing and restore it afterwards. But that will probably have unintended sideeffects on the output, makes customizing the output harder (because you have to do the changes in Intrafont code) and will reduce performance.

jetdrone
Posts: 20
Joined: Wed Dec 01, 2010 7:54 am
Contact:

Re: The state of libraries on the PSP.

Post by jetdrone » Thu Mar 10, 2011 11:13 am

ChaoticXSinZ wrote:Minpsp does indeed help in alleviating some of the problems with the libraries but, like jetDrone said, it's a one man project mostly. Also many projects haven't been updated in quite some time. This results in some frustrating times when you try to use these libraries and they end up not working.

Personally, for the first version of my app I used SDL (and all it's 'plugin' libraries) and they worked well for the most part. I then moved on to SDL/OpenGL after I got the hang of it mostly. Now I'm working on my latest app using straight sceGu. I can't recall how long I spent some times trying to get a single thing to work the way I wanted it too. But thankfully, after a lot of trial and error as well as help from others I've gotten rendering with sceGu down (for at least my purposes). I can render texts, shapes, and images (even those > 512×512). Using some library to wrap everything for me (like OSLib) would have probably made it much easier but I have to admit that all in all it's a learning experience. Sure it's frustrating, but it does feel good in the end :)

Oh and a few things about minpsp: (given that my emails don't seemed to be working with a mail delivery subsystem error]
This is all for v 0.10
- The pspsh binary packaged with the ubuntu 64 bit deb doesn't seem to work. I wasn't able to type anything in so I just compiled my own version. Also, something I've noticed that doesn't seem to be included in minpsp is the remotejoy program. The one provided requires some options such as port, ip, mapfile, device etc Thus I just compiled Remote Joy SDL for PSP myself from the svn.

Here is a copy of the emails I tried to send to pmlopes AT jetcube.eu:
I've been working with TinyXML in creating an XML based UI for my PSP app. I
had some problems with using the TinyXML library provided with minpspw.
Thus, I tried out downloading the latest version from upstream's sourceforge
and it worked. So it seems there are some bugs in the version provided with
minpsp which have been fixed upstream. For now I'm bundling TinyXML with my
app and just compiling it with my own makefile. I do hope you update it
soon.
Something I noticed is that, at least in the ubuntu 64bit deb, intrafont won't work without the libccc.h file. A quick fix is downloading it yourself and placing it in the same folder as intraFont.h (/opt/pspsdk/psp/sdk/include/ on my system). Hope it gets updated in the next version. Thanks for all the work.
Sorry for hijacking the thread :P
Yes lots of things have been broken, for the older releases, with 0.11 i fixed the pspsh issue, and the assembler does generate good code. Again the best way to contribute is either to submit patches to the ps2dev svn which has been down for a year or so, or send a patch to sourceforge.net/projects/minpspw tracker since everything is public and the source available to all.

It is very helpful is anyone wants to help on the minpspw project since i don't devote much time to it as i did in the past.

Strangelove
Posts: 286
Joined: Thu Nov 25, 2010 6:32 pm

Re: The state of libraries on the PSP.

Post by Strangelove » Fri Mar 11, 2011 2:13 pm

I've contributed some bugreports / bugfixes, and I agree it belongs with whoever maintains the library.

I'm currently aware of many bugs with OSLib mod, the PNG reader was recently fixed, but the JPEG reader is in a sorry state, and the audio player has a known bug. The source code is full of commented out sections, comments in french or italian, and lacking error-checking.
I've also submitted proper bugfixes (with explanation) for other bugs. So far one was accepted, and I haven't heard anything more about the other bugfix.
The current maintainer is useless, if he can't even be bothered to take a bugfix he don't even deserve to call himself a maintainer. He will not get any more contributions from me.

I've tried to register on PS2DEV but since they had the brilliant idea to ban gmail and hotmail and a number of other domains. I can't register there, it throws me error messages when I attempt other email addresses, and at this point I've had it with that site. Can't even contact the staff there.

I still recognize the importance of a quality toolchain+SDK though so if I have something to contribute in that area I'll just send the fix directly to MinPSP. At one point I thought about doing some work on the build system.

As for libraries it's a sad state of affairs. I no longer care, I'll just start do like everyone else, fork them and not contribute fixes back.
I wholeheartedly agree with Coldbird: The PSP scene is rotten (in more than one way), and they don't get the idea behind open source AT ALL.
Please note that I do NOT include Jetdrone and a few other individuals in that statement. Jetdrone is a nice guy and he DOES get open source.

Oh well, enough drama for today...
"If you have specific questions ... don't hesitate to ask as the more generic the question is the more philosophic the answer will be" - PSPWizard

Salmon
Posts: 68
Joined: Fri Jan 07, 2011 12:08 pm

Re: The state of libraries on the PSP.

Post by Salmon » Sat Mar 12, 2011 12:00 pm

Not completely related, however some may find it interesting or useful. It looks like someone has been able to update the psptoolchain GCC version to 4.5.2. See here.

Post Reply

Return to “Programming and Security”