Best texturing approach on PSP
Best texturing approach on PSP
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
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
SharkOne, www.en-mousse.org
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.
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.
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...
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.
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.
I might be interested in making a similar tool but actually command line based and of course easily portable.
can anyone answer this ?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 :)
--
SharkOne, www.en-mousse.org
SharkOne, www.en-mousse.org
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.
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.
So let's resume everything :
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 ?
- 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
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
SharkOne, www.en-mousse.org
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.
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.
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.
Wrong, PSP handles that automatically, it can even trilinear filter between mipmaps per pixel.ashleydb wrote:You do have to calculate which one to use each frame for each mipmap textured object though.
http://www.dtek.chalmers.se/~tronic/PSPTexTool.zip Free texture converter for PSP with source. More to come.
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 ?
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
SharkOne, www.en-mousse.org
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
SharkOne, www.en-mousse.org
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.
Is this Sample Code somewhere to be found in the meantime??? I am having a hard time using your .ptx format and display it..ector wrote: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...
Also BMP2RAW does not really convert the 24Bit BMP properly :(
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:
Code: Select all
// Class1.cs
using System;
using System.IO;
using System.Drawing;
using PSPToolbox;
namespace PSPTexConv
{
/// <summary>
/// Summary description for Class1.
/// </summary>
class Class1
{
/// <summary>
/// The main entry point for the application.
/// </summary>
private static string HelpMessage =
"Usage: PSPTexTool inFile [outFile] [params ...]\n" +
" Params:\n" +
" (None) - Interactive Mode\n" +
" Format: -RGB0565, -RGB1555 (default), -RGB4444, -RGB8888, -CLUT4, -CLUT8\n" +
" Swizzling: -Swizzle (default), -NoSwizzle\n" +
" Mipmaps: -8, -4 (default), -2, -1";
static void PrintError(string s)
{
Console.WriteLine(HelpMessage);
Console.WriteLine("\nERRORS: {0}", s);
}
[STAThread]
static int Main(string[] args)
{
PSPTextureOptions options = new PSPTextureOptions();
string inFile = "";
string outFile = "";
bool bError = false;
string errorString = "";
options.Format = PSPTextureFormat.RGB1555;
options.Swizzle = true;
options.NumMipmaps = 4;
foreach (string s in args)
if (s.Length > 0)
{
if (s[0] == '-')
{
switch (s.Substring(1, s.Length - 1).ToUpper())
{
case "RGB0565": options.Format = PSPTextureFormat.RGB0565; break;
case "RGB1555": options.Format = PSPTextureFormat.RGB1555; break;
case "RGB4444": options.Format = PSPTextureFormat.RGB4444; break;
case "RGB8888": options.Format = PSPTextureFormat.RGB8888; break;
case "CLUT4" : options.Format = PSPTextureFormat.CLUT4; break;
case "CLUT8" : options.Format = PSPTextureFormat.CLUT8; break;
case "SWIZZLE": options.Swizzle = true; break;
case "NOSWIZZLE": options.Swizzle = false; break;
case "8": options.NumMipmaps = 8; break;
case "4": options.NumMipmaps = 4; break;
case "2": options.NumMipmaps = 2; break;
case "1": options.NumMipmaps = 1; break;
default: bError = true; errorString += "\nUnknown option: " + s; break;
}
}
else
{
if (inFile == "")
inFile = s;
else if (outFile == "")
outFile = s;
else
{
bError = true;
errorString += "\nToo many input files: " + s;
}
}
}
if (inFile == "")
{
bError = true;
errorString += "\nNo input file specified";
}
else
{
if (outFile == "")
outFile = Path.ChangeExtension(inFile, ".ptx");
if (Path.GetExtension(outFile) == String.Empty)
outFile = Path.ChangeExtension(outFile, ".ptx");
if (inFile == outFile)
{
bError = true;
errorString += "\nInput and output files are identical (" + inFile + " , " + outFile + ")";
}
}
if (bError)
{
PrintError(errorString);
return 1;
}
try
{
Bitmap bmp = new Bitmap(inFile);
PSPTexture texture = new PSPTexture(bmp);
texture.options = options;
texture.SetDirty();
texture.Quantize();
FileStream fs = new FileStream(outFile, FileMode.Create);
BinaryWriter writer = new BinaryWriter(fs);
texture.Save(writer);
writer.Close();
fs.Close();
}
catch
{
PrintError("Processing bitmap image " + inFile);
return 1;
}
return 0;
}
}
}
Paco
-
- Posts: 75
- Joined: Mon Sep 19, 2005 5:41 am
Swizzle results
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!!
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
- Posts: 142
- Joined: Thu Apr 14, 2005 2:08 am
- Location: Florida, USA
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.
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
-
- Posts: 10
- Joined: Tue Oct 18, 2005 6:47 pm
The offline swizzled textures are fastest to load, but you can do that while loading too. Basically you can just load the stuff to memory and you're ready to go. The texture converter mentioned already in this thread can be easily used for that purpose.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.)
The screenshot sample (link below) is really simple to extend to load a png as texture (instead of dumping it to framebuffer). I have not noticed any ready-to-go libraries around though.
http://svn.ps2dev.org/filedetails.php?r ... rev=0&sc=0