Compiler is mingw32. Language is C99. OS is windows. Graphics card is Nvidia 260GTX
I can link against opengl32/glu32 and build against it, but nothing from OpenGL 3.x is included... in fact, I would say its probably missing 2.x extensions!
GLEW and GLM are both C++ and doesn't work with straight C. Glee doesn't have any mingw32 binaries (and doesn't build cleanly on my system).
I'm using SDL and that has some OpenGL functions (??), but again, looks way outdated.
I just I don't understand the fundamental problem on why it's so difficult to get C/OpenGL working on windows? Why is is so unique? Why doesn't the Khronos provide an SDK/libraries/headers, etc?
I do OpenGL via Java/lwjgl and takes no time to set it up and get it compiling/running.
In Windows anything above OpenGL-1.1 is only accessible through extensions. This is how it has been designed and how it goes. GLEW works perfectly well with plain C (if I'm not mistaken GLEW is written in plain C).
Khronos cannot provide a SDK because actually providing the OpenGL API is a task left to the operating system vendor and in Windows the graphics drivers are required to provide the implementation. In the case of Windows this is Microsoft, who left the ARB some years ago, in favour of their proprietary Direct3D technology; there used to be heated debates which was the better API, but now that the whole world, except Microsoft settled on OpenGL this time of arguing is over.
Anyway, if you want things to be really easy, instead of GLUT, SDL, etc. use GLFW http://glfw.org, a really excellent OpenGL framework, that does all the hard things for you, does extension loading and OpenGL-3 context setup if you ask it so (you still need some extension wrapper to use extensions in your own code – however creating a pure OpenGL-3 context requires some proxy context, loading a few extensions using that and use the functions obtained to create a real OpenGL-3 context. Just for clarification).
Related
I have been searching to get the source code of the header file <graphics.h> and its associated library in order to integrate it with my C++ program.
At the same time, I am interested in those cross-platform libraries that works on more than one compiler. Just to be more explicit, I am talking about those libraries that are used for drawing shapes, lines, and curves in C++.
<graphics.h> is very old library. It's better to use something that is new
Here are some 2D libraries (platform independent) for C/C++
SDL
GTK+
Qt
Also there is a free very powerful 3D open source graphics library for C++
OGRE
<graphics.h> is not a standard header. Most commonly it refers to the header for Borland's BGI API for DOS and is antiquated at best.
However it is nicely simple; there is a Win32 implementation of the BGI interface called WinBGIm. It is implemented using Win32 GDI calls - the lowest level Windows graphics interface. As it is provided as source code, it is perhaps a simple way of understanding how GDI works.
WinBGIm however is by no means cross-platform. If all you want are simple graphics primitives, most of the higher level GUI libraries such as wxWidgets and Qt support that too. There are simpler libraries suggested in the possible duplicate answers mentioned in the comments.
There is a modern port for this Turbo C graphics interface, it's called WinBGIM, which emulates BGI graphics under MinGW/GCC.
I haven't it tried but it looks promising. For example initgraph creates a window, and
from this point you can draw into that window using the good old functions, at the end closegraph deletes the window. It also has some more advanced extensions (eg. mouse handling and double buffering).
When I first moved from DOS programming to Windows I didn't have internet, and I begged for something simple like this. But at the end I had to learn how to create windows and how to handle events and use device contexts from the offline help of the Windows SDK.
The Borland Graphics Interface, the library fronted by the graphics.h header, has been re-implemented atop SDL. This brings support for modern hardware and operating systems (multiple operating systems, in fact, since SDL is fairly portable).
It can be downloaded here prebuilt for a variety of common desktop targets.
Or if you wish to (or must) build it from source, here is a github mirror.
Note that it is a port of a very old software library and will run atop modern tools, so you should check with the instructor if you intend to use it for class assignments. It would be irritating to fail an assignment because you used idioms that require support from a modern compiler and find that they do not compile on a marking system from the 1980s.
You may find it better to get and develop with a virtual machine clone of the marking system to prevent nasty surprises.
graphics.h appears to something once bundled with Borland and/or Turbo C++, in the 90's.
http://www.daniweb.com/software-development/cpp/threads/17709/88149#post88149
It's unlikely that you will find any support for that file with modern compiler. For other graphics libraries check the list of "related" questions (questions related to this one). E.g., "A Simple, 2d cross-platform graphics library for c or c++?".
The below link shows examples on how the Windows API works:
Module 1. Your First Windows Program
I am quite interested in how the Mac API looks like.
After doing some reading, I read a lot of things like XCode (Environment), Cocoa Framework, etc. However, I dont see any information about something like the Win32 API.
Doesn't Apple have a low level C API that is not based on Obective-C but just plain old C?
Your link points to a tutorial for the GUI components of Windows. In that case, the equivalent for OS X is indeed the Cocoa framework, which consists of the Foundation and AppKit libraries, which are Objective-C libraries.
Cocoa's control drawing is entirely local to the application. Therefore, the only way to build applications using controls is with Objective-C. Nothing stops you from building a C API on top of that; similar tactics have been used to build libraries like Qt or bindings to languages like Python and Ruby.
There is no plain C GUI API in OS X. There are low-level APIs (part of the Quartz graphics framework, aka the Core Graphics API) for dealing with the window manager to open the top-level windows, but these are either very complicated or completely undocumented. And even then, you'd be responsible for doing all the controls and input handling yourself. Update Some of the basic facilities that applications build on top of are also available through C APIs, namely Core Foundation, Core Graphics, Core Text, and Grand Central Dispatch. But these are still not enough to use Cocoa; Cocoa is just built on top of them.
There is also the Carbon API, which is a C API, but was intended for transitioning pre-OS X applications to OS X and is thus not suitable for new application development. In fact, I'm not even sure it is even supported anymore.
So you have two options if you want to write a GUI program for OS X in plain C:
find a wrapper library
give up and learn Objective-C, which sits on top of plain C anyway
If online tutorials, including Apple's official ones, don't suit you, the Big Nerd Ranch books on Cocoa development are good. Note that their beginner-oriented books are transitioning to the Swift language, but they have a separate book dedicated to teaching Objective-C as well.
You'll also need to know that OS X applications almost exclusively design their user interfaces using a graphical designer called Interface Builder, akin to the form designers in Visual Studio. With the Windows API, you can still get away with doing things by code, and a lot of people do so; with OS X, doing everything programmatically is difficult (but still possible).
I'm getting started with OpenGL and decided to go with OpenGL 2.1. The reason I want to do this is, because it's easier and I want my programs to be compatible with old hardware. However I don't know if I can get a compatibility profile in linux.
Can I get OpenGL 2.1 program working in a linux machine with mesa (let me be more specific there, a mesa's version that implements the OpenGL 3.x+)?
If not, using OpenGL 2.1 makes my programs being less compatible with new hardware (in linux)?
Don't know what to do here. Any help is apreciated
I am a Linux developer.
OpenGL 2.1 has no concept of compatibility profiles; that only appears in OpenGL 3.x+, where using the compatibility profile adds back the features that were removed.
If you request an OpenGL 2.1 context and you get it, you're all set. And yes, Mesa supports OpenGL 2.1.
Using an old version of GL could, in theory, make your program incompatible with a driver that only supports OpenGL 3.1+ with only the core profile. In practice though, virtually every desktop GPU driver still supports old OpenGL.
I'm trying to disassemble a C/C++ DLL, and have made some progress, but I would like to create my own C DLL with the same function the original exports, and compare disassemblies.
Visual Studio adds to much crap, and when I remove the crap and build my project, the expected DLL is missing.
I need a lightweight, preferably IDE, tool to edit and build very simple C libraries.
Take a look at Code::Blocks
I need a lightweight, preferably IDE, tool to edit and build very simple C libraries.
I have found that one of the best ways to do integrated C-only Win32 development is using the freely available Lcc Win32 Compiler which comes with a built-in IDE, including resource editor.
In fact, it is really very lightweight and can be run from a USB stick with some manual tweaking.
It's indeed a really small download of just 6 mb and you can even download an optional Win32 API help file which is really useful while doing development.
The compiler also comes with a C tutorial, as well as good user documentation detailing how to use the integrated Win32 resource editor "wedit", there's also an advanced manual about more complex development tasks.
Dev-C++ is a nice and fast IDE which works well with MingW.
But it's all been asked and answered before ...
MinGW adds its own crap. Install your VC express properly and save yourself a lifetime of trouble.
Btw, you don't need to use Visual Studio for its compiler or vice versa. The oddity of missing a build dll is probably because you are not looking at the right path.
If you are building C DLLs you really would benefit from its command line toolset and utilities, sdks, easy config etc. MS lock-in proprietary extensions are widely used (in context of you trying to emulate another dll), and last thing you need is chasing cross compiler issues..
GCC + any text editor such as VIM is a very light alternative.
For Windows Development, all you need is inside MinGW
Edit: If you are in dire need of an IDE you can also use the MinGW tools from Eclipse with the CDT plugin. Although it adds weight to the solution because of the installation of Eclipse, this is what I really use to build my small DLLs (JNI wrappers in my case).
You can setup your small and direct makefiles or let Eclipse do it automatically for you and concentrate only on the source files (*.h, *.c).
The best part of using this approach instead other IDE is that you do not need Eclipse to further build the DLL, since the underlying project files generated are standard ones directly usable by integrated dev inside MinGW (or any Unix distro) such as make, configure, automake, and so on.
I'll second the vote for Code::Blocks, it's what I use (despite having VS 2008 installed as well). It is very simple and lightweight but has basically all the features you'd expect out of an IDE. It comes with several predefined project templates for all kinds of C and C++ development, including templates for DLLs.
Download the version that includes MinGW and you get a complete lightweight IDE ready to start compiling. You can also easily configure it to use the Visual Studio compiler instead of gcc if you prefer.
try Open Watcom. A cross-platform product, well-supported by the community, lets you develop in DOS, Windows, OS/2 etc for a lot of platforms. Version 1.8 was released recently. Has a light-weight IDE indeed
Good day folks, I'm in a need of a bit of guidance.
Basically, I'm a webdev who knows some C from the past, but I've only developed somewhat simple console apps for *nix.
Shortly, I want to develop a simple Win program with a GUI and not get my hands into any of the following technologies:
.NET C#
Java
C++ (especially this one)
Because I have nor the time nor the need for it currently.
1). Can I use wxWidgets without resorting to cpp (if not, what other native looking and lightweight widget toolkit would you suggest?)
2). Can I use OpenCV with strict C? (no templates, inline functions, etc)
3). Should I look for other options for a compiler besides MinGW? Is Intel one worth investigating? (AFAIK, it has a restrictive license).
4). What IDE of the following would you suggest for windows / c programming
Dev-C++
Eclipse with appropriate plugins (can't remember the exact one)
Any text editor + *.bat for compiling??
Thanks!
If you're interested in learning C-based Windows programming directly, and not using other intermediate tools:
There's a really good reference book by Charles Petzold called Programming Windows. It's definitely the way to get started. Absolutely everything is crystal clear, and you never need C++.
The Windows API, as a whole, is built for C programmers. All the fancy stuff like an actual application window is passed back as "HANDLE"s, which are more-or-less just pointers into the OS's object table. You as a programmer never have to deal with objects, just their HANDLEs.
Also, this particular book does a good job describing the Windows event-loop. If you're unfamiliar with it, it is described in generous detail.
Good luck!
For C Windows GUI programming the easiest thing is VC++ (any version since 6.0) and The Charles Petzold Programming Windows book.
The free Express version of the Microsoft compiler should work fine - I'm not sure if you'd have to download the Platform SDK or if it comes with one.
You can write Windows GUI programs in straight C. Download the Windows SDK and look at the "GENERIC" sample (I assume it's still in there). This is pretty much the minimal code required for a Win32 app, and it's in plain-ol' C.
Edit: Hmmm, it doesn't appear to be installed on this laptop. You can find it online here.
It might be worth reconsidering C#.NET. You could easily learn C# in a couple days, and be developing slick apps very quickly. Straight C-based windows libraries, particularly Win32, are BRUTAL in comparison. You'd spend a week just to write a simple app that would take minutes in C#.
The only C-based toolkit I can think of is the Windows port of GTK+. I have no experience using it in the Windows environment though. It is very mature on the Linux side though, and may be good enough if your needs are simple.
Learning the Win32 API is hard! But like others have stated, Petzold's book is the way to go if you insist on going down that path.
My opinion is that developing a Windows GUI using only C and the Win32 API would be harder to learn than picking up just enough C++ to utilize one of the C++-based frameworks. You could still do the majority of your work in plain C.
As for free IDEs, I would go with Visual Studio 2008 Express Edition.
You don't need anything.
Just use C and Win32 api , like real programmers, not kids..
See the VS Win32 wizard
Regarding wxWidgets, you can use https://sourceforge.net/projects/wxc
I never actually heavily used it, so I'm not aware of its maturity.
Mingw and Microsoft Visual C++ are my favorite compilers. Remember you can always use strict C and compile it using a C++ compiler, since valid C is almost always valid C++.
For windows, I've used Dev-C++ in the past, but nowadays Microsoft Visual C++ seems a better solution.
If you're going for text editor+bat, check out Notepad++.
EDIT: Just to clarify, using Microsoft Visual C++ does NOT mean learning C++. You can use C in it perfectly because - I repeat - valid C is often valid C++. Don't want C++? No problem. Just stay away from the C++-only features and you're still safe in a C++ compiler.
EDIT: Roger Lipscombe has noted in the comments that a pure C compiler is available in Microsoft's Visual C, using the /TC switch.