forums.ps2dev.org

There's a BIG thread on uclinux on the PSP here... search for it and read the whole thread. That should keep you from duplicating work already done before.

I'm saying one of the most obvious differences could be the instruments. Switchings from a set that's (for example) 8 MB to one that's 30 MB clearly has great potential to make the game run out of memory the moment the instruments are loaded. Many libs like timidity simply abort the program when the...

The same way you debug anything else on the PSP - with psplink/gdb or logging. I'm a traditional programmer, so I go for logging. Do things like print out the results of memory allocations and stuff.

You'd need to port a really old compiler as the PSP doesn't have nearly enough memory for a modern compiler like gcc.

Remember that timidity is gonna allocate a SHITLOAD of memory when it starts... mostly due to the instruments. If you don't have much memory after the game itself is loaded, you may need to do something else for music. At least try it with a set of smaller instruments.

Okay, main() is in the platform specific code like os2.cpp. In os2.cpp you find: int CDECL main(int argc, char *argv[]) { SetRandomSeed(time(NULL)); return ttd_main(argc, argv); } Clearly, in your psp.c...

mase wrote:Yes, but the working code doesn't provide a SDL_main function, too.
So how can it run?

Buried in the makefile(s) somewhere is probably a define for SDL_main that sets it to ttd_main.

I suggest you use the minipats I put together for RotT and Duke3D. You can find them here:
minipats.zip

They're only slightly more than 4MB, but still sound excellent. You won't find a better set of instruments for the size.

you know, if sony would know anything about business, they would make some boot-loader app that you can download for 100$ from psn (just like you have to pay for MS' xna dev) and allow ppl to start that bootloader just like they do with any other download. They could easily keep all other restricti...

I had a thought on a legitimate reason Sony would have for pulling OTHEROS from the Slim: they cut the size of the flash rom again. The original PS3 had 256 MB of flash in it. Current PS3's have only 128 MB of flash. Maybe they cut the new Slims to 64 MB of flash. Remember that the OTHEROS loader is...

It's called tessellation, and you'll find many wonderful articles about it on the web. It's been around for a LONG time. It's one of those topics any 3D programmer should already know. :)

The majority of arguments I heard for not exploiting the PS3 was that we had OTHEROS. If Sony takes that away, they are only encouraging hacker to finally start digging into PS3 exploits. It's rather counter-productive if you ask me. My brother had a point though - he thinks the only reason Sony is ...

Sorry - looked like a game magazine site. :)

The new PS3 system will focus on delivering games and other entertainment content

Yeah, because linux has been such a tremendous focus to this point. ;)

Still looking for a SONY link about removing OTHEROS. Only a couple stories from non-Sony sites claim that the "Install OTHER OS" feature is removed. There's also another way that could be interpreted as well - that you no longer need to install a boot loader, but rather it could be launch...

Or perhaps more constraints on the recursion - maybe only have it recurse over a line at a time. In the end, I think Jim's right - recursion is a bad way to do a flood fill. You might get away with it on a PC where you have nearly infinite memory and a stupidly fast CPU, but such things shouldn't be...

ooPo wrote:It seems that otheros support has been dropped from the new slim PS3.

I wonder why...

Do you have a link for that? I haven't seen one word anywhere about OTHEROS being dropped. All articles claim it has ALL the functionality of the regular PS3.

A preferable way to make the patch would be to make the changes to the SVN repository, running "svn add" etc to add new files, and then send the output of "svn diff". Well, yes, if you were just making minor changes to what's in the repo. For something like updating SDL from an ...

Old configure script don't recognize the new versions due to the poor method used to check the version. You need to edit the configure script before running it and change the version detection method. Look for if ${MAKEINFO} --version \ | egrep 'texinfo[^0-9]*&#...

how do i make a patch diff -ruN <original file> <modified file> > <patch file> what is a patch, and how can i use it. A patch file has the differences between the original file and your modified file. If you have the original and a patch file, then you use patch to make the modified file. patch -p0...

PSP_MODULE_INFO&#40;"AVec", 0x1000, 1, 0&#41;; PSP_MAIN_THREAD_ATTR&#40;0&#41;; PSP_MAIN_THREAD_STACK_SIZE_KB&#40;1024&#41;; PSP_HEAP_SIZE_KB&#40;-1024&#41;; That's old kernel mode homebrew... it should be PSP_MODULE_INFO&#40;"AVec", 0, 1, 0&a...

You should be able to use those lines... if you can't, there's something wrong, possibly with your toolchain. How old is the toolchain/where did you get it/how are you running the app?

Are you also setting the heap size? You might be using heap size max, which would prevent you from making the stack size larger. Leave enough free memory where you can increase the stack appropriately.

The only changes recently are the two I made that never made it to the repo - you'll find a thread on my PSPGL and SDL with TV support somewhere here, and the other change to SDL I made was a fast resampler for the audio that works (converts odd sample rates to the rate you told SDL you wanted). The...

//cross point of x double xinters = &#40;p.y - p1.y&#41; * &#40;p2.x - p1.x&#41; / &#40;p2.y - p1.y&#41; + p1.x; //overlies on a ray if&#40;fabs&#40;p.x - xinters&#41; < __DBL_EPSILON__&#41; return bound; Looks like double precision to me.

Well, the main difference between standing still and moving appears to be InsidePolygon(). You might want to check that function. In particular, make sure you aren't doing any double-precision math anywhere. The PSP does that in software as it can only do single precision in hardware.

Comment out the cout << lines and see what happens. :)

The problem is memcpy&#40;&gsFont->Texture->Mem, &buffer&#91;m&#93;, size&#41;; It should be memcpy&#40;gsFont->Texture->Mem, &buffer&#91;m&#93;, size&#41;; ->Mem is a variable pointing to the memory, not an array that is the memory. Also, the m += 4; afte...

DarkShadow44 wrote:thx

Could I copy some parts, or not ?

As long as the license you use for your project is compatible with the license of the stuff you are copying, that's fine.

Yes, if the get pixel check does work, that should keep the recursion from being infinite. Better check those routines... maybe the alpha is getting stripped or something similar, which would then make the color check fail which would then allow infinite recursion.

Your recursion is infinite - look at these two lines: floodfill&#40;x-1, y, 0, 0xFFABCDEF&#41;; floodfill&#40;x+1, y, 0, 0xFFABCDEF&#41;; A recursion on the first line there when it causes a recursion on the second line is the exact same pixel as you started with... meaning you're re...