forums.ps2dev.org

or you could just buy a sixaxis :)

sweet, thanks, oopo!

or set up apache to run cgi...

I just checked it out.. it seems to be a linux system.. and you can build it from source... so theoretically if you had the linux kit for playstation, and if you were a linux guru, and if you were a great ps2 programmer with loads of free time, you could port the code for the core to the ps2 and hav...

A ps2 is not a pc inside.. you might be thinking of an XBOX, which is very similar to a pc, but even an XBOX wouldn't work for your app because it can't net boot... sorry.

pretty much any install will be fine for deving, as long as you can compile stuff..
personally I suggest debian as it's very easy to get new progs and stuff to work without a lot of dependancy headaches.. synapticpackage manager is where it's at..
.later.

I use the PBP unpacker tool to do that... google pdc pbp unpacker

that's what I do... I was never able to get any of the networking clients or usb clients to work with my setup except for the ftp server, so currently that's the only way I have to transfer files to my ps2... BTW, the PSP version of the text editor is progressing nicely, I am just about to add menu ...

I have an idea... what about using the analog stick kinda like the iPod's pad? one could use it to "roll" past letters using a circular motion.. similar to the post above about it, but with all 26 letters at once...

you can also edit the .bashrc in the /home/yourloginname directory in cygwin...
that way all you have to do is copy & paste the "export ..." lines from the readme without having to edit them... that's what I did for my windows machine...

yeah, you need to use malloc() (and free(), when you are done). I use it in the text editor I am making.. However, Malloc & free aren't specifically psp related, so you would probably be better off searching google for "malloc tutorial" or something... that would give you the best pict...

search for "kxploit"... that'll set you on the path to enlightenment.. BTW, I am from Van as well!

those numbers are the data for the rgb values for the pixels in the image.. they are converted like that so that it makes it easier to use an image in a c program.. you can use the Gimp to convert them.. but you should look at some source code (hello world is an example) to see how they are used, be...

yeay, it gives some debug-ish info on the screen.. ie, what directory the app was executed from, etc.. if your psp is powering off, then there is something wrong.. (;P) make sure that your toolchain is up to date.. btw, You probably know this, but you don't need to use the outpatch anymore.. the elf...

works for me..

Thanks a lot for all the hard work, people.. You are really an inspiration!

I understand that it's the pro duos themselves that have a problem with atrac, not just from soundstage.. but I don't know why.. I'd just make mp3's from the atracs if i were you.

actually, I am in the (slow) process of creating one.. I made one for linux, I am in the process of porting it over...

I use linux for most of my computers, but I also have a mac with panther and a laptop with w2k

Sweet! I'm glad I could help.. to be honest, I learned a lot too... before seeing nem's code, I had no idea how to implement a magnification for sprites.. :P but anyway, you're welcome.

to be honest, I'm not exactly sure about your "bigger buffer" question.. I assume you want to keep it in Vram? if you don't, then you could make an array with the same number of elements as pixels for your buffer, copy the image data into this array, then use a modified bitblt to only capt...

oh, I see. well, his style is a bit different than mine, but i wrote mine based on his... his variable naming is a bit hard to understand at first, that's why I changed the names of mine.. but the basic premise is this.. he gets the place of the first pixel in the psp's ram with the vptr0=... line h...

or do you mean the original bitblit from pg.c?

cause i thought you were talking about my code..

vptr0 is just a pointer to the vram of the psp.. pgGetVramAddr supplies the correct address for a given pixel for each iteration. the next line puts the pixel data from the picture into the ram, effectively drawing one pixel.. jeach time the for loops are incremented, the yloop and xloop values chan...

ok, that's just too funny! you totally got it, though..:)

maybe I should have said : althogh your picture is 2d, all memory (on your hdd, the psp, everything) is 1d that means that your pic must be chopped up and arranged in mem as 1d, then when the psp puts it on screen, it reads out the 1d memory in chunks of SCREEN_WIDTH, for each line. so like this for...

ahh, see, that's the trick... you only need access to the first char, then you offset the pointer by the size of exactly one char for each pixel into the picture you want.. note that to move down a y value, you have to offset by y*SCREEN_WIDTH because you are "skipping" those pixels. and t...

because it is the color information...
the address is held in the pointer, but the pointer points to an unsigned char, which is the color..

note that mag's lowest value is 0, so if you call it with mag=1, your tiles will be twice their orig size.. (just noticed that bug)

well, I don't know, but I don't think so, because in the end, you have to write the data twice..