From: Groepaz (groepaz_at_gmx.net)
Date: 2002-12-09 01:39:14
On Saturday 07 December 2002 21:19, Christian Groessler wrote:
> Hi,
>
> On 12/07/2002 11:22:54 AM CET Groepaz wrote:
> >On Friday 06 December 2002 23:44, Christian Groessler wrote:
> >> Use bgcolor() to set the color. textcolor() only selects the luminance
> >> of the text.
> >
> >that shouldnt be the case though
>
> But it is. (See description of 40x24 Atari text mode.)
haha lol, well what i mean is, that if the atari doesnt have any colors in
textmode, the textcolor() function should have NO effect at all, instead of
doing something undefined. if you'd like a function for setting brightness
(or luminance or tint or whatever) you should define a function that does
just that instead of abusing an api that was defined to be portable.
> >> The c64-compatible COLOR_xxx defines don't make much
> >> sense in this context.
> >
> >ehrm... in what sence is something like "COLOR_RED" c64 specific? (or are
> > you saying someone just cut'n'pasted the values? :=P)
>
> They are in that way c64 specific in that they duplicate the 16 possible
> colors of the c64. (Maybe not that accurate, I'm color
> blinded).
at that point please notice that "c64 colors" is somewhat equal to "primary
colors, secondary colors and some shades of grey" which is pretty much the
most basic selection of colors available (also very simelar to the 4bit
windoze colortable if i remember right)... IMHO it does even make sence to
define these instead of others, since every color-capable videocircuit
(unless taken from the ibm-pc stoneage ;=P haha) can produce simelar colors.
(accuracy doesnt really matter here does it?)
> Should I invent 128 new COLOR_xxx values for all
> possible Atari colors?
didnt you say the atari doesnt have colours in textmode? :o)
/me scratches head...makes note to UZ: "tgi has own colordefinitions?"
however if you are really concerned about a colorful border...yeah define them
:o) hehe (i _think_ the original borland api defined sth like "max 16 colors"
for exactly that reason - it doesnt make sence to define more than the most
basic colors.....generally, if you cant name the colour with one word, do not
define it :o))
> >> The brightness is specified by bits 1 to 3 of
> >> the colorvalue, use textcolor (0xe) for max. bightness, or
> >> textcolor(0) for max. darkness of the text.
> >
> >looks to me as if someone was a bit lazy with the implementation here :o)
>
> Don't think so. What more do you suggest to implement?
nothing, just if the atari doesnt have colors for text, it shouldnt implement
something unrelated through a well defined api :)
imagine someone like me writes a tetris clone using the conio-api, and he uses
colors. i cant test on atari (since i dont have one, nor found or even
searched for an emu yet ;=)), so i test on a c64 and the various cbm-machines
emulated by VICE. now if my program works alright with any of these
(including the plus4 which has different colors than c64 aswell, and the pet
which has no colors at all) i should be well able to rely on the fact the
conio-api was designed for portability, and that it WILL work (unless the
implementation is faulty - which it seems to be.)
however, i see two ways to fix this here...
a) fix your headerfiles in a way that colors are estimated, and non-available
colors are substituted by "white" (for historical reasons, since the terminal
background is supposed to be black). this may allow you to use your "faulty"
conio implementation in a portable way, and still get the "undefined"
behavior. however if some program you try to port uses absolute values for
colors instead of the defines you are in trouble. (needless to say not using
the defines make the program non-portable...but anyway :o)) this also creates
new problems on your side, for example if you can use all the colors in
bgcolor but not textcolor. (it will however still NOT break portability, just
limit use of colors more than it had to)
b) fix your implementation in a way that it complies a "no color"
implementation, that is remove the color-defines alltogether and let the
textcolor function have no effect. this ofcoz means that you can no longer
use textcolor() for setting brightness, but i dont think creating another
function/macro for that would be a problem ;)
oh..and there might be
c) request an api-change/adaption that invents a macro like
#define COLOR_INTENSITY(x) (x<<4)
which returns a value that must be ORed into the textcolor, ie
textcolor(COLOR_INTENSITY(7)|COLOR_RED);
(this is almost how it works in the borland api btw :o))
however, c) is probably quite tricky to solve and it generates new problems...
i say go for b) :o) (i did the same for the vic20 at the weekend actually,
which made the tetris thing work nicely without any changes at its code...
and thats what all the fuzz is about :o))
--
___ ___ .___________________ .___________ _______.
c=64 / | \| \__ ___/ \ \_ _____/ \ \ [groepaz]
gb / ' \ | | | / \ / \ | __)_ / | \ gp32
cgb \ . / | | |/ ' \| \/ | \ psx
gba \___|_ /|___| |____|\____|__ /_______ /\____|__ / dc
-----\/-----'---------------\/--------\/---------\/
http://www.hitmen-console.org Hitmen WWW Headquarters
http://fly.to/hitmen-groepaz my personal playground
http://rr.c64.org/silversurfer home of the RR debugger
ftp.musoftware.de/pub/groepaz cc65 dump site
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2002-12-09 00:15:16 CET