cells-devel

cells-devel@common-lisp.net

567 discussions

[cells-devel] X11 conflict building ImageMagick
by Kenneth Tilton 19 Oct '04

19 Oct '04

I took all the defaults building ImageMagick via Fink Commander. It got upset because: Unpacking xfree86 (from .../xfree86_4.3.99.16-2_darwin-powerpc.deb) ... WARNING: if you compile X11 applications against this XFree86 release, you will *not* be able to run them if you decide to revert to Apple's X11 provided with Panther. You have an existing X11 installation in /usr/X11R6 and/or /etc/X11. This package refuses to overwrite these. Remove them, then tell Fink to install xfree86 again. (The package won't be recompiled.) If you want to keep your X11 installation, install system-xfree86 resp. system-xtools instead to make this known to Fink's package system. Press Return to continue. dpkg: error processing /sw/fink/dists/stable/main/binary-darwin-powerpc/x11-system/ xfree86_4.3.99.16-2_darwin-powerpc.deb (--install): subprocess pre-installation script returned error exit status 1 Unpacking xfree86-shlibs (from .../xfree86-shlibs_4.3.99.16-2_darwin-powerpc.deb) ... You have an existing X11 installation in /usr/X11R6/lib. This package refuses to overwrite these. Remove them, then tell Fink to install xfree86-shlibs again. (The package won't be recompiled.) -------------------------------- Well, at least the messages are detailed and try to be helpful. But I am left with a number of questions. Jeez. I have to throw out one X11 installation to install xfree86? Well, the first error above says I can "install system-xfree86 resp. system-xtools", but the second error says X11 must be removed. Now my guess would be to stick with Apple's own X11. Should I override the default when the ImageMagick build asks if I want to build the xfree86 dependency? If not, should I remove X11, or install system-xfree86? If the latter, what the hell does "resp. system-xtools" mean, and what made them think they could not spell out the word beginning "resp.". :) I am assuming the second error message was faulty in saying X11 had to be removed, and that the system-xfree86 install will clear that conflict as well. kt

4 4

[cells-devel] Cello updates and... OS X or Bust!!!!
by Kenny Tilton 19 Oct '04

19 Oct '04

Just updated CVS with a long-needed refactoring of the key layout class hierarchy under IX-INLINE. Also added a new shape to the fancy Cello demo, the simple nurbs shape in the OpenGL Red Book. It turned out to be quite a poser because of my use of display lists. Kind of a gap in the OpenGL doc, but I got lucky and figured out what was going on. Turns out it is a frequent gotcha. Anyway, my once silent laptop now never shuts up, so it may be time to get a four-fan Mac desktop and start working there. I cannot tolerate Windows XP much longer anyway, as little as I interact with it. Gotta use my developer discount by November, too. And since I am starting on an educational software project, OS X compatibility is a little more urgent than would otherwise be the case. So whoop-dee-doo, Cello heads for OS X! kenny -- Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

4 6

[cells-devel] Emailing: fgc.def, FTGLFromC.cpp
by Kenny Tilton 18 Oct '04

18 Oct '04

OK, I just got my groovy Apple flat-panel monitor today and learned my G5 has shipped, due here Friday. I am taking a break from the joys of PowerBuilder to re-execute the port to Lispworks on win32. That usually flushes a couple of FFI differences, and I would rather get those resolved before attempting the LW+OSX port. The good news for others is that this will force me to make sure an ASDF build works, if only via Thomas Burdicks cool ASDF-ACLPROJ work. Meanwhile, attached is the glue code for FTGL should anyone get that far. (There is a copy of the cpp file in the CVS tree, but it is not current.) The .def file is necessary for VC6 to set up DLLs so apps can find the entry points. I do not know if such a beast is necessary for .SO files. kt DESCRIPTION 'C Interface to FTGL' VERSION 0.1 EXPORTS fgcSetFaceSize fgcCharTexture fgcStringX fgcAscender fgcDescender fgcStringAdvance fgcRender fgcFree fgcBitmapMake fgcPixmapMake fgcTextureMake fgcPolygonMake fgcOutlineMake fgcExtrudedMake fgcSetFaceDepth fgcBuildGlyphs #include <assert.h> /* ;;; ;;; Copyright © 2004 by Kenneth William Tilton. ;;; ;;; Permission is hereby granted, free of charge, to any person obtaining a copy ;;; of this software and associated documentation files (the "Software"), to deal ;;; in the Software without restriction, including without limitation the rights ;;; to use, copy, modify, merge, publish, distribute, sublicense, and/or sell ;;; copies of the Software, and to permit persons to whom the Software is furnished ;;; to do so, subject to the following conditions: ;;; ;;; The above copyright notice and this permission notice shall be included in ;;; all copies or substantial portions of the Software. ;;; ;;; THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR ;;; IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, ;;; FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE ;;; AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER ;;; LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING ;;; FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS ;;; IN THE SOFTWARE. */ #include "FTGLBitmapFont.h" #include "FTBitmapGlyph.h" #include "FTGLPixmapFont.h" #include "FTPixmapGlyph.h" #include "FTGLTextureFont.h" #include "FTTextureGlyph.h" #include "FTGlyphContainer.h" #include "FTBBox.h" #include "FTGLPolygonFont.h" #include "FTPolyGlyph.h" #include "FTGLOutlineFont.h" #include "FTOutlineGlyph.h" #include "FTGLExtrdFont.h" #include "FTExtrdGlyph.h" extern "C" { void __stdcall fgcBuildGlyphs( FTFont* f ) { f->BuildGlyphs(); } bool __stdcall fgcSetFaceSize( FTFont* f , unsigned int faceSize , unsigned int res ) { return f->FaceSize( faceSize, res ); } float __stdcall fgcAscender( FTFont* f ) { return f->Ascender( ); } float __stdcall fgcDescender( FTFont* f ) { return f->Descender( ); } float __stdcall fgcStringAdvance( FTFont* f, const char* string ) { return f->Advance( string ); } int __stdcall fgcCharTexture( FTFont* f, int chr ) { return ((FTGlyph *) f->FontGlyph( chr ))->glRendering(); //return f->GlyphRendering( chr ); } /* void FTFont::DoRender( const unsigned int chr, const unsigned int nextChr) { CheckGlyph( chr); FTPoint kernAdvance = glyphList->Render( chr, nextChr, pen); pen.x += kernAdvance.x; pen.y += kernAdvance.y; }*/ float __stdcall fgcStringX( FTFont* f, const char* string ) { float llx,lly,llz,urx,ury,urz; f->BBox( string, llx, lly, llz, urx, ury, urz ); return llx; } void __stdcall fgcRender( FTFont* f, const char *string ) { f->Render( string ); } void __stdcall fgcFree( FTFont* f ) { delete f; } //--------- Bitmap ---------------------------------------------- FTGLBitmapFont* __stdcall fgcBitmapMake( const char* fontname ) { return new FTGLBitmapFont( fontname ); } //--------- Pixmap ---------------------------------------------- FTGLPixmapFont* __stdcall fgcPixmapMake( const char* fontname ) { return new FTGLPixmapFont( fontname ); } //--------- Texture ---------------------------------------------- FTGLTextureFont* __stdcall fgcTextureMake( const char* fontname ) { return new FTGLTextureFont( fontname ); } //--------- Polygon ---------------------------------------------- FTGLPolygonFont* __stdcall fgcPolygonMake( const char* fontname ) { return new FTGLPolygonFont( fontname ); } //--------- Outline ---------------------------------------------- FTGLOutlineFont* __stdcall fgcOutlineMake( const char* fontname ) { return new FTGLOutlineFont( fontname ); } //--------- Extruded Polygon ------------------------------------- FTGLExtrdFont* __stdcall fgcExtrudedMake( const char* fontname ) { return new FTGLExtrdFont( fontname ); } bool __stdcall fgcSetFaceDepth( FTGLExtrdFont* f , float depth ) { f->Depth( depth ); return true; } }

1 0

[cells-devel] Building (and patching) FTGL
by Kenneth Tilton 18 Oct '04

18 Oct '04

On Oct 18, 2004, at 10:18 AM, Mark Sapa wrote: > Ehhhm... As to the Project Builder stuff: I am completely naive to PB, > but at the moment > I am trying to get FTGL to work. First, it seems I have to install > cppunit for that... :( > > So far my approach to adding the includes and the library has been to > select libftgl.a > in the "Targets" Group, selecting the editor tool, selecting "Search > Paths" and then doing > the obvious thing in the Headers, Libraries, etc. subcategories. > Fantastic, it worked. And using Project Builder, which helps because I have never spent much time on Unix/Linux and I hope to avoid mastering all that as long as possible. > The funk seems to be that the Project file is expecting the header > file names to be all > UPPERCASE with _subscores_ as in > >> #include FT_GLYPH_H > > where in my /sw/lib/freetype2/include/freetype2/freetype/ > there is a ftglyph.h. > > Maybe if someone was diligent enough to fix all this... ;-) I see that funny #include, but the build error I was getting mentioned "ft2build.h" and once I added a path to that and another path to the slightly deeper freetype2 directory project builder was able to build everything. btw, I mentioned to Frank a fix to FTGL which apparently is still in testing in an upcoming FTGL 2.1. Here it is. In FTTextureGlyph.cpp, in the Render method, modify the first few lines to look like this: float FTTextureGlyph::Render( const FTPoint& pen) { //glGetIntegerv( GL_TEXTURE_2D_BINDING_EXT, &activeTextureID); //if( activeTextureID != glTextureID) //{ glBindTexture( GL_TEXTURE_2D, (GLuint)glTextureID); //} ...etc.... The original tried to avoid binding the texture if it was already the bound texture, but when one builds a display list this cannot work, because all the glGet calls run immediately instead of being added to the display list. But the glBindTexture call just gets compiled and does not execute. So glget in this case just returns whatever texture happens to be bound during the display list compilation (rather random, that). Besides, display lists just include opengl calls, so there is no way to build a display list which branches conditionally based on runtime values. A better fix might be to have the application keep track of the last texture bound during display list compilation, but the FTGL author just went for always binding the texture. My guess is there is no cost if one happens to be rebinding the same texture. Meanwhile, Doh! I just remembered I have to add my FTGLFromC.cpp suite of glue routines to FTGL so Lisp can talk to FTGL in "C". This could be a little trickier because we also have to publish the new entry points. kenny

1 0

[cells-devel] Cello fixes for FTGL <whew!>
by Kenny Tilton 29 Sep '04

29 Sep '04

CVS willing (I have my doubts), Cells and Cello have now been updated with changes to resolve some deadly problems with FTGL when combined with display lists. The Cells change had to do with enhancing the "lazy" option to be more of a code than a flag: one now has options :once-asked, :until-asked, and :always (alias t). Aside: I was surprised to see I had done this originally as an option on a formula for a slot. Seems to me it should be a slot option. ie, that when one needs lazy it will because the slot itself needs that behavior, no matter what the formula. So we'll put a "watch" on this design decision,which I left as is for now. making display list calculation lazy (until asked) solved the problem with extruded fonts. Texture fonts were fixed by hacking FTGL in ways which turned out to be in testing already for FTGL v2.1 -- ie, I ran into this at the same time as others and happened to come up with the same fix. The problem was pretty subtle, so I will spare you all unless someone asks for the deets. Pretty much just a deep issue with display list generation. Anyway, it now seems as if FTGL is back under control. Note that all this started when I went for the big performance enhancement of using nested display lists for all imaging. That interacted badly with some FTGL design decisions which have now been fixed or worked around. kenny

1 0

[cells-devel] proposed refinement of lazy cells
by Kenny Tilton 27 Sep '04

27 Sep '04

I have been working on Cello and seem to have run into a problem arising from the Cells sub-system, specifically the "awakening" process which forces all non-lazy cells to be evaluated. I have a slot which cannot be evaluated just any old time, it needs the right active OpenGL context (the containing window's). I /could/ have an "active" cell on the window itself and turn it on during GLUT callbacks, but that would be inefficient and a silly way to achieve something more elegantly (I think) conceived of as laziness: do not calculate this until asked. (The specific is the building of the OpenGL display list for a widget.) Unfortunately, the lazy option as currently set up will not work, because the slot never gets sampled if no containg widget is forced to rebuild its own display list. (the neat thing is that simply rebuilding the named display list causes the Right Thing to happen when the containing display list next gets kicked off.) Currenty laziness has two manifestations: cells are not awakened artificially, and change propagation stops at them. display-lists need to avoid the artificial awakening but not change propagation. Since I can imagine another cell requiring awakening but not change propagation, I am considering making the lazy boolean into a code, with legal values: :until-asked do not awaken artifically, but once asked stop being lazy :after-awakening awaken artificially, but do not propagate change automatically :always, or t current semantics, aka both I guess i will just go ahead since I am not breaking anything, but comments/questions are welcome. kt -- Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

1 0

[cells-devel] hiCells-devel
by Eddy Shipman 18 Sep '04

18 Sep '04

Cells-devel,' 75%off for all New Softwares. WindowXP,Photoshop,Window2003...etcMore http://QhSHhP.nenehbn.info/?4jC96lAjB8btmA4dD8pcp nope, not for me: http://pmj.applymed.biz/b.html -- afferent backlog bedimmed buildup nucleus danny bryce dimension bodhisattva memoranda alter electronic sparta

1 0

[cells-devel] Hi Cells-devel
by Cody Pratt 28 Aug '04

28 Aug '04

Cells-devel,~ We are going to be closing soon! We have the highest quality, and now, lowest priced prescription drugs online. Buy something while you still can! VI3AGRA C4ialis VALIU+M X7ANAX http://eazmea.weaponless8185biz.com/b12m postulate asymptotic firestone beech argive thebes adulate diaper quadrilateral involutorial dietician joyride emasculate thornton reportorial ankara expurgate sexy feather exhaustible crestview bisexual weave assyriology antiquated kidnap adjutant barnstorm discus .

1 0

Re: [cells-devel] Request for some simple howtos
by deepblue18＠spymac.com 01 Aug '04

01 Aug '04

:) Sorry i wasnt clear the first time around. I intend using cello right now. I am a game designer, at this point i just want to use cello for some very primitive game prototyping. And based on the results i achieve i will take it from there. In fact given that you are implementing cello, would you know what are the other opengl bindings available for lispworks? (I know cormanlisp has some, and scheme has them too) Regards, Deepankar Sharma On Sat Jul 31 11:47 , Kenny Tilton <ktilton(a)nyc.rr.com> sent: > > >deepblue18(a)spymac.com wrote: > >>Could you please put a more detailed installation procedure >>in the FAQ for newbie users like ? >> >OK. Are you trying to install just Cells or the whole Cello environment >(or Celtic, the Cells+LTk package)? I see you mentioned drawing a cube, >so maybe you are talking about Cello. If so, there is bad news and good >news for newbies: the bad news is that I have Cello is available at this >point only for hardcore developers willing to fight things out with the >necessary libraries and/or incompatibilities with different >environmentts. The good news (for you) is that I develop on Windows at >this point, both AllegroCL and the Lispworks freebee, so I should be >able to help you get things running. > >>(Btw i am on Lispworks personal free edition on the windows >>platform, so any help on this particular platform will be >>appreciated a lot.) >> >>Also could you include some simple tutorial examples explaining >>drawing a cube ? >> >>Once the initialisation barrier falls down, i could begin doing >>some of the newbie documentation myself. >> > >thx for the offer. once I am sure which subprojects you want to run I >will get you some doc and give you all the support you need to get the >code running. > >kenny > >> >>Regards, >>Deepankar Sharma >>---- Introducing Spymac MailPro: http://www.spymac.com/mailpro/ >> >>_______________________________________________ >>cells-devel site list >>cells-devel(a)common-lisp.net >>http://common-lisp.net/mailman/listinfo/cells-devel >> >> >> > >-- >Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/ >Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film > > ---- Introducing Spymac MailPro: http://www.spymac.com/mailpro/

1 0

[cells-devel] Request for some simple howtos
by deepblue18＠spymac.com 31 Jul '04

31 Jul '04

Could you please put a more detailed installation procedure in the FAQ for newbie users like ? (Btw i am on Lispworks personal free edition on the windows platform, so any help on this particular platform will be appreciated a lot.) Also could you include some simple tutorial examples explaining drawing a cube ? Once the initialisation barrier falls down, i could begin doing some of the newbie documentation myself. Regards, Deepankar Sharma ---- Introducing Spymac MailPro: http://www.spymac.com/mailpro/

2 1

← Newer
1
...
46
47
48
49
50
51
52
...
57
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

cells-devel