L’ultime version de Glide64 qui est le meilleur plugin graphique pour carte \u00e0 base de 3DFX. Pour rappel il utilise le glide wrapper Glitch64 d’Hacktarux et le module GlideHQ (permettant d’afficher des textures en hautes r\u00e9solutions) de KoolSmoky. Il fait directement suite \u00e0 Glide64 Napalm WX’ Release 1.1 et int\u00e8gre toute les am\u00e9liorations de ces derni\u00e8res ann\u00e9es pour les trois modules (glide64, glitch64, glideHQ) .<\/p>\n
Since this is the anniversary release, let me omit the usual \u201cwhat\u2019s new\u201d section. Disclaimer: Sorry for my poor English, my native language is C++<\/p>\n Disclaimer 2: Sorry, if I offended somebody somehow, it was not on purpose.<\/p>\n The beginning. new video plugin uses Glide3x, the proprietary graphics API by 3dfx. That is the plugin was Keep moving. The glide wrapper. When I almost accepted my destiny to become the single user of my video plugin, I unexpectedly got help Frame buffer emulation. Texture enhancement. Enthusiasts of N64 emulation also always wished to somehow improve poor visual quality of their favorite games. Portability. The End. All these ten years I worked on the project using the same PC, powered by Intel Celeron CPU and 3dfx Voodoo card. The Very Special Thanks. My eternal gratitude to Olivieryuyu (France), the main beta tester of the project. Olivieryuyu is Indiana I want to thank all authors of all open-source N64 projects, and especially Orkin, Rice and Ziggy, I want to thank S.M, Emu X Haven Admin\/Webmaster for hosting Glide64 forum and home page. Special thanks to kurono, Special thanks to Pokefan 999, a beta tester, who submitted many bug reports. Happy birthday, Glide64, and farewell! T\u00e9l\u00e9charger Glide64 Final (10th Anniversary) r282 (1.7 Mo)<\/a><\/p>\nThe Glide64 project was started on December 29th, 2001. Today is its 10th anniversary.
\nGood date to make a new release, the final one.<\/p>\n
\nYou may visit project\u2019s source code repository and get lists of commits and fixed bugs.
\nThis day I want to briefly recall most noticeable and important moments of the long
\nproject\u2019s history and people participated in it.<\/p>\n
\nTen years ago David 'Dave2001' Forrester (USA) announced a new graphics plugin for N64 emulators.
\nN64 emulation had been developing pretty rapidly at the beginning of 21th century, so the announce
\nby itself had not been something extraordinary. However, the project immediately caught attention
\nof emulation community. There were at least three reasons for that:<\/p>\n
\ndesigned specially for 3dfx cards. 3dfx company was not officially dead yet, millions of 3dfx
\ncards still were in use. Unfortunately, after release of UltraHLE, N64 emulators offered 3dfx
\nusers little reasons to rejoice. The situation became especially bad with Project64 first
\npublic release. It was great release, which could run many games nearly flawlessly, but not
\non 3dfx cards. While TNT and GeForce users enjoyed perfect picture, 3dfx users contemplated
\numerous color and texture glitches with eternal despondency. It was clear, that Project64 is
\nthe new king of N64 emulation and it was obvious that 3dfx cards will never get good enough
\nDirect3D driver to enjoy it. Fortunately, Project64 not only provided new level of N64 emulation,
\nbut also it introduced new plugin architecture based on open specifications
\n(Zilmar\u2019s plugins specifications). It opened opportunity for third-party plugins creation.
\nDave took that opportunity to create the first Glide3x based graphics plugin and he named it Glide64.
\nFirst alpha version was released January 2, 2002, few days after the project was started.
\nFirst version, which actually allowed users to play games was released next month. Within six
\nmonths Glide64 achieved quality of graphics comparable with the one produced by Project64 default
\nvideo plugin \u2018Jabo\u2019s Direct3D\u2019, being way behind it in terms of compatibility though. Nevertheless,
\n3dfx users were happy.
\nAnother reason was Dave\u2019s personality. He was only 15 years old schoolboy when he started
\nGlide64, but at the same time he already was skillful and experienced programmer. He worked very
\nfast and the project progressed rapidly. Also, he is a very open and communicative man, and the
\nproject was always surrounded by buddies and fans. Glide64 mirc channel was always full.
\nDave\u2019s project attracted not only emu-gamers. The project was open source from the start.
\nAnd from the start Dave said: \"help is always appreciated\". Anyone with programming skills could
\njoin the project. Soon Gugaman, a student from Brazil, joined the project. I was big fan of N64
\nemulation, and being impressed of plugin\u2019s rapid progress decided to join it too. We became Glide64 team.
\nInternational team. Developers from USA, Brazil and Russia, testers from anywhere around the world.
\nAs I remember, our main tester, Ogy, was from Israel. Dave still was the leader and the main developer.
\nSeveral months the project development was rocket fast. Each day it gained new features, more and more
\ngames become playable. Then Dave became busy with school final exams, then with college preliminary exams.
\nGugaman also became busy with exams and other stuff. At the end of July 2002 the development stopped.<\/p>\n
\nI was enjoying short Siberian summer, so the break in development did not worry me at first.
\nThen my vacation finished, the warm days finished too but the only news from Dave was that he got
\nhimself a new PC with GeForce card and he is happy with it. I decided to move forward by myself in
\nhope that other members of the team will return back soon. I\u2018ve got new results, but Dave still was busy,
\nGugaman just disappeared. Finally, at the fall of 2002 I\u2019ve got an email from Dave. He wrote that he
\ncouldn\u2019t work on the project anymore, as he is very busy at school. \"The project is now yours\" he said.
\nThus I became main and only developer of the plugin. December 29th, 2002 I made my first unassisted release.
\nThe project still was open source, but 3dfx was dead and nobody wanted to help me with 3dfx-only project.<\/p>\n
\nThe initial goal of Glide64 project was to get 3dfx users decent graphics plugin. I joined the project
\nbecause I wanted to create the best possible graphics plugin, which could run on my system
\n(Voodoo3 + Intel Celeron). The reference, the etalon was the best video plugin of that time,
\nJabo\u2019s Direct3D 1.6. With each new version I become closer to my goal. Version 0.5, released at
\nthe end of 2003, was comparable with Jabo\u2019s Direct3D in every aspect: speed, quality, and compatibility.
\nAt the same time number of plugin\u2019s users melted each day because people got rid of their Voodoos.
\nThe only way to use the plugin with non-3dfx card is to use special wrapper, which emulates Glide3x
\ndriver by translating Glide API calls to some common API calls. At the beginning of Glide64 history
\nthe best glide3x wrapper was eVoodoo, which translated Glide3x to Direct3D. Glide64 quickly became one
\nof the most popular applications for eVoodoo. McLeod, the author of eVoodoo, worked together with Dave
\nto better support Glide64 in eVoodoo and eVoodoo in Glide64. Unfortunately, Glide3x emulation in eVoodoo
\nwas incomplete and some vital functions were not implemented. Lack of multi-texturing support had
\nespecially bad impact on image quality. So, non-3dfx users could use Glide64+eVoodoo combination,
\nbut had no reasons for that \u2013 native Direct3D plugins were better. eVoodoo development stopped in 2003
\nand soon it became incompatible with new versions of Glide64, since they use glide3x calls unsupported
\nby eVoodoo.<\/p>\n
\nfrom Hacktarux (France), the author of multu-platform N64 emulator Mupen64. Hacktarux needed descent
\ngraphics plugin for his emulator. Since the plugin had to be ported to Linux, it must be open source
\nand must use OpenGL. I think that with his skills Hacktarux could write video plugin by himself or port
\nGlide64 to OpenGL, but it is very time consuming task, and he decided to make a shortcut: create portable
\nGlide3x to OpenGL wrapper. He did not need general purposes glide3x wrapper, and he had implemented only
\nthose functions, which Glide64 actually uses. But he implemented them right! Glide64 with Hacktarux glide
\nwrapper worked on decent video cards almost as good as on native 3dfx cards. Hacktarux ported Glide64 to
\nLinux, and Linux users finally got good native N64 emulator. From the other side, since 2004 the wrapper
\nde facto became the second part of Glide64 project.<\/p>\n
\nFirst versions of Glide64 had no frame buffer emulation (FBE). Since FBE is essential for many N64 games,
\nI invented my own FBE method, which allowed me to emulate many complex frame buffer effects, including
\nnever emulated before motion blur. FBE was included into version 0.5 and it greatly increased plugin\u2019s
\npopularity. To emulate frame buffer effects plugin read data from video card\u2019s frame buffer, scaled it
\ndown to N64 native resolution and put it into N64 frame buffer area in RDRAM. Thus, frame buffer effects
\nworked slowly and image quality was poor. I had no idea how to make it better, but there was one person,
\nwho had the IDEA! It was Orkin, the author of a good open source OpenGL video plugin glN64. N64 games
\ncreate auxiliary frame buffers in RDRAM, and then use them as textures. Orkin's idea was in using the
\nsame schema: create auxiliary frame buffer in video card\u2019s texture memory, and then use it as texture
\ninstead of the texture from N64 auxiliary frame buffer, with no need to copy it to the main memory.
\nOrkin had implemented the idea in his glN64, and all people including me were very impressed by Zelda
\nOOT pause screen frame buffer effect emulated in hardware. I wished that feature to be in my plugin,
\nbut was pretty sure that 3dfx hardware can\u2019t do that. Fortunately, I was right only partially.
\nI asked for help one of the 3dfx gurus, Hiroshi 'KoolSmoky' Morii (Japan). He said, that my Voodoo3
\nreally couldn\u2019t support texture frame buffers due to restriction on texture size. However, Voodoo 4\/5
\nare free of these restrictions and texture frame buffer can be created using Glide3x extensions,
\ncreated specially for these cards. Hiroshi also made me an unexpected offer I couldn't refuse:
\nhe donated me Voodoo 5 AGP card. It was end of 2003. This gift pushed the project forward greatly.
\nI found, that the card has almost everything for perfect N64 emulation. When I needed new functionality,
\nI just checked Glide3x extension section and found necessary extension. The extensions, necessary for
\nhardware frame buffer emulation (HWFBE) were powerful and at the same time easy for use and they exactly
\nmatch N64 functionality. With Voodoo 5 I could work with auxiliary frame buffers exactly the same way as
\nN64 games do. After several months of work I obtained impressive results: many frame buffer effects were
\nsupported in hardware, including motion blur. HWFBE also allowed me to emulate effects, which were
\nimpossible to support with the standard method, e.g. dynamic shadows. And what is the most important,
\nthe frame buffer effects worked with no loss in speed and image quality, as on real N64. It looked as
\na miracle, so new version of Glide64 was named \"Miracle Edition\" and released at Spring 2004.
\nThis release made Voodoo 4 and 5 the best video cards for N64 emulation, because only these cards supported
\nall features of the new release. Users of non-3dfx cards could not enjoy advanced features because Hacktarux
\nglide wrapper did not support necessary glide3x extensions. Fortunately, Hacktarux updated the wrapper and
\nimplemented most of the new extensions I used. However, texture buffer extension was a hard nut to crack.
\nOnly at the end of 2005, after the new major Glide64 release (\"Wonder\"), Hacktarux found a way to implement
\ntexture frame buffer with OpenGL similarly to Glide. He used new OpenGL extension: Frame Buffer Object (FBO).
\nIt is powerful tool, but it does not exactly matches glide3x functionality. Whole 2006 Hacktarux and me worked
\non HWFBE support in the wrapper, and only at the end of 2006 we achieved the result comparable with HWFBE
\non Voodoo cards. Comparable, but not the same. We could not use texture color buffer and main depth buffer
\nsimultaneously with FBO, while Glide3x easily provided that essential for correct emulation functionality.
\nThus, FBO based HWFBE suffers from depth issues. In the beginning of 2007 the wrapper got help from
\nVincent \u2018Ziggy\u2019 Penne (France), the author of z64, the first low-level graphics plugin for N64.
\nVincent decided to use another approach for implementing texture frame buffer functionality in the wrapper,
\nwithout FBO. He hoped that it would be free of FBO approach drawbacks. Vincent\u2019s successfully
\nimplemented his idea, and the new method is free of depth problem indeed. Unfortunately, it has it\u2019s own
\nproblems and causes its own glitches. Thus it was included in the wrapper as an alternative to FBO,
\nand users may switch between both methods. Of course, Voodoo 4\/5 have no such problems. Besides,
\nwe failed to fully implement texture depth buffer functionality in the wrapper, so Lens of Truth in
\nZelda MM still works 100% correct only on Voodoos. My Voodoo 5 is still the best video card for N64 emulation :)<\/p>\n
\nSome emu users prefer emulators to keep original look and feel of classic games, others prefer to refresh
\nsomehow poor original image quality of their favorite games. The main method for improving quality of 2D
\nimages is using upsampling methods, e.g. 2xSaI, which interpolate original low-resolution image to new
\nhigh-resolution one. 3D graphics plugins provide high-resolution rendering, unavailable in the original
\nsystems, but they use the same low-polygon models and low-resolution textures. Thus, the first idea,
\nhow to improve image quality, was in using the image interpolating methods to get more detailed textures.
\nJabo and Rice added 2xSaI support to their video plugins, and many games really look better with it.
\nGlide64 users also would like to get texture enhancement functionality, but for me it was low-priority task.
\nBesides, I personally prefer original unmodified N64 textures. At July 2007 I've got new email from KoolSmoky.
\nHiroshi wrote that he took Glide64 sources and implemented support for Super2xSaI and hq4x filters.
\nIt was great news and big relief for me. This prototype underlay the new programming module of Glide64 project,
\nGlideHQ (High Quality). All texture enhancement algorithms were carried to GlideHQ, and only small changes
\nhad been made on Glide64 side. At August 2007 Glide64 users finally got texture enhancement support.
\nAnd it was not all.<\/p>\n
\nWhile the idea to replace original low-polygonal 3D models by new high-polygonal ones is impracticable,
\nthe idea to replace original low-resolution textures by new high-res ones is real. Rice, co-author of 1964
\nand the author of 'Rice Video' open source graphics plugin, was the first who practically supported texture
\nreplacement idea. He designed necessary specifications for texture artists and implemented texture dumping
\nand replacement in his plugin. It was a bomb! The idea was supported by many talented people, new texture
\npacks for most popular games appeared quickly after the release. Rice's format became standard de facto for
\nhi-res texture packs. A bit later Jabo designed his own format for textures packs, which is more
\nend-user friendly, but Rice's format has one huge advantage: it is implemented in freely available
\nopen source plugin, so it can be supported by other plugins. Hiroshi took that opportunity,
\nand at August 2007 he made the first version of GlideHQ with Rice hi-res format support.
\nSeveral months we polished that functionality and finally achieved very good results.
\nGlideHQ became the diamond in the crown of new Glide64 release, 'Napalm'.<\/p>\n
\n'Napalm' was the first major release, for which I did not release the source code.
\nMy next goal was to make the project portable. While the wrapper was portable from the beginning,
\nand GlideHQ was also based on portable libraries, Glide64 used direct calls to Win32 API for all system tasks.
\nThere was a port of Glide64 to Linux, but I very disliked the way it was done.
\nI decided to make it right and do it myself. KoolSmoky suggested me to use portable assembler compiler
\nNASM for asm part of the code and a portable GUI library for system tasks, Qt or wxWidgets.
\nI chose wxWidgets since it is free and allows users to link its libraries statically.
\nAlso, wxWidgets contains not only GUI library, but also includes all necessary system functionality,
\nbitmaps support, internalization support, networking etc. I threw away large part of the original code
\nand rewrote it using wxWidgets. Assembler code was also re-written and moved from .cpp files into .asm files.
\nPlugin's source code started to look much better. It was time to actually port it to other OS.
\nI started with Linux. I never work with Linux before, and I needed help. I've got the help from
\nBrad 'mudlord' Miller (Australia). Brad is a well know person in emulation community, participant of
\nseveral emu projects. In Glide64 project, Brad made many improvements in the wrapper before 'Napalm' release.
\nAnisotropic filtering support is one of his works. He also is an experienced Linux user,
\nwith knowledge of GNU development tools. Brad helped me to compile the project on Linux and he made
\nall necessary updates for the wrapper, since it's SDL-related part was seriously outdated.
\nAt the end we had got the Linux port with nearly the same level of functionality, as with the original
\nWin32 version. Next goal was MacOSX. I've got limited access to a MacBook and managed to build the project on it.
\nIt looked almost alive: the GUI was fully functional, but actual rendering failed.
\nThen I lost access to the MacBook, and this work remained unfinished. The new version, 'Napalm WX' had been
\nreleased at August 20, 2009. All project's source code was added to the repository on code.google.com.
\nBtw, the repository was also created by Brad.<\/p>\n
\nAfter 'Napalm WX' release I become more and more busy with real life stuff. I could not work on the project
\nas actively, as before. Also, my interest in emulation faded. Nevertheless, the development continued.
\nMore then 200 commits submitted to the repository since 'Napalm WX' release, more then 100 reported issues fixed,
\nincluding several critical bug fixes. New features emulated, stability increased.
\nNew version supports internalization, translations for several languages included in the release.
\nThe project is now in the very good shape. Of course, not everything is perfect. More then 100 issues
\nare still open, and it seems that they will remain open forever, sorry.<\/p>\n
\nI used almost every ability of my hardware, and I can run almost all N64 games on it,
\nwith little-to-none glitches and at full speed. Glide64 is one of the most advanced Glide3x applications.
\nHowever, everything comes to its end. I finally bought myself a new PC, so I has no reasons to use Glide3x anymore.
\nMy new N64 project, if I'll ever decide to start it, will be free of 3dfx legacy.<\/p>\n
\nIn this section I want to thank people, who performed non-coding tasks in the project,
\nor helped it in some other way. First of all, I thank all our beta testers. I already mentioned Ogy,
\nthe first main beta tester, the author of the first Compatibility List.
\nMany thanks to Leo 'Raziel64' Gutierrez (Argentina), the main beta tester of my first releases.
\nFederelli (Argentina), long time beta tester and author of 'Federelli Nemu64 ini' for Glide64.
\nVladimir 'Flash' Ermakov (Russia), long time beta tester. Vladimir provided me with complete N64 romset and
\nfound me working Voodoo 2 card, which I heavily used for debugging. Wes 'Legend' McDaniel (USA),
\nlong time beta tester, and quality assurance manager of 'Napalm WX' version. Wes gave me many valuable
\nadvices how to make the plugin more convenient for end users and greatly helped me with optimal GUI layout.<\/p>\n
\nJones of N64 emulation, the man, who discovered many lost artifacts: unreleased betas of N64 games,
\nrare N64 hardware documentation, N64 development tools etc. He also made an outstanding contribution
\nto Glide64 project, performing countless duties like Compatibility List and Known Bugs List maintenance,
\noptimization of the settings file, French translation and so on.<\/p>\n
\nwhose sources helped me to improve my work. Special thanks to Sergey 'Angrylion' Povalihin (Russia),
\nthe author of outstanding low-level graphics plugin, who shared with me sources of his work and helped
\nme to understand many complex details of RDP work.<\/p>\n
\nthe home page designer.<\/p>\n
\nHe read all the sources of Glide64 and pointed me on many issues in the code. Pokefan 999 also suggested
\nprogrammer solutions for several problems. Since not all of his changes were included into Glide64 sources,
\nhe created his own branch of Glide64 and included it in his project 1964mod. I recommend you to check it.<\/p>\n
\nSergey 'Gonetz' Lipskiy, 29 December, 2011[\/CODE]<\/p>\n