forums.ps2dev.org

Check http://www.lukasz.dk for news
Check http://cvs.ps2dev.org/libito for code

This thread for comments and words of wisdom :)

Lukasz

Very interesting, congrats lkz...

trying it!!!

lukasz - silly question (im still getting over some of the bumps in the road of using linux on vmware)

I tried to "make all" this (or even just "make build-tools") and I am getting the following error: what version of gcc should this compile ok on - it doesnt seem to want to work with gcc 3.3.5 (main.cpp, exoquant.c, swizzle.cpp are all trying to compile with gcc not iop/ee gcc -- it looks like a tool that is correct)

After poking about a little I also note that strupr is not present in ./usr/include/string.h

as well as this:
http://gcc.gnu.org/ml/gcc-help/2002-08/msg00199.html (my man pages dont have any listing for strupr btw)

Definitely nice to see libito in the cvs! (even if it means I may have to go back to cygwin, btw does cygwin list anything for "man strupr")

edit: crossing my fingers that installing the xmingw gcc and libs will help.

Hi Lukasz,

I just saw in fpumath.cpp that you rewrite both sin() and cos() function ?

can I ask you why ? for performance reason ? about float .. ?? why don't you use the one from libc ?

cory1492 wrote: I tried to "make all" this (or even just "make build-tools") and I am getting the following error:

Code: Select all

loadimage.cpp:84: error 'strupr' undeclared (first use in this function)

No libc does not have strupr, a simple strupr for *nix is easy though.

char *
strupr(char *str) {
char *p = str;
for (; *p != NULL; p++) {
*p = toupper(*p);
}
return str;
}

ifdef that out for win32 and you should be all set.

evilo wrote:Hi Lukasz,

I just saw in fpumath.cpp that you rewrite both sin() and cos() function ?

can I ask you why ? for performance reason ? about float .. ?? why don't you use the one from libc ?

I guess it is to avoid doublemath, otherwise his functions doesnt seem to be that fast, but most likely faster than libc's anyway since they try to maintain precision that isnt really necessary for displaying purposes.

Before reading bd's reply, I commited a fix for the strupr function, so just update from cvs.

Some people have been having trouble compiling the lib in Windows, just compile within Cygwin and you will avoid problems compiling the lib aswell as other ps2 projects. Check out http://forums.ps2dev.org/viewtopic.php?t=920 if you need some help.

As for sin and cos and possible stuff which is available elsewhere, I just like to keep things small and simple, linking with newlib just to get sin and cos is a little overkill in my opinion, just a personal preference.

For further questions, just PM my spokesperson blackdroid, he also has a discount on kebabs this week, dont miss it ;)

Dont miss next weeks special on blueberry pierogies.

I just grab this from CVS and build it and Iam getting an error, it runs for a good 2-3 minutes then craps out at:

obj/Vu0MathAsm_MacroSinCos.o obj/Vu0MathAsm_VpuReset.o
ee-ar: /usr/local/ps2dev/libito/lib/libito.a: No such file or directory
make[1]: *** [/usr/local/ps2dev/libito/lib/libito.a] Error 1
make[1]: Leaving directory `/usr/local/ps2dev/libito/source'
make: *** [build-ito] Error 2

I can't find the file libito.a anywheres or I would just change the path.


Any ideas?

bbchazz wrote:I just grab this from CVS and build it and Iam getting an error, it runs for a good 2-3 minutes then craps out at:

obj/Vu0MathAsm_MacroSinCos.o obj/Vu0MathAsm_VpuReset.o
ee-ar: /usr/local/ps2dev/libito/lib/libito.a: No such file or directory
make[1]: *** [/usr/local/ps2dev/libito/lib/libito.a] Error 1
make[1]: Leaving directory `/usr/local/ps2dev/libito/source'
make: *** [build-ito] Error 2

I can't find the file libito.a anywheres or I would just change the path.


Any ideas?

I tried to replicate this error and the only way I could make it happen was if the lib directory in your case /usr/local/ps2dev/libito/lib/ did not exist.

If this is the note the case, please paste the first part of the last command which will start with "ee-ar rcs .."

Ive commited a fix which now creates the lib directory if it did not exist, so just update from cvs.

Thanks for fixing the strupr Lukasz, as well as for the *nix function up above blackdroid. Will recheckout as soon as I get my *nix in order again (rebuilt it)

Looks very nice. I've only had time to compile the samples so far, but I'm very impressed. I'll make my next demo with the baby :)

Nice work LKZ

Looks like you used strupr in a few places lukasz (saveiif.cpp line 592)

Im going to include the above function for now in my build and see if that works out ok - maybe strupr() could be included in ps2dev, even though it is win based it is still kinda handy to use (simpler than toupper in any case)

ok, that worked OK, except the warning about the null...

what environment do these tools build under? I see it trying to load a stdio.h that isnt correct under *nix nor in the ps2sdk... line 385 is this in my (not ee-) include dir: arrgh, wonder if I even need the tools

you need stdio.h which is "standard I/O" library for C from your *nix enviroment, if you dont even have this working, there isnt much of a chance you will get my code working :)

I developed the code under cygwin.

Lukasz wrote:you need stdio.h which is "standard I/O" library for C from your *nix enviroment, if you dont even have this working, there isnt much of a chance you will get my code working :)

I developed the code under cygwin.

Why do you assume that all PS2 devers will have any *nix environment, if even just cygwin style ? For a Windows user it is much more natural to install the PS2Dev gcc and PS2SDK without using any parts of cygwin other than the main dll (which comes as part of the package). This is what I use myself, and it has worked fine for some projects. But obviously, it will fail for sources that assume the presence of header files missing from PS2SDK, or from the main PS2Dev compiler package.

Surely it can't be all that hard to add the necessary stuff to headers in the PS2SDK, thus making it independent of other environments.

Best regards: dlanor

his tools is pc side, why should he depend on PS2SDK headers ?
the source is in cvs, if you want to add WIN32 ifdef's around it, send him a patch.

had a chance to look at that alpha blending stuff yet lkz? ;)

's ok, now I have a working cygwin sdk and it does compile fine... still working on figuring out why the compile under gentoo wont finish the tools, but hey - my cygwin is working right for a change (backed it up just in case too)

Raizor wrote:had a chance to look at that alpha blending stuff yet lkz? ;)

I forgot, I told you to bug me sunday :)

I will have at look at it monday/tuesday, unfortunately I wont have time to hunt down the problem before then.

no problem matey. I was too ill on sunday to be doing any bugging :p

thanks

raiz

i tried to compile libito on macosx.

1st prob. exoquant.c:27:20: malloc.h: No such file or directory

easily fixed for everyone:
#include <stdlib.h>
#ifdef HAVE_MALLOC_H
#include <malloc.h>
#endif

2nd prob. saveiif.cpp:592: error: `strupr' undeclared (first use this function)

I've got the head revision of libito and there's no strupr? It's quicker
to write than report... perhaps it can be included?

3rd prob. ld: Undefined symbols: ___gxx_personality_v0

Fixed by using g++ instead of gcc

4th prob. Error: "fire_clut.bmp" is not a valid BMP file.

Argh lots of endian fixes needed. Anyone patched their version?

rinco wrote:i tried to compile libito on macosx.

1st prob. exoquant.c:27:20: malloc.h: No such file or directory

easily fixed for everyone:
#include <stdlib.h>
#ifdef HAVE_MALLOC_H
#include <malloc.h>
#endif

2nd prob. saveiif.cpp:592: error: `strupr' undeclared (first use this function)

I've got the head revision of libito and there's no strupr? It's quicker
to write than report... perhaps it can be included?

3rd prob. ld: Undefined symbols: ___gxx_personality_v0

Fixed by using g++ instead of gcc

4th prob. Error: "fire_clut.bmp" is not a valid BMP file.

Argh lots of endian fixes needed. Anyone patched their version?

Hey rinco, thanks for the bug report and solutions, Ive commited your fixes for problem 1 and 3. Looks like I missed a strupr when replacing it with my own custom function, now fixed :)

As for problem 4, this is a quite serious problem and I will look into fixing it this weekend. If you are around on IRC this weekend, I would appriciate it if you could help test.

I'm really stuck. I am trying to compile a pad program from the thread http://forums.ps2dev.org/viewtopic.php?t=798 .

First error was couldn't find gsDefs.h, etc., I found the include files in libito. I cvs checkout libito and compiled it. No errors and I can compile the samples.

I used libito sample Makefile as a guide to the Makefile for the pad program.

EE_BIN = padtst.elf
EE_OBJS = padtst.o

all: $(EE_BIN)

include $(LIBITO)/Makefile.prefab

I get the following errors:

In file included from padtst.c:1:
/usr/local/ps2dev/ps2sdk/common/include/tamtypes.h:65: syntax error before "u8"
/usr/local/ps2dev/ps2sdk/common/include/tamtypes.h:66: syntax error before "u16"

/usr/local/ps2dev/ps2sdk/common/include/tamtypes.h:67: syntax error before "u32"

Plus many more errors.

Never mind; I incorrectly named the source file padtst.c instead of padtst.cpp. That and it turns out the gsDefs.h is also in the library gslib. I installed gslib and after many errors getting the makefiles and make variables sorted out I got a running padtst that works great. On the one hand it would be nice if everything from ps2dev worked consistently. Realizing that the different libs and install procedures were written at different times by different people explains why this is not true. On the other hand it is a 'trial by fire' getting everything sorted out and what point would there be putting these kinds of tools in the hands of someone too inexperienced to survive the initial 'learning curve'.

Hi

I downloaded the latest version of ITO but got compiler errors when compiling the tools. I tracked the error down to the line of "types.h" and got everything working again when renaming dprintf to dprintf2 (and all referenses to this function) :)
I use "gcc (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)", maybe a global type with the name dprint is already declared in this version of gcc.

/Viktor

cory1492 wrote: what environment do these tools build under? I see it trying to load a stdio.h that isnt correct under *nix nor in the ps2sdk...

Code: Select all

gcc -c loadbmp.cpp -o loadbmp.o
In file included from loadbmp.cpp:3:
/usr/include/stdio.h:385:  error: parse error before 'do'
make[2]: *** [loadbmp.o] Error 1
leaving dir
make[1]: ***[_dir_iit] Error 2
leaving dir
make: *** [build-tools] Error 2

Is there anything that can be done about this problem other than running cygwin? I'm using Linux and GCC 3.2.2. If you run cygwin, are you not running the same version of GCC?

Cheers.

What does this lib do? The news site you link to has no mention of it.

-Edit- Heh just noticed how old the last post was.