GEM-dev

gem-dev@lists.iem.at

2417 discussions

gpl vs lpgl license question
by tigital 15 Jul '03

15 Jul '03

hey guys, ...I've just done a "quick and dirty" port of a bunch of Pete's_Plugins, which are under the lpgl, and I notice that Gem is gpl'ed: will this cause any problems? I'm not familiar with these kind of formalities ;-) l8r, jamie

3 2

Re: [GEM-dev] FTGL linux port
by IOhannes zmoelnig 11 Jul '03

11 Jul '03

tigital wrote: > On Friday, July 11, 2003, at 01:29 PM, IOhannes m zmoelnig wrote: > > hi iohannes, > > ...guess that's me! I started working on updating the font usage to > FTGL, but didn't take it to completion because I got distracted into > other areas ;-) I also realized that I didn't know FTGL very well, > blahblahblah... > > ...all the changes I started to make (which are sure to be few) are > "#ifdef FTGL", and changing that would now affect compilation on macs: > thanks for asking before hand! ok. so i will go home now, have a sleep and then start working on the FTGL-support for all 3 platforms. the code as it looks now is really bad, anyhow. i think it will be another major rewrite, and i hope it can be done in due time. in the meantime, it just keeps crashing.... btw, what is the TexFont.h for ? i guess it means something with applying textures to fonts (which is supported by FTGL). can we savely delete it from the cvs ? mfg.asd.r IOhannes > > l8r, > jamie > >

1 0

FTGL linux port
by IOhannes m zmoelnig 11 Jul '03

11 Jul '03

hi! i am currently trying to build gem against FTGL. however, there are problems, and i was wondering, whether the mac-version of Gem has really FTGL-support (or did the attempt just stop?) if so, the apple-devs are including a FTGLFont.h file, which is not included with my version of FTGL. Might be, this is a wrapper for the GLTT-api around FTGL. can someone send it to me ? of course it would be simple to write it from scratch, but i don't want to break things in apple-land. mfg.as.rd IOhannes

1 0

Re: GEM stability
by IOhannes zmoelnig 23 Jun '03

23 Jun '03

Daniel Heckenberg wrote: > Hi all, > > GEM isn't very stable on Windows at the moment - I'm noticing a number of oh, maybe i should reboot into "dos" more often ;-) > I'm wondering whether other platforms are suffering any of these problems or i have never noticed any problems under linux. although i had had problems under mac, when the cpu usage went very high after some time (without doing much) > whether anyone is actively tracking down similar/related problems? sorry (for you): no, at least not me > PS There was talk of a major point release for GEM some time soon. When > will that be and what steps are required to get there? actually this is the question i tried to ask. i have no date in mind (as we are no software-company, we are not that bound to release-dates), but the sooner, the better. i tried to outline what has to be done: 1. stability (fits to this thread...) on all platforms 2. feature-freeze: i don't think i will have the dv-in working soon under linux (and i need some help with the class-concept for addressing two different driver-architectures) furthermore, i don't think that the new release will feature any other outputs ("gemwin"s like dv-out). this is fine for a next release. i think, basically that's it. mfg.asd.r IOhannes

9 13

pix_rds added
by tigital 17 May '03

17 May '03

hiya, ...just added pix_rds, which is a port of the effectTV random dot stereogram code...which brings me to a question: how should we best deal with "utility" type functions? I've been porting from several different effects packages, and some of them use similar code for colorspace changes, or matrix math, or whatever...I noticed a problem with namespace clashes when I loaded GEM, PDP, PDP2GEM, and PIDIP, because PIDIP and GEM have similar ports of effects from effectTV... ...seems to me the only way to do this would be to encapsulate all functions within the pix_"object" class, but this leads to a lot of redundancy (which really isn't bad, I guess)...any ideas? l8r, jamie

1 0

Re: [GEM] update && Re: [PD-dev] [GEM] update
by IOhannes zmoelnig 16 May '03

16 May '03

gÃ¼nter wrote: > I have taken a look at the new film classes, and I have to say that I > am not fully convinced by the design. > If every platform has to go through this, it might be good to give > it a little bit of thought. > The cleanest solution would be to have the decoder (film) classes > register themselves with the system if they are linked in, and not > call their constructors from the pix_filmNEW. > (This can be done for example by instantiating a global class in each > filmXXX implementation, where the constructor registers itself) > This would save the #ifdefs that are currently in the filmXXX > classes. this is true. however, i have never before done such thing and so i have not "wasted" too much thought on it. mfg.asd.r IOhannes

1 0

version numbering
by IOhannes zmoelnig 16 May '03

16 May '03

just a tiny little thread about the version of the new release (not very important) gem-0.88 would be the "normal" version number however, as chris has pointed out, there were a lot changes and maybe 0.88 would be to small a change from 0.87 however, since 0.88 (or 0.90) isn't that far from 0.99 any more, which is (normally) the pre-version of 1.0, i would suggest just an extension to 3 digits as 0.888 1.) this would give us some room 2.) the 3 digits are symbolic for the 3 major platforms, Gem is running on. 3.) it is just a thought mfg.as.dr IOhannes

1 0

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

GEM-dev