Статистика |
|
Сейчас на сайте: 1 Гостей: 1 Пользователей: 0 | |
|
|
| | |
| Главная » 2011 » Декабрь » 29 » Glide64 Final (10th Anniversary)
17:25 Glide64 Final (10th Anniversary) |
Величайшая новость всех времён и народов. особенно для фанатов эмуляции Н64 и любителей игр на эту консоль, обновился самый лучший видео плагин для эмуляторов, в нём так же встроена поддержка Русского языка (не моя), изменения колоссальные, он у меня раньше то перебивать начинал с первого места плагин Джабо, а теперь то сто пудово лучший плагин, но для тех у кого слабые машины, эта новость может показаться до лампочки, так как ресурсов этот плагин требует очень прилично, и так немного информации не на нашем:
The Glide64 project was started on December 29th, 2001. Today is its
10th anniversary. Good date to make a new release, the final one.
Since
this is the anniversary release, let me omit the usual "what’s new”
section. You may visit project’s source code repository and get lists of
commits and fixed bugs. This day I want to briefly recall most
noticeable and important moments of the long project’s history and
people participated in it.
Disclaimer: Sorry for my poor English, my native language is C++
Disclaimer 2: Sorry, if I offended somebody somehow, it was not on purpose.
The beginning. Ten years ago
David 'Dave2001' Forrester (USA) announced a new graphics plugin for N64
emulators. N64 emulation had been developing pretty rapidly at the
beginning of 21th century, so the announce by itself had not been
something extraordinary. However, the project immediately caught
attention of emulation community. There were at least three reasons for
that:
new video plugin uses Glide3x, the proprietary graphics API
by 3dfx. That is the plugin was designed specially for 3dfx cards. 3dfx
company was not officially dead yet, millions of 3dfx cards still were
in use. Unfortunately, after release of UltraHLE, N64 emulators offered
3dfx users little reasons to rejoice. The situation became especially
bad with Project64 first public release. It was great release, which
could run many games nearly flawlessly, but not on 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 the new king of N64 emulation and it was
obvious that 3dfx cards will never get good enough Direct3D driver to
enjoy it. Fortunately, Project64 not only provided new level of N64
emulation, but also it introduced new plugin architecture based on open
specifications (Zilmar’s plugins specifications). It opened opportunity
for third-party plugins creation. Dave took that opportunity to create
the first Glide3x based graphics plugin and he named it Glide64. First
alpha version was released January 2, 2002, few days after the project
was started. First version, which actually allowed users to play games
was released next month. Within six months Glide64 achieved quality of
graphics comparable with the one produced by Project64 default video
plugin ‘Jabo’s Direct3D’, being way behind it in terms of compatibility
though. Nevertheless, 3dfx users were happy. Another reason was
Dave’s personality. He was only 15 years old schoolboy when he started
Glide64, but at the same time he already was skillful and experienced
programmer. He worked very fast and the project progressed rapidly.
Also, he is a very open and communicative man, and the project was
always surrounded by buddies and fans. Glide64 mirc channel was always
full. Dave’s project attracted not only emu-gamers. The project was
open source from the start. And from the start Dave said: "help is
always appreciated". Anyone with programming skills could join the
project. Soon Gugaman, a student from Brazil, joined the project. I was
big fan of N64 emulation, and being impressed of plugin’s rapid progress
decided to join it too. We became Glide64 team. International team.
Developers from USA, Brazil and Russia, testers from anywhere around the
world. As I remember, our main tester, Ogy, was from Israel. Dave still
was the leader and the main developer. Several months the project
development was rocket fast. Each day it gained new features, more and
more games become playable. Then Dave became busy with school final
exams, then with college preliminary exams. Gugaman also became busy
with exams and other stuff. At the end of July 2002 the development
stopped.
Keep moving. I
was enjoying short Siberian summer, so the break in development did not
worry me at first. Then my vacation finished, the warm days finished
too but the only news from Dave was that he got himself a new PC with
GeForce card and he is happy with it. I decided to move forward by
myself in hope that other members of the team will return back soon.
I‘ve got new results, but Dave still was busy, Gugaman just disappeared.
Finally, at the fall of 2002 I’ve got an email from Dave. He wrote that
he couldn’t work on the project anymore, as he is very busy at school.
"The project is now yours" he said. Thus I became main and only
developer of the plugin. December 29th, 2002 I made my first unassisted
release. The project still was open source, but 3dfx was dead and nobody
wanted to help me with 3dfx-only project.
The glide wrapper. The
initial goal of Glide64 project was to get 3dfx users decent graphics
plugin. I joined the project because I wanted to create the best
possible graphics plugin, which could run on my system (Voodoo3 + Intel
Celeron). The reference, the etalon was the best video plugin of that
time, Jabo’s Direct3D 1.6. With each new version I become closer to my
goal. Version 0.5, released at the end of 2003, was comparable with
Jabo’s Direct3D in every aspect: speed, quality, and compatibility. At
the same time number of plugin’s users melted each day because people
got rid of their Voodoos. The only way to use the plugin with non-3dfx
card is to use special wrapper, which emulates Glide3x driver by
translating Glide API calls to some common API calls. At the beginning
of Glide64 history the best glide3x wrapper was eVoodoo, which
translated Glide3x to Direct3D. Glide64 quickly became one of the most
popular applications for eVoodoo. McLeod, the author of eVoodoo, worked
together with Dave to better support Glide64 in eVoodoo and eVoodoo in
Glide64. Unfortunately, Glide3x emulation in eVoodoo was incomplete and
some vital functions were not implemented. Lack of multi-texturing
support had especially bad impact on image quality. So, non-3dfx users
could use Glide64+eVoodoo combination, but had no reasons for that –
native Direct3D plugins were better. eVoodoo development stopped in 2003
and soon it became incompatible with new versions of Glide64, since
they use glide3x calls unsupported by eVoodoo.
When I almost
accepted my destiny to become the single user of my video plugin, I
unexpectedly got help from Hacktarux (France), the author of
multu-platform N64 emulator Mupen64. Hacktarux needed descent graphics
plugin for his emulator. Since the plugin had to be ported to Linux, it
must be open source and must use OpenGL. I think that with his skills
Hacktarux could write video plugin by himself or port Glide64 to OpenGL,
but it is very time consuming task, and he decided to make a shortcut:
create portable Glide3x to OpenGL wrapper. He did not need general
purposes glide3x wrapper, and he had implemented only those functions,
which Glide64 actually uses. But he implemented them right! Glide64 with
Hacktarux glide wrapper worked on decent video cards almost as good as
on native 3dfx cards. Hacktarux ported Glide64 to Linux, and Linux users
finally got good native N64 emulator. From the other side, since 2004
the wrapper de facto became the second part of Glide64 project.
Frame buffer emulation. First
versions of Glide64 had no frame buffer emulation (FBE). Since FBE is
essential for many N64 games, I invented my own FBE method, which
allowed me to emulate many complex frame buffer effects, including never
emulated before motion blur. FBE was included into version 0.5 and it
greatly increased plugin’s popularity. To emulate frame buffer effects
plugin read data from video card’s frame buffer, scaled it down to N64
native resolution and put it into N64 frame buffer area in RDRAM. Thus,
frame buffer effects worked slowly and image quality was poor. I had no
idea how to make it better, but there was one person, who had the IDEA!
It was Orkin, the author of a good open source OpenGL video plugin
glN64. N64 games create auxiliary frame buffers in RDRAM, and then use
them as textures. Orkin's idea was in using the same schema: create
auxiliary frame buffer in video card’s texture memory, and then use it
as texture instead of the texture from N64 auxiliary frame buffer, with
no need to copy it to the main memory. Orkin had implemented the idea in
his glN64, and all people including me were very impressed by Zelda OOT
pause screen frame buffer effect emulated in hardware. I wished that
feature to be in my plugin, but was pretty sure that 3dfx hardware can’t
do that. Fortunately, I was right only partially. I asked for help one
of the 3dfx gurus, Hiroshi 'KoolSmoky' Morii (Japan). He said, that my
Voodoo3 really couldn’t support texture frame buffers due to restriction
on texture size. However, Voodoo 4/5 are free of these restrictions and
texture frame buffer can be created using Glide3x extensions, created
specially for these cards. Hiroshi also made me an unexpected offer I
couldn't refuse: he donated me Voodoo 5 AGP card. It was end of 2003.
This gift pushed the project forward greatly. I found, that the card has
almost everything for perfect N64 emulation. When I needed new
functionality, I just checked Glide3x extension section and found
necessary extension. The extensions, necessary for hardware frame buffer
emulation (HWFBE) were powerful and at the same time easy for use and
they exactly match N64 functionality. With Voodoo 5 I could work with
auxiliary frame buffers exactly the same way as N64 games do. After
several months of work I obtained impressive results: many frame buffer
effects were supported in hardware, including motion blur. HWFBE also
allowed me to emulate effects, which were impossible to support with the
standard method, e.g. dynamic shadows. And what is the most important,
the frame buffer effects worked with no loss in speed and image quality,
as on real N64. It looked as a miracle, so new version of Glide64 was
named "Miracle Edition" and released at Spring 2004. This release made
Voodoo 4 and 5 the best video cards for N64 emulation, because only
these cards supported all features of the new release. Users of non-3dfx
cards could not enjoy advanced features because Hacktarux glide wrapper
did not support necessary glide3x extensions. Fortunately, Hacktarux
updated the wrapper and implemented most of the new extensions I used.
However, texture buffer extension was a hard nut to crack. Only at the
end of 2005, after the new major Glide64 release ("Wonder"), Hacktarux
found a way to implement texture frame buffer with OpenGL similarly to
Glide. He used new OpenGL extension: Frame Buffer Object (FBO). It is
powerful tool, but it does not exactly matches glide3x functionality.
Whole 2006 Hacktarux and me worked on HWFBE support in the wrapper, and
only at the end of 2006 we achieved the result comparable with HWFBE on
Voodoo cards. Comparable, but not the same. We could not use texture
color buffer and main depth buffer simultaneously with FBO, while
Glide3x easily provided that essential for correct emulation
functionality. Thus, FBO based HWFBE suffers from depth issues. In the
beginning of 2007 the wrapper got help from Vincent ‘Ziggy’ Penne
(France), the author of z64, the first low-level graphics plugin for
N64. Vincent decided to use another approach for implementing texture
frame buffer functionality in the wrapper, without FBO. He hoped that it
would be free of FBO approach drawbacks. Vincent’s successfully
implemented his idea, and the new method is free of depth problem
indeed. Unfortunately, it has it’s own problems and causes its own
glitches. Thus it was included in the wrapper as an alternative to FBO,
and users may switch between both methods. Of course, Voodoo 4/5 have no
such problems. Besides, we failed to fully implement texture depth
buffer functionality in the wrapper, so Lens of Truth in Zelda MM still
works 100% correct only on Voodoos. My Voodoo 5 is still the best video
card for N64 emulation :)
Texture enhancement. Some
emu users prefer emulators to keep original look and feel of classic
games, others prefer to refresh somehow poor original image quality of
their favorite games. The main method for improving quality of 2D images
is using upsampling methods, e.g. 2xSaI, which interpolate original
low-resolution image to new high-resolution one. 3D graphics plugins
provide high-resolution rendering, unavailable in the original systems,
but they use the same low-polygon models and low-resolution textures.
Thus, the first idea, how to improve image quality, was in using the
image interpolating methods to get more detailed textures. Jabo and Rice
added 2xSaI support to their video plugins, and many games really look
better with it. Glide64 users also would like to get texture enhancement
functionality, but for me it was low-priority task. Besides, I
personally prefer original unmodified N64 textures. At July 2007 I've
got new email from KoolSmoky. Hiroshi wrote that he took Glide64 sources
and implemented support for Super2xSaI and hq4x filters. It was great
news and big relief for me. This prototype underlay the new programming
module of Glide64 project, GlideHQ (High Quality). All texture
enhancement algorithms were carried to GlideHQ, and only small changes
had been made on Glide64 side. At August 2007 Glide64 users finally got
texture enhancement support. And it was not all.
Enthusiasts of
N64 emulation also always wished to somehow improve poor visual quality
of their favorite games. While the idea to replace original
low-polygonal 3D models by new high-polygonal ones is impracticable, the
idea to replace original low-resolution textures by new high-res ones
is real. Rice, co-author of 1964 and the author of 'Rice Video' open
source graphics plugin, was the first who practically supported texture
replacement idea. He designed necessary specifications for texture
artists and implemented texture dumping and replacement in his plugin.
It was a bomb! The idea was supported by many talented people, new
texture packs for most popular games appeared quickly after the release.
Rice's format became standard de facto for hi-res texture packs. A bit
later Jabo designed his own format for textures packs, which is more
end-user friendly, but Rice's format has one huge advantage: it is
implemented in freely available open source plugin, so it can be
supported by other plugins. Hiroshi took that opportunity, and at August
2007 he made the first version of GlideHQ with Rice hi-res format
support. Several months we polished that functionality and finally
achieved very good results. GlideHQ became the diamond in the crown of
new Glide64 release, 'Napalm'.
Portability. 'Napalm'
was the first major release, for which I did not release the source
code. My next goal was to make the project portable. While the wrapper
was portable from the beginning, and GlideHQ was also based on portable
libraries, Glide64 used direct calls to Win32 API for all system tasks.
There was a port of Glide64 to Linux, but I very disliked the way it was
done. I decided to make it right and do it myself. KoolSmoky suggested
me to use portable assembler compiler NASM for asm part of the code and a
portable GUI library for system tasks, Qt or wxWidgets. I chose
wxWidgets since it is free and allows users to link its libraries
statically. Also, wxWidgets contains not only GUI library, but also
includes all necessary system functionality, bitmaps support,
internalization support, networking etc. I threw away large part of the
original code and rewrote it using wxWidgets. Assembler code was also
re-written and moved from .cpp files into .asm files. Plugin's source
code started to look much better. It was time to actually port it to
other OS. I started with Linux. I never work with Linux before, and I
needed help. I've got the help from Brad 'mudlord' Miller (Australia).
Brad is a well know person in emulation community, participant of
several emu projects. In Glide64 project, Brad made many improvements in
the wrapper before 'Napalm' release. Anisotropic filtering support is
one of his works. He also is an experienced Linux user, with knowledge
of GNU development tools. Brad helped me to compile the project on Linux
and he made all necessary updates for the wrapper, since it's
SDL-related part was seriously outdated. At the end we had got the Linux
port with nearly the same level of functionality, as with the original
Win32 version. Next goal was MacOSX. I've got limited access to a
MacBook and managed to build the project on it. It looked almost alive:
the GUI was fully functional, but actual rendering failed. Then I lost
access to the MacBook, and this work remained unfinished. The new
version, 'Napalm WX' had been released at August 20, 2009. All project's
source code was added to the repository on code.google.com. Btw, the
repository was also created by Brad.
The End. After
'Napalm WX' release I become more and more busy with real life stuff. I
could not work on the project as actively, as before. Also, my interest
in emulation faded. Nevertheless, the development continued. More then
200 commits submitted to the repository since 'Napalm WX' release, more
then 100 reported issues fixed, including several critical bug fixes.
New features emulated, stability increased. New version supports
internalization, translations for several languages included in the
release. The project is now in the very good shape. Of course, not
everything is perfect. More then 100 issues are still open, and it seems
that they will remain open forever, sorry.
All these ten years I
worked on the project using the same PC, powered by Intel Celeron CPU
and 3dfx Voodoo card. I used almost every ability of my hardware, and I
can run almost all N64 games on it, with little-to-none glitches and at
full speed. Glide64 is one of the most advanced Glide3x applications.
However, everything comes to its end. I finally bought myself a new PC,
so I has no reasons to use Glide3x anymore. My new N64 project, if I'll
ever decide to start it, will be free of 3dfx legacy.
The Very Special Thanks. In
this section I want to thank people, who performed non-coding tasks in
the project, or helped it in some other way. First of all, I thank all
our beta testers. I already mentioned Ogy, the first main beta tester,
the author of the first Compatibility List. Many thanks to Leo
'Raziel64' Gutierrez (Argentina), the main beta tester of my first
releases. Federelli (Argentina), long time beta tester and author of
'Federelli Nemu64 ini' for Glide64. Vladimir 'Flash' Ermakov (Russia),
long time beta tester. Vladimir provided me with complete N64 romset and
found me working Voodoo 2 card, which I heavily used for debugging. Wes
'Legend' McDaniel (USA), long time beta tester, and quality assurance
manager of 'Napalm WX' version. Wes gave me many valuable advices how to
make the plugin more convenient for end users and greatly helped me
with optimal GUI layout.
My eternal gratitude to Olivieryuyu
(France), the main beta tester of the project. Olivieryuyu is Indiana
Jones of N64 emulation, the man, who discovered many lost artifacts:
unreleased betas of N64 games, rare N64 hardware documentation, N64
development tools etc. He also made an outstanding contribution to
Glide64 project, performing countless duties like Compatibility List and
Known Bugs List maintenance, optimization of the settings file, French
translation and so on.
I want to thank all authors of all
open-source N64 projects, and especially Orkin, Rice and Ziggy, whose
sources helped me to improve my work. Special thanks to Sergey
'Angrylion' Povalihin (Russia), the author of outstanding low-level
graphics plugin, who shared with me sources of his work and helped me to
understand many complex details of RDP work.
I want to thank
S.M, Emu X Haven Admin/Webmaster for hosting Glide64 forum and home
page. Special thanks to kurono, the home page designer.
Special
thanks to Pokefan 999, a beta tester, who submitted many bug reports. He
read all the sources of Glide64 and pointed me on many issues in the
code. Pokefan 999 also suggested programmer solutions for several
problems. Since not all of his changes were included into Glide64
sources, he created his own branch of Glide64 and included it in his
project 1964mod. I recommend you to check it.
Happy birthday, Glide64, and farewell! Sergey 'Gonetz' Lipskiy, 29 December, 2011
Каково?, не поражены?)Давненько небыло обновлений, не считая сборок конечно, которые почти каждый день выходят.
|
Просмотров: 1225 |
Добавил: Satan
| Рейтинг: 5.0/1 |
Добавлять комментарии могут только зарегистрированные пользователи. [ Регистрация | Вход ]
| |
| | |
|
Поддержать |
| YandexMoney:
410011302991026
WebMoney:
R164863925645 | |
|
|