Hello! All

Well its a problem i have no idea about it ...

check dis :

i created a small graphics program.. like which draw a circle on screen..

it works very fine..

on other hand when i shift that code into my bigger program where i have used structers and filehandling .. i simply put that graphics code in a function and call it in main ... It Gives error..

BGI Error : Graphics not initialised (use 'initgraph')


but everything is fine..... do any one why it happens???

cuz even in that error program if i remove all other code specially structures... graphics works (

Please help...

One more thing .. On one of my PC which has high power components... Like 7900GTX .. graphics Dont work on C++ :O

Thanks !

Are you using the Borland graphics from graphics.h in Turbo C or Turbo C++ ? Yes, then I'm not supprised it doesn't work with modern high-powered graphics cards. Afterall, Turbo C is something like 20+ years old.

Thanks, i admit that c is very old but what about my problem where graphics works and just not work in my partiular program..

my complete guess is that the program has run out of memory.

It would be easier for others to find the problem if you post your code or else people will be forced to guess like Ancient Dragon

> One more thing .. On one of my PC which has high power components... Like 7900GTX ..
Buy Ferrari.
Take out engine.
Replace engine with a horse.

Your compiler is the horse!

In one fell swoop, you've reduced your uber machine to an 8086 (and not the pentium-iv it has) with 640K of RAM (not the GB it has), and a VGA display with limited resolution and colours (and nothing like the graphics card you have).

Not to mention
- short filenames
- no knowledge of NTFS
- probable Y2K issues (gosh, really, that was like 10 years ago man)

Also (if that's not enough to convince you), dumb stuff like
char *buff; gets(buff);
usually works on DOS (for a while at least), whereas with any decent OS/Compiler, you get your ass handed back to you on a plate because it's such crap code.

For compilers
http://www.thefreecountry.com/compilers/cpp.shtml
http://www.compilers.net/
http://www.codeblocks.org/home
The latest visual studio express from Microsoft (+ the platform SDK), or code::blocks seem good choices.

And for graphics
http://www.libsdl.org/
SDL is a wrapped up version (simpler) than OpenGL (which you could also use).

Thank you Salem You have fed me enough knowledge to convince my friends why not to use Turbo C.

I was once trying to convince my teacher to convince my university to change the compiler; yet they still won't change it. Sadly, I have to learn with that old compiler.

Well, All I want is to change my friends. At least that should be possible
I was not able to convince my teacher
When I said that, The answer I got was this "Visual C++ should not be used, Its a different language. You should use C++" I should say Turbo c++ == C++ in my world!

Glad though that the trend is changing.
In many institutions turbo c is replaced by gnu compilers. As to me Daniweb is the only source of light.

> "Visual C++ should not be used, Its a different language.
Yes, and so is "Turbo C++" as well.
Either is brain-damage if the tutor gets too "comfortable" with a particular compiler. The tutor is already on shaky ground if they can't tell the difference between a language and an implementation.

If the tutor was actually any good, they'd suggest a set of compilers and ask the students to choose one. Any decent course in "standard C++" simply wouldn't care about which compiler you used, they should all be the same.

Getting code to work on your favourite compiler is no great feat. Writing portable code which works across a range of operating systems and compilers takes it to the next level.

The real problem is a lot of tutors have learnt "dialect C++" and they're just too lazy (or shamed) to fix the problem by learning standard C++. So they trot out the same old lines about how hard it is to upgrade to something more modern.