Simple 2D samples

[Brunni]

Hello
I'm looking for very simple 2D samples for PSP.
I looked at samples included with PSPSDK. The "sprite" draws a torus, but it's impossible for me to understand. I have no knowledge about 3D, nor PSP hardware, so it's difficult.
The blit sample is simple, but blits from RAM, which is slow.
The goal would be to write very fast reusable general 2D routines, like loading a sprite into VRAM, drawing it, rotating it, alpha-blending, tinting it, etc. and also drawing empty+fill rectangles, lines, polygons, and so on, using - if possible - only integrated libraries (like GU, and no PSPGL for example).
So, can you tell me please where I can find VERY SIMPLE 2D samples, for a total begginer?

[Shatterdome]

Take a look at shines Snake game, it's writes to VRAM, although the way you have to import 'sprites' is abit memory intense (he uses the program that converts a .bmp or .png to .c and then for loops to write it to VRAM...a typical 480X272 bg is around 1meg, so the eboot gets abit large) but i've tried to slow it down with no results, so it is damned quick....check it out..

I could say search for it, but I don't beleive in that elitest mentatlity, so here ya go...

http://forums.ps2dev.org/viewtopic.php? ... ake+source

[71M]

You might wanna check out the code to FileAssistant++, it has a basic 2D renderer in CGfx.cpp
There's also texture support classes in CTexture that has the ability to upload textures to VRAM for speed.

http://tmpstore.free.fr/FileAssistant/

Cheers,
71M

[Brunni]

Thank you for your replies.
Unhopefully, FileAssistant seems to be offline (not downloadable).
And snake uses software rendering...
Any other proposition of a simple 2D sample to draw hardware accelerated sprites would be very nice ^^

[71M]

Ooops, sorry, must remember to update the download links! :D
http://www.psp-hacks.com/file/133

PM me if you need any further help...

Cheers,
71M

[Shine]

Thank you for your replies.
Unhopefully, FileAssistant seems to be offline (not downloadable).
And snake uses software rendering...
Any other proposition of a simple 2D sample to draw hardware accelerated sprites would be very nice ^^

Snake is very old, I've enhanced the graphics library in Lua Player and fraca7 has used this as a base for the new 2D C++ library in cpplibs/libpsp2d in SVN, which are used from Python and, when I have some time, it will be used from Lua Player, too. Would be a good idea to enhance this to use VRAM cached images, but it is already very fast, if you don't want to blit too many layers at once at 60 Hz.

[Brunni]

I downloaded FileAssistant but source is not included...

Would be a good idea to enhance this to use VRAM cached images, but it is already very fast, if you don't want to blit too many layers at once at 60 Hz.

I'll take a look at libpsp2d. But you speak from layers, does this mean rendering is software?

[71M]

Doh!!!
Sorry, wrong link, try this.

[Shine]

But you speak from layers, does this mean rendering is software?

Blitting to framebuffer is done with hardware acceleration, blitting from images to images currently in software, because images are not cached in VRAM and you can't blit from RAM to RAM with hardware acceleration (I think). The library uses double buffering, so this should be no problem, when you blit some sprites to offscreen.

With layers I meant something like in your signature image, e.g. a background image, the main layer where the player runs and perhaps a foreground layer, for clouds etc.

[71M]

Ok, here's a simple 2D example ripped from FA++ www.easy-monkey.co.uk/Simple2D.rar

You'll need the libpng and zlib libraries to get it to link correctly.
Place the texture.png along side the EBOOT.PBP so it can load it correctly.

Hope that helps you out!

Cheers,
71M

[Brunni]

Thank you very much ^^
The simple 2D sample seems to be exactly what I need. However, it doesn't work, it always crashes with ASSERT: p_texture != NULL, exiting from png_read_png probably with the setjmp (the file is found and its signature is correct, however).

Blitting to framebuffer is done with hardware acceleration, blitting from images to images currently in software, because images are not cached in VRAM and you can't blit from RAM to RAM with hardware acceleration (I think). The library uses double buffering, so this should be no problem, when you blit some sprites to offscreen.

One thing I don't understand, is why don't you put your screen buffers directly in VRAM? You could directly draw on it with PSP hardware, and still access to it from the main CPU. Okay VRAM is slower for random accesses due to its lower frequency / wider bus, but usually copying images requires sequencial accesses. Except oldschool mode 7 and HBLANK-powered raster effects, anything can be done in hardware, so CPU-access to VRAM would be quite rare. Emulators all use RAM, so there must be something I missed.

[71M]

Hmm, that's very strange! The texture is being read, but CTextureManager is returning a NULL pointer?
You can try to see at what stage in the PNG decompression it is erroring by sprinkling in lots of BREAK_POINT macros. then you can see what path the program is taking.

Screen buffers can be in both RAM and VRAM, as far as I know.
The original hello world example had the screen buffers in RAM so you can write directly to it. Any GU samples will have the frame buffers in VRAM.
I think the easiest way to tell is to see what address is being passed to sceGuDrawBuffer and sceGuDispBuffer. If it's zero based, then it's in VRAM, otherwise it's mapped to RAM.

I'm probably wrong, so please feel free to correct me! :D

Cheers,
71M

[F.J. Sánchez]

Hi, I'm new. I was trying compile Simple2D but I cannot because it doesn't find pspaudiolibplus.h. I'm under GNU/Linux and using psptoolchains (updated today). What could be the problem?

Thank you.

[71M]

Sorry, that was left in from when I stripped FA++ down.
Simply remove that header file from CTypes.h and everything should be fine.

Cheers,
71M

[F.J. Sánchez]

Okey, I made other changes but I get this while compiling:

/usr/local/pspdev/psp/sdk/include/psputils.h:43: error: ‘clock_t’ no nombra a un tipo
CString.h: In function ‘s32 StringCompareI(const char*, const char*)’:

Does I forget define something in the Makefile?

[71M]

Hmmm, not too sure what that problem is.
Here's a long shot, move the following in CTypes.h to before line 39.

Code: Select all

#include <stdio.h>
#include <stdlib.h>
#include <stdarg.h>
#include <string.h>
#include <list>
#include <vector>
#include "CMath.h"
#include "CVector.h"
#include "CAssert.h"

Sorry I can't be of any help...