Hi again,
first I've added `const' (C) and `protected' (Pascal) to some function parameters, to make them a little "safer" (diff19 -- also contains some other small corrections).
Then I compared graph.pas with Borland's version and noticed (only) the following incompatibilities, some of which are easy to fix (diff20):
- GraphGetMemPtr and GraphFreeMemPtr are missing. I'm adding these as dummies. (There are more flexible ways to take over heap allocation with GPC/GCC, so I don't think these pointers are needed. However, if you prefer, I can also add these variables in the C version and make all heap de-/allocation through these variables.)
- The fields in ViewPortType are named differently. Since the field names are relevant to user programs, I'm changing them.
- EGAMonoHi is 3 in Pascal, not 0. I'm adding 3 as an alternative in src/bgi/bgimode.c and set EGAMonoHi to 3 in graph.pas.
- CurrentDriver is -128 while GRX declares Current_Driver (with underscore) as -1. Since this constant doesn't seem to be used anywhere, I'm just changing it.
- Same for Detect (0 instead of -2) which also doesn't seem to be used anywhere.
- NotPut was missing. I've added it, and supported in it PutImage -- though in a rather crude way, by just inverting the bitmap (temporarily). It might be a little more efficient to do it during the blit, but I didn't want to dive into the drivers and their blitting routines. At least it seems to work now, but you might want to take a closer look at it ...
(I didn't add support for NotPut in SetWriteMode because Borland doesn't support it there, either, and it would be quite pointless since it would just amount to using another color.)
- And finally: White is a function rather than a constant. This is part of the more general issue that all the other predefined colors (Blue, Green, ...) are not really what their name says. We could also make functions for them (e.g. function Blue which returns EgaColor(1)). This would work for programs which use the EGA colors by name, not for those that use a variable that runs from 0 to 15 or so. But AFAICS there's no easy solution for the latter, anyway. (It would require translating the colors in all the graphic routines, I think.)
Anyway, it seems inconsistent to me that White is a function which returns the correct value and the other colors are constants which contain (in general) wrong values. So, what is more important -- that the colors behave as their name says, or that they are constants (and can be used in initializers) with values compatible to BP and to other units (like CRT)? I think the former, so I'm adding the functions (but in a separate patch, diff21, in case you disagree; in that case I'd also suggest making White a constant with value 15).
Finally, pascal/bgi/demo.pas mentions some "unknown crashes with GPC". I can't reproduce them (without the "work-around"), neither on Linux nor DJGPP. Does anyone know more about them, or were they perhaps with older versions only? In this case, I'd suggest to remove the note and the "work-around". (diff22)
Frank
Frank Heckenbach escribió:
Hi again,
first I've added `const' (C) and `protected' (Pascal) to some function parameters, to make them a little "safer" (diff19 -- also contains some other small corrections).
Ok, I will need some time to validate it, it's a big patch (and a good work :-)
Then I compared graph.pas with Borland's version and noticed (only) the following incompatibilities, some of which are easy to fix (diff20):
Ok
....
Anyway, it seems inconsistent to me that White is a function which returns the correct value and the other colors are constants which contain (in general) wrong values. So, what is more important -- that the colors behave as their name says, or that they are constants (and can be used in initializers) with values compatible to BP and to other units (like CRT)? I think the former, so I'm adding the functions (but in a separate patch, diff21, in case you disagree; in that case I'd also suggest making White a constant with value 15).
It's ok for me (I don't know Pascal), any comments Maurice?
Finally, pascal/bgi/demo.pas mentions some "unknown crashes with GPC". I can't reproduce them (without the "work-around"), neither on Linux nor DJGPP. Does anyone know more about them, or were they perhaps with older versions only? In this case, I'd suggest to remove the note and the "work-around". (diff22)
Again, it's ok for me
Mariano Alvarez Fernandez wrote:
Frank Heckenbach escribió:
Anyway, it seems inconsistent to me that White is a function which returns the correct value and the other colors are constants which contain (in general) wrong values. So, what is more important -- that the colors behave as their name says, or that they are constants (and can be used in initializers) with values compatible to BP and to other units (like CRT)? I think the former, so I'm adding the functions (but in a separate patch, diff21, in case you disagree; in that case I'd also suggest making White a constant with value 15).
It's ok for me (I don't know Pascal), any comments Maurice?
Very good idea I think. I never used these color names for HiColor/Truecolor beforehand, just for that reason. I checked it worked as expected.
Maurice