Hi,
since Mariano has ended his GRX maintaining cycle, there's still the question of how to continue.
Currently, there are four diffs against 2.4.6 for the parts I'm using myself (including the one I'm just sending in another mail), and there are probably some more patches for the other parts. So it would seem useful to at least make a new archive with the existing patches (and why not call it 2.4.7 then)?
Does anyone feel like doing so? Dimitar, what about you?
Frank
19 Sep 2004 Frank Heckenbach frank@g-n-u.de wrote:
since Mariano has ended his GRX maintaining cycle, there's still the question of how to continue.
Well, one way to continue is by tearing GRX apart and using the pieces in other projects... life after death.
Currently, there are four diffs against 2.4.6 [...] it would seem useful to at least make a new archive with the existing patches [...] Does anyone feel like doing so? Dimitar, what about you?
Not likely. Me ported the GRX font routines to SDL, changing some things ad-hoc (buffer overflows, endian handling), then installed SDL_gfx and am happy now.
Dimitar Zhekov wrote:
19 Sep 2004 Frank Heckenbach frank@g-n-u.de wrote:
since Mariano has ended his GRX maintaining cycle, there's still the question of how to continue.
Well, one way to continue is by tearing GRX apart and using the pieces in other projects... life after death.
Well, I don't consider it dead. We're still using actively using it. I think it's still a good choice if you need a "plain", portable, and easy to install graphics library.
(I'd like to stress the "easy to install part". I haven't tried to build SDL lately, but with many other current "fashionable" libraries and projects, my experience was that they have so many dependencies that it was [almost] impossible to install them on a system unless there wasn't a prepackaged binary for that system available already or you spent way too much time. OTOH, GRX (for my purposes) only requires libpng and libjpeg, both optional and easy to install as well ...)
Currently, there are four diffs against 2.4.6 [...] it would seem useful to at least make a new archive with the existing patches [...] Does anyone feel like doing so? Dimitar, what about you?
Not likely.
OK, so if no-one else volunteers, I'll probably make a new archive with the patches I have. If there are other patches I should include, let me know.
Me ported the GRX font routines to SDL, changing some things ad-hoc (buffer overflows, endian handling),
Were these bugs in GRX? If so, could you please send me just the bugfixes (without SDL porting, if that's easily possible), so I can do this as well)?
Frank
19 Sep 2004 Frank Heckenbach frank@g-n-u.de wrote:
since Mariano has ended his GRX maintaining cycle, there's still the question of how to continue.
Well, one way to continue is by tearing GRX apart and using the pieces in other projects...
Well, I don't consider it dead. We're still actively using it. I think it's still a good choice if you need a "plain", portable, and easy to install graphics library [...] haven't tried to build SDL lately, but with many other current "fashionable" libraries and projects, my experience was that they have so many dependencies that it was [almost] impossible to install them unless a prepackaged binary for that system available already [...]
SDL runs on a wide range of systems and has practically no requirements. OTOH, it's just a raw video/audio/... access library, various extra libraries (such as SDL_gfx and GRX_font) are needed to make it GRX-like, so you are right to some extent. Yet I prefer the modular approach of SDL - see BOSS/libgraph, SDL_image, SDLmm, SDL_ttf...
Me ported the GRX font routines to SDL, changing some things ad-hoc (buffer overflows, endian handling) ...
Were these bugs in GRX? If so, could you please send me just the bugfixes (without SDL porting, if that's easily possible), so I can do this as well)?
Unfortunately, I started the port by changing indent and identifier names... You can download:
http://www.is-vn.bg/hamster/GRX_font-2.0.1.tar.gz
and "backport" fdv_*, loadfont and fontpath (they are not SDL-specific, only the sources under sdl/*.c are). Check the dumpfont stack char[] too. The new fdv_raw is buggy, character count (256 vs. 512) must be swapped.
Here <<attachment>> are some other small bugfixes for GRX, I'm not sure which of them are applied already...
Dimitar Zhekov wrote:
Me ported the GRX font routines to SDL, changing some things ad-hoc (buffer overflows, endian handling) ...
Were these bugs in GRX? If so, could you please send me just the bugfixes (without SDL porting, if that's easily possible), so I can do this as well)?
Unfortunately, I started the port by changing indent and identifier names... You can download:
http://www.is-vn.bg/hamster/GRX_font-2.0.1.tar.gz
and "backport" fdv_*, loadfont and fontpath (they are not SDL-specific, only the sources under sdl/*.c are). Check the dumpfont stack char[] too. The new fdv_raw is buggy, character count (256 vs. 512) must be swapped.
Here <<attachment>> are some other small bugfixes for GRX, I'm not sure which of them are applied already...
Did you mean to send an attachment with this mail? I didn't get any, sorry.
Frank
On Wed, 22 Sep 2004 17:19:01 +0200, Frank Heckenbach frank@g-n-u.de wrote:
Here <<attachment>> are some other small bugfixes for GRX, I'm not sure which of them are applied already
Did you mean to send an attachment with this mail? I didn't get any, sorry.
Hmmm... well, let's do that again. Note: these are GRX- specific and not related to the GRX_font fixes/changes.
BTW, I forgot to mention yet another bug. When resizing and boldifing / italicizing a scalable font in one step, the characters are first rasterized to raww by hgt:
if(!(*bitmap)(chr, raww, hgt, bmp)) goto error;
and then resized from oldw to raww: (?)
neww = cvtbitmap(oldw, raww, &cv, bmp);
The 2nd pass should convert from raww to neww (that is, do boldify/italicize only, since raww ::= neww - boldwdt - italwdt). Using oldw => raww causes buffer underflows.
-
Dimitar Zhekov -
Frank Heckenbach