History Main / ApplicationProgrammingInterface

17th Aug '13 7:25:42 AM Whitecroc
Is there an issue? Send a Message


->''The wonderful thing about standards is that there are so many of them to choose from.''
->--'''The UNIX-HATERS Handbook'''

An API, or Application Programming Interface, is a communication protocol between two sets of code. It's like a language; both parties agree that words have a particular meaning, so that they can talk to each other.

Why? Because Software is Hard.

Hardware makers do their best ''not'' to agree on how hardware should be made. Power requirements & connections have to be standardized, but how do you think they could actually make such a great [=XYZ5000=] if they actually told you how they did it?

A driver implements a particular [=API=] that the operating system requires for interfacing with a certain kind of hardware. So hardware makers write 'software drivers' that allow your lowly computer to understand & communicate with the awesomeness that is their [=XYZ5000=], at least on a basic level.

So your computer can now handle the hardware, be it Microsoft Windows, MacOS, or UsefulNotes/{{UNIX}}.

However, Microsoft, Apple, or the various makers of the various *nix's are not stupid; they know there's malicious (or just poorly written) code out there. They are not just going to let any old program willy talk to drivers. ''Especially'' drivers relating to drawing stuff on the screen. The OS needs to know about this sort of thing, and it needs to manage access to that hardware.

So the OS exposes an [=API=] that allows other programs to talk to the hardware.

[=OpenGL=] and [=Direct3D=] are the two available [=APIs=] for dealing with 3D graphics. An interesting aspect of both [=APIs=] is that, because they directly access hardware, their features are very reliant on the underlying code. Previous graphics cards may work, as there's usually a built-in render path using older versions, but you usually won't see the new features. There are also programs which implement the [=API=] in software, although the featureset and performance is always well under what you can find in hardware.

Frequently, how efficiently these pieces of Hardware work with [=APIs=] depend not only on the hardware, but on how nicely they play with [=APIs=] (part of software drivers). The amount of work put into this, in part, is determined by how much money they expect to make from them. ''In the future''. So old hardware slowly migrates to the great big garbage dump in the sky, because there is no money to be made.

There have also been cases of newer graphics cards omitting or otherwise breaking little-used features that some games during the [=Direct3D=] 7 and prior era used, either at the driver or hardware level, so don't expect perfect backwards compatibility. Sometimes you might just have to build an old computer to run a suitably old game well, or even at all.

!!Graphics API
[[AC:Glide]]

The first most widespread graphics API. It was developed by video card maker [=3dfx=] for use in their cards. It was one of the most widely used [=APIs=] until about 1998 or so, when [=DirectX=] and [=OpenGL=] were mature enough and the fact the API only worked on [=3dfx=] cards, while NVIDIA and ATI were coming out with their own hardware.

Much love still remains for this API, with people creating "Glide Wrappers" for games that don't officially support it.

[[AC:[=Direct3D=]]]

[=Direct3D=] is Microsoft's baby, and, thus, it's only available through Microsoft Windows operating systems, the {{Xbox}} consoles, and through very careful and questionably legal reverse engineering schemes. It is often referred to as [=DirectX=] even though [=DirectX=] is an entire suite of [=APIs=] for dealing with more than just rendering (sound, input), of which [=Direct3D=] is just one member.

The current popular versions of [=DirectX=] are 9.0c and 11. DirectX 9.0c survives because the {{Xbox 360}} runs on it and many [[SoftwarePorting ports]] from the 360 to Windows run on it, and thus Windows XP. [=DirectX 11=] requires Windows Vista [=SP2=] (with some further updates), Windows 7, or Windows 8 and compatible video cards. While [=DirectX=] officially only operates in Windows and on the Xbox systems, [=WINE=] and Cedega groups have gotten some features to work fairly well on Linux.

In case you're wondering where's [=DirectX=] 10, it was released with Windows Vista. Since it offered very few quality advantages over [=DirectX=] 9.0c and was only compatible with Windows Vista, nobody really cared about it.

[[AC:[=OpenGL=]]]

[=OpenGL=] is [=Direct3D's=] primary competitor, and in many ways the tool of choice for cross-platform gaming (though, in truth, it is the only tool for cross-platform game development). [=OpenGL=] is a graphics API, so it only technically competes against [=Direct3D=], the 3D portion of [=DirectX=]; most Windows games that use [=OpenGL=] use the non-graphics part of DirectX for other tasks, while other operating systems use different [=APIs=] for other tasks (for example, [=OpenAL=] for audio acceleration). Many individuals feel it's much easier to program in than [=DirectX=]. However the open standard certainly made it more expandable, and many [=OpenGL=] games such as CityOfHeroes are made up of more extensions than original standard code.

While [=OpenGL=] can work with a variety of operating systems, it does have some downsides. Since [=DirectX=] is nowadays the API of choice, many consumer-oriented graphics cards have horrible [=OpenGL=] support (although this is usually the fault of the card's driver, the card itself has no real concept of OpenGL or DirectX, only the machine language supported by the GPU. This is the reason why the same card may have excellent OpenGL performance if run in Linux than on Windows). Earlier ATI and Intel embedded graphics chips in particular might run a [=DirectX=] game well, but crawl when using [=OpenGL=]. After AMD got ATI, though, [[http://fireuser.com/blog/amd_updates_entire_firepro_line_to_evergreen_gpus/ having fresh cards work with]] any fresh software eventually ceased to be a problem.

The latest version of [=OpenGL=] is 4.5. For older hardware (hardware limited to [=DirectX=] 10), there is version 3.3. For REALLY old hardware that is (huge fake GASP) 5+ years old, there is [=OpenGL=] 2, which roughly corresponds with [=DirectX=] 9.

For embedded applications, such as cell phones and even the PlayStation 3 and Vita, there's a special version of [=OpenGL=] called [=OpenGL ES=]. It's currently on version 3.0 and contains similar features the [=OpenGL=] of the same version.

[[AC:Other Graphics API]]
* '''[=GDI=]''': Microsoft's 2D API for drawing graphics in Windows. It was primarily used in Windows 3.0 up until Windows XP (although using an upgraded version called GDI+, which was also backported to Windows 9x, ME and 2000 for use with Microsoft's Office suite). It is supported in Windows Vista and beyond for compatibility reasons.
** '''[=DirectDraw=]''': A 2D API that was part of [=DirectX=], but was released and maintained parallel with GDI+ - while GDI+ is mostly used in productivity software, [=DirectDraw=] is mostly used in 2D games. Like [=Direct2D=] it offers hardware acceleration, albeit a at much more limited scope (it required that the graphics card drivers specifically supported the framework, and doesn't support compute-based acceleration like it's successor, [=Direct2D=]- understandable because compute-capable graphics cards doesn't exist at the time.
** '''[=Direct2D=]''': GDI's and [=DirectDraw=]'s successor. It offers better performance over GDI and allows for even hardware acceleration via compute-capable [=GPUs=].
* Mac OS Classic has the '''Toolbox API''' calls, since most of the graphical code resided within the Macintosh BIOS itself.
** There is also '''[=QuickDraw=]''' which is an accelerated graphics API for Classic Macs. Like [=DirectDraw=], it supported special ''accelerator cards''.
* '''Carbon''' for Mac OS, a high level API meant to ease the transition to ...
* '''Cocoa''', an API framework that sits atop Quartz.
* '''[=Quartz=]''': The Macintosh API for rendering graphics. Unsurprisingly, it is only available on AppleMacintosh computers running OS X. A revised version with hardware acceleration called '''[=Quartz Extreme=]''' was introduced with OS X 10.2 and persists to this day.
* '''[=SDL=]''': The ''Simple [=DirectMedia=] Layer''- a large API for handling graphics (with delegation of 3D rendering to [=OpenGL=]), sound, input and networking. Highly favored by commercial game companies due to ease of use and that porting games that are written around the DirectX API to other platforms using SDL requires very little effort. ValveSoftware's Linux port of Steam and various Steam games, for example, use this API heavily.
* '''[=GGI=]''': General Graphics Interface- another API specialized in rendering graphics, with a sister library, '''GII''', the General Input Interface, for handling input. Programs that uses it are less common than SDL, but due to it's speed, it has a fanbase.
* '''[=Curses=]''': An API for drawing GUI elements like text boxes, check boxes and menus in ASCII. Superseded by:
** '''[=NCurses=]''': The New Curses library, which is basically an improved version of the Curses API.
* Actually, {{Unix}} systems are just full of separate [=APIs=] that handle drawing GUI elements, due to the ''Choice is good'' mantra (see this page's quote). All of them being methods that sit above the ''[=X Windows=]'' or ''Wayland'' GUI server, which also consists of a server, a set of tools, and an API.
** '''[[WritingAroundTrademarks [=wxWidgets=]]]''', formerly [=wxWindows=]
** '''[=Motif=]''' and it's spinoffs '''[=LessTif=]''' and '''[=OpenMotif=]'''
** '''[=GTK+=]'''
** '''[=Qt=]'''
** '''[=GnomeUI=]''', which is actually an expansion built atop ''GTK+''
** '''[=XAW=]''': the X Athena Widgets API.


!!Audio API
[[AC:[=DirectSound=]]]

The [=DirectX=] component that is responsible for rendering sound in 3D and 2D spaces, as well as mixing audio. Supported in all Windows versions before Windows Vista, where Microsoft rewrote the audio subsystem.

One mixing API that heavily relied on [=DirectSound=] was Creative Lab's EAX.

[[AC:[=OpenAL=]]]

When Microsoft redesigned the driver structure in Windows NT 6 (introduced with Vista) based operating systems, they stripped out key features from [=DirectX=], namely [=DirectSound=]. Creative Labs, who make gaming soundcards, found their EAX now useless. As a result, they developed [=OpenAL=]. While it has support for a wide variety of platforms, it is not open source like the rest of the Open [=APIs=] are.

[[AC:[=OSS=]]]

OSS is the defacto API standard (and driver set) for most {{Unix}} flavors, except under Linux where it has been superseded by [=ALSA=]. Both actually maintains a friendly competition for each other and actually have compatibility libraries to allow support for the competing API (OSS comes with optional libraries to allow for ALSA API compiled programs support- should you decide to throw ALSA out in favor of sticking to OSS on Linux for whatever reason, while ALSA also comes with optional libraries to support programs compiled against the OSS API). And then there's the bunch of Mixer [=APIs=] (see ''Mixer API'' below) that sit above it perform audio mixing since OSS has no ability to do that on their own yet.

[[AC: [=ALSA=]]]

A competing standard and driver set found on most modern Linux distributions, which was created due to a licensing dispute with the creators of OSS. However, even with the dispute, the ALSA team are actually in friendly terms with the OSS team and even offers a compatibility layer to let programs that require OSS to run on ALSA systems, and allow OSS to offer a compatibility library to for providing ALSA program support in OSS. Like OSS, there is a bunch of Mixer [=APIs=] that sit above it (again, see ''Mixer API'' below) to do mixing as ALSA has no ability to do mixing by it's own yet either.

[[AC: [=CoreAudio=]]]

The Macintosh API for handling audio, found on Mac OS X Systems. Again, exclusive to AppleMacintosh computers.

[[AC: [=MME=]]]

The classic Windows API for handling audio, having existed since at least Windows 3.0 and probably not going away anytime soon. Commonly called waveOut after what the function names for playing sound all start with.

[[AC: [=PortAudio=]]]

A portable wrapper API - it just passes everything on to whatever your system's real API is, but largely hides the differences from the program using it.

[[AC:Mixer API]]

A subclass of the Audio API, Mixer [=APIs=] act as a higher level API that provides the ability to mix audio from multiple programs or streams into a single stream prior to feeding it to the sound card of the device. They're typically found in {{Unix}} systems due to OSS and ALSA being incapable of handling multiple audio streams natively. Will probably become redundant once ALSA and OSS implement driver-level mixing.
* ''NAS'': The Network Audio System. Primarily found in Sun's [=SunOS=] (for which it was initially developed for) and Solaris systems, although it can be compiled and run on other Unix systems that uses OSS or has OSS compatibility.
* ''ESD'': The Enlightened Sound Daemon: Largely forgotten nowadays, it was the predecessor of Gnome's own [=PulseAudio=] system, and largely abandoned after the schism between Gnome and the Enlightenment Project.
* ''[=aRts=]'': The mixer daemon used by KDE prior to version 4.
* ''[=PulseAudio=]'': The mixer daemon found in Gnome 2.10 and higher, replacing ''ESD''. Comes with a set of ESD compatibility libraries to ensure older programs written for ESD will still run on it.
* ''Phonon'': The mixer daemon found in KDE 4 and higher, replacing ''[=aRts=]''.
* ''JACK'': A low latency mixer library targeted at applications that requires fast audio mixing, for example professional music and audio programs like ''[=RoseGarden=]'' and ''[=Hydrogen=]''. Very CPU intensive and works best with special realtime kernels in most Linux distributions.
* ''[=SndIOd=]'': Found in BSD systems like ''[=OpenBSD=]'', just because they do not agree with the licensing used by the other mixers.

!!Compute API
[[AC:[=CUDA=]]]

One of the first API specifically made for general purpose GPU support developed by NVIDIA. They were pretty big pushers for the [=GPGPU=] idea after releasing the GeForce 8 series.

[[AC:[=OpenCL=]]]

Initially developed by Apple with support from AMD, IBM, Intel, and NVIDIA. It was later submitted to the Khronos Group (who maintain [=OpenGL=]). This is largely CUDA's main competitor in terms of GPGPU compute API.

[[AC:[=DirectCompute=]]]

Microsoft's answer to both [=CUDA=] and [=OpenCL=], although it's not frequently used since [=GPGPU=] is a technology mostly used by experimental supercomputing server farms, which usually prefers {{Unix}} that [=OpenCL=] and [=CUDA=] natively supports.

It however enjoys usage in games to perform things such as physics calculations and post-processing antialiasing, mostly because it's already part of the [=DirectX=] library.

!!Miscellaneous API
* [=DirectInput=]: The [=DirectX=] component that is largely responsible for handling input. Partially superseded.
** [=XInput=]: The new API that has partially superseded [=DirectInput=]. Has a BrokenBase due to the fact that the gamepad part of the API is specialized for the {{Xbox 360}} controller and thus does not work well with other USB gamepads, particularly those with more buttons and axes compared to the Xbox 360 controller.
* ''Video For Windows'': An early API for Windows 3.1 meant to be used to display videos in programs. Many third party programs and games relied on it. It was eventually replaced by:
* ''[=ActiveMovie=]'': You may have heard of it- it was a short-lived API that was meant to be used to implement FMV cutscenes in games among other things. It was later rechristened ''[=DirectShow=]''. Egregiously, games that used earlier versions of the API will have problems playing back their [=FMV=] on systems that run later versions of [=DirectX=]. It has since been replaced by:
** ''Media Foundation'': A new API for media playback in programs.
* ''[=QuickTime=]'' is widely known as Apple's media player for Macs, but it also provide a set of [=APIs=] to allow for third party programs and games to use it for playing back FMV cutscenes or other videos. {{Myst}} used the API heavily.
* ''[=FFMpeg=]'': A popular API used by many Media Player and Multimedia Editing programs in Unix, and also used by some games for the platform.

!!![[AC:[=Running alien software=]]]
An API is an interface, so it's only natural that people tried to let a program interact with a translation layer, resembling an OS sitting on top of the native OS - thus allowing a program to work under an OS it wasn't made for, as long as less flexible things (like CPU commands) are all the same. Naturally, x86 is the most interesting for a majority of users, as Windows and Unix (Linux and OS X) are the most desirable targets. True emulators and virtual machines eat a lot of resources, but API translators are much less voracious. Results are good, though this approach isn't a universal silver bullet and ''some'' performance is always sacrificed for translation.
* [[http://www.cygwin.com/ Cygwin]] is a Unix-like environment for Windows. It's ''not'' a way to run native Linux apps on Windows. You have to rebuild your application from the source if you want it to run on Windows. However, apps for Linux tend to be open source, so "rebuild" usually means just one or two extra commands as part of the installation process. It's free and open source.
** Then, there's [[http://mingw.org/ MinGW]], ''Minimalist GNU for Windows''. Theoretically, it functions the same way as Cygwin does (although technically, there is one major difference that hampers its compatibility). Of course, in the open source world that Linux resides in, friendly competition is good.
** For those who likes living in the 80s, there is [[http://www.delorie.com/djgpp/ DJGPP]], which is a port of the Unix-like environment to DOS-based systems. However, it has not been updated for years.
* [[http://www.andlinux.org/ andLinux]], on the other hand, is an actual Linux environment for Windows. Unlike Cygwin, it can actually run Linux programs on Windows, as it actually runs a modified Linux kernel as a compatibility layer. andLinux is based on Ubuntu Linux, and is able to use the same packages. It's free and open source, as befits a Linux distribution.
* [[http://www.winehq.org/ Wine]] is a translation layer (a program loader) capable of running Windows applications on Linux and other POSIX compatible operating systems (including post-2005 [[AppleMacintosh Intel Macs]]). It naturally has [=OpenGL=] and even limited [=DirectX=] support. [[http://appdb.winehq.org/ Application Database]] has information on more than 10,000 applications' compatibility with Wine. It, too, is free and open source.
** [[http://www.cedega.com/support/about-cedega/ Cedega]] (formerly known as [=WineX=]) is a commercial "run Windows games on Linux" translation software, naturally focused on [=DirectX=] support. It also has some sort of limited, but free, open source demo version. Cedega was retired in February 2011, but it's back-end was rechristened GameTreeLinux and became completely free (albeit still requiring one to sign up for the service). The company behind Cedega, Transgaming, also offers a technology called "Cider" to quickly port PC software to the Mac OS X platform.
** [[http://www.codeweavers.com/ CodeWeavers]]' [=CrossOver=] products were Cedega's primary competitor. Like Cedega, they offer Wine distributions that have been modified with proprietary code. Unlike Cedega, they offer different versions of their software for different purposes. They also offer a version of their product that allows Intel Mac OS X users to run windows apps without an emulator or dual-booting. [=CodeWeavers=] is quite popular in the open-source community, as much of their proprietary code are often released back into the open-source WINE project.
* [[http://www.ardi.com/ardi.php ARDI Executor]] allows you to run old Mac software (pre-System 7) on an operating system of your choice. Originally a paid app, it is now free and open source. Development seems to have crawled to a halt, with no one picking up the project. What differentiates this from similar software is the fact that it also emulates a 68k processor used in older Macs, as opposed to requiring said processor in the computer (so it is in fact a semi-emulator).
* There was once talks of implementing a MacOS Classic translation layer for [=PowerPC=] Linux systems (for example, newer {{Amiga}} boxes, [[AppleMacintosh Macs]] converted to run Linux, and {{Creator/IBM}} workstations), like Wine for Intel Unix boxes. It was to be called ''[[PunnyName Mace]]''. The project apparently went nowhere and quickly died when Mac OS X was released, and was totally forgotten when Apple ditched the Power platform for x86. [[hottip:*:Which was a shame, given that such a project nowadays would've been useful in providing a legal alternative to running Mac-exclusive software on other operating systems aside from the usual solution of building a hackintosh. Yes, there are a handful of pompous developers who only releases software and games for Mac OS X, although most people in the Linux and Windows world ignore them and think that said developers are deluded.]]
----
<<|HowVideoGameSpecsWork|>>

to:

->''The wonderful thing about standards is that there are so many of them to choose from.''
->--'''The UNIX-HATERS Handbook'''

An API, or Application Programming Interface, is a communication protocol between two sets of code. It's like a language; both parties agree that words have a particular meaning, so that they can talk to each other.

Why? Because Software is Hard.

Hardware makers do their best ''not'' to agree on how hardware should be made. Power requirements & connections have to be standardized, but how do you think they could actually make such a great [=XYZ5000=] if they actually told you how they did it?

A driver implements a particular [=API=] that the operating system requires for interfacing with a certain kind of hardware. So hardware makers write 'software drivers' that allow your lowly computer to understand & communicate with the awesomeness that is their [=XYZ5000=], at least on a basic level.

So your computer can now handle the hardware, be it Microsoft Windows, MacOS, or UsefulNotes/{{UNIX}}.

However, Microsoft, Apple, or the various makers of the various *nix's are not stupid; they know there's malicious (or just poorly written) code out there. They are not just going to let any old program willy talk to drivers. ''Especially'' drivers relating to drawing stuff on the screen. The OS needs to know about this sort of thing, and it needs to manage access to that hardware.

So the OS exposes an [=API=] that allows other programs to talk to the hardware.

[=OpenGL=] and [=Direct3D=] are the two available [=APIs=] for dealing with 3D graphics. An interesting aspect of both [=APIs=] is that, because they directly access hardware, their features are very reliant on the underlying code. Previous graphics cards may work, as there's usually a built-in render path using older versions, but you usually won't see the new features. There are also programs which implement the [=API=] in software, although the featureset and performance is always well under what you can find in hardware.

Frequently, how efficiently these pieces of Hardware work with [=APIs=] depend not only on the hardware, but on how nicely they play with [=APIs=] (part of software drivers). The amount of work put into this, in part, is determined by how much money they expect to make from them. ''In the future''. So old hardware slowly migrates to the great big garbage dump in the sky, because there is no money to be made.

There have also been cases of newer graphics cards omitting or otherwise breaking little-used features that some games during the [=Direct3D=] 7 and prior era used, either at the driver or hardware level, so don't expect perfect backwards compatibility. Sometimes you might just have to build an old computer to run a suitably old game well, or even at all.

!!Graphics API
[[AC:Glide]]

The first most widespread graphics API. It was developed by video card maker [=3dfx=] for use in their cards. It was one of the most widely used [=APIs=] until about 1998 or so, when [=DirectX=] and [=OpenGL=] were mature enough and the fact the API only worked on [=3dfx=] cards, while NVIDIA and ATI were coming out with their own hardware.

Much love still remains for this API, with people creating "Glide Wrappers" for games that don't officially support it.

[[AC:[=Direct3D=]]]

[=Direct3D=] is Microsoft's baby, and, thus, it's only available through Microsoft Windows operating systems, the {{Xbox}} consoles, and through very careful and questionably legal reverse engineering schemes. It is often referred to as [=DirectX=] even though [=DirectX=] is an entire suite of [=APIs=] for dealing with more than just rendering (sound, input), of which [=Direct3D=] is just one member.

The current popular versions of [=DirectX=] are 9.0c and 11. DirectX 9.0c survives because the {{Xbox 360}} runs on it and many [[SoftwarePorting ports]] from the 360 to Windows run on it, and thus Windows XP. [=DirectX 11=] requires Windows Vista [=SP2=] (with some further updates), Windows 7, or Windows 8 and compatible video cards. While [=DirectX=] officially only operates in Windows and on the Xbox systems, [=WINE=] and Cedega groups have gotten some features to work fairly well on Linux.

In case you're wondering where's [=DirectX=] 10, it was released with Windows Vista. Since it offered very few quality advantages over [=DirectX=] 9.0c and was only compatible with Windows Vista, nobody really cared about it.

[[AC:[=OpenGL=]]]

[=OpenGL=] is [=Direct3D's=] primary competitor, and in many ways the tool of choice for cross-platform gaming (though, in truth, it is the only tool for cross-platform game development). [=OpenGL=] is a graphics API, so it only technically competes against [=Direct3D=], the 3D portion of [=DirectX=]; most Windows games that use [=OpenGL=] use the non-graphics part of DirectX for other tasks, while other operating systems use different [=APIs=] for other tasks (for example, [=OpenAL=] for audio acceleration). Many individuals feel it's much easier to program in than [=DirectX=]. However the open standard certainly made it more expandable, and many [=OpenGL=] games such as CityOfHeroes are made up of more extensions than original standard code.

While [=OpenGL=] can work with a variety of operating systems, it does have some downsides. Since [=DirectX=] is nowadays the API of choice, many consumer-oriented graphics cards have horrible [=OpenGL=] support (although this is usually the fault of the card's driver, the card itself has no real concept of OpenGL or DirectX, only the machine language supported by the GPU. This is the reason why the same card may have excellent OpenGL performance if run in Linux than on Windows). Earlier ATI and Intel embedded graphics chips in particular might run a [=DirectX=] game well, but crawl when using [=OpenGL=]. After AMD got ATI, though, [[http://fireuser.com/blog/amd_updates_entire_firepro_line_to_evergreen_gpus/ having fresh cards work with]] any fresh software eventually ceased to be a problem.

The latest version of [=OpenGL=] is 4.5. For older hardware (hardware limited to [=DirectX=] 10), there is version 3.3. For REALLY old hardware that is (huge fake GASP) 5+ years old, there is [=OpenGL=] 2, which roughly corresponds with [=DirectX=] 9.

For embedded applications, such as cell phones and even the PlayStation 3 and Vita, there's a special version of [=OpenGL=] called [=OpenGL ES=]. It's currently on version 3.0 and contains similar features the [=OpenGL=] of the same version.

[[AC:Other Graphics API]]
* '''[=GDI=]''': Microsoft's 2D API for drawing graphics in Windows. It was primarily used in Windows 3.0 up until Windows XP (although using an upgraded version called GDI+, which was also backported to Windows 9x, ME and 2000 for use with Microsoft's Office suite). It is supported in Windows Vista and beyond for compatibility reasons.
** '''[=DirectDraw=]''': A 2D API that was part of [=DirectX=], but was released and maintained parallel with GDI+ - while GDI+ is mostly used in productivity software, [=DirectDraw=] is mostly used in 2D games. Like [=Direct2D=] it offers hardware acceleration, albeit a at much more limited scope (it required that the graphics card drivers specifically supported the framework, and doesn't support compute-based acceleration like it's successor, [=Direct2D=]- understandable because compute-capable graphics cards doesn't exist at the time.
** '''[=Direct2D=]''': GDI's and [=DirectDraw=]'s successor. It offers better performance over GDI and allows for even hardware acceleration via compute-capable [=GPUs=].
* Mac OS Classic has the '''Toolbox API''' calls, since most of the graphical code resided within the Macintosh BIOS itself.
** There is also '''[=QuickDraw=]''' which is an accelerated graphics API for Classic Macs. Like [=DirectDraw=], it supported special ''accelerator cards''.
* '''Carbon''' for Mac OS, a high level API meant to ease the transition to ...
* '''Cocoa''', an API framework that sits atop Quartz.
* '''[=Quartz=]''': The Macintosh API for rendering graphics. Unsurprisingly, it is only available on AppleMacintosh computers running OS X. A revised version with hardware acceleration called '''[=Quartz Extreme=]''' was introduced with OS X 10.2 and persists to this day.
* '''[=SDL=]''': The ''Simple [=DirectMedia=] Layer''- a large API for handling graphics (with delegation of 3D rendering to [=OpenGL=]), sound, input and networking. Highly favored by commercial game companies due to ease of use and that porting games that are written around the DirectX API to other platforms using SDL requires very little effort. ValveSoftware's Linux port of Steam and various Steam games, for example, use this API heavily.
* '''[=GGI=]''': General Graphics Interface- another API specialized in rendering graphics, with a sister library, '''GII''', the General Input Interface, for handling input. Programs that uses it are less common than SDL, but due to it's speed, it has a fanbase.
* '''[=Curses=]''': An API for drawing GUI elements like text boxes, check boxes and menus in ASCII. Superseded by:
** '''[=NCurses=]''': The New Curses library, which is basically an improved version of the Curses API.
* Actually, {{Unix}} systems are just full of separate [=APIs=] that handle drawing GUI elements, due to the ''Choice is good'' mantra (see this page's quote). All of them being methods that sit above the ''[=X Windows=]'' or ''Wayland'' GUI server, which also consists of a server, a set of tools, and an API.
** '''[[WritingAroundTrademarks [=wxWidgets=]]]''', formerly [=wxWindows=]
** '''[=Motif=]''' and it's spinoffs '''[=LessTif=]''' and '''[=OpenMotif=]'''
** '''[=GTK+=]'''
** '''[=Qt=]'''
** '''[=GnomeUI=]''', which is actually an expansion built atop ''GTK+''
** '''[=XAW=]''': the X Athena Widgets API.


!!Audio API
[[AC:[=DirectSound=]]]

The [=DirectX=] component that is responsible for rendering sound in 3D and 2D spaces, as well as mixing audio. Supported in all Windows versions before Windows Vista, where Microsoft rewrote the audio subsystem.

One mixing API that heavily relied on [=DirectSound=] was Creative Lab's EAX.

[[AC:[=OpenAL=]]]

When Microsoft redesigned the driver structure in Windows NT 6 (introduced with Vista) based operating systems, they stripped out key features from [=DirectX=], namely [=DirectSound=]. Creative Labs, who make gaming soundcards, found their EAX now useless. As a result, they developed [=OpenAL=]. While it has support for a wide variety of platforms, it is not open source like the rest of the Open [=APIs=] are.

[[AC:[=OSS=]]]

OSS is the defacto API standard (and driver set) for most {{Unix}} flavors, except under Linux where it has been superseded by [=ALSA=]. Both actually maintains a friendly competition for each other and actually have compatibility libraries to allow support for the competing API (OSS comes with optional libraries to allow for ALSA API compiled programs support- should you decide to throw ALSA out in favor of sticking to OSS on Linux for whatever reason, while ALSA also comes with optional libraries to support programs compiled against the OSS API). And then there's the bunch of Mixer [=APIs=] (see ''Mixer API'' below) that sit above it perform audio mixing since OSS has no ability to do that on their own yet.

[[AC: [=ALSA=]]]

A competing standard and driver set found on most modern Linux distributions, which was created due to a licensing dispute with the creators of OSS. However, even with the dispute, the ALSA team are actually in friendly terms with the OSS team and even offers a compatibility layer to let programs that require OSS to run on ALSA systems, and allow OSS to offer a compatibility library to for providing ALSA program support in OSS. Like OSS, there is a bunch of Mixer [=APIs=] that sit above it (again, see ''Mixer API'' below) to do mixing as ALSA has no ability to do mixing by it's own yet either.

[[AC: [=CoreAudio=]]]

The Macintosh API for handling audio, found on Mac OS X Systems. Again, exclusive to AppleMacintosh computers.

[[AC: [=MME=]]]

The classic Windows API for handling audio, having existed since at least Windows 3.0 and probably not going away anytime soon. Commonly called waveOut after what the function names for playing sound all start with.

[[AC: [=PortAudio=]]]

A portable wrapper API - it just passes everything on to whatever your system's real API is, but largely hides the differences from the program using it.

[[AC:Mixer API]]

A subclass of the Audio API, Mixer [=APIs=] act as a higher level API that provides the ability to mix audio from multiple programs or streams into a single stream prior to feeding it to the sound card of the device. They're typically found in {{Unix}} systems due to OSS and ALSA being incapable of handling multiple audio streams natively. Will probably become redundant once ALSA and OSS implement driver-level mixing.
* ''NAS'': The Network Audio System. Primarily found in Sun's [=SunOS=] (for which it was initially developed for) and Solaris systems, although it can be compiled and run on other Unix systems that uses OSS or has OSS compatibility.
* ''ESD'': The Enlightened Sound Daemon: Largely forgotten nowadays, it was the predecessor of Gnome's own [=PulseAudio=] system, and largely abandoned after the schism between Gnome and the Enlightenment Project.
* ''[=aRts=]'': The mixer daemon used by KDE prior to version 4.
* ''[=PulseAudio=]'': The mixer daemon found in Gnome 2.10 and higher, replacing ''ESD''. Comes with a set of ESD compatibility libraries to ensure older programs written for ESD will still run on it.
* ''Phonon'': The mixer daemon found in KDE 4 and higher, replacing ''[=aRts=]''.
* ''JACK'': A low latency mixer library targeted at applications that requires fast audio mixing, for example professional music and audio programs like ''[=RoseGarden=]'' and ''[=Hydrogen=]''. Very CPU intensive and works best with special realtime kernels in most Linux distributions.
* ''[=SndIOd=]'': Found in BSD systems like ''[=OpenBSD=]'', just because they do not agree with the licensing used by the other mixers.

!!Compute API
[[AC:[=CUDA=]]]

One of the first API specifically made for general purpose GPU support developed by NVIDIA. They were pretty big pushers for the [=GPGPU=] idea after releasing the GeForce 8 series.

[[AC:[=OpenCL=]]]

Initially developed by Apple with support from AMD, IBM, Intel, and NVIDIA. It was later submitted to the Khronos Group (who maintain [=OpenGL=]). This is largely CUDA's main competitor in terms of GPGPU compute API.

[[AC:[=DirectCompute=]]]

Microsoft's answer to both [=CUDA=] and [=OpenCL=], although it's not frequently used since [=GPGPU=] is a technology mostly used by experimental supercomputing server farms, which usually prefers {{Unix}} that [=OpenCL=] and [=CUDA=] natively supports.

It however enjoys usage in games to perform things such as physics calculations and post-processing antialiasing, mostly because it's already part of the [=DirectX=] library.

!!Miscellaneous API
* [=DirectInput=]: The [=DirectX=] component that is largely responsible for handling input. Partially superseded.
** [=XInput=]: The new API that has partially superseded [=DirectInput=]. Has a BrokenBase due to the fact that the gamepad part of the API is specialized for the {{Xbox 360}} controller and thus does not work well with other USB gamepads, particularly those with more buttons and axes compared to the Xbox 360 controller.
* ''Video For Windows'': An early API for Windows 3.1 meant to be used to display videos in programs. Many third party programs and games relied on it. It was eventually replaced by:
* ''[=ActiveMovie=]'': You may have heard of it- it was a short-lived API that was meant to be used to implement FMV cutscenes in games among other things. It was later rechristened ''[=DirectShow=]''. Egregiously, games that used earlier versions of the API will have problems playing back their [=FMV=] on systems that run later versions of [=DirectX=]. It has since been replaced by:
** ''Media Foundation'': A new API for media playback in programs.
* ''[=QuickTime=]'' is widely known as Apple's media player for Macs, but it also provide a set of [=APIs=] to allow for third party programs and games to use it for playing back FMV cutscenes or other videos. {{Myst}} used the API heavily.
* ''[=FFMpeg=]'': A popular API used by many Media Player and Multimedia Editing programs in Unix, and also used by some games for the platform.

!!![[AC:[=Running alien software=]]]
An API is an interface, so it's only natural that people tried to let a program interact with a translation layer, resembling an OS sitting on top of the native OS - thus allowing a program to work under an OS it wasn't made for, as long as less flexible things (like CPU commands) are all the same. Naturally, x86 is the most interesting for a majority of users, as Windows and Unix (Linux and OS X) are the most desirable targets. True emulators and virtual machines eat a lot of resources, but API translators are much less voracious. Results are good, though this approach isn't a universal silver bullet and ''some'' performance is always sacrificed for translation.
* [[http://www.cygwin.com/ Cygwin]] is a Unix-like environment for Windows. It's ''not'' a way to run native Linux apps on Windows. You have to rebuild your application from the source if you want it to run on Windows. However, apps for Linux tend to be open source, so "rebuild" usually means just one or two extra commands as part of the installation process. It's free and open source.
** Then, there's [[http://mingw.org/ MinGW]], ''Minimalist GNU for Windows''. Theoretically, it functions the same way as Cygwin does (although technically, there is one major difference that hampers its compatibility). Of course, in the open source world that Linux resides in, friendly competition is good.
** For those who likes living in the 80s, there is [[http://www.delorie.com/djgpp/ DJGPP]], which is a port of the Unix-like environment to DOS-based systems. However, it has not been updated for years.
* [[http://www.andlinux.org/ andLinux]], on the other hand, is an actual Linux environment for Windows. Unlike Cygwin, it can actually run Linux programs on Windows, as it actually runs a modified Linux kernel as a compatibility layer. andLinux is based on Ubuntu Linux, and is able to use the same packages. It's free and open source, as befits a Linux distribution.
* [[http://www.winehq.org/ Wine]] is a translation layer (a program loader) capable of running Windows applications on Linux and other POSIX compatible operating systems (including post-2005 [[AppleMacintosh Intel Macs]]). It naturally has [=OpenGL=] and even limited [=DirectX=] support. [[http://appdb.winehq.org/ Application Database]] has information on more than 10,000 applications' compatibility with Wine. It, too, is free and open source.
** [[http://www.cedega.com/support/about-cedega/ Cedega]] (formerly known as [=WineX=]) is a commercial "run Windows games on Linux" translation software, naturally focused on [=DirectX=] support. It also has some sort of limited, but free, open source demo version. Cedega was retired in February 2011, but it's back-end was rechristened GameTreeLinux and became completely free (albeit still requiring one to sign up for the service). The company behind Cedega, Transgaming, also offers a technology called "Cider" to quickly port PC software to the Mac OS X platform.
** [[http://www.codeweavers.com/ CodeWeavers]]' [=CrossOver=] products were Cedega's primary competitor. Like Cedega, they offer Wine distributions that have been modified with proprietary code. Unlike Cedega, they offer different versions of their software for different purposes. They also offer a version of their product that allows Intel Mac OS X users to run windows apps without an emulator or dual-booting. [=CodeWeavers=] is quite popular in the open-source community, as much of their proprietary code are often released back into the open-source WINE project.
* [[http://www.ardi.com/ardi.php ARDI Executor]] allows you to run old Mac software (pre-System 7) on an operating system of your choice. Originally a paid app, it is now free and open source. Development seems to have crawled to a halt, with no one picking up the project. What differentiates this from similar software is the fact that it also emulates a 68k processor used in older Macs, as opposed to requiring said processor in the computer (so it is in fact a semi-emulator).
* There was once talks of implementing a MacOS Classic translation layer for [=PowerPC=] Linux systems (for example, newer {{Amiga}} boxes, [[AppleMacintosh Macs]] converted to run Linux, and {{Creator/IBM}} workstations), like Wine for Intel Unix boxes. It was to be called ''[[PunnyName Mace]]''. The project apparently went nowhere and quickly died when Mac OS X was released, and was totally forgotten when Apple ditched the Power platform for x86. [[hottip:*:Which was a shame, given that such a project nowadays would've been useful in providing a legal alternative to running Mac-exclusive software on other operating systems aside from the usual solution of building a hackintosh. Yes, there are a handful of pompous developers who only releases software and games for Mac OS X, although most people in the Linux and Windows world ignore them and think that said developers are deluded.]]
----
<<|HowVideoGameSpecsWork|>>
[[redirect:UsefulNotes/ApplicationProgrammingInterface]]
13th Aug '13 9:15:09 PM RAMChYLD
Is there an issue? Send a Message


A competing standard and driver set found on most modern Linux distributions, which was created due to a licensing dispute with the creators of OSS. However, even with the dispute, the ALSA team are actually in friendly terms with the OSS team even offers a compatibility layer to let programs that require OSS to run on ALSA systems, and OSS offers a compatibility layer to let programs that requires ALSA to run on OSS systems. Like OSS, there is a bunch of Mixer [=APIs=] that sit above it (again, see ''Mixer API'' below) to do mixing as ALSA has no ability to do mixing by it's own yet either.

to:

A competing standard and driver set found on most modern Linux distributions, which was created due to a licensing dispute with the creators of OSS. However, even with the dispute, the ALSA team are actually in friendly terms with the OSS team and even offers a compatibility layer to let programs that require OSS to run on ALSA systems, and allow OSS offers to offer a compatibility layer library to let programs that requires for providing ALSA to run on OSS systems.program support in OSS. Like OSS, there is a bunch of Mixer [=APIs=] that sit above it (again, see ''Mixer API'' below) to do mixing as ALSA has no ability to do mixing by it's own yet either.
13th Aug '13 9:12:42 PM RAMChYLD
Is there an issue? Send a Message


A subclass of the Audio API, Mixer [=APIs=] act as a higher level API that provides the ability to mix audio from multiple programs or streams into a single stream prior to feeding it to the sound card of the device. They're typically found in {{Unix}} systems due to Unix's method of handling audio being unable to handle multiple audio streams natively. Will probably become redundant once ALSA and OSS implement driver-level mixing.

to:

A subclass of the Audio API, Mixer [=APIs=] act as a higher level API that provides the ability to mix audio from multiple programs or streams into a single stream prior to feeding it to the sound card of the device. They're typically found in {{Unix}} systems due to Unix's method OSS and ALSA being incapable of handling audio being unable to handle multiple audio streams natively. Will probably become redundant once ALSA and OSS implement driver-level mixing.
13th Aug '13 9:11:12 PM RAMChYLD
Is there an issue? Send a Message


** '''[=Direct2D=]''': GDI's successor. It offers better performance over GDI and allows for even hardware acceleration via compute-capable [=GPUs=].

to:

** '''[=Direct2D=]''': GDI's and [=DirectDraw=]'s successor. It offers better performance over GDI and allows for even hardware acceleration via compute-capable [=GPUs=].



** There is also '''[=QuickDraw=]''' which is an accelerated graphics API for Classic Macs. Like DirectDraw, it supported special ''accelerator cards''.

to:

** There is also '''[=QuickDraw=]''' which is an accelerated graphics API for Classic Macs. Like DirectDraw, [=DirectDraw=], it supported special ''accelerator cards''.



A subclass of the Audio API, Mixer [=APIs=] act as a higher level API that provides the ability to mix programs from multiple programs or streams into a single stream prior to feeding it to the sound card of the device. They're typically found in {{Unix}} systems due to Unix's method of handling audio being unable to handle multiple audio streams natively. Will probably become redundant once ALSA and OSS implement driver-level mixing.

to:

A subclass of the Audio API, Mixer [=APIs=] act as a higher level API that provides the ability to mix programs audio from multiple programs or streams into a single stream prior to feeding it to the sound card of the device. They're typically found in {{Unix}} systems due to Unix's method of handling audio being unable to handle multiple audio streams natively. Will probably become redundant once ALSA and OSS implement driver-level mixing.
13th Aug '13 1:27:13 PM RAMChYLD
Is there an issue? Send a Message


* ''QuickTime'' is widely known as Apple's media player for Macs, but it also provide a set of [=APIs=] to allow for third party programs and games to use it for playing back FMV cutscenes or other videos. {{Myst}} used the API heavily.

to:

* ''QuickTime'' ''[=QuickTime=]'' is widely known as Apple's media player for Macs, but it also provide a set of [=APIs=] to allow for third party programs and games to use it for playing back FMV cutscenes or other videos. {{Myst}} used the API heavily.
13th Aug '13 1:26:47 PM RAMChYLD
Is there an issue? Send a Message



to:

* ''Video For Windows'': An early API for Windows 3.1 meant to be used to display videos in programs. Many third party programs and games relied on it. It was eventually replaced by:
* ''[=ActiveMovie=]'': You may have heard of it- it was a short-lived API that was meant to be used to implement FMV cutscenes in games among other things. It was later rechristened ''[=DirectShow=]''. Egregiously, games that used earlier versions of the API will have problems playing back their [=FMV=] on systems that run later versions of [=DirectX=]. It has since been replaced by:
** ''Media Foundation'': A new API for media playback in programs.
* ''QuickTime'' is widely known as Apple's media player for Macs, but it also provide a set of [=APIs=] to allow for third party programs and games to use it for playing back FMV cutscenes or other videos. {{Myst}} used the API heavily.
* ''[=FFMpeg=]'': A popular API used by many Media Player and Multimedia Editing programs in Unix, and also used by some games for the platform.
13th Aug '13 1:12:39 PM RAMChYLD
Is there an issue? Send a Message


** '''[=DirectDraw=]''': A 2D API that was part of [=DirectX=], but was released and maintained parallel with GDI+ - while GDI+ is mostly used in productivity software, [=DirectDraw=] is mostly used in 2D games. Like Direct2D it offers hardware acceleration, albeit a at much more limited scope (it required that the graphics card drivers specifically supported the framework, and doesn't support compute-based acceleration like it's successor, [=Direct2D=]- understandable because compute-capable graphics cards doesn't exist at the time.

to:

** '''[=DirectDraw=]''': A 2D API that was part of [=DirectX=], but was released and maintained parallel with GDI+ - while GDI+ is mostly used in productivity software, [=DirectDraw=] is mostly used in 2D games. Like Direct2D [=Direct2D=] it offers hardware acceleration, albeit a at much more limited scope (it required that the graphics card drivers specifically supported the framework, and doesn't support compute-based acceleration like it's successor, [=Direct2D=]- understandable because compute-capable graphics cards doesn't exist at the time.
13th Aug '13 1:11:14 PM RAMChYLD
Is there an issue? Send a Message


** '''[=Direct2D=]''': GDI's successor. It offers better performance over GDI and allows for even hardware acceleration.

to:

** '''[=Direct2D=]''': GDI's successor. It offers better performance over GDI and allows for even hardware acceleration.acceleration via compute-capable [=GPUs=].



** There is also '''[=QuickDraw='''] which is an accelerated graphics API for Classic Macs.

to:

** There is also '''[=QuickDraw='''] '''[=QuickDraw=]''' which is an accelerated graphics API for Classic Macs.Macs. Like DirectDraw, it supported special ''accelerator cards''.
13th Aug '13 1:09:43 PM RAMChYLD
Is there an issue? Send a Message


* [=GDI=]: Microsoft's 2D API for drawing graphics in Windows. It was primarily used in Windows 3.0 up until Windows XP (although using an upgraded version called GDI+, which was also backported to Windows 9x, ME and 2000 for use with Microsoft's Office suite). It is supported in Windows Vista and beyond for compatibility reasons.
** [=DirectDraw=]: A 2D API that was part of [=DirectX=], but was released and maintained parallel with GDI+ - while GDI+ is mostly used in productivity software, [=DirectDraw=] is mostly used in 2D games. Like Direct2D it offers hardware acceleration, albeit a at much more limited scope (it required that the graphics card drivers specifically supported the framework, and doesn't support compute-based acceleration like it's successor, [=Direct2D=]- understandable because compute-capable graphics cards doesn't exist at the time.
** [=Direct2D=]: GDI's successor. It offers better performance over GDI and allows for even hardware acceleration.
* Mac OS Classic has the Toolbox API calls, since most of the graphical code resided within the Macintosh BIOS itself.
** There is also [=QuickDraw=] which is a graphics API for Classic Macs.
* Carbon for Mac OS, a high level API meant to ease the transition to ...
* Cocoa, an API framework that sits atop Quartz.
* [=Quartz=]: The Macintosh API for rendering graphics. Unsurprisingly, it is only available on AppleMacintosh computers running OS X. A revised version with hardware acceleration called [=Quartz Extreme=] was introduced with OS X 10.2 and persists to this day.
* [=SDL=]: The Simple [=DirectMedia=] Layer- a large API for handling graphics (with delegation of 3D rendering to [=OpenGL=]), sound, input and networking. Highly favored by commercial game companies due to ease of use and that porting games that are written around the DirectX API to other platforms using SDL requires very little effort. ValveSoftware's Linux port of Steam and various Steam games, for example, use this API heavily.
* [=GGI=]: General Graphics Interface- another API specialized in rendering graphics, with a sister library, GII, the General Input Interface, for handling input. Programs that uses it are less common than SDL, but due to it's speed, it has a fanbase.
* [=Curses=]: An API for drawing GUI elements like text boxes, check boxes and menus in ASCII. Superseded by:
** [=NCurses=]: The New Curses library, which is basically an improved version of the Curses API.

to:

* [=GDI=]: '''[=GDI=]''': Microsoft's 2D API for drawing graphics in Windows. It was primarily used in Windows 3.0 up until Windows XP (although using an upgraded version called GDI+, which was also backported to Windows 9x, ME and 2000 for use with Microsoft's Office suite). It is supported in Windows Vista and beyond for compatibility reasons.
** [=DirectDraw=]: '''[=DirectDraw=]''': A 2D API that was part of [=DirectX=], but was released and maintained parallel with GDI+ - while GDI+ is mostly used in productivity software, [=DirectDraw=] is mostly used in 2D games. Like Direct2D it offers hardware acceleration, albeit a at much more limited scope (it required that the graphics card drivers specifically supported the framework, and doesn't support compute-based acceleration like it's successor, [=Direct2D=]- understandable because compute-capable graphics cards doesn't exist at the time.
** [=Direct2D=]: '''[=Direct2D=]''': GDI's successor. It offers better performance over GDI and allows for even hardware acceleration.
* Mac OS Classic has the Toolbox API '''Toolbox API''' calls, since most of the graphical code resided within the Macintosh BIOS itself.
** There is also [=QuickDraw=] '''[=QuickDraw='''] which is a an accelerated graphics API for Classic Macs.
* Carbon '''Carbon''' for Mac OS, a high level API meant to ease the transition to ...
* Cocoa, '''Cocoa''', an API framework that sits atop Quartz.
* [=Quartz=]: '''[=Quartz=]''': The Macintosh API for rendering graphics. Unsurprisingly, it is only available on AppleMacintosh computers running OS X. A revised version with hardware acceleration called [=Quartz Extreme=] '''[=Quartz Extreme=]''' was introduced with OS X 10.2 and persists to this day.
* [=SDL=]: '''[=SDL=]''': The Simple ''Simple [=DirectMedia=] Layer- Layer''- a large API for handling graphics (with delegation of 3D rendering to [=OpenGL=]), sound, input and networking. Highly favored by commercial game companies due to ease of use and that porting games that are written around the DirectX API to other platforms using SDL requires very little effort. ValveSoftware's Linux port of Steam and various Steam games, for example, use this API heavily.
* [=GGI=]: '''[=GGI=]''': General Graphics Interface- another API specialized in rendering graphics, with a sister library, GII, '''GII''', the General Input Interface, for handling input. Programs that uses it are less common than SDL, but due to it's speed, it has a fanbase.
* [=Curses=]: '''[=Curses=]''': An API for drawing GUI elements like text boxes, check boxes and menus in ASCII. Superseded by:
** [=NCurses=]: '''[=NCurses=]''': The New Curses library, which is basically an improved version of the Curses API.



** [[WritingAroundTrademarks [=wxWidgets=]]], formerly [=wxWindows=]
** [=Motif=] and it's spinoffs [=LessTif=] and [=OpenMotif=]
** [=GTK+=]
** [=Qt=]
** [=GnomeUI=], which is actually an expansion built atop GTK+
** [=XAW=]: the X Athena Widgets API.


to:

** [[WritingAroundTrademarks [=wxWidgets=]]], '''[[WritingAroundTrademarks [=wxWidgets=]]]''', formerly [=wxWindows=]
** [=Motif=] '''[=Motif=]''' and it's spinoffs [=LessTif=] '''[=LessTif=]''' and [=OpenMotif=]
'''[=OpenMotif=]'''
** [=GTK+=]
'''[=GTK+=]'''
** [=Qt=]
'''[=Qt=]'''
** [=GnomeUI=], '''[=GnomeUI=]''', which is actually an expansion built atop GTK+
''GTK+''
** [=XAW=]: '''[=XAW=]''': the X Athena Widgets API.

13th Aug '13 1:07:09 PM RAMChYLD
Is there an issue? Send a Message

Added DiffLines:

** [=DirectDraw=]: A 2D API that was part of [=DirectX=], but was released and maintained parallel with GDI+ - while GDI+ is mostly used in productivity software, [=DirectDraw=] is mostly used in 2D games. Like Direct2D it offers hardware acceleration, albeit a at much more limited scope (it required that the graphics card drivers specifically supported the framework, and doesn't support compute-based acceleration like it's successor, [=Direct2D=]- understandable because compute-capable graphics cards doesn't exist at the time.
This list shows the last 10 events of 81. Show all.
http://tvtropes.org/pmwiki/article_history.php?article=Main.ApplicationProgrammingInterface