forums.ps2dev.org

BFB creates uncompressed TGA files, while the BMP it outputs are based on screen colordepth. Basically, the BFB TGA 8-bit file is just a file header followed by 1 byte per pixel (non-flipped) raw data which I feed directly into the alpha channel (actually, I think I had to do 0x80-(image[x+y*width]>...

I designed a new font type I'm currently calling Alpha Font. It's an 8-bit TGA/DAT combo (like the bmp_dat font) but it loads the TGA into the alpha channel and uses a solid white as the RGB portion of the font texture. This allows the font to be antialiased on the edges and be transparent in the bl...

I found a bug in the font loader for bmp/dat files. The Path_BMP and Path_DAT members of GSFONT are never defined. It's an easy fix but was annoying until I found the problem. I fixed it with else if( gsFont->Type == GSKIT_FTYPE_BMP_DAT ) //original line { gsFont->Path_BMP=c...

Writing a couple new functions won't fix it. Take a look... rv = fileXioDread(hddFd, &dirEnt); That shows the problem is not here, but elsewhere. Either in fileXio or in the function *it* calls later on to access the hdd device. My guess is maybe opening a protected partition, t...

There is no reason to put work into things when the only thing will be a bunch of warezers trying to steal as much as they can and bitching to make it to X or Y feature that you either don't want it to do, or is far more work than it's work on the PS2. I understand where you're coming from. One of ...

I was only yelling 'cause I got yelled at first, and because all of you seem to shut down your brains at the mere sight of the letters HDL. I apologize. I'm sure it seems a reasonable reaction to you. It doesn't to me. As far as the speed of PS2SDK during GetFilesystemList, I don't think it's PS2SDK...

If your claim is that most people that would be running homebrew are warezing bastards, well, take a guess why I haven't released anything significant publicly for quite a while. That's your choice to release or not. Warezers always were and always will be. Another thing you'll just have to learn t...

My point isn't everyone else is doing it. My point was it's a problem that exists and should be taken into account, whether you like it or not. And the one specific program thing is why I suggested possibly making an alternate function that skips and non-PFS partition. As far as WHY it takes so long...

Drakonite wrote:My HDD stuff doesn't take a year to load. But then again, I'm not a warezing bastard either.

It would if your average PS2 homebrew user ran it (assuming it uses GetFilesystemList).

I don't know. I've never counted. I've got a 120GB HD. 3 or 4 gigs is PFS formatted. It took MCManager at least a minute (though I think closer to 2, I never timed it) to load before I changed it to not scan for partitions. I noticed a lot of people thinking HD programs were locking up on their syst...

I'm not talking about supporting it. What part of the patch makes you think it's being supported? It's merely making GetFilesystemList not take freakin' forever if there are HDL partitions on the system by skipping them. How is that supporting it? Oh well, do whatever, I guess I'll just be the only ...

That's BS. It exists. Deal with it. Ignoring it won't make it go away. It'll just screw up the homebrew scene when peope can't get a program to load in a timely manner. Just because you acknowledge the existence of something enough to get around the problems it causes doesn't mean you approve of it.

I don't know how to use CVS very well. Just enough to tell WinCVS to checkout. I'd be worried I'd break something.

Can someone with CVS access change the part of hddGetFilesystemList that says // We only want to know about main partitions (non-empty ones at that :P) if((dirEnt.stat.attr & ATTR_SUB_PARTITION) || (dirEnt.stat.mode == FS_TYPE_EMPTY&#41...

That's what I thought too, but as of previous versions, that wasn't the case. I could never get fileXio to access anything but HD. I haven't checked with 1.2 yet. It'd be nice if I could stop using "if (!(strncmp(filename,"pfs",3))) fileXioOpen else fioOpen"

Will it ever be possible that these 2 file methods will ever be able to be combined into 1 command that doesn't care if something is on HD or MC/HOST/CDFS, or will HD ever be fio compatible? I was just looking at the stdlib fopen, etc. code and it only handles fio. I'm wondering 'cause I've been loo...

oh! Is that what it is :-)

I would agree, but it was 64 aligned the whole time. I'm not that dense :-) It could have been only because it was in a class and not global. But 64 aligned in a class didn't work all the time. Considering how it's not an issue that happens all the time, it'd be hard to figure out exactly which one ...

I think I figured it out so keep this post for future reference :-) the padPortOpen's third parameter needs to be in section .bss. Since this may not always happen by accident, the padBuf needs __attribute__ ((section (".bss"))) on it, especially when dealing with classes. Since __attribut...

Assuming this is a graphics something issue, how would I fix it? I switched my code from libIto to gsLib and still have the problem. I put the pad initialization routines before the graphics initialization and still have the problem. I completely removed the graphics manipulation code and still have...

You'd have to convert iif to bmp first. There's a program with libito that converts bmp to iif but I don't know if it goes the other way. It wouldn't be hard to write one yourself though. The format for an iif file is very simple (and I think it's in the ito code if not the docs).

Apart from speed purposes, when is it necessary to align variables in PS2 development? I've been wondering if some of my problems I've been having could be from structures taking memory allocated to others because of some way in which the PS2 handles memory blocks, or just not being able to access t...

Assuming padInit() is successful, what could cause padPortOpen(0,0, padBuf) to fail? If I put my call to my pad initialization function early, it works, but if I put it later, like after the graphics have been initialize, it fails.

I commented out the SifExecModuleBuffer and I get a weird situation. But first, some background. The ExecModule funtion I'm working on searches for the irx file to load (first in SYS-MODULES on the MCs, then host, then if the HDD is initialized, SYS-MODULES on __boot). First it looks for compressed ...

This is a little wierd I think. The following code works: printf("Executing module size=%d\n",size); if (size>0) { module.Close(); char temp2[1025]; sprintf(temp2,"host:%s.irx",filename&#...

The first time I tried casting it didn't work. Later, after getting frustrated enough, I tried again and it did. I seem to be having problems like that: code that worked fine yesterday is now all buggy and when I change a setting in my screen class, the gamepad port won't open (even though they're u...

Well, I know how to get rid of the error (and managed to after a lot of messing with it). It's just changing it all that was a pain in the butt, since all the code had already been written and I was just converting it to C++

Why won't C++ convert between u8 and char like C does? I'm getting errors like crazy here and it's driving me nuts.

I would except I can't handle that low level stuff.

Is it possible to make a homebrew program that can use the USB keyboard or mouse without breaking copyrights by bin2s-ing the usbd.irx or requiring the user to copy that file from a disc of theirs?