PSP error - can anyone help?
- Thread starter cdub30
- Start date
SonicStorm
New member
It's possible you're experiencing a memory overload. The PSP and Wii versions of OpenBOR can't play certain large games if I remember correctly.
SonicStorm
New member
While I don't know much about it, I think the PSP version of OpenBOR can play the same stuff that the Wii version can. Some games that I'm pretty sure work on Wii's OpenBOR include Battletoads, Hyper Final Fight and Final Fight DC.
From my experience most games that don't work are usually ones that are really large (e.g. 250 MBs for example) and/or take a lot of RAM, like games that use lots of .png format pictures. TMNT Rescue-Palooza uses a lot of .png files for it's graphics in addition to high-quality sound effects.
From my experience most games that don't work are usually ones that are really large (e.g. 250 MBs for example) and/or take a lot of RAM, like games that use lots of .png format pictures. TMNT Rescue-Palooza uses a lot of .png files for it's graphics in addition to high-quality sound effects.
There's no rock solid way to know which modules will work and which ones won't without trying them, because that's up to the creator.
Some of us (myself for instance), just don't give a rat's behind about consoles and prefer to make larger, more ambitious modules. Others are very conscious toward portability and try to keep things simpler so their work plays on any supported platform. Others take a middle ground and make multiple versions of their module. Usually a mainline for more powerful platforms, and a "light" version with some features cut for maximum portability.
Which modules are you trying to load? We don't have a perfect list of compatibility, but there are some that we know have 0 chance of working on the PSP. At 32MB, the original PSP is a very memory starved platform.
SonicStorm Image format has absolutely nothing to do with compatibility. When used properly the .png format has ~20% better compression than .gif, and both are automatically optimized by the engine on load anyway.
It's the volume of images that matters, along with number of (and yes quality) of sounds, scripts, stage sizes, how the creator chooses to arrange "know" vs. "load", and a lot of other factors.
It's logical to assume bigger modules will use more memory because they are probably more ambitious in general, but the sheer size of a module on disk does not directly affect memory use. The module might be bloated up with material it doesn't actually load, or as is often the case, it has oversized music tracks. That's a common mistake, but doesn't use more memory. Music is streamed and doesn't load into RAM.
DC
Some of us (myself for instance), just don't give a rat's behind about consoles and prefer to make larger, more ambitious modules. Others are very conscious toward portability and try to keep things simpler so their work plays on any supported platform. Others take a middle ground and make multiple versions of their module. Usually a mainline for more powerful platforms, and a "light" version with some features cut for maximum portability.
Which modules are you trying to load? We don't have a perfect list of compatibility, but there are some that we know have 0 chance of working on the PSP. At 32MB, the original PSP is a very memory starved platform.
SonicStorm said:
SonicStorm Image format has absolutely nothing to do with compatibility. When used properly the .png format has ~20% better compression than .gif, and both are automatically optimized by the engine on load anyway.
It's the volume of images that matters, along with number of (and yes quality) of sounds, scripts, stage sizes, how the creator chooses to arrange "know" vs. "load", and a lot of other factors.
It's logical to assume bigger modules will use more memory because they are probably more ambitious in general, but the sheer size of a module on disk does not directly affect memory use. The module might be bloated up with material it doesn't actually load, or as is often the case, it has oversized music tracks. That's a common mistake, but doesn't use more memory. Music is streamed and doesn't load into RAM.
DC
SonicStorm
New member
I thought I heard somewhere that .png (on Wii and PSP) used more memory due to it using an older decompiler? Oops! Thanks for clearing all of this up for me though. I actually didn't know that music files didn't count towards OpenBOR's memory limit. I think I understand how OpenBOR's memory works better now.Damon Caskey said:
There is a wii compatibility list on the wiki page and the psp original or 1000 model has 32mb for homebrew but any other model has 50mb and wii has about 60mb
SonicStorm said:I thought I heard somewhere that .png (on Wii and PSP) used more memory due to it using an older decompiler? Oops! Thanks for clearing all of this up for me though. I actually didn't know that music files didn't count towards OpenBOR's memory limit. I think I understand how OpenBOR's memory works better now.
What you probably saw is an issue with loading speed. The old .png decoder in current releases is slightly slower per file and it can add up to to noticeably longer load times if you have tons of sprites. But .png is still the newer, superior, smaller format. So it came down to personal preference.
But now the code-base has an all new encoder thanks to Plombo that loads as fast or faster than .gif does. On top of that, he recently released a new version of his palette tool that makes the most of .png's better compression potential, so there's no reason at all to use .gif unless you just want to be stubborn.
DC
When I last tested between gif and png they had different file sizes (png being smaller) but they took the same amount of memory in the engine.
Another issue was if a png was using anything less then 256 colour palette it would crash the engine I hope that has been addressed with the new decoder.
Another issue was if a png was using anything less then 256 colour palette it would crash the engine I hope that has been addressed with the new decoder.
msmalik681 said:
I've already explained this over and over - even in this same thread. The engine optimizes files internally, including trimming them down to the closest possible pixels. The main advantage of .png is smaller size on disk. This can be quite significant for download speeds (remember a lot of users here are still on low bandwidth) and low end Android users without a lot of storage.
First I've ever heard of this and I've used .png for years. In any case, it's off topic and Plombo's new app would be crashing the engine if it wasn't (corrected).
DC