forums.ps2dev.org

[SharkOne]

I've been browsing the forum for about a week now and I'm getting more and more interested in starting homebrew development and maybe make it available as a platform choice in the game development laboratory I'm in (http://labconsole.epitech.net).

So right now I'm trying to get as much knowledge as I can before really starting.

I have a few questions about the best (most efficient) method for handling geometry and texture data.
Should everything be in VRAM ? If yes, how to put geometry data in VRAM ? (I think I found how to put textures in VRAM using sceGuCopyImage is that right ?)

What's the prefered mode for textures ? 16bits ? which mode then ? having an alpha channel with 16bits seems pretty tricky right ? 4444 mode doesnt seem easy to create :)

I understood that swizzled textures are a must-go right ?

ector's texture tool seems really really nice. But what is the point of creating mipmaps offline ? is it that the psp cannot create them itself ?

what about CLUT ? are they paletted textures ? is that the fastest available ?

I'm sorry about this question overflow but I would really like to understand a few things before actually dive into coding.

I'm sure this thread would actually be of interested for a lot of newbies like me on the forum

thanks in advance
_________________
--
SharkOne, www.en-mousse.org

[ashleydb]

I'm still trying to figure out texturing myself, especially swizzling.

As I'm sure you are aware, doing as much work offline (i.e. not on the PSP, but on your PC when creating textures) as you can means the content will run faster on the PSP since it will have less to do iteself. So, creating mipmaps with ector's tool means they are ready to just read in, rather than having to generate. The same would be true of swizzling, which you could do ahead of time.

I'm sure you've read that swizzling is the rearranging of image data to be in a format which is faster for the PSP. It is quicker to send over the PSP's bus since each pixel's data is contiguous rather than spread around an array.

CLUT is paletted. I'm not sure if it is faster, but it should save memory. You will obviously have a reduced amount of colours available to you for that image though.

Once some of this stuff is clarified, I intended to document how to do it all myself. Not only for everyone to read, but for my own benefit :) This thread is a great idea to start that off.
_________________
www.PSP-Files.com - PSP News, Hacks etc.

www.HiAsh.com - My work and stuff

[Tim]

Pardon the n00b question, but I never had to deal with this "swizzling" in directx or opengl... Does swizzling just add a pitch to the side of the texture so it has proper alignment for bus transfers?

~Tim

[ashleydb]

Swizzle FAQ
_________________
www.PSP-Files.com - PSP News, Hacks etc.

www.HiAsh.com - My work and stuff

[ector]

Yeah the advantage of my format is how ridiculously fast you can load the textures: a single sceRead and a few pointer fixups and you're done, complete with mipmaps, and being swizzled for max efficiency.

I really should do some sample code to use textures from my tool from libGu instead of just my private library :/

Hope to get that done and commited to svn tonight, but we'll se...
_________________
http://www.dtek.chalmers.se/~tronic/PSPTexTool.zip Free texture converter for PSP with source. More to come.

[ashleydb]

That would be amazing. I've had a look at your tool and it seems to work well. I've just been trying to get the exported files back into an sce App...
_________________
www.PSP-Files.com - PSP News, Hacks etc.

www.HiAsh.com - My work and stuff

[SharkOne]

yeah ector that would be great :)

I might be interested in making a similar tool but actually command line based and of course easily portable.

[Kristof]

You can put what you want in VRAM (texture or geometry) for faster access. But all work well also in RAM. It depends if you need GPU fast processing or not.

For textures, I use mainly 4 bits textures, as they are the fastest (because the smallest). But you only have 16 colors (colors can be in 8888 format, so alpha is fully supported for each color).

But again this is a choice to made depending on your game/demo/application.

[SharkOne]

So let's resume everything :

Always swizzle texture
The smaller the texture is, the faster its usage will be
The smaller texture's bitdepth is, the faster its usage will be
Put every critical texture in VRAM (bigger textures first)
Put anything really critical in VRAM to get faster access

So what's the truth about paletted textures then ?
What about mipmapping ? Is it only a graphic quality feature ? or can it also help speeding things up ?

To put geometry in VRAM, memcpy is the key ? just transfering it anywhere there and use it ? (Sorry I'm not familiar at all with console platform and limitations)

So this means you have to code your own memory manager to handle VRAM on its own right ?
_________________
--
SharkOne, www.en-mousse.org

[Kristof]

On PSP memory access are slow. So if you want to speed up your display, then put everything in VRAM, or use the smallest datas possible if your datas are in RAM.

If you do not need performance display, do not care about all of that. PSP can handle a nice amount of polygon even without all these tricks.

[ashleydb]

Mipmaps use more memory, (typically a third) but they are faster to transfer over the bus since you are only sending a texture of a useful size, (for example, a building far away is only a few pixels high on the screen, so send a tiny texture, like 4*4, not that whole 256x256 one!) You do have to calculate which one to use each frame for each mipmap textured object though. It will also enhance graphical quality to some extent by preventing swimming/shimmering. It can have nasty looking blurring between each transition, but if you can get anisotropic filtering going, it will look really good.
_________________
www.PSP-Files.com - PSP News, Hacks etc.

www.HiAsh.com - My work and stuff

[ector]

[SharkOne]

Cool ! I was just going to ask that :)

I'll try to find some infos on anisotropic filtering as I have no experience with it.

GL_LINEAR_MIPMAP_LINEAR is trilinear filtering right ?
_________________
--
SharkOne, www.en-mousse.org

[holger]

yes.

[SharkOne]

I googled a little around about anisotropic filtering and it really seems a really intensive process. Is the PSP able to do it on its own ? because I could only find DX/OGL implementations using built-in features (HW accelerated), like it's impossible to do in software. And BTW I have strictly no idea how you could bypass the PSP rendering pipeline to integrate aniso
_________________
--
SharkOne, www.en-mousse.org

[ector]

I don't think it has aniso, you'll have to make do with trilinear (which is better than what the ps2 has :) )
_________________
http://www.dtek.chalmers.se/~tronic/PSPTexTool.zip Free texture converter for PSP with source. More to come.

[SharkOne]

ok so everything seems clear in my head now :)
thanks a lot!
_________________
--
SharkOne, www.en-mousse.org

[ayatollah]

[Paco]

The tool works great, only thing I miss is .NET being able to load TGA files. :) This is a command-line version of the tool:

[ayatollah]

If only I had some C compiler to compile it for Windows use..

What do I need to get ?! Never actually done any code for PC.. :(

[starman2049]

I am in the process of porting a game that is finished on PS2 and PC and have the game 100% up and running on PSP but it is running *really* slow.

1) I tested Swizzling today by just setting the Swizzle arg to sceGuTexMode() to GU_TRUE to see what kind of improvement I would get without actually reformatting my texture data. As I would expect the textures appear garbled, but unexpectedly there was absolutely no performance improvement.

2) I then changed my texture set/load code to load a fixed 64x32 32 bit texture instead of the intended texture so there were as many texture loads per frame, but they were all the same texture and there was a huge performance boost.

3) I then changed my texture set/load code to load the first 8k of every texture and there was a huge performance boost - running similiar to #2 above.

My question is why am I not seeing the same performance boost using swizzling as everyone else? My tests would indicate that performance has more to do with having tetxures that fit into the 8k texture cache than the layout withing the 8k texture cache. Has anyone else done any real-world tests with this?

I'm trying to figure out where to go from here and the conslusion I am at is that I should scale my textures down when exporting rather than mess with swizzling. Has anyone else moved a large-scale game onto PSP and if so what strategies did you use to get decent performance??? Given the small PSP screen size, lower rez textures don't seem to have much of a disadvantage, and there is a BIG speed bost.

Any help is GREATLY appreciated!!

[ChaosKnight]

It looks like you are instructing the PSP to swizzle the texure for you. You need to use a tool to swizzle the texture on your PC and store that instead of your regular flat texture.

Also you seem to talk about loading textures per frame. This is really really going to affect performance. If you can try to load all of the textures you need for a level at the beginning of the level and only swap out if you really, really need to.
_________________
w00t

[stinkymeat]

Just so I understand this correctly and for clarification:

-Textures should be prepared "offline" on a PC for the PSP to save processing time
-Textures can currently not be loaded from files in a high-level format (i.e. texture_1.png texture_2.jpg etc.)

Are these correct?

[memon]