| View previous topic :: View next topic |
| Author |
Message |
Brunni
Joined: 08 Oct 2005
Posts: 186
|
 Posted: Sat Nov 26, 2005 7:06 am Post subject: Simple 2D samples |
 |
|
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?
_________________
Sorry for my bad english
 Oldschool library for PSP - PC version released |
|
| Back to top |
|
 |
Shatterdome
Joined: 22 Nov 2005
Posts: 11
|
| Posted: Sat Nov 26, 2005 8:24 am Post subject: |
|
|
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?t=2345&highlight=snake+source |
|
| Back to top |
|
|
71M
Joined: 21 Jun 2005
Posts: 122
Location: London
|
| Posted: Sun Nov 27, 2005 3:30 am Post subject: |
|
|
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 |
|
| Back to top |
|
|
Brunni
Joined: 08 Oct 2005
Posts: 186
|
| Posted: Sun Nov 27, 2005 5:24 am Post subject: |
|
|
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 ^^
_________________
Sorry for my bad english
Oldschool library for PSP - PC version released |
|
| Back to top |
|
|
71M
Joined: 21 Jun 2005
Posts: 122
Location: London
|
| Posted: Sun Nov 27, 2005 5:47 am Post subject: |
|
|
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 |
|
| Back to top |
|
|
Shine
Joined: 03 Dec 2004
Posts: 728
Location: Germany
|
| Posted: Sun Nov 27, 2005 5:52 am Post subject: |
|
|
| Brunni wrote: | 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. |
|
| Back to top |
|
|
Brunni
Joined: 08 Oct 2005
Posts: 186
|
| Posted: Sun Nov 27, 2005 6:32 am Post subject: |
|
|
I downloaded FileAssistant but source is not included...
| Quote: | | 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?
_________________
Sorry for my bad english
Oldschool library for PSP - PC version released |
|
| Back to top |
|
|
71M
Joined: 21 Jun 2005
Posts: 122
Location: London
|
| Posted: Sun Nov 27, 2005 6:41 am Post subject: |
|
|
Doh!!!
Sorry, wrong link, try this. |
|
| Back to top |
|
|
Shine
Joined: 03 Dec 2004
Posts: 728
Location: Germany
|
| Posted: Sun Nov 27, 2005 7:06 am Post subject: |
|
|
| Brunni wrote: | | 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. |
|
| Back to top |
|
|
71M
Joined: 21 Jun 2005
Posts: 122
Location: London
|
| Posted: Sun Nov 27, 2005 8:26 am Post subject: |
|
|
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 |
|
| Back to top |
|
|
Brunni
Joined: 08 Oct 2005
Posts: 186
|
| Posted: Sun Nov 27, 2005 8:40 pm Post subject: |
|
|
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).
| Quote: | | 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.
_________________
Sorry for my bad english
Oldschool library for PSP - PC version released |
|
| Back to top |
|
|
71M
Joined: 21 Jun 2005
Posts: 122
Location: London
|
| Posted: Sun Nov 27, 2005 11:05 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
F.J. Sánchez
Joined: 06 Nov 2005
Posts: 10
|
| Posted: Mon Nov 28, 2005 9:09 am Post subject: |
|
|
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.
_________________
Hack your mind
Okupa tu mente. |
|
| Back to top |
|
|
71M
Joined: 21 Jun 2005
Posts: 122
Location: London
|
| Posted: Mon Nov 28, 2005 9:18 am Post subject: |
|
|
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 |
|
| Back to top |
|
|
F.J. Sánchez
Joined: 06 Nov 2005
Posts: 10
|
| Posted: Mon Nov 28, 2005 9:44 am Post subject: |
|
|
Okey, I made other changes but I get this while compiling:
| Quote: | /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?
_________________
Hack your mind
Okupa tu mente. |
|
| Back to top |
|
|
71M
Joined: 21 Jun 2005
Posts: 122
Location: London
|
| Posted: Mon Nov 28, 2005 9:58 am Post subject: |
|
|
Hmmm, not too sure what that problem is.
Here's a long shot, move the following in CTypes.h to before line 39.
| Code: | #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... |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
