Quad-Ren package.

Question

Hi, I am the developer of the Quad-Ren graphics engine(www.quad-ren.sourceforge.net), A resolution independent 2D graphics engine designed to work with tiling WM's.
Recently I tried to upload a PKGBUILD for the lib, only to find out that someone else had already uploaded one, I don't mind someone besides me maintaining the package, but the uploaded PKGBUILD is both out of date and doesn't install the PNG->QRDD compiler. Here is my origonal PKGBUILD which does not have these problems.
# Contributor: Robert Hickman hessiess^at)hessiess[dot>com
pkgname=quad-ren
pkgver=0.3
pkgrel=0
pkgdesc="Quad-Ren is a resolution independent 2D graphics engine that aims to ease the
development of bitmap-based applications, primarily games. Applications using
Quad-Ren will function the same regardless of screen resolution or aspect ratio.
Quad-Ren is programmed in, and usable from C++, with a simple object-oriented API
and a small, well documented, easy to edit code base.
This package contains the runtime library, header files and support applications
needed to develop applications with Quad-Ren."
arch=('i686' 'x86_64')
url="http://quad-ren.sourceforge.net/"
license=('LGPL')
depends=('libpng' 'mesa' 'sdl')
makedepends=('gcc' 'make' 'pkgconfig')
makedepends=('automake' 'autoconf' 'libtool')
source=(http://heanet.dl.sourceforge.net/sourceforge/quad-ren/quad-ren-$pkgver.tar.gz)
build() {
#build the sheared lib
cd "$srcdir/quad-ren-$pkgver"
./configure --prefix=/usr \
--sysconfdir=/etc \
--localstatedir=/var \
--disable-static
make || return 1
make DESTDIR="$pkgdir" install || return 1
#build the support application(s)
cd support_apps
make
mkdir "$pkgdir/usr/bin/"
mv ./png_qrdd_conv "$pkgdir/usr/bin/"
Also, I don't recommend using SVN builds of the lib, unless you are interesed in developing the engine. I frequantly upload uncompleted code which may or may not compile or segfault at runtime.

Answer 1

Hi Ian,
What you are pointing out is an error in the footprint-to-symbol mapping for the component LM3301. If you were creating a custom component such as the LM3301N what you would want to do is have each of the quad packages to be tied to footprint pins 7 and 14 (which is what I believe made logical sense to you in the first place).
The reason that everything works out with the netlist in Multisim/Ultiboard despite this error is due to those symbol-pin designation of COM (common) which I described earlier. In later stages of the model creation (such as footprint-to-symbol mapping), the COM designation by default changes the other common pins to have the same footprint mapping as the first one that is defined. So in the footprint mapping page, once the VS1+, VS1- were assigned to 7 and 14, VS2+, VS3+ and VS4+ are automatically assigned to the same thing by Multisim once components are placed onto a schematic (regardless of what is written in the footrpint-to-symbol map). So essentially the error is automatically overwritten.
When you are designing any components you will want to avoid this issue by just assigning the symbol pins to the footprint pins as they should be (i.e. all VS+ to 7 and VS- to 14). If you need any further assistance in creating components please check out the following tutorial: http://zone.ni.com/devzone/conceptd.nsf/webmain/897FBC1CA3296F088625712B0034BEE9.
I hope this clears any confusion.
Thanks
Bhavesh