installing winbgim with codeblocks

[iamdenteddisk]

hi, I have followed all advice on how to install winbgim to work with GCC and codeblocks.
i copy'd the lib file to the lib folder and the .h files to their include folder. I then got a first error while trying to compile the analog_clock.cpp , it is saved as a .cpp....then i hit re-build and get the two instances or right in line 302 of graphics.h... so I fixed that typo to.

finally that leaves me with 0 errors and only 1warning in line 65 of analog_clock.cpp...which reads   

Code

initgraph(&gdriver,&gmode,"d:\\tc\\bgi");

this I know is a path issue looking for the "bgi",
any ideas where i will find this "bgi" beit in mingw or codeblocks? 

I had this same issue with my old borland compiler so I know it was a graphics interface driver but IDK how it is implemented in mingw or codeblocks to do dos graphics..

any help would be great.

[MortenMacFly]

And why do you ask here and not in a Borland forum? People here are hardly experts for Borland stuff...

[stahta01]

And why do you ask here and not in a Borland forum? People here are hardly experts for Borland stuff...

winbgim is a library; so, he needs to learn how to use it.
This is a site that supports Code::Blocks; and, I agree how to use libraries is NOT a valid topic for this site.
http://forums.codeblocks.org/index.php/topic,9996.0.html

I suggest posting a full build log on http://cboard.cprogramming.com/forum.php because I doubt there is a site that supports the library.

Edit: https://github.com/stahta01/windows-games Site I set up once to help a person with a similar question.
It is NOT valid to ask questions about this on this site; I would suggest opening a thread  cboard.cprogramming.com and adding a link to that thread to this thread.

Tim S.

[iamdenteddisk]

I ask here because I am not using borland compiler but mingw.

I was directed to mingw by codeblocks

I followed codeblocks instructions on how to install both mingw compiler and winbgim library

I use an x86 machine, as such i trusted codeblocks gave good advice in both yet dont fully support follow up on it.


as I see it.

there are only so many (3 dos,win32/64,linux) platforms to support for. how hard would it be to explain a route for setting up to each?

if Dos game development is just not possible, or not yet,  "just say so". don't waste an hour for a would be developer dl/installing chasing fairy tales.

in review of the codblocks IDE. I find it really useful "to look" at some colorized C source code. but it can't compile or run a proven dos program. out of the box or at all for lack of support.

when your colorblind, that can be done in notepad!

thanks for the no-help!
I really appreciate the pass the buck to the invisible man method of support!
I would have been more pleased if it just said "you are wasting your time"

[stahta01]

To OP: Read the rules. http://forums.codeblocks.org/index.php/topic,9996.0.html

This thread is done for me.

You can lead a horse to water; but, you can't make him drink.

Tim S.

[thomas]

I had this same issue with my old borland compiler

That suggests a PEBCAK. In any case, it's not something related to Code::Blocks nor something we would be able to help with.

To be clear: Code::Blocks is an IDE which runs under a graphical environment. That means it is a tool responsible for editing and organizing the sources into a project, and calling the compiler with appropriate options. It does not compile anything, nor does it manage your compiler and/or development library installation.

It also means you cannot run it under DOS (due to lack of GUI). However, you can still develop DOS applications or applications for other platforms that do not have a graphical environment or much of an operating system (say, Arduino) which may even run on a completely different processor, provided that you have a compiler environment set up that works.

How to set up each and every single one of the 57,320 existing compilers for 43,997 platforms, with 350 toolkits, and a million auxilliary libraries is something we can't tell. At least, not for the ones we're not incidentially using ourselves.