Call for help: Quad-Ren cross platform testing.


hessiess

Member
Joined
Apr 26, 2008
Messages
219
QR *Should* be platform independent as it only uses cross-platform libraries, however I have only tested it on Linux, and when benjymous tried to compile it with MSVC (thread on the other forum, unfortunately not assessable right now) the engine was crashing in the libpng code, which suggests that ether there was something wrong with the Libpng build, or that I am using it in a way which only works on Linux.

Because of this I am looking for people to compile the lib on whatever OS you are using, and report any problems you have with it.

The source code is available from http://quad-ren.sourceforge.net

I am also looking for someone to port the renderer to OGL ES 2.0, this shouldn't be too difficult but it will require a texturing shader which supports alpha transparency.
 
OK, I'm going to observe every little detail.
First of all, the SVN seems to be out of date, I'm taking the quad-ren-0.4 release here.

Fedora 11; gcc (GCC) 4.4.0 20090427 (Red Hat 4.4.0-3); Linux 2.6.29.1-111.fc11.x86_64

configure: not checking for SDL_* dependencies (but maybe I'm too used to cmake and forget that autotools doesn't do this?)
src/qrdd_file_handler.cpp: missing an "#include <stdint.h>"
Makefile: doesn't install the libquad-ren.so.0 file correctly on 64-bit to /usr/lib64, but instead to /usr/lib

Exampleapp 1: Seems to be working, but I haven't got a checklist to go by :p
Exampleapp 2: Yep, check.
Exampleapp 3: Works, but the flame animation speed seems to depend on FPS, but this can't be when looking at the source code :p

Jolly good work, I didn't find much to complain about :p

(and I probably should have tested this on a non-Linux platform shouldn't I)
 
dflemstr said:
OK, I'm going to observe every little detail.
First of all, the SVN seems to be out of date, I'm taking the quad-ren-0.4 release here.
The qr_0.2 branch is the current development version, I just haven't bean creating new branches for each new version, it should rilly be called qr_0.2* ;)

Fedora 11; gcc (GCC) 4.4.0 20090427 (Red Hat 4.4.0-3); Linux 2.6.29.1-111.fc11.x86_64

configure: not checking for SDL_* dependencies (but maybe I'm too used to cmake and forget that autotools doesn't do this?)
Makefile: doesn't install the libquad-ren.so.0 file correctly on 64-bit to /usr/lib64, but instead to /usr/lib
To be honest the build system was kind of ``hacked together quickly', Have you got any tips on how to fix these problems?

src/qrdd_file_handler.cpp: missing an "#include <stdint.h>"
Thanks, fixed ;)

Exampleapp 1: Seems to be working, but I haven't got a checklist to go by :p
Exampleapp 2: Yep, check.
Exampleapp 3: Works, but the flame animation speed seems to depend on FPS, but this can't be when looking at the source code :p

Jolly good work, I didn't find much to complain about :p

(and I probably should have tested this on a non-Linux platform shouldn't I)
Yes, I am more interested in finding out what was wrong on Win32 and seeing if it works on OSX, but thanks for pointing out those few problems.
 
Last edited by a moderator:
During my trials and tribulations with SDL, I noticed that libpng in linux would handle missing files much more nicely than on Win32. More than likely your crashyness on win32 platforms is because of something retarded like incorrect path translation from linux to win32.
 
As far as I am aware the problem was occurring with one of the example apps, The files in these are all referenced using relative filenames, maby using / instead of \ was causing the problem, however this is strange as the custom QRDD loader was working, and all of the files referenced with this also uses relative file names separated with `/'.
 
Hessiess said:
Fedora 11; gcc (GCC) 4.4.0 20090427 (Red Hat 4.4.0-3); Linux 2.6.29.1-111.fc11.x86_64

configure: not checking for SDL_* dependencies (but maybe I'm too used to cmake and forget that autotools doesn't do this?)
Makefile: doesn't install the libquad-ren.so.0 file correctly on 64-bit to /usr/lib64, but instead to /usr/lib
To be honest the build system was kind of ``hacked together quickly', Have you got any tips on how to fix these problems?

1. For the dependencies, use PKG_CHECK_MODULES(....) in your configure.ac. There's plenty of documentation for that online.
2. Remove the line "libdir=..." in your "Makefile.am", and run "./configure" again.
 
Last edited by a moderator:
2. Remove the line "libdir=..." in your "Makefile.am", and run "./configure" again.
That is there as auto tools was insisting on putting it in /usr/local/lib/, which isnt in the path
on Arch.
 
Hessiess said:
2. Remove the line "libdir=..." in your "Makefile.am", and run "./configure" again.
That is there as auto tools was insisting on putting it in /usr/local/lib/, which isnt in the path
on Arch.
That's really weird, as autotools does the "right" thing on Ubuntu and Fedora (as far as I have tested it), but /usr/local/lib/ actually make sense when you think about it... As long as you haven't packaged your library, the distro is actually SUPPOSED to put it in /usr/local/ as a local package.
If I were you, I'd just add that path to your library path, or mark your lib for packaging.

If you don't want to, then please look at this documentation: http://sources.redhat.com/automake/auto ... nditionals
(You can basically check if your platform is Arch and make an exception)
 
Back
Top