OESF | ELSI | pdaXrom | OpenZaurus | Zaurus Themes | Community Links | Ibiblio

IPB

Welcome Guest ( Log In | Register )

3 Pages V  < 1 2 3 >  
Reply to this topicStart new topic
> Quake.. Again, Softfloat !
iamasmith
post Nov 27 2004, 09:20 AM
Post #16





Group: Members
Posts: 1,248
Joined: 6-July 04
Member No.: 3,928



I'm still going down the 2.95 route to see if we can use most of the shared libc in the Sharp ROM.

I have now traced the problems I was experiencing with Quake compiled with libfloat and -msoft-float to the floor() and ceil() functions in use within Quake and some rather dubious casting of floats into doubles. When compiled with softfloat these functions invariably return 0 which is why all textures etc. come out with a zero byte size and why D_SCAlloc complains that it is trying to cache 0 bytes of texture.

I'm now going to see if I can build a static linkable module from a toolchain that carries all the maths functions - this version to be built using -msoft-float and linked against libfloat.

As to my best guess as to why there is such a problem, well I'm now wondering if the format of the float type changes when compiling using soft-float.....hmm.

- Andy
Go to the top of the page
 
+Quote Post
cmisip
post Nov 27 2004, 04:52 PM
Post #17





Group: Members
Posts: 256
Joined: 6-March 04
Member No.: 2,191



I uploaded the instructions on building the toolchain in my web site referenced below. Its on the very bottom of the zaurus section.
Go to the top of the page
 
+Quote Post
cmisip
post Nov 27 2004, 05:01 PM
Post #18





Group: Members
Posts: 256
Joined: 6-March 04
Member No.: 2,191



Maybe someone can help recompile the Qtopia libs so they will be soft float enabled. I will endeavor to do that as well.

This opens up new possibilities for the Z. I dont know how much of the programs currently compiled for the Z use hard FPU. It might be worth recompiling them for soft FPU to improve performance. Mplayer comes to mind.
Go to the top of the page
 
+Quote Post
cmisip
post Nov 27 2004, 06:07 PM
Post #19





Group: Members
Posts: 256
Joined: 6-March 04
Member No.: 2,191



Well, I just found out that Qtopia will not compile with gcc 3.4.x because it has a problem with packed structs. So I am building another toolchain with gcc 3.3.3.
Go to the top of the page
 
+Quote Post
maslovsky
post Nov 28 2004, 05:40 AM
Post #20





Group: Members
Posts: 1,426
Joined: 22-October 03
Member No.: 89



Exellent work you guys are doing! One of the reasons I've tried pdaxrom was to see Quake runnign at playable speed smile.gif Now if you manage to get similar result on Sharp-based ROM that will be great! Looking forward to seeing you suceed.
Go to the top of the page
 
+Quote Post
iamasmith
post Nov 28 2004, 11:25 AM
Post #21





Group: Members
Posts: 1,248
Joined: 6-July 04
Member No.: 3,928



OK, what I have found so far with -msoft-float and libfloat.

1. You don't actually need to copy libfloat up onto your development box if you are using the Embeddix toolchain. try this....

find /opt/Embeddix -name soft-float

it will report a couple of subdirectories containing soft-float enabled versions of library stubs. You may link with gcc using -msoft-float and it will find these stubs without you having to specify -lfloat.

2. Unfortunately the libm.so doesn't seem to handle soft-float compiled binaries properly, at least not all the time. I can compile simple apps with soft-float and the math.h stuff works well. Quake just doesn't, the floor() and ceil() commands that quake uses quite a lot always seem to return 0. - It isn't a format problem with the floating point storage, simple things like printf("%f",myfnum) would fail if that were the case. Not sure (yet) why these functions fail in quake and to be honest even the new version of gdb that I built isn't helping sad.gif

So, cmisip, what sort of frame rate are you getting out of your version of quake with the GCC 3 toolchain ?...

You can time this from the console using timedemo demo1.dem

Oh and BTW: did you try Duke3D again yet smile.gif ?

- Andy
Go to the top of the page
 
+Quote Post
cmisip
post Nov 28 2004, 11:44 AM
Post #22





Group: Members
Posts: 256
Joined: 6-March 04
Member No.: 2,191



Unfortunately I do not have the tilde key on the zaurus keyboard so I cant access the console. Maybe you can modify the quake source so I can access it another way. (You are more qualified to tinker with the quake source than me). I think I am getting at least 25 fps though. It is faster than prboom which probably needs to be recompiled with soft float as well. The quake binary is in the website referenced below on my signature. It should work on your system since libraries are statically linked.

We seem to be taking different routes to the same problem. I am trying to get the libraries and compilers to work with the quake source. You are trying to get the quake source to work with existing compilers and libraries.

My biggest stumbling block right now is that I cant seem to build libqpe. Following the readme.html that came with the free version of qt embedded, it only built libqte. I am still trying to figure this out. I think I pretty much know how to compile libsdl and quake once I get that library built. If you have tips regarding the building of libpqe let me know.

As far as duke nukem 3d, I was able to at least get rid of the problem with all the sound being played back sequentially when you start the game. Its a hack though, If I remember correctly, I just disabled the loading of sound data greater than a certain size. I think its a memory issue. I have not looked at the source for a while. Maybe you can take that on as well. I do not have any programming background. I just slept at a holiday inn.

smile.gif
Go to the top of the page
 
+Quote Post
iamasmith
post Nov 28 2004, 11:59 AM
Post #23





Group: Members
Posts: 1,248
Joined: 6-July 04
Member No.: 3,928



You can get the console up through the options menu... if you are working on the same source..

.. Oh, you can change the console binding by editing id1/config.cfg, just look for the line that says bind "`" "toggleconsole".

BTW: If I try your precompiled version I get...

$ runquake.sh
Cvar_RegisterVariable: crosshair is a command
Added packfile /mnt/card/quake/id1/pak0.pak (339 files)
Added packfile /mnt/card/quake/id1/pak1.pak (85 files)
PackFile: /mnt/card/quake/id1/pak1.pak : gfx/pop.lmp
Playing registered version.
PackFile: /mnt/card/quake/id1/pak0.pak : gfx.wad
Console initialized.
UDP Initialized
Exe: 23:14:14 Nov 26 2004
8.0 megabyte heap
PackFile: /mnt/card/quake/id1/pak0.pak : gfx/palette.lmp
PackFile: /mnt/card/quake/id1/pak0.pak : gfx/colormap.lmp
Error: VID: Couldn't load SDL: Unable to open a console terminal
$

Andy
Go to the top of the page
 
+Quote Post
cmisip
post Nov 28 2004, 12:57 PM
Post #24





Group: Members
Posts: 256
Joined: 6-March 04
Member No.: 2,191



you must run it as root.
Go to the top of the page
 
+Quote Post
cmisip
post Nov 28 2004, 01:00 PM
Post #25





Group: Members
Posts: 256
Joined: 6-March 04
Member No.: 2,191



Can you clear up something for me? I know libqte is built using qt-embedded. Is libqpe built using qtopia-free-1.X? Is qpe-1.X just an earlier version of qtopia-free-1.x.

I have decided to try qt-embedded-2.3.3 with qpe-1.4.

What is the version running on the sharp rom?

Thanks.
Go to the top of the page
 
+Quote Post
cmisip
post Nov 28 2004, 01:09 PM
Post #26





Group: Members
Posts: 256
Joined: 6-March 04
Member No.: 2,191



I managed to run timedemo demo1.dem and it showed 18.8 fps at 320 x 200

It felt like it was faster than that though.
Go to the top of the page
 
+Quote Post
iamasmith
post Nov 28 2004, 01:20 PM
Post #27





Group: Members
Posts: 1,248
Joined: 6-July 04
Member No.: 3,928



Sorry don't know about the libqpe stuff.

BTW: Got the binary running, actually had to boot out of Qtopia to a plain old shell before I could see anything - I guess this figures, you build SDL without Qtopia right ?

It runs upside down on an 860... hey that's easily fixable and runs about 12.5fps with no overclocking but I can't believe that. It seems SO much faster than the PDAXROM version.... I really don't know what's going on here.

Anyway, it's given me some motivation to see what results I can get out of a 2.95.2 version.... although I'm getting to the point of wondering if it would actually be better to build a softfloat enabled uclibc and statically link against that.

I may try the GCC 3 route again soon, I'm wondering if the ELF headers of the .o files can be simply tweaked to allow linkage against non soft-float stuff.

Have you played with readelf ? does it show you anything different on your objects ?

- Andy
Go to the top of the page
 
+Quote Post
cmisip
post Nov 28 2004, 02:01 PM
Post #28





Group: Members
Posts: 256
Joined: 6-March 04
Member No.: 2,191



The statically linked SDL was compiled without qtopia.
That is why I am trying to build libqte and libqpe with soft-float.

I think I got libqte built right but libqpe is problematic.



How do you fix the fact that it is upside down?

You are getting only 12.5 fps. Are you running at a higher resolution?

I dont know anything about readelf or uclibc.

In the future, I might build a toolchain based on xscale. It will be with gcc 3.4.X. Maybe we canget higher frame rates with xscale optimization.

But right now, libqpe first.
Go to the top of the page
 
+Quote Post
iamasmith
post Nov 28 2004, 02:26 PM
Post #29





Group: Members
Posts: 1,248
Joined: 6-July 04
Member No.: 3,928



QUOTE(cmisip @ Nov 28 2004, 10:01 PM)
The statically linked SDL was compiled without qtopia.
That is why I am trying to build libqte and libqpe with soft-float.

I think I got libqte built right but libqpe is problematic.



How do you fix the fact that it is upside down?

You are getting only 12.5 fps.  Are you running at a higher resolution?

I dont know anything about readelf or uclibc.

In the future, I might build a toolchain based on xscale.  It will be with gcc 3.4.X.  Maybe we canget higher frame rates with xscale optimization.

But right now, libqpe first.

If you check out the zport SDL cvs you can find code that gets the rotation right for various different models.

My command line is set to 320x240, however, because I'm running from the console the frame buffer is probably set to 640x480 causing quake to run quad pixel blocks so that may account for the drop in frame rate. When running under Qtopia I can tell Qtopia to scale to 320x240, may make up the frame rate by doing that.

I found the cause of the math.h/libm proble rolleyes.gif.. take this sample...

mathtest.h....

#include <stdio.h>
#include <math.h>

float module1();
float module2();

module1.c...

float module1()
{
float f1,f2;
f1=3.14159;
f1/=1.23456;
f2=floot(f1);
return f2;
}

module2.c.....

#include "mathtest.h"

float module2()
{
float f1,f2;
f1=3.14159;
f1/=1.23456;
f2=floor(f1);
return f2;
}

test.c....

#include "mathtest.h"

main()
{
printf("%f\n",module1());
printf("%f\n",module2());
}


...now first compile with...

arm-linux-gcc -o module1.o -c module1.c
arm-linux-gcc -o module2.o -c module2.c -msoft-float
arm-linux-gcc -o test.o -c test.c -msoft-float
arm-linux-gcc -o test test.o module1.o module2.o libfloat.a -lm

(I made a static link version of libfloat).

Results when you run test on the Z...

0
0

Now recompile as follows...

arm-linux-gcc -o module1.o -c module1.c
arm-linux-gcc -o module2.o -c module2.c -msoft-float
arm-linux-gcc -o test.o -c test.c
arm-linux-gcc -o test test.o module1.o module2.o libfloat.a -lm

And results are...

2
2

Excellent it works, now why ????

I'm pretty sure now that if you link the main() module in your executable as soft-float it removes the exception handler that normally sits on SIGFPE which is what is normally used to handle the unimplemented FP opcodes. Since the libm library is linked with hard floating point this is why the library is failing.

Now, unfortunately, libSDL throws a spanner in the works. You start up with SDL_main rather than main() and I have tried SDL build with both FPE and soft-float... both barf.

So I now need to find out why SDL is linking with FPE unhooked from the SIGFPE handler.

Anyway, I'm a much happier bunny now I now the cause of the problem !
Go to the top of the page
 
+Quote Post
iamasmith
post Nov 29 2004, 07:16 AM
Post #30





Group: Members
Posts: 1,248
Joined: 6-July 04
Member No.: 3,928



OK, now I know that the Netwinder FPE is not kicking in when using modules with the main() function compiled for -msoft-float I thought that I would look at what may be happening with SIGFPE.

Firstly I patched the SDL_Parachute install routines which normally install handlers where SIG_DEF are installed so that it definitely wouldn't touch SIGFPE... no luck. Well I didn't expect this to be the root cause of the problem so I thought that it may be possible to re-vector the signal handler for SIGFPE within a Soft float binary such that the Netwinder FPE (in the kernel) kicked in.

So, (please take a look at my previous example in the last post), I created another test.

#include <signal.h>
#include <stdio.h>

main()
{
void *t;
t=signal(SIGFPE,SIG_DFL);
signal(SIGFPE,t);
printf("%08X\n",t);
}

This should very simply print out the hex ID of any handler installed on SIGFPE, this was compiled with FPE and with soft-float.

BOTH returned 00000000 !

It is now my guess that the vectoring of the FPE is somehow handled by the ELF loader dependent upon flags in the ELF headers of the executable (probably on _main) and that the vectoring is done silently such that SIG_DFL is returned.

Anyone know much about ELF headers.

objdump and readelf don't seem to reveal much.

- Andy
Go to the top of the page
 
+Quote Post

3 Pages V  < 1 2 3 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 24th November 2014 - 08:29 AM