- Forum
- General C++ Programming
- why the graphics.h and conio.h was losed
why the graphics.h and conio.h was losed?
Pages: 12
why the graphics.h and conio.h( textforecolor(), textbackcolor(), gotoxy() and clear() ) was losed?
Because:
* Both headers are from ancient libraries that have modern alternatives
* conio.h was never standardized, and each compiler toolchain included slightly different stuff in it
* graphics.h, as far as I know, was never part of the Windows API
You can probably still find libraries that provide both these headers, but please don't write new code with them. Please?
-Albatross
* Both headers are from ancient libraries that have modern alternatives
* conio.h was never standardized, and each compiler toolchain included slightly different stuff in it
* graphics.h, as far as I know, was never part of the Windows API
You can probably still find libraries that provide both these headers, but please don't write new code with them. Please?
-Albatross
at least the conio.h could be standardized, because use the textforecolor(), textbackcolor(), gotoxy() and clear().
in my opinion: a basic thing with CMD is for change the carret\cursor position and the colors and clear..... it's an opinion
in my opinion: a basic thing with CMD is for change the carret\cursor position and the colors and clear..... it's an opinion
Sure, but the point is that they're not the only ways to do those things. Windows has a sophisticated console API that can be used to do those four operations, and more.
gotoxy(): https://docs.microsoft.com/en-us/windows/console/setconsolecursorposition
clear(): http://www.cplusplus.com/articles/4z18T05o/#Windows
(Isn't it usually clrscr? Also, I couldn't find a shorter equivalent in the high-level API, but all well.)
textforecolor()/textbackcolor(): https://docs.microsoft.com/en-us/windows/console/setconsoletextattribute
(Again, aren't these normally textcolor/textbackground?)
-Albatross
gotoxy(): https://docs.microsoft.com/en-us/windows/console/setconsolecursorposition
clear(): http://www.cplusplus.com/articles/4z18T05o/#Windows
(Isn't it usually clrscr? Also, I couldn't find a shorter equivalent in the high-level API, but all well.)
textforecolor()/textbackcolor(): https://docs.microsoft.com/en-us/windows/console/setconsoletextattribute
(Again, aren't these normally textcolor/textbackground?)
-Albatross
Last edited on
"Isn't it usually clrscr?"
yes... sorry, my mistake...
thank you so much for all.
or even with system() function.
is these function for be avoid?
yes... sorry, my mistake...
thank you so much for all.
or even with system() function.
is these function for be avoid?
Which functions?
system: In most cases, yes, it should be avoided. There are uses for it, like any tool, but in general it's an oversimplified, clumsy way of running another program.
The conio.h functions: Yes, you should avoid them.
The high-level Windows console API functions: I mean, using them will make it harder for people to run your program on on macOS or Linux, but that's a problem you'd run into with conio too. Otherwise, no, they're fine to use.
-Albatross
system: In most cases, yes, it should be avoided. There are uses for it, like any tool, but in general it's an oversimplified, clumsy way of running another program.
The conio.h functions: Yes, you should avoid them.
The high-level Windows console API functions: I mean, using them will make it harder for people to run your program on on macOS or Linux, but that's a problem you'd run into with conio too. Otherwise, no, they're fine to use.
-Albatross
| system: In most cases, yes, it should be avoided. There are uses for it, like any tool, but in general it's an oversimplified, clumsy way of running another program. |
Its also a way to write better than average batch or shell scripts that need just a little more than those tools provide.
system is also just slow (matters if you're planning on using it in a loop). CreateProcess on Windows is faster, and I'm sure the equivalent API on linux is faster as well. Using system depends on the current environment of your computer (e.g. you call a program called "foo", but what program actually gets called depends on what batch/exe called "foo" is in your PATH or local directory).
But for a single call, I do use system() for some personal code (e.g. customized input to ffmpeg or something like that; but I could just as easily write a wrapper around CreateProcess to make it just as easy to not use system); I wouldn't use it for an actual product.
For the initial question: One answer is that C++ is standardized in such a way that it is agnostic to the details of what output device it's being displayed on. It only has the concept of input/output streams (stdout, stdin, stderr). Particular details about how it's running on a particular terminal window is a detail that the designers of C++ have chosen to not deal with.
But for a single call, I do use system() for some personal code (e.g. customized input to ffmpeg or something like that; but I could just as easily write a wrapper around CreateProcess to make it just as easy to not use system); I wouldn't use it for an actual product.
For the initial question: One answer is that C++ is standardized in such a way that it is agnostic to the details of what output device it's being displayed on. It only has the concept of input/output streams (stdout, stdin, stderr). Particular details about how it's running on a particular terminal window is a detail that the designers of C++ have chosen to not deal with.
Last edited on
A Short History of BGI
When Borland released Turbo Pascal 4.0, people were just beginning to have hardware like mice and color graphics cards (let alone cards that could display pixel graphics), both at work and at home.
Remember going to the library in the 1990s and using the computer card catalogs with the text displays? Yep.
TP4 was a game changer.
It provided support for all this stuff, including well-written libraries for business application development. The basic design was widely adopted by competitors, and is present even today in legacy textual user interfaces.
The Hardware Problem
The problem that existed was, basically, the lack of plug and play, something that we take for granted today. Video hardware like CGA and HGC and EGA chipsets are completely different, and require specialized code to use their graphical (non-text) display modes. (Even the text modes required special care.)
It wasn’t just monitors. Printers and plotters are also graphical output devices.
There were similar problems with mouse hardware and limited memory available in segmented memory systems.
Borland’s solution
Borland created what we would today call a plug-in system that they called the Borland Graphics Interface. For each graphics card there was a BGI module which could be loaded to manipulate the video hardware. The application itself didn’t have to know (or care) about whether you were connected to an EGA or a Hercules card or a printer. You could still produce a nice pie chart.
It wasn’t as perfect as it sounds, but it worked well within its constraints.
Distributed with TP4 came various .bgi files, like egavga.bgi, which you would also distribute with your program so it would work with the hardware your end users possessed, like an EGA or VGA card.
Enter C++
After the wide success of Turbo Pascal, Borland wanted “in” on the emerging C++ market. Their C++ compiler system was heavily based on the existing Pascal code base, which included leveraging the many libraries available to Turbo Pascal programmers. The <graphics.h> library is a direct port of the Pascal Graph library.
Evolution
This concept of plug-in drivers became widespread. During the height of the Super VGA wars, part of purchasing a video game, for example, was making sure it included support for your graphics card. Games (in particular) came with a plethora of drivers for a wide variety of popular cards.
This trickled back to the ever popular Borland development tools, and third-party developers produced a broad variety of BGI drivers. Of most interest were the VESA / SVGA BGI drivers.
Today, of course, the concept has matured to the point that plug-and-play exists everywhere and is supported by hardware. Plug your phone into your PC and the driver is automatically installed.
In the early days, though, it was revolutionary. And the quality and ease-of-use exemplified by the Graph / BGI library makes it still relevant today, even in obsolescence.
When Borland released Turbo Pascal 4.0, people were just beginning to have hardware like mice and color graphics cards (let alone cards that could display pixel graphics), both at work and at home.
Remember going to the library in the 1990s and using the computer card catalogs with the text displays? Yep.
TP4 was a game changer.
It provided support for all this stuff, including well-written libraries for business application development. The basic design was widely adopted by competitors, and is present even today in legacy textual user interfaces.
The Hardware Problem
The problem that existed was, basically, the lack of plug and play, something that we take for granted today. Video hardware like CGA and HGC and EGA chipsets are completely different, and require specialized code to use their graphical (non-text) display modes. (Even the text modes required special care.)
It wasn’t just monitors. Printers and plotters are also graphical output devices.
There were similar problems with mouse hardware and limited memory available in segmented memory systems.
Borland’s solution
Borland created what we would today call a plug-in system that they called the Borland Graphics Interface. For each graphics card there was a BGI module which could be loaded to manipulate the video hardware. The application itself didn’t have to know (or care) about whether you were connected to an EGA or a Hercules card or a printer. You could still produce a nice pie chart.
It wasn’t as perfect as it sounds, but it worked well within its constraints.
Distributed with TP4 came various .bgi files, like egavga.bgi, which you would also distribute with your program so it would work with the hardware your end users possessed, like an EGA or VGA card.
Enter C++
After the wide success of Turbo Pascal, Borland wanted “in” on the emerging C++ market. Their C++ compiler system was heavily based on the existing Pascal code base, which included leveraging the many libraries available to Turbo Pascal programmers. The <graphics.h> library is a direct port of the Pascal Graph library.
Evolution
This concept of plug-in drivers became widespread. During the height of the Super VGA wars, part of purchasing a video game, for example, was making sure it included support for your graphics card. Games (in particular) came with a plethora of drivers for a wide variety of popular cards.
This trickled back to the ever popular Borland development tools, and third-party developers produced a broad variety of BGI drivers. Of most interest were the VESA / SVGA BGI drivers.
Today, of course, the concept has matured to the point that plug-and-play exists everywhere and is supported by hardware. Plug your phone into your PC and the driver is automatically installed.
In the early days, though, it was revolutionary. And the quality and ease-of-use exemplified by the Graph / BGI library makes it still relevant today, even in obsolescence.
thanks to all.
but why, C\C++, don't have, at least, clrsr(), gotoxy(), textcolor() and textbackcolor() by standard\ANSI?
but why, C\C++, don't have, at least, clrsr(), gotoxy(), textcolor() and textbackcolor() by standard\ANSI?
@Cambalinho,
For one thing, it isn't much of a standard for the language to follow. Historically, C, the origin of all of this, was purpose built to take the position of an CPU independent assembler for writing the UNIX operating system. At the time, output was on a "teletype" device, which meant you didn't have a CRT display, the output was printed on paper. It was basically a text only printer with a keyboard.
Later (not much), "dumb terminals" became the norm, but the "standards" by which these are controlled for the purposes you have in mind differed based on brand and model. There was no formal standard.
They were also monochrome, so color didn't apply.
The color notion was implied by the PC with a color graphics adapter in the early 80's. That, too, changed frequently (from 4 colors to 16, from 80 x 24 characters to 132 x 50, etc).
The typical way to handle this type of thing, with respect to the language history, was to use libraries. Sometimes those were specific to a particular platform.
At this point there is nearly zero interest in the text mode operation with respect to language standardization, especially when one considers how the problem is solved (it isn't worth the effort).
The Windows console itself isn't even standardized. Over the years one might have assumed something like "gotoxy" should work, but in recent releases one must load a mode of operation for it to work.
If you look forward to more modern versions of this kind of issue, you'll understand more clearly how these decisions are made. For example, there is no language standard GUI for C++, like there may be for other languages.
To write GUI applications in C++, one must consider using a framework. There are some which only offer Windows support, while others allow you to target Windows, MAC and Linux, with some limited support for various mobile devices.
If you write games, there are no less than a dozen (it seems) versions of DirectX (many are similar, some are not), OpenGL in 4 major flavors with important sub-versions, Vulkan and Metal. The only reasonable response a C++ programmer has to that situation is to use libraries (or write one) which makes these various API's for real time graphics hidden to the application developer.
We're generations beyond text mode "standardization".
| why, C\C++, don't have, at least, clrsr(), gotoxy(), textcolor() and textbackcolor() by standard\ANSI? |
For one thing, it isn't much of a standard for the language to follow. Historically, C, the origin of all of this, was purpose built to take the position of an CPU independent assembler for writing the UNIX operating system. At the time, output was on a "teletype" device, which meant you didn't have a CRT display, the output was printed on paper. It was basically a text only printer with a keyboard.
Later (not much), "dumb terminals" became the norm, but the "standards" by which these are controlled for the purposes you have in mind differed based on brand and model. There was no formal standard.
They were also monochrome, so color didn't apply.
The color notion was implied by the PC with a color graphics adapter in the early 80's. That, too, changed frequently (from 4 colors to 16, from 80 x 24 characters to 132 x 50, etc).
The typical way to handle this type of thing, with respect to the language history, was to use libraries. Sometimes those were specific to a particular platform.
At this point there is nearly zero interest in the text mode operation with respect to language standardization, especially when one considers how the problem is solved (it isn't worth the effort).
The Windows console itself isn't even standardized. Over the years one might have assumed something like "gotoxy" should work, but in recent releases one must load a mode of operation for it to work.
If you look forward to more modern versions of this kind of issue, you'll understand more clearly how these decisions are made. For example, there is no language standard GUI for C++, like there may be for other languages.
To write GUI applications in C++, one must consider using a framework. There are some which only offer Windows support, while others allow you to target Windows, MAC and Linux, with some limited support for various mobile devices.
If you write games, there are no less than a dozen (it seems) versions of DirectX (many are similar, some are not), OpenGL in 4 major flavors with important sub-versions, Vulkan and Metal. The only reasonable response a C++ programmer has to that situation is to use libraries (or write one) which makes these various API's for real time graphics hidden to the application developer.
We're generations beyond text mode "standardization".
if we have the cout and cin.... seems to be limited don't have the gotoxy() and the colors... ok it's an opinion and experience
cout and cin are instantiations of the streams for input and output.
The typical use case, beyond displaying text and taking keyboard input, is to allow *NIX programs to accept input from a pipe, and send output to a file through command direction.
For example, assume a program prints out a list of values to cout called "stuff".
That Linux command (UNIX too) would send the output of the program "stuff" (where cout was used to "print" the output) to a text file named stufflist.txt. This is i/o redirection at the command line.
Next, consider an application which takes input as a list of file names, then sorts them and prints that same list in sorted order. Say the application that does this is called "sortnames".
The Linux command "ls", which lists the files in the local directory, is piped with the "|" character as input to the sortnames program (assumed to be in the path). "sortnames" takes the input using cin. It sorts, the sends the output using cout. In this command line sample, that output is then stored in the file namelist.txt
That is the real common usage intent of the original "devices' stdin and stdout (which are wired to cin and cout respectively). The point being that "cin" and "cout" are not exclusively about text you see or keyboard input you provide. It's about standard input and standard output devices stdin and stdout, defined by the operating system (a standard that existed long before C++ was invented).
Now, what actually does "gotoxy" do?
It sends a short sequence of characters in a format which places the cursor. It may look like:
This is a "fake" simplified example. Here, (27) means "byte 27", or the "escape" character, which indicates to the "terminal" that a command follows. The "=" was common as the "goto" command, but many others were used depending on brand and model. The next two characters encoded the X and Y position to place the cursor.
Think about that a moment. All that gotoxy does is send a few special control characters which represents a location. The exact format differs by terminal model/brand (or PC emulation of this notion).
A language like C++ just doesn't have reason to address something like that. It never rose to the occasion as important for the language to define such a thing, because it is otherwise so easily handled by a function.
Further, this has no place in a text file, which is the presumed target of a redirected "cout" output. I know, we spend a lot of time trying to format output for viewing on a display or text to a printer, but the original UNIX concept was to use the standard input and standard output devices as a way of connecting the output of one program as the input to another, chaining them for more complex operations at the command line.
Gotoxy and related features have no place in such a context.
Similarly, clear screen, setting colors...all have related command forms which are nothing more than sending a few special characters the terminal "understands".
When designing standards for a language like C++, this is not a "language" level concept. It's a library level concept, and not one C++ was ever considered to assume responsibility for (since that had already been addressed by the "curses" library in *NIX long before).
The typical use case, beyond displaying text and taking keyboard input, is to allow *NIX programs to accept input from a pipe, and send output to a file through command direction.
For example, assume a program prints out a list of values to cout called "stuff".
./stuff > stufflist.txt |
That Linux command (UNIX too) would send the output of the program "stuff" (where cout was used to "print" the output) to a text file named stufflist.txt. This is i/o redirection at the command line.
Next, consider an application which takes input as a list of file names, then sorts them and prints that same list in sorted order. Say the application that does this is called "sortnames".
| ls | sortnames > namelist.txt |
The Linux command "ls", which lists the files in the local directory, is piped with the "|" character as input to the sortnames program (assumed to be in the path). "sortnames" takes the input using cin. It sorts, the sends the output using cout. In this command line sample, that output is then stored in the file namelist.txt
That is the real common usage intent of the original "devices' stdin and stdout (which are wired to cin and cout respectively). The point being that "cin" and "cout" are not exclusively about text you see or keyboard input you provide. It's about standard input and standard output devices stdin and stdout, defined by the operating system (a standard that existed long before C++ was invented).
Now, what actually does "gotoxy" do?
It sends a short sequence of characters in a format which places the cursor. It may look like:
| (27) '=' (x)(y) |
This is a "fake" simplified example. Here, (27) means "byte 27", or the "escape" character, which indicates to the "terminal" that a command follows. The "=" was common as the "goto" command, but many others were used depending on brand and model. The next two characters encoded the X and Y position to place the cursor.
Think about that a moment. All that gotoxy does is send a few special control characters which represents a location. The exact format differs by terminal model/brand (or PC emulation of this notion).
A language like C++ just doesn't have reason to address something like that. It never rose to the occasion as important for the language to define such a thing, because it is otherwise so easily handled by a function.
Further, this has no place in a text file, which is the presumed target of a redirected "cout" output. I know, we spend a lot of time trying to format output for viewing on a display or text to a printer, but the original UNIX concept was to use the standard input and standard output devices as a way of connecting the output of one program as the input to another, chaining them for more complex operations at the command line.
Gotoxy and related features have no place in such a context.
Similarly, clear screen, setting colors...all have related command forms which are nothing more than sending a few special characters the terminal "understands".
When designing standards for a language like C++, this is not a "language" level concept. It's a library level concept, and not one C++ was ever considered to assume responsibility for (since that had already been addressed by the "curses" library in *NIX long before).
Last edited on
http://catb.org/jargon/html/koans.html#id3141171 wrote:
I understand your desire to do cool stuff with the terminal. I kind you not, I’ve personally done cool stuff with the terminal that hasn’t even occurred to you to try.
It isn’t opinion.
Nor is it experience, though experience will inform your knowledge.
It is part of the fundamental design behind the OS and C/C++. And... you are trying to do something that is antithetical to that design.
In other words, you are doing it wrong.
If you wish to use the terminal like a plotter or GUI display, then you must use the libraries required for it.
• On Windows, that is the Windows Console API
• On *nixen, that is the terminfo/Curses library
In either case, doing so specifically indicates that your program is not a normal streams application. For some applications, this is correct, like Nano and vim (text editors for use by people with text-terminal-only interfaces).
For almost all other non-GUI applications, this is incorrect. Design your program properly:
• Using the proper interface
• Using the proper tools
Part of learning CS is learning how these things work.
It isn’t opinion, it is simply the way things are.
And they are the way they are for correct reasons.
And a whole lot of history.
Hope this helps.
| Tom Knight and the Lisp Machine A novice was trying to fix a broken Lisp machine by turning the power off and on. Knight, seeing what the student was doing, spoke sternly: “You cannot fix a machine by just power-cycling it with no understanding of what is going wrong.” Knight turned the machine off and on. The machine worked. |
I understand your desire to do cool stuff with the terminal. I kind you not, I’ve personally done cool stuff with the terminal that hasn’t even occurred to you to try.
| Cambalinho wrote: |
|---|
| if we have the cout and cin.... seems to be limited don't have the gotoxy() and the colors... ok it's an opinion and experience |
It isn’t opinion.
Nor is it experience, though experience will inform your knowledge.
It is part of the fundamental design behind the OS and C/C++. And... you are trying to do something that is antithetical to that design.
In other words, you are doing it wrong.
If you wish to use the terminal like a plotter or GUI display, then you must use the libraries required for it.
• On Windows, that is the Windows Console API
• On *nixen, that is the terminfo/Curses library
In either case, doing so specifically indicates that your program is not a normal streams application. For some applications, this is correct, like Nano and vim (text editors for use by people with text-terminal-only interfaces).
For almost all other non-GUI applications, this is incorrect. Design your program properly:
• Using the proper interface
• Using the proper tools
Part of learning CS is learning how these things work.
It isn’t opinion, it is simply the way things are.
And they are the way they are for correct reasons.
And a whole lot of history.
Hope this helps.
...and to beat this thing to the bitter end :)....
There were a large line of DOS applications which reached legendary status, like Lotus 1-2-3 (which was eventually ground into historical dust by Excel), which used an entirely different approach you may want to know.
The early PC used a simple "dumb frame" for the text display card (and similarly, later, for the early "graphics" displays). This was from about '81 through the very early 90's.
What we saw on the display was, essentially, a block of RAM. Each "byte" or "word" in that memory was a character cell on the display. To show text, as a result, you merely needed to know the base address of the display, which was in a fixed location in RAM.
These "famous" DOS applications, as a result, merely write bytes to the display memory. It was the fastest way to control display output. This made the display look like a 2D array in C (or C++ when that eventually came out), ordered by rows and columns.
Write an "A" into disp[2][40], and you'd see a "centered" "A" on line 3 (it started from zero).
I'm oversimplifying it a little, but writing directly to display memory was the common means of the period (not gotoxy), and thus simple math placed text on the display in that era.
The color display merely had different memory locations than the monochrome, and options to encode color.
There were also control registers we could write to change display modes. Some were not well documented and prone to serious error. The hardware was primitive, and not well protected.
As a result, if one accidentally wrote garbage values into certain display control registers of the CGA display mode, it would alter the refresh rate of the card. However, the monitor had a fixed refresh rate, and could not tolerate anything faster. Those old glass tube CRT's used a very high voltage transformer (in the range of 20,000 volts) to send electrons to the display. They're called "flyback" transformers (aren't used anymore), and were the basic component of a kind of stun gun, or the old style ignition coil and a 70's era car engine.
Anyway, if set to the wrong value, the flyback transformer would be overworked in seconds, heating it up.
What followed were sparks, smoke...and a dead monitor.
Imagine having that as a display bug in one's software!
There were a large line of DOS applications which reached legendary status, like Lotus 1-2-3 (which was eventually ground into historical dust by Excel), which used an entirely different approach you may want to know.
The early PC used a simple "dumb frame" for the text display card (and similarly, later, for the early "graphics" displays). This was from about '81 through the very early 90's.
What we saw on the display was, essentially, a block of RAM. Each "byte" or "word" in that memory was a character cell on the display. To show text, as a result, you merely needed to know the base address of the display, which was in a fixed location in RAM.
These "famous" DOS applications, as a result, merely write bytes to the display memory. It was the fastest way to control display output. This made the display look like a 2D array in C (or C++ when that eventually came out), ordered by rows and columns.
Write an "A" into disp[2][40], and you'd see a "centered" "A" on line 3 (it started from zero).
I'm oversimplifying it a little, but writing directly to display memory was the common means of the period (not gotoxy), and thus simple math placed text on the display in that era.
The color display merely had different memory locations than the monochrome, and options to encode color.
There were also control registers we could write to change display modes. Some were not well documented and prone to serious error. The hardware was primitive, and not well protected.
As a result, if one accidentally wrote garbage values into certain display control registers of the CGA display mode, it would alter the refresh rate of the card. However, the monitor had a fixed refresh rate, and could not tolerate anything faster. Those old glass tube CRT's used a very high voltage transformer (in the range of 20,000 volts) to send electrons to the display. They're called "flyback" transformers (aren't used anymore), and were the basic component of a kind of stun gun, or the old style ignition coil and a 70's era car engine.
Anyway, if set to the wrong value, the flyback transformer would be overworked in seconds, heating it up.
What followed were sparks, smoke...and a dead monitor.
Imagine having that as a display bug in one's software!
Last edited on
Hey, perhaps if you said what your app does we could give some guidance on how to move forward. Since we do not know what you are doing, I cannot say what you want is wrong. (Only that thinking of C++ I/O facilities they way you were is wrong.)
Here is an example of a simple full-terminal application to animate a Gosper Glider Gun:
http://www.cplusplus.com/forum/lounge/75168/
The first post contains code to control the terminal. (The second post is the Game Of Life program itself, using a very simple control loop.)
Give it a download and compile and you will get an idea of what you can do with just those primitive functions.
Keep in mind, though, that that program is explicitly for the purpose of animating a textual image on the terminal. It doesn’t have any purpose or utility beyond ‘fun to look at and dink with for a few minutes.’
More useful programs will communicate directly in text streams (via the standard streams and/or through text files) so that they can be “linked” (or “chained”) to communicate and transform data by other programs.
@Niccolo
I was all pleased with myself when I first wrote and linked an Assembly routine to activate the HGC’s graphics mode. (And then added routines for drawing pixels, and lines, etc and finally full images, which I promptly animated to do cool stuff.)
I had one of those really nice amber-colored monitors (not green), and loved playing with that thing.
Then I got a nice Trident SVGA, and life got so much cooler. LOL.
Here is an example of a simple full-terminal application to animate a Gosper Glider Gun:
http://www.cplusplus.com/forum/lounge/75168/
The first post contains code to control the terminal. (The second post is the Game Of Life program itself, using a very simple control loop.)
Give it a download and compile and you will get an idea of what you can do with just those primitive functions.
Keep in mind, though, that that program is explicitly for the purpose of animating a textual image on the terminal. It doesn’t have any purpose or utility beyond ‘fun to look at and dink with for a few minutes.’
More useful programs will communicate directly in text streams (via the standard streams and/or through text files) so that they can be “linked” (or “chained”) to communicate and transform data by other programs.
@Niccolo
I was all pleased with myself when I first wrote and linked an Assembly routine to activate the HGC’s graphics mode. (And then added routines for drawing pixels, and lines, etc and finally full images, which I promptly animated to do cool stuff.)
I had one of those really nice amber-colored monitors (not green), and loved playing with that thing.
Then I got a nice Trident SVGA, and life got so much cooler. LOL.
@Duthomhas,
I had a Trident SVGA Too!
Amber monitor on the side (Borland's debugger had a mode to put the debugger display on the monochrome card while the app ran in graphics on the SVGA...two "graphics" cards on a PC!
I had a Trident SVGA Too!
Amber monitor on the side (Borland's debugger had a mode to put the debugger display on the monochrome card while the app ran in graphics on the SVGA...two "graphics" cards on a PC!
for the moment:
1 - i need create a menu like these:
Play
Options
Exit
and imagine the text color show us the item selection;
2 - imagine a form where we ask the name, age and more and show the date.. the enter is for give us the data and go to next place to write:
Name: Age:
(asking the name and age in same line, but different position)
that's why i need the text color and (text)background color and the cursor position.
(3 - the graphics.h is great for play, but i can learn directx and\or GDI)
now you understand what i need to do
1 - i need create a menu like these:
Play
Options
Exit
and imagine the text color show us the item selection;
2 - imagine a form where we ask the name, age and more and show the date.. the enter is for give us the data and go to next place to write:
Name: Age:
(asking the name and age in same line, but different position)
that's why i need the text color and (text)background color and the cursor position.
(3 - the graphics.h is great for play, but i can learn directx and\or GDI)
now you understand what i need to do
Pages: 12