Graphics programming for Windows - what tools to use?

[AlephZero]

I have plenty of experience of other systems, from right back to Calcomp pen plotters and the first graphics terminals up to OpenGL, but I haven't done any graphics programming for a few years and I've never programmed graphics on Windows before.

So the question is, what libraries, development environment, etc, to learn?

Some criteria:

• Will be running on desktop computers (and possibly tablets), but not games consoles, Windows phones, etc.
• Minimize dependence on MS software, beyond the core Windows components.
• C++ and/or Fortran (i.e. not Java, C#, etc, etc).
• Minimize dependence on graphics hardware.
• Don't meed ultra high performance.
• Want something likely to be stable for a reasonable timescale (i.e. 5 years, not 5 months).
• Preferably, free.

OpemGL on Windows seems to be implemented using vendor-specific graphics drivers, so could be problematic with a diverse set of hardware (system dependent bugs, unsupported graphics cards, etc) - or as a software implementation on top of DirectX.

DirectX seems like the cleanest option:

• Runs on pretty much all existing versions of Windows.
• Apparently it's a core part of MS's future strategy, but
• I can find non-MS-written tutorials on the Web that don't start every other sentence with "This is easiest on Windows 8.1", "Using MS Visual Studio", or "The MS App Store" ...
• No reason why I can't develop using the Gnu compilers.

Any comments and/or alternative suggestions?

 

[DavidSnider]

I have plenty of experience of other systems, from right back to Calcomp pen plotters and the first graphics terminals up to OpenGL, but I haven't done any graphics programming for a few years and I've never programmed graphics on Windows before.

So the question is, what libraries, development environment, etc, to learn?

Some criteria:

• Will be running on desktop computers (and possibly tablets), but not games consoles, Windows phones, etc.
• Minimize dependence on MS software, beyond the core Windows components.
• C++ and/or Fortran (i.e. not Java, C#, etc, etc).
• Minimize dependence on graphics hardware.
• Don't meed ultra high performance.
• Want something likely to be stable for a reasonable timescale (i.e. 5 years, not 5 months).
• Preferably, free.

OpemGL on Windows seems to be implemented using vendor-specific graphics drivers, so could be problematic with a diverse set of hardware (system dependent bugs, unsupported graphics cards, etc) - or as a software implementation on top of DirectX.

DirectX seems like the cleanest option:

• Runs on pretty much all existing versions of Windows.
• Apparently it's a core part of MS's future strategy, but
• I can find non-MS-written tutorials on the Web that don't start every other sentence with "This is easiest on Windows 8.1", "Using MS Visual Studio", or "The MS App Store" ...
• No reason why I can't develop using the Gnu compilers.

Any comments and/or alternative suggestions?

Your choice of DirectX seems to be in contradiction with "Minimize dependence on MS software, beyond the core Windows components."

Yes, OpenGL is implemented using vendor specific drivers, but unless you're getting really fancy they both pretty much do the same thing. Also I think there are only two major vendors these days, nVidia and AMD.

 

[AlephZero]

Your choice of DirectX seems to be in contradiction with "Minimize dependence on MS software, beyond the core Windows components."

What I meant was that the DirectX runtime components are part of every supported version of Windows so (I assume) a DirectX application will "run anywhere on Windows" without the user having to install or upgrade anything else.

On the other hand, I don't want to get locked into Windows-specific software development tools, (e.g. Visual studio, MS proprietary programming languages or language extensions) or get my development PC cluttered with any more of them than are essential. (Obviously I need the appropriate SDK to do anything at all.)

 

[willem2]

try SDL?

http://wiki.libsdl.org/FrontPage

available for various platforms/compilers, and can use directx under windows

 

[gsal]

I wish I knew OpenGL...it's been there, it's there and it will be there...and I just don't trust MS not breaking compatibility for no good reason or profitable reasons or whatever.

Various other software/programming languages use OpenGL and/or offer OpenGL interface, too.

There is pyOpenGL

There is http://www.mesa3d.org/intro.html, if anything

my 2 cents

 

[SteamKing]

I believe the popular graphics cards for the PC (nVidia and AMD) have OpenGL support built into their respective graphics chipset drivers.

OpenGL would give you a means to program graphics in your applications independent of the Windows DirectX system.

There are plenty of SDK for C++ and the like out there, including Windows Visual Studios. Finding Fortran Windows development systems is a little trickier, but with the right package, you can create and manage dialogs and other parts of the Windows API using calls to a set of library routines provided by the development system. You can also use OpenGL routines.

One of the development packages I used to dabble with is Winteracter:

http://www.winteracter.com/

This package is from the UK and has libraries for a variety of OSs and Fortran compilers, along with demo programs, etc. Windows API programming has a pretty substantial learning curve to overcome, which is why I never spent the time to learn it to write a viable program. I was more used to the DOS/Fortran environment, which allowed for quicker development of a program to obtain results without having to fiddle with Windows.

Another good website to check out Fortran tools is the Fortran Company:

http://www.fortran.com/

This site is chock full o links to all things Fortran.

 

[gsal]

By the way, AlephZero, can you be a bit more specific as to what you meant by graphics programming? Games? Virtual reality? Rendering? 3D-modeling? ...depending on what your needs are, there may already be an application out there you may be able to tap into with a plug-in, module or something and not have to worry about the entire application development process.

 

[AlephZero]

One of the development packages I used to dabble with is Winteracter:

http://www.winteracter.com/

It's a bit expensive to "dabble" with, unless somebody else is paying! (£495 for a single user licence).

 

[AlephZero]

By the way, AlephZero, can you be a bit more specific as to what you meant by graphics programming? Games? Virtual reality? Rendering? 3D-modeling?

The complete application will be a combination of signal processing, system identification (as in control theory or modal analysis), physics simulation, and data visualization. At least three of those four will involve graphics!

No doubt most of it could be built in something like Simulink, but I don't want to end up being constrained by "what software package X can do".

 

[AlephZero]

try SDL?

http://wiki.libsdl.org/FrontPage

available for various platforms/compilers, and can use directx under windows

I looked at the website, but I can't see what its unique selling point is apart from the cross-platform capability (which I don't need).

Apart from that it seems to be "yet another API for a subset of the underlying graphics package".

 

[gsal]

The complete application will be a combination of signal processing, system identification (as in control theory or modal analysis), physics simulation, and data visualization. At least three of those four will involve graphics!

No doubt most of it could be built in something like Simulink, but I don't want to end up being constrained by "what software package X can do".

Well, I would go the "glueing" route with Python from where you have access to many specialized modules from (scipy) signal processing, PyOpenGL, control systems, to, of course, matplotlib...

...this way, you are not constrained by the limitation of a single piece of software and instead you have access to independently developed and specialize modules...

In other words, why re-invent the wheel? I mean, if you needed matrix inverse, decomposition...would you write your own? or download LAPACK? ...kind of along those lines...glue needed functionality at the library level...

...just an idea.

 

[SteamKing]

It's a bit expensive to "dabble" with, unless somebody else is paying! (£495 for a single user licence).

If wishes were horses, rides would be free.

Development tools and compilers can cost some real money. And then a new version of the OS comes out and you've got to upgrade everything. It's no longer a casual hobby to develop software, even for strictly personal use. I still use a lot of software developed 20 years ago under DOS and paper over the gaps with spreadsheets like Excel. It was too big a time suck for me to start all over from scratch just to get a Windows version of the software working.

IDK if you've taken a look at the documentation put out by MS for the Windows API. They are door stopper type books, even for XP. Scads and scads of non-MS books on the same topic.

 

[AlephZero]

In other words, why re-invent the wheel? I mean, if you needed matrix inverse, decomposition...would you write your own? or download LAPACK?

Of course there's no point re-inventing the wheel. But the value of searching the web for new wheels depends how many wheels you already have in your personal "software toolbox".

IDK if you've taken a look at the documentation put out by MS for the Windows API.

I've been browsing the on line documentation for DirectX. Actually it looks pretty much the same as OpenGL, except the function names don't start with "gl" any more.

A bit more research suggests the DirectX route looks like the best method to stick with the compiler system and IDE that I know and love already. The NVIDIA development kit for openGL is tied into MS Visual Studio. And unless you want to spend $$$ on a compiler, VS pretty much ties you into the MS compilers' (non-standard) ideas about programming languages, and excludes Fortran.

They are door stopper type books.

Sure - the DirectX SDK is a 500 Mbyte download. But that doesn't mean you have to read all of it before you can do anything.

Figuring out how to use any API by reading the documentation "from scratch" is not a good idea. Just find some tutorial code that works and does the basics (open a window, create a graphics context, handle events, etc) and away you go. The basic structure of an event driven graphics program is the same, whatever software you use to build it.

Of course, being paid by my employer to learn my first event driven graphics software package, a long time ago, was a bonus

 

[Daverz]

Do you really want to program a user interface with DirectX or OpenGL? I think this would be a very inefficient use of developer time.

I would suggest Qt. C++, but bindings are available for many languages; cross platform; LGPL; supports touch interfaces if needed; has several good plotting components available, but you can use OpenGL if you want to; popular for scientific work.