Thread: Make this image in c:

If you want portable code, then use

Code:

/* Uses Web color names, see http://en.wikipedia.org/wiki/Web_colors */

#define  ALL_NORMAL "\033[0m"

#define  FG_BLACK   "\033[22;30m"
#define  FG_MAROON  "\033[22;31m"     /* Dark red */
#define  FG_GREEN   "\033[22;32m"
#define  FG_OLIVE   "\033[22;33m"     /* Brown */
#define  FG_NAVY    "\033[22;34m"     /* Dark blue */
#define  FG_PURPLE  "\033[22;35m"
#define  FG_TEAL    "\033[22;36m"     /* Dark cyan */
#define  FG_SILVER  "\033[22;37m"     /* Light gray */

#define  FG_GRAY    "\033[1;30m"      /* Dark gray */
#define  FG_RED     "\033[1;31m"      /* Light red */
#define  FG_LIME    "\033[1;32m"      /* Light green */
#define  FG_YELLOW  "\033[1;33m"
#define  FG_BLUE    "\033[1;34m"
#define  FG_FUCHSIA "\033[1;35m"      /* Light purple */
#define  FG_AQUA    "\033[1;36m"      /* Light cyan */
#define  FG_WHITE   "\033[1;37m"

#define  BG_BLACK   "\033[40m"
#define  BG_MAROON  "\033[41m"
#define  BG_GREEN   "\033[42m"
#define  BG_OLIVE   "\033[43m"
#define  BG_NAVY    "\033[44m"
#define  BG_PURPLE  "\033[45m"
#define  BG_TEAL    "\033[46m"
#define  BG_SILVER  "\033[47m"

If your terminal supports UTF-8, then you can use

Code:

#define BLOCK_100 "\342\226\210"
#define BLOCK_75  "\342\226\223"
#define BLOCK_50  "\342\226\222"
#define BLOCK_25  "\342\226\221"

to output filled glyphs with a 100%, 75%, 50%, and 25% raster. But I might use # though. There are also Unicode versions for box drawing characters -- and they're even more versatile than the DOS era ones; includes dual-line-to-single-line joins, for example.

To use the above, you simply output them normally. For example,

Code:

printf("I like " BG_NAVY FG_AQUA "aqua on navy" ALL_NORMAL ".\n");

or

Code:

printf("I like %s%s%s, too.\n", FG_RED, "bright red", ALL_NORMAL);

If you wanted to draw a picture using those, you could use

Code:

#define PURPLE_DOT  FG_FUCHSIA "#" ALL_NORMAL
#define CYAN_DOT    FG_TEAL    "#" ALL_NORMAL
#define RED_DOT     FG_RED     "#" ALL_NORMAL
#define YELLOW_DOT  FG_YELLOW  "#" ALL_NORMAL

/* To draw one yellow dot to standard output: */
fputs(YELLOW_DOT, stdout);

_ _ _ _ _ _ _ _ _ _ _ _

I'd be very interested to know about a desktop system where this does not work for standard output. Especially you, Windows users. To test, you can just run this trivial program:

Code:

#include <stdio.h>

#define BLOCKS "\342\226\210 \342\226\223 \342\226\222 \342\226\221 # "

int main(void)
{
    static const char normal[8][8] = { "black", "maroon", "green", "olive", "navy", "purple", "teal", "silver" };
    static const char bright[8][8] = { "gray", "red", "lime", "yellow", "blue", "fuchsia", "aqua", "white" };

    int f, b;

    for (b = 0; b < 8; b++) {

        for (f = 0; f < 8; f++)
            printf("\033[22;3%d;4%dm " BLOCKS " %7s on %-7s \033[0m   (%s on %s)\n", f, b, normal[f], normal[b], normal[f], normal[b]);

        for (f = 0; f < 8; f++)
            printf("\033[1;3%d;4%dm " BLOCKS " %7s on %-7s \033[0m   (%s on %s)\n", f, b, bright[f], normal[b], bright[f], normal[b]);

    }

    return 0;
}

The output should be similar to the following (taken on a terminal with black background):Attachment 12085Attachment 12086Attachment 12087Attachment 12088

(Grumble grumble, Windows users and their conio.h garbage, grumble grumble, while portable stuff is even easier, grumble. Gurgle. The last one was my stomach, sorry; haven't had breakfast yet. Also, my originals were nice PNG's, but the uploader converts them to JPEG. So blame it, not me, for the blurry images.)

Now what color should we paint the bike shed?

No colors at all on Windows 7 x64 (runs 32 bit programs also).

Originally Posted by Adak

No colors at all on Windows 7 x64 (runs 32 bit programs also).

Should have guessed, dammit. Microsoft does not seem to be able to follow any standards, not even ones they develop themselves. (Actually, I hear that a future version of Office might actually follow the OOXML standard; that would be a first.)

Historically, Microsoft DOS provided a driver called ansi.sys to provide the ANSI output support. For quite a long time, it was in heavy use, especially with third-party utilities. I hear that it is still available in Windows 7, if you switch from a cmd.exe shell to a command.com one, and load the driver. (It might be interesting to know if that works, but it does not really matter: I understand the cmd.exe shell is much superior to the half-braindead command.com.)

Could you be so kind to check if running ansicon -p or just ansicon (the latter will start a new instance of cmd.exe) would provide the necessary ANSI support for your cmd.exe shell?

I thought that looked familiar from DOS days.

This is a default install, and I just looked, there is no ansi.sys file on the system. Entering "ansicon" or "ansicon -p" brings up the error "ansicon is not recognized as an internal or external command" etc. I tried it with both cmd.exe and command com, with the same results - no colors and no response to ansicon.

Maybe conio.h is not looking so bad then?

Originally Posted by Adak

Windows.h, ncurses.h, etc., are not part of the C standard. Conio.h works on all versions of Windows, also works on DOS, if you happen to run across such relic hardware, and is easier to use (more concise).

Which would you rather keyboard?

conio.h:
gotoxy()

or

windows.h:
setConsoleCursorPosition()

I like standards, but I love being practical.

Exactly how are you being practical when 1) your arthritis is so bad I am actually concerned and 2) you really want to target DOS hardware in 2012.

Originally Posted by whiteflags

Exactly how are you being practical when 1) your arthritis is so bad I am actually concerned and 2) you really want to target DOS hardware in 2012.

No arthritis, but I have a bit of carpal tunnel. What part of the picture I posted doesn't seem to have color, to you?

That's just being silly - conio.h works with ALL versions Windows (including Windows 7 64 and 32 bit).

Originally Posted by Adak

I thought that looked familiar from DOS days.

That's because it is a frigging standard, ISO/IEC 6429. First standardized in this form as ECMA-48 in 1976. Last changed in 1991. It provides an extremely stable, simple, mechanism for controlling text-based terminal attributes.

During the Windows era prior to XP at least, it was supported on Windows too. In the DOS era, it was extensively used, because then it worked everywhere.

Originally Posted by Adak

Entering "ansicon" or "ansicon -p" brings up the error "ansicon is not recognized as an internal or external command" etc.

ANSICON is a third-party utility. Click on the link, and you can download it. It provides the functionality Microsoft has chosen not to provide anymore. The ZIP package contains both 32-bit and 64-bit executables, and their source code.

Originally Posted by Adak

Maybe conio.h is not looking so bad then?

As usual, Microsoft wants its users to rely on a non-standard, proprietary "solution", conio.h, so that they are unlikely to be able to port their work to any other platforms. Vendor lock-in, dear Adak; vendor lock-in. Just because it is easy, does not mean it is not so bad.

Look, we have a standard, ISO/IEC 6429. It is extremely stable. It is supported everywhere else except latest two or three Windows major versions, and there only because Microsoft has chosen to omit the support it previously did provide, and provide only its proprietary, only-works-in-Windows, replacement.

Does it not make sense to you to install a free, trivial, open-source utility to provide standard functionality not provided by your vendor, rather than rely on the proprietary legacy interfaces provided by that vendor?

Isn't it kind of expected that a Windows user is expected to install a few utilities and applications, to get a full-featured, safe working environment?

I guess this is my question:

Would it be too much to ask Windows users to install ANSICON, so they too would get standards-based terminal control, rather than teach students legacy proprietary interfaces?

The link's server is not responding, atm. I'll try it tomorrow.

Frankly, I thought ansi.sys was a legacy program. Is there a way to alter the colors a bit? Quite useful having a red that's RED!

Originally Posted by Adak

Well, I didn't use a line equation for my program, but you have a square let's say, and at the bottom left corner, you have a line that extends to the top right corner. That's lineLR. (left to right)

lineRL has an origin at the right bottom corner, and extending to the top left corner of the square.

Both of these lines have a slope. and you can calculate any point inside the square, AS IF it had a line going back to the bottom of lineLR, and calculate it's slope.

Now you can compare that imaginary line slope, with lineLR's slope, and use a while loop or for loop, to make the same logic, work for every pixel in the same colored area.

Not only can you use that logic for comparison with the slope (and thus the position relative to the line), for lineLR, but you can also use it for a calculation with lineRL. This time imagining that the line to your pixel runs down to the bottom right hand corner.

Consider the magenta color in your pic. The magenta color is printed when the slope to the point being considered, is greater (steeper), than the slope of lineRL && the slope of the line to point lower left corner, is also steeper than the slope of the lineLR.

Code:

^ * * * * * * #   #-lineLR
* ^ * * * * # *   
* * ^ * * # * *    ^-lineRL
* * * ^ # * * *
* * * # ^ * * *    L-point of origin for lineLR
* * # * * ^ * *
* # * * * * ^ *    R-point of origin for lineRL
L * * * * * * R

I'm no math whiz, and I used a simpler approach, but if I had to use the slope of the line formula, that's how I'd do it. If the slope ever got too vertical, I'd just create an extra "border" row around the array, and work from 1 column to the left of the actual square, and one column to the right of the actual square, to avoid that problem.

So you are saying i need to find the equation of the line?
Would this work?:
y1=mx+b; //lineLR
y2=mx+b; //LineRL

if (y1>mx+b)
//print the color red
else (y1<mx+b)
//print the color blue
if (y2>mx+b)
//print the color pink
else (y2>mx+b)
//print the color yellow

I just want to know if I am on the right path or not.

I know you can edit the colors in Linux terminals (and console, using most console drivers), and in Windows when using PuTTY (which provides its own ANSI support), but I don't know about cmd.exe.

The ZIP file containing both the sources and the 32-bit and 64-bit Windows binaries at the ANSICON home page works fine from here. I downloaded the sources to see if it defines the colors, but it seems it just uses the ones Windows has defined.

To be honest, I think students learning C might have more fun if they started working with GTK+ instead. It is pure C, not C++ (and not just a C interface to a C++ library), while it does use some OOP principles. Learning it is a bit of a steep curve, as you learn pointers and whatnot very early, but I believe those skills prove very useful, are portable across architectures and systems, and would be fun to learn: visually rewarding results with little effort. Note that GTK+ is its own project, not part of Gnome; it shares origins with GIMP. The examples are very short; you do not need a lot of lines to get started. The downside is the installation process: you'll need to get mingw and either the All-in-one bundle or the numerous individual packages listed on the GTK+ download page (for 32-bit Windows). It certainly beats any text console stuff in efforts vs. rewards department, and the skills are likely to be useful in the future, too. (I think MSYS, the shell that comes with MinGW and you can use instead of cmd.exe, has ANSI support built-in.) (Or you can use Cygwin, but I think it is a bit bloated and clunky. Just my opinion, though!) With MinGW (or Cygwin), you'd also have a C compiler that supports the latest C99 standard, and would not be limited to more than two-decade old C89. (Flexible array members! Casting rules making Kahan sum et al. easy to write with optimizations enabled! What more do you want?)

That said, I understand perfectly that none of that is a good idea if it takes hours to set up, and is even a little bit fragile. The installation and the entire non-Windows-likeness is a real problem; I know its not smooth for most users. I don't personally use Windows, but if I did, the thing I would do now is set up a web page giving detailed instructions and links to how to reliably, robustly, install and use GTK+ and MinGW on Windows 7. No, actually, I'd create installers. Perhaps that way more lecturers would let go of ancient C compilers and spartan niche environments, and do something fun, rewarding, and ultimately useful. Even for a C learner only targeting Windows environments, learning GTK+ will give very useful insight into GUI programming principles, while keeping out of the full blown object-oriented paradigm. It might be even a workable approach to the depths of OSes.. All these tools are free to use (mostly GPL so both libre and gratis), and work on all major platforms and most minor ones, too.

And Adak, thanks for testing my suggestions; I really appreciate it. I am a bit hostile towards Windows (not for ideology; I do closed-source stuff too. I just hate vendor lock-in), but I'll try to tone it down.

O_o

Careful how much of the past you invoke Nominal Animal; we don't want socks wondering around complaining how "real TSR" is better than "all this daemon crap".

Soma

Originally Posted by meLearningC

So you are saying i need to find the equation of the line?
Would this work?:
y1=mx+b; //lineLR
y2=mx+b; //LineRL

if (y1>mx+b)
//print the color red
else (y1<mx+b)
//print the color blue
if (y2>mx+b)
//print the color pink
else (y2>mx+b)
//print the color yellow

I just want to know if I am on the right path or not.

Refer to your specific assignment and notes - but from any point on the plane (in the square), you can compare the slope of the two lines. So if my point is on the left side of the mid y point of the square, and I'm comparing it to the diagonal lineLR, then the slope to that point will be > the slope of the lineLR, and it will be < the slope of the diagonal lineRL, if the point is lower than the points along the diagonal lineRL. A higher point than the lineRL will have a greater slope.

So you want to compute the slope of the two diagonal lines: lineLR and lineRL, just one time. Then compare their slope, with the point you are considering how to color - using an imaginary line from the point being considered, back to the lowest point of the diagonal lineLR, and then for lineRL.

You MAY want to also use the x and y values of the point being considered. For the magenta area, for instance, the area is also > than midy, and all the yellow area is < midy.

Using this way, I believe you can use the slope of the line (rise / run), instead of y=mx+b.

Two cautions: First, I haven't used much math in decades, and two, in my program, I just used int variables, and no math.

Secondarily, try to minimize the math needed for each pixel.

Nail down EXACTLY what the assignment requires. Specifically, if you MUST use the y=mx+b equation. And let me know so we can get on the same page.

This is helping out a lot, but what do you mean by midy? Is that the slope?

Also this is what I am working with right now:

Code:

void print_Row (int yValue, int width, int height)
{
  int rise_LR=1;
  int run_LR=1;
  int line_LR=(rise_LR/run_LR);
  
  int rise_RL=-1;
  int run_RL=1;
  int line_RL=(rise_RL/run_RL);
  
  int rise_x=height;
  int run_x=1;
  int x=(rise_x/run_x);
  
  while (x > line_LR && -x < line_RL)
  {
    make_pixel(255,0,0);
    x++;
  }


}