Community Hub0 Subscribers
Community hub
Glide (API)
View on Wikipediafrom Wikipedia
 | This article needs additional citations for verification. (August 2017) |
| Glide | |
|---|---|
| Original author | 3dfx Interactive |
| Stable release | 3.10.00.30303
/ September 2, 2003 |
| Written in | Assembly, C |
| Operating system | Cross-platform |
| Type | 3D graphics API |
| License |
|
| Website | sourceforge |
Glide is a 3D graphics API developed by 3dfx Interactive for their Voodoo Graphics 3D accelerator cards. It started as a proprietary API but was later open-sourced by 3dfx.[2][3] It was dedicated to rendering performance, supporting geometry and texture mapping primarily, in data formats identical to those used internally in their cards.[4][5] Wide adoption of 3Dfx led to Glide being extensively used in the late 1990s, but further refinement of Microsoft's Direct3D and the appearance of full OpenGL implementations from other graphics card vendors, in addition to growing diversity in 3D hardware, eventually caused it to become superfluous.[5]
Glide wrappers and emulators
[edit]Glide emulator development has been in progress since the late 1990s. During 3dfx's lifetime, the company was aggressive at trying to stop these attempts to emulate their proprietary API, shutting down early emulation projects with legal threats.[6] However, just before it ceased operations and had its assets purchased by Nvidia, 3dfx released the Glide API, along with the Voodoo 2 and Voodoo 3 specifications, under an open-source license,[7] which later evolved into an open-source project.[8]
See also
[edit]- Vulkan (API)
- 3dfx Interactive
- MiniGL
- Mantle (API) – another low-level API
References
[edit]- ^ "3DFX GLIDE Source Code General Public License". GitHub. 3dfx. 1999-12-06. Archived from the original on December 5, 2021. Retrieved 2024-08-28.
- ^ "The 3DFX GLIDE Source Code General Public License". Archived from the original on 2009-02-10.
- ^ "3dfx Open Sources Glide API And Releases Hardware Specifications" (Press release). 3dfx. 1999-12-06. Archived from the original on 2000-03-03. Retrieved 2024-08-28.
- ^ MacLellan, Andrew (1995-11-06). "Startup 3Dfx Eyes 3D Graphics Arena". Electronic News. Vol. 41, no. 2090. p. 84. Retrieved 2024-08-24.
- ^ a b Ajami, Amer (1999-12-06). "3dfx Open Sources Glide". GameSpot. Archived from the original on December 5, 2021. Retrieved 2024-08-28.
- ^ "3dfx wraps up wrapper Web sites". The Register. April 8, 1999. Archived from the original on August 10, 2017. Retrieved August 10, 2017.
- ^ "3dfx open sources Glide, Voodoo 2 and 3 specs". The Register. Archived from the original on 2019-12-28. Retrieved 2017-08-10.
- ^ "Glide for 3dfx hardware". 3 April 2013. Archived from the original on 13 November 2012. Retrieved 20 April 2010.
External links
[edit]- Glide SourceForge Project. Archived 2012-02-08 at the Wayback Machine
- GLIDE programming manual. Archived 2012-04-02 at the Wayback Machine
- Glide Wrappers List. Archived 2012-01-26 at the Wayback Machine
- OpenGL Documentation. Archived 2012-01-15 at the Wayback Machine
| Graphics processors |  | |
|---|---|---|
| Acquisitions | ||
| Related articles | ||
Glide (API)
View on Grokipediafrom Grokipedia
History
Origins and development
3dfx Interactive was founded on August 24, 1994, in San Jose, California, by Ross Smith, Scott Sellers, and Gary Tarolli, all former employees of Silicon Graphics (SGI) who had previously worked on advanced graphics systems.[6] The trio, backed by venture capitalist Gordon Campbell, aimed to create high-performance 3D graphics hardware tailored for the emerging consumer gaming market, capitalizing on the popularity of titles like DOOM and Descent.[12] Glide was conceived from the outset as a proprietary, low-level API specifically designed to unlock the full potential of 3dfx's Voodoo Graphics hardware by providing direct, efficient access to its rasterization and rendering features.[13] Development of Glide began in 1995 and continued through 1996, with the API implemented primarily in Assembly and C to ensure minimal overhead and optimal hardware control.[14] As a thin software layer, it exposed the Voodoo chip's architecture directly to developers, allowing for precise management of video RAM and specialized functions like texture mapping and anti-aliasing without the abstractions of more general APIs.[12] This approach was inspired by SGI's IRIS GL but streamlined for the Voodoo's dual-ASIC design, which separated texture mapping units (TMU) from the framebuffer interface (FBI) to prioritize 3D gaming performance over 2D capabilities.[3] The core design philosophy of Glide emphasized simplicity and accessibility for game developers, focusing on a narrow set of gaming-specific optimizations rather than broad interoperability or standards compliance.[13] By avoiding direct competition with OpenGL and instead offering a straightforward interface—using "gr" prefixed functions for commands—it enabled rapid integration and maximized hardware utilization, such as bilinear filtering and Z-buffering, while reducing the need for developers to reverse-engineer the hardware.[12] This developer-centric focus was intended to foster quick adoption in an era lacking standardized 3D APIs for consumer hardware.[6] Early prototypes of Glide were rigorously tested with internal demos during 1996, highlighting the Voodoo 1's abilities in real-time 3D rendering at resolutions up to 640x480.[12] These tests, including arcade-style simulations like Home Run Derby showcased at E3 1996, validated the API's role in demonstrating the hardware's speed and features, such as 1 million triangles per second processing, paving the way for its integration into PC gaming.[6]Release and adoption
Glide was officially released in November 1996 alongside 3dfx's Voodoo Graphics chipset, bundled as part of the software development kit (SDK) provided to developers for creating optimized 3D applications on the new hardware.[3] The SDK included the Glide API as a low-level rasterization library, initially supporting DOS and IRIX environments, and was distributed freely to encourage rapid integration into games and tools.[2] The API saw rapid adoption during the late 1990s PC gaming boom, with early support added to id Software's Quake (released June 1996) via a Glide wrapper DLL provided by 3dfx shortly after the Voodoo launch, enabling enhanced performance through hardware acceleration.[15] This momentum continued, leading to over 100 games supporting Glide by mid-1998, including titles like Tomb Raider II and Unreal, which leveraged the API for superior rendering on Voodoo cards.[16] By 1997, Glide-powered Voodoo cards had achieved market dominance in the 3D accelerator segment, capturing an estimated 80-85% of the market by year-end while Nvidia held about 24%, amid the growing demand for 3D gaming.[17] The cards were particularly praised for features such as bilinear texture filtering and 16-bit color depth, which delivered smoother visuals and deeper colors compared to contemporaries, contributing to their widespread appeal in consumer and gaming PCs.[4] Developers appreciated Glide's ease of use relative to Microsoft's Direct3D at the time, citing its straightforward access to Voodoo-specific hardware capabilities without the complexity of broader cross-platform abstractions.[18] 3dfx bolstered this adoption by offering the SDK at no cost and providing dedicated technical support, which facilitated quick porting and optimization efforts for game studios targeting the burgeoning 3D market.[19]Open-sourcing and decline
On December 6, 1999, 3dfx Interactive announced the open-sourcing of the Glide API, releasing its source code under the 3DFX GLIDE Source Code General Public License, a permissive license allowing modification and distribution of derived works while restricting certain commercial uses of the core API.[20][21][22] This move occurred amid mounting pressures, just over a year before Nvidia announced its acquisition of 3dfx's assets on December 15, 2000, primarily for intellectual property valued at $70 million in cash and 1 million shares of stock.[23] The decline of Glide began with 3dfx's financial difficulties, exacerbated by its $141 million acquisition of STB Systems in December 1998, which shifted the company into full-scale graphics card manufacturing and strained resources as market competition intensified.[7][24] By 1999, 3dfx reported significant losses, including an $11.5 million loss in its second fiscal quarter (ended July 31, 1999), amid declining market share against rivals like Nvidia and ATI.[25] These troubles were compounded by competition from Microsoft's DirectX 6.0, released in August 1998, which included Direct3D enhancements for hardware-agnostic 3D rendering, and the broader adoption of OpenGL as a cross-platform, vendor-neutral alternative that diminished Glide's proprietary advantages.[26] The subsequent DirectX 7.0 release in September 1999 further accelerated this shift by introducing hardware transform and lighting (T&L) support, reducing the need for Glide-optimized games.[27] Prior to open-sourcing, 3dfx actively opposed efforts to extend Glide compatibility beyond its hardware through wrappers and emulators, issuing crackdowns on developers and distributors in April 1999—particularly those supporting the UltraHLE Nintendo 64 emulator—and filing a lawsuit against Creative Labs in June 1999 over a Glide wrapper included in its Graphics Blaster card.[28] These actions, including cease-and-desist demands targeting non-3dfx implementations, aimed to protect Glide's exclusivity but were abandoned by December 1999 with the API's release.[28] Following Nvidia's acquisition, Glide maintenance continued briefly under the new ownership, culminating in the final stable release, version 3.10, on September 2, 2003, before being discontinued as Nvidia prioritized OpenGL and DirectX drivers for its GeForce lineup. Post-open-sourcing, community-driven emulation efforts emerged to preserve Glide compatibility on modern hardware.Technical overview
Core architecture
Glide's core architecture is designed as a thin, hardware-specific rasterization library tailored for 3dfx Voodoo chipsets, employing a hybrid implementation in C and assembly language to enable direct access to the graphics hardware while bypassing operating system layers, thereby achieving minimal latency in the rendering pipeline.[2] This low-overhead approach, with performance impacts limited to 5-10%, abstracts low-level hardware details to support efficient real-time 3D rendering on 1990s-era processors.[2] Central to the architecture are key components for managing hardware resources and rendering states. Device initialization occurs via functions such asgrSstSelect, which selects the Voodoo Graphics subsystem, followed by grSstWinOpen to configure resolution, refresh rate, and color formats.[1] Buffer management is handled by grBufferSwap, which exchanges front and back buffers with options for vertical retrace synchronization to prevent tearing.[1] State management relies on grEnable and grDisable to toggle features like fog (e.g., GR_FOG_WITH_TABLE_ON_Q), depth buffering, and anti-aliasing through a state machine that minimizes bandwidth usage.[2]
The rendering model adopts a single-pass approach optimized for 3dfx's SST (Single-Stream Triangle) architecture, where geometry setup and scan conversion are processed internally by dedicated chips like Pixelfx for pixel operations and Texelfx for texture mapping, supporting up to 1-10 million triangles per second with multiple texture mapping units (TMUs).[2] This pipeline leverages vertex arrays and packed RGBA data for efficiency, enabling advanced texture features in one traversal without multi-pass overhead.[2]
The memory model allocates 2 MB or 4 MB of VRAM to each TMU for textures, with separate allocation for framebuffers and auxiliary buffers via the FBI, accommodating double or triple buffering configurations with direct linear framebuffer (LFB) access via locking mechanisms.[1] Fixed-point arithmetic, particularly 16-bit formats for z-buffering and optional 16-bit floating-point for w-buffering, ensures precise depth comparisons and computational efficiency suited to the era's hardware constraints.[2]
Key rendering features
Glide's advanced texture mapping capabilities were central to its rendering prowess, providing hardware-accelerated support for mipmapping to reduce aliasing and improve texture quality across distances, with up to nine texture maps per mipmap chain and programmable level-of-detail (LOD) bias for fine-tuned control.[2] Trilinear filtering further enhanced realism by blending between bilinear-filtered mipmaps in a single pass on dual-texture-map-unit (TMU) configurations like the Voodoo 2, minimizing performance overhead while delivering smooth texture transitions.[2] Multitexturing allowed up to two textures per rendering pass on Voodoo 2 hardware through chained TMUs, enabling complex surface effects like light mapping combined with base textures without multiple draw calls.[2] The API's anti-aliasing and blending features leveraged dedicated hardware for high-quality output, including full-screen anti-aliasing (FSAA) at 2x and 4x modes that used supersampling and alpha-based pixel coverage to smooth jagged edges effectively.[29] Alpha blending supported transparent effects with no rasterization penalty, configurable via source and destination factors such as source alpha and one-minus-source-alpha, allowing seamless integration of semi-transparent elements like particles or glass.[2] Special effects in Glide were optimized for immersive visuals, with built-in detail textures that blended secondary high-frequency patterns onto primary textures based on LOD proximity, achievable in a single pass on multi-TMU setups to add surface granularity without bandwidth loss.[29] Chroma-keying discarded pixels matching a specified reference color, facilitating efficient transparency for overlays or sprites in gaming scenes.[1] Volumetric fog applied per-pixel atmospheric effects using a 64-entry lookup table indexed by 1/w for perspective-correct density, supporting modes that integrated fog color and intensity directly into the rendering pipeline for depth-enhanced environments.[2] Performance metrics underscored Glide's efficiency on target hardware, achieving up to 50 million pixels per second fill rate on the Voodoo 1, which supported smooth gameplay at 640x480 resolution exceeding 30 frames per second even in complex, textured scenes.[30] These capabilities prioritized real-time rendering for gaming, balancing visual fidelity with the era's hardware constraints.[2]Programming interface
API structure and functions
The Glide API is structured around a single primary header file,glide.h, which declares all core functions and defines constants using the GR_ prefix for enumerations and parameters, such as GR_CLIP_COORDS for coordinate systems and GR_TMU0 for texture mapping units.[2] Functions follow a gr prefix convention, enabling developers to access hardware-accelerated rendering on 3dfx Voodoo graphics subsystems without managing low-level device details.[1] This design emphasizes simplicity, with the API exposing a streamlined set of calls for scene setup and primitive submission, typically requiring inclusion of glide.h alongside 3dfx.h for base types and constants.[29]
Core functions are categorized into initialization, drawing primitives, and cleanup. Initialization begins with grGlideInit, which detects and configures the 3dfx hardware, followed by grSstSelect to choose a specific graphics subsystem and grSstWinOpen to establish the rendering window with parameters like resolution and buffer depth.[2] Drawing primitives include grDrawTriangle for rendering filled triangles via three vertex parameters (x, y, and attributes like color or texture coordinates), grDrawVertexList or grDrawVertexArray for batching multiple vertices, and specialized variants like grAADrawTriangle for anti-aliased edges.[1] Cleanup is handled by grGlideShutdown to release resources and grSstWinClose to terminate the window, ensuring proper hardware state reset.[29]
Error handling and queries provide debugging and informational support. The grGetString function retrieves version details or extension strings, such as the API version or supported features, while grErrorGet returns error codes for runtime issues like invalid parameters.[2] Developers can install custom error callbacks via grErrorSetCallback for debug builds, and queries like grSstQueryHardware or grBufferNumPending allow checking hardware capabilities or pending buffer swaps to synchronize frame completion.[1]
A typical workflow for a basic scene involves initializing the device with grGlideInit and window setup, configuring render states (e.g., grVertexLayout for attribute packing, grColorCombine for shading modes), submitting triangles via grDrawTriangle, and swapping buffers with grBufferSwap before cleanup—often spanning 50-100 lines of code for simple textured renders.[2] This pattern enables efficient pipeline usage, with functions like grTexCombine briefly referencing texture and blending features for decal or modulated mapping.[1]
Development tools and libraries
3dfx Interactive released the official Software Developer's Kit (SDK) to support Glide API development, comprising the Glide Rasterization Library and accompanying utilities for Windows and DOS environments. The full SDK included sample source code demonstrating core functionalities such as initialization, vertex processing, triangle rendering, texture mapping, and special effects like fogging and blending, enabling developers to optimize applications for Voodoo hardware. Distributed via developer CD-ROMs starting from version 1.0 in 1996, the SDK facilitated high-performance 3D rendering capable of 1-10 million triangles per second through efficient vertex arrays and packed data formats.[31][2] A key component of the SDK was MiniGL, a lightweight OpenGL 1.1 subset wrapper built atop Glide to provide compatibility for existing OpenGL-based games, such as Quake, without extensive code modifications. Official MiniGL releases, including version 1.47 from February 1999, supported Intel, Cyrix, and AMD processors, abstracting Glide calls into familiar OpenGL functions while maintaining hardware acceleration on 3dfx cards. This tool streamlined porting efforts by handling the translation layer, allowing developers to leverage Glide's rasterization strengths indirectly.[31][32] Debugging capabilities within the SDK featured a dedicated debug build of the Glide library, which incorporated parameter validation, error callbacks viagrErrorSetCallback(), and runtime queries using grGet() for performance profiling, such as tracking pixels processed (GR_STATS_PIXELS_IN) and system state on Voodoo hardware. These tools enabled real-time monitoring and optimization during development, contrasting with the release build that omitted validation for maximum speed; developers were advised to switch to the debug version for initial testing and troubleshooting. The SDK also included TexUS, a texture utility for converting images (e.g., from BMP formats) into 3dfx-specific .3DF files with mipmaps and compression tables, essential for preparing assets compatible with Glide's texture download functions like grTexDownloadMipMap().[2]
Third-party libraries extended Glide's ecosystem, with Glide64 emerging as an early wrapper integrating the API into Nintendo 64 emulation projects like Project64, allowing hardware-accelerated rendering of N64 graphics on 3dfx Voodoo cards through Glide3x calls. This plugin supported features like motion blur and frame buffer emulation by mapping N64 RDP commands to Glide primitives, enhancing compatibility and performance in retro emulation contexts.[33][34]
Documentation for Glide development spanned comprehensive manuals from 1996 to 1999, including the Glide Programming Guide, Reference Manual, and SST1 Application Notes, which detailed API functions, context management, and optimization strategies. These resources, bundled on 3dfx developer CD-ROMs, featured tutorials for porting applications from Direct3D to Glide, covering transformations like replacing Direct3D's retained mode with Glide's immediate-mode rasterization and adapting texture and lighting pipelines. The Porting Guide specifically outlined steps for windowed rendering and hardware abstraction, aiding transitions for titles targeting Voodoo Rush and later accelerators.[31][2][35]
Hardware support
Compatible 3dfx products
Glide was initially developed to leverage the capabilities of 3dfx's Voodoo Graphics hardware, providing optimized 3D acceleration for PC gaming in the late 1990s.[36] The Voodoo Rush, released in May 1997, offered Glide compatibility on a PCI card integrating the Voodoo Graphics chip with 2D acceleration, featuring 4 MB or 6 MB EDO RAM (typically 2 MB frame buffer and 2-4 MB texture memory), at 50 MHz with reduced performance due to the PCI interface.[37][38] The Voodoo Graphics, released in November 1996, marked the first implementation of Glide support, featuring 4 MB of EDO RAM (typically configured as 2 MB for the frame buffer and 2 MB for texture storage) and a single-texture pipeline via one Texture Mapping Unit (TMU). This setup enabled resolutions ranging from 512×384 to 800×600, with a peak fill rate of approximately 50 million pixels per second at a 50 MHz core clock, prioritizing high-quality bilinear filtered textures and mipmapping for immersive gameplay in titles like Quake.[4][39] The Voodoo 2, introduced in February 1998, expanded Glide's hardware compatibility with dual-chip Scan-Line Interleave (SLI) support for up to two cards connected via a ribbon cable, allowing doubled performance and resolutions up to 1024×768. It offered 8 MB EDO RAM configurations (e.g., 4 MB frame buffer and 4 MB texture memory across its Pixelfx2 and dual Texelfx2 chips), multitexturing through two TMUs for applying dual textures in a single pass, and an enhanced texel fill rate of up to 180 million texels per second at 90 MHz (pixel fill rate of 90 million pixels per second), significantly boosting efficiency in multitextured scenes compared to its predecessor. Subsequent models further refined Glide integration. The Voodoo3 series, launched in April 1999, incorporated an on-chip 300 MHz RAMDAC for native full-screen 2D/3D switching without requiring a separate VGA card, while delivering full Glide 2.x and 3.x compatibility at clock speeds up to 166 MHz and resolutions supporting 85 Hz at 1600×1200 in 16-bit color. The Banshee, released in late 1998 as 3dfx's first consumer 2D/3D hybrid card, provided full Glide 2.x and 3.x support, operating at 100 MHz with 16 MB or 32 MB SDRAM. Early OpenGL acceleration used the MiniGL library, which translated OpenGL calls to Glide until full OpenGL ICD drivers were released.[40][41] Official Glide support was limited to these earlier series, with no dedicated implementation for the Voodoo4 and Voodoo5 cards released in 2000; by then, 3dfx had prioritized OpenGL and Direct3D, rendering Glide a legacy API for the VSA-100-based successors despite potential third-party workarounds.[42]Integration with operating systems
Glide primarily supported Windows 95 and Windows 98 through installable drivers distributed on 3dfx setup disks, enabling both full-screen and windowed rendering modes via the Win32 API.[43] These drivers facilitated integration with the operating system's graphics subsystem, allowing applications to leverage Voodoo hardware without relying on broader standards like Direct3D or OpenGL. For MS-DOS environments, Glide provided direct hardware access for full-screen operations, using a null window handle in initialization calls to bypass any OS-mediated graphics layers.[29] The architecture of Glide's Windows integration centered on the Glide2x.dll dynamic link library, which supported runtime linking to enable seamless application integration and direct communication with 3dfx hardware, independent of standard OS API calls for rendering.[43] This DLL was included in official 3dfx driver packages, ensuring compatibility with games and tools that statically or dynamically linked against the Glide API for accelerated 3D effects. In practice, developers initialized Glide via functions likegrGlideInit and grSstWinOpen, passing appropriate window handles for Win32 contexts to handle resizing and movement events.[29]
Cross-platform adaptations were limited but notable in community efforts around 1998, particularly for Linux, where unofficial ports emerged to support Voodoo cards under kernels 2.1.x and 2.2.x. These ports included device drivers installed as kernel modules (e.g., creating /dev/3dfx) and utilized X11 for windowed modes through Mesa/GLX integration, with environment variables like MESA_GLX_FX="window" to enable hardware acceleration in 16-bit color depth.[44] Similar limited community drivers appeared for BeOS during this period, extending Glide's reach beyond proprietary Microsoft ecosystems, though official 3dfx backing remained focused on Windows and DOS.[2]
Integration challenges arose with Windows NT and Windows 2000, where native support was absent or severely limited due to the operating systems' stricter kernel protections and, in the case of Windows 2000, mandatory driver signing requirements under WHQL certification.[45] While early NT 4.0 saw some Glide driver availability for Voodoo hardware, the API's direct hardware access model conflicted with NT's protected-mode architecture, often resulting in instability or incompatibility without custom modifications. This lack of official support for these platforms ultimately drove reliance on third-party wrappers for any modern OS compatibility.[46]