Another day full of news!
Mupen64k v0.8
"-Removed useless files
-New Kailleraclient
-Removed oldkaillera and supraclient
-Glitch64 Added
-New Glide64 added
-Project64 1.6.1 plugin updates
-New Icon
-New website
-Implemented Manifest in .exe
-Disabled broken menu options"
Source
Dolphin mth-exp-stuff Git 3.0-306
"* Partially revert r27bda2c054f3."
Source
Stella SVN r2309
"r2304
Fixed segfault on program exit if joysticks have never been initialized.
r2306
Updated documentation, bumped version # slightly.
r2307
A little more work on KidVid support. The sound isn't working yet, but at least it progresses through different screens when you press 1, 2, 3.
r2309
Updated changelog for DonationWare status."
Source
VisualBoyAdvance-M SVN r1063
"r1050
libpng 1.4.8 and nasm 2.09.10
r1051
DEBIAN: GTK and WX can now build together properly. No need to build twice anymore.
r1052
Some fixes to help building on NetBSD
r1053
GTK: Fix an uninitialized variable causing potential crashes in the joypad config dialog.
r1054
CMake: Fix building outside of a working copy when subversion is installed.
r1055
GTK: Hint the file manager it can use gvbam to open GB and GBA rom files
r1056
I'm not sure where these MIME types came from, but if we're going to invent some, let's invent some proper ones. I'm not sure if -rom is the best suffix though.
r1057
Add missing extensions.
r1058
Add missing extensions.
r1059
Add missing extensions. Note though that the association section is still missing .dmg
r1060
SDL: Install vba-over.ini in the data directory and use it.
r1061
CMake: Disable building the wxWidgets port by default since it is not supported yet.
r1062
took drnach's dmg association and expanded on it :)
looks like the branch doesn't have properties assigned
r1063
merge from trunk"
Source
WinVICE v2.3.13
"* doc/vice.pdf, doc/vice.hlp, doc/vice.txt, doc/vice.guide,
doc/vice.chm, configure.in, ChangeLog, src/version.h,
src/arch/win32/vice-version.bat, src/monitor/mon_lex.c, po/es.po,
po/ko.po, po/fr.po, po/da.po, po/tr.po, po/sv.po, po/de.po, po/hu.po,
po/ru.po, po/nl.po, po/pl.po, po/it.po: VICE 2.3.13"
Source
Altirra 2.1 Test 4
"This version adds Covox support and also fixes a bug that was causing noise in high pass filtering (affected Nemesis demo). I did also do some heavy reorganization on the CPU hooking code, so watch out for SIO/CIO patch breakage.
I'll have to look into the DOS XE issue. It may be another problem with PERCOM block support (grr)."
Source
MESS SVN r13772
"r13770
Worked around 0x3d8 VGA reading
r13771
alphatro: added some PORT_CHAR definitions (no whatsnew)
r13772
SLC1 - Fixed display & keyboard. Marked as Working [Robbbert]"
Source
1964 SVN r100
"r100
1964: (Warning this may break stuff, its not complete and is more committed so i don't accidentally wipe it)
Even more cleanups of the win gui code
Removed some useless checks and removed of some features that are more likely to cause problems then anything
Remove unnecessary plugin loading code
Remove unnecessary extra PeekMessage in the WindowMsgLoop"
Source
Glide64 Final (10th Anniversary)
"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"
Source
Jpcsp SVN r2423
"r2420
- Fix for r2418
r2421
Fix again for r2418. Now the Cube demo is running again.
r2422
Draft implementation for a rendering in software, i.e. not using GPU/OpenGL. This implementation is currently disabled and can only be activated in the source code. It is not yet functional and only 2D rendering is implemented.
Small improvements in the memory management for vertex reading (avoid to create a new VertexState object for each vertex).
Otherwise, no functional change.
r2423
Code clean-up in Compiler."
Source
PCSX Reloaded SVN r73846
"r73846
Fail in PcsxrPlugin initialization if we can't find the plugin specified. Prevents a crash if a plug-in was removed/renamed."
Source
DeSmuME SVN r4140
"r4140
Cocoa Port:
- Bring back the build target for the v10.4 SDK in the XCode project. (This is for legacy support only. Do not use for new builds -- use the v10.5 build target instead.)
- Add "Info (Debug).plist", and remove the custom build script phase for adding external files to the .app package, replaced with file references in the XCode project. This fixes Debug builds so that they can compile again.
- Use UTIs in addition to file extensions for determining file types.
- Add new icons for ROM Cartridge Images (.nds), ROM Saves (.dsv), and Emulation Save States (.dst).
- Change default compiler to Clang/LLVM (but continue to use GCC 4.2 for ppc64 build).
- Add instruction scheduling optimization to ppc and ppc64 builds, slightly improving performance on PowerPC machines."
Source
0 comments:
Post a Comment