jjzcp
Experienced Member
Does Turbo C version 2.01 have graphical capabilities? Can i use real time graphics, so i can have a dot move across the screen, or something simple? If so is there a free online, book i can take a look at?
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
does Turbo C 2.01 have graphic capabilities?
- Thread starter jjzcp
- Start date
CP/M User
Veteran Member
jjzcp wrote:
> Does Turbo C version 2.01 have graphical
> capabilities? Can i use real time graphics, so i can
> have a dot move across the screen, or something
> simple? If so is there a free online, book i can take
> a look at?
Sorry but I haven't used Turbo C to really know the answer to
that question.
However what I have been able to do is write up a simple
Bouncy Ball routine using Small-C v1.x & I must admit - it
doesn't get any simplier (in terms of C compilers) than that.
I must admit though - I used a great deal of Inline Assembly -
which SmallC seemed to do very well.
The advantage of using SmallC is the ability of compiling for
CP/M too! You'll find the example here in the Recent file
downloads section.
If Turbo C doesn't support graphical routines as such it's
perhaps better to write your own in Assembly - if
possible. The best way to get started using Graphics on an IBM
is to find some guide to "INT 10h" programming - which has
lots of useful stuff. Or check out my SmallC example which
uses a bit of this stuff. There's some other graphical stuff
in there as well.
Good Luck.
> Does Turbo C version 2.01 have graphical
> capabilities? Can i use real time graphics, so i can
> have a dot move across the screen, or something
> simple? If so is there a free online, book i can take
> a look at?
Sorry but I haven't used Turbo C to really know the answer to
that question.
However what I have been able to do is write up a simple
Bouncy Ball routine using Small-C v1.x & I must admit - it
doesn't get any simplier (in terms of C compilers) than that.
I must admit though - I used a great deal of Inline Assembly -
which SmallC seemed to do very well.
The advantage of using SmallC is the ability of compiling for
CP/M too! You'll find the example here in the Recent file
downloads section.
If Turbo C doesn't support graphical routines as such it's
perhaps better to write your own in Assembly - if
possible. The best way to get started using Graphics on an IBM
is to find some guide to "INT 10h" programming - which has
lots of useful stuff. Or check out my SmallC example which
uses a bit of this stuff. There's some other graphical stuff
in there as well.
Good Luck.
DoctorPepper
Experienced Member
Yes, TC 2.01 supports graphics using BGI. Turbo C supported graphics since version 1.0.
CP/M User
Veteran Member
DoctorPepper wroet:
> Yes, TC 2.01 supports graphics using BGI. Turbo C
> supported graphics since version 1.0.
Personally, I hate BGI - though whatever you do with your
programs it's upto you.
My problem with BGI is this, I've actually found a program
harder to port between languages & routines are generally
slower.
But as I said - whatever you do with your programs it's upto
you.
CP/M User.
> Yes, TC 2.01 supports graphics using BGI. Turbo C
> supported graphics since version 1.0.
Personally, I hate BGI - though whatever you do with your
programs it's upto you.
My problem with BGI is this, I've actually found a program
harder to port between languages & routines are generally
slower.
But as I said - whatever you do with your programs it's upto
you.
CP/M User.
carlsson
Veteran Member
Well, graphic extentions to programming languages or environments usually aren't very portable. Perhaps a library implemented in several languages, but it is a more modern approach. On the IBM PC platform, I suppose you can write directly to video memory (at least for some graphics cards), but whether those writes are more portable between languages I dunno. For sure it would make it harder to port to a different computer.
CP/M User
Veteran Member
carlsson wrote:
> Well, graphic extentions to programming languages or
> environments usually aren't very portable. Perhaps a
> library implemented in several languages, but it is a
> more modern approach. On the IBM PC platform, I
> suppose you can write directly to video memory (at
> least for some graphics cards), but whether those
> writes are more portable between languages I dunno.
> For sure it would make it harder to port to a
> different computer.
Yeah well I can only speak about my examples which were ports
between my Amstrad CPC computer & IBM compatable programs.
Both systems have somewhat simular Graphical abilities. The
CPC uses the equivalent of an CGA found on the IBM - but it's
view setup is somewhat different - Left to Right increments
horizontally across the screen, though vertical increments
turn into decrements if an image is to look the same (pixel
for pixel) on both Video Systems.
Apart from that my Circle examples written in GWBASIC are IBM
equivalent of an earlier Amstrad program (which wasn't easy to
archieve!).
CP/M User.
> Well, graphic extentions to programming languages or
> environments usually aren't very portable. Perhaps a
> library implemented in several languages, but it is a
> more modern approach. On the IBM PC platform, I
> suppose you can write directly to video memory (at
> least for some graphics cards), but whether those
> writes are more portable between languages I dunno.
> For sure it would make it harder to port to a
> different computer.
Yeah well I can only speak about my examples which were ports
between my Amstrad CPC computer & IBM compatable programs.
Both systems have somewhat simular Graphical abilities. The
CPC uses the equivalent of an CGA found on the IBM - but it's
view setup is somewhat different - Left to Right increments
horizontally across the screen, though vertical increments
turn into decrements if an image is to look the same (pixel
for pixel) on both Video Systems.
Apart from that my Circle examples written in GWBASIC are IBM
equivalent of an earlier Amstrad program (which wasn't easy to
archieve!).
CP/M User.
DoctorPepper
Experienced Member
There's always a trade-off when you use any language-specific or compiler-specific library. Some (like the bare-bones Win32 API) can be blazingly fast. Others may not be. Try porting a C program written entirely in the Win32 API to Linux. Not an easy task. The reason I suggested BGI was because the original question was specific to graphics handling on Turbo C 2.01. Also the person asking the question didn't sound like they had a firm grasp on DOS-based graphics in the first place (no slight intended). Using the graphics package developed for Turbo C gives him the advantage of many examples that came with Turbo C.
Yes, BGI is slower than hand-written graphics. Yes, it isn't portable to another compiler (like Quick-C), although it is quite portable to another DOS system with a different graphics type.
To the person that originated this thread, a Google (or other search engine) search will produce a treasure trove of information. I did a two-step search on "graphics programming" followed by "turbo c", and came up with this nice hit:
http://electrosofts.com/cgraphics/
If you reproduce my search, you will find many other links that will help you learn graphics programming with Turbo C 2.01.
I tried the examples on the URL above, and they all worked well. Word of worning, when using the "initgraph" function, you should specify the absolute path to your Turbo C (of Turbo C++, in my case) BGI directory. The line currently reads (in examples 2 & 3):
initgraph(&gd, &gm, "");
To make it work correctly, I had to add the full path, like so:
initgraph(&gd, &gm, "e:\\tcpp3\bgi ");
Have fun!
Yes, BGI is slower than hand-written graphics. Yes, it isn't portable to another compiler (like Quick-C), although it is quite portable to another DOS system with a different graphics type.
To the person that originated this thread, a Google (or other search engine) search will produce a treasure trove of information. I did a two-step search on "graphics programming" followed by "turbo c", and came up with this nice hit:
http://electrosofts.com/cgraphics/
If you reproduce my search, you will find many other links that will help you learn graphics programming with Turbo C 2.01.
I tried the examples on the URL above, and they all worked well. Word of worning, when using the "initgraph" function, you should specify the absolute path to your Turbo C (of Turbo C++, in my case) BGI directory. The line currently reads (in examples 2 & 3):
initgraph(&gd, &gm, "");
To make it work correctly, I had to add the full path, like so:
initgraph(&gd, &gm, "e:\\tcpp3\bgi ");
Have fun!
Last edited:
carlsson
Veteran Member
Oh, a blast from the past: both initgraph and the directory paths where you need double backslash in the beginning of the path.
CP/M User
Veteran Member
DoctorPepper wrote:
> The reason I suggested BGI was because the original
> question was specific to graphics handling on Turbo C
> 2.01.
Well to me it just sounded like somebody who wanted Graphics
regardless!
Yes, it's been proven that Turbo C does support Graphics -
though it's always nice to know the alternatives just in case
others want to know - or the poster themselves.
> Also the person asking the question didn't sound like
> they had a firm grasp on DOS-based graphics in the
> first place (no slight intended). Using the graphics
> package developed for Turbo C gives him the advantage
> of many examples that came with Turbo C.
The basis for my responce was due to that person posting
topics in the past based on their post dealing with more
advanced advanced graphics. This thread sounds more like an
walk in the park as an comparision.
> Yes, BGI is slower than hand-written graphics. Yes,
> it isn't portable to another compiler (like Quick-C),
> although it is quite portable to another DOS system
> with a different graphics type.
Okay, so I don't like BGI - big deal. Guess it's there for
anyone who wants to use it. Likewise a Google Search for "INT
10h"+"Pixel" pulls up lots of interesting sites - Turbo C
mightn't need Assembly to handle Interrupts - it could be as
simple as setting the values into the Registers & performing
an interrupt call.
Anyway, it's all relevant.
CP/M User.
> The reason I suggested BGI was because the original
> question was specific to graphics handling on Turbo C
> 2.01.
Well to me it just sounded like somebody who wanted Graphics
regardless!
Yes, it's been proven that Turbo C does support Graphics -
though it's always nice to know the alternatives just in case
others want to know - or the poster themselves.
> Also the person asking the question didn't sound like
> they had a firm grasp on DOS-based graphics in the
> first place (no slight intended). Using the graphics
> package developed for Turbo C gives him the advantage
> of many examples that came with Turbo C.
The basis for my responce was due to that person posting
topics in the past based on their post dealing with more
advanced advanced graphics. This thread sounds more like an
walk in the park as an comparision.
> Yes, BGI is slower than hand-written graphics. Yes,
> it isn't portable to another compiler (like Quick-C),
> although it is quite portable to another DOS system
> with a different graphics type.
Okay, so I don't like BGI - big deal. Guess it's there for
anyone who wants to use it. Likewise a Google Search for "INT
10h"+"Pixel" pulls up lots of interesting sites - Turbo C
mightn't need Assembly to handle Interrupts - it could be as
simple as setting the values into the Registers & performing
an interrupt call.
Anyway, it's all relevant.
CP/M User.
jjzcp
Experienced Member
Walk in the park? try a walk around the world. I've barrly done graphics. Mostly, i do text based programs, and i've practicly done zero graphics with C. I am by no means an experienced programmer. Although, i would like to programm as a career as soon as i get older, and more experienced. Also, the only thing that i've been able to use to learn to program is books... very, very old books.
CP/M User
Veteran Member
jjzcp wrote:
> Walk in the park? try a walk around the world. I've
> barrly done graphics. Mostly, i do text based
> programs, and i've practicly done zero graphics with
> C. I am by no means an experienced programmer.
> Although, i would like to programm as a career as
> soon as i get older, and more experienced. Also, the
> only thing that i've been able to use to learn to
> program is books... very, very old books.
Well may I make a suggestion and suggest you try Turbo Pascal
before Turbo C? The beauty of Turbo Pascal is it's available
(v3.x or v5.5) are certainally capable of Graphics - even
programming graphics using INT 10h (they handle it quite well
- and you don't need Assembly knowledge to do this). There's
also Free Pascal (a newer form of Turbo Pascal - which
generates 32bit code).
Yes, C is a great language - capable of doing anything beyond
your wildest dreams, though the learning phase is the killer.
I jumped into C the deep end (I'd done only a little bit of
Pascal & Delphi prior) - though the inital shock was great. I
guess I'm only saying this cause I jumped into this stuff &
got spat out - my maths isn't great I must admit though - so
for some people, I think it's easy to learn C.
I've only moved to TP cause I seem to have a great time
playing with it. It's got some of the aspects you find in C
which I think would help when moving onto C programs. But
that's what I can make of it.
CP/M User.
> Walk in the park? try a walk around the world. I've
> barrly done graphics. Mostly, i do text based
> programs, and i've practicly done zero graphics with
> C. I am by no means an experienced programmer.
> Although, i would like to programm as a career as
> soon as i get older, and more experienced. Also, the
> only thing that i've been able to use to learn to
> program is books... very, very old books.
Well may I make a suggestion and suggest you try Turbo Pascal
before Turbo C? The beauty of Turbo Pascal is it's available
(v3.x or v5.5) are certainally capable of Graphics - even
programming graphics using INT 10h (they handle it quite well
- and you don't need Assembly knowledge to do this). There's
also Free Pascal (a newer form of Turbo Pascal - which
generates 32bit code).
Yes, C is a great language - capable of doing anything beyond
your wildest dreams, though the learning phase is the killer.
I jumped into C the deep end (I'd done only a little bit of
Pascal & Delphi prior) - though the inital shock was great. I
guess I'm only saying this cause I jumped into this stuff &
got spat out - my maths isn't great I must admit though - so
for some people, I think it's easy to learn C.
I've only moved to TP cause I seem to have a great time
playing with it. It's got some of the aspects you find in C
which I think would help when moving onto C programs. But
that's what I can make of it.
CP/M User.
mngrif
Member
There's plenty of libraries out there under the GPL (read: FREE) that will do all kinds of graphics manipulation. Depending on the actual graphics card used, SVGAlib would be a good start, along with SDL (Simple Direct Layer). Turbo C doesn't need to be able to handle it, it just needs to be able to link it. But if that's a problem, gcc will compile a binary for almost anything under the sun...