Яндекс

Tuesday, December 30, 2014

New Year beta.

Hello everybody!

The project is moving forward according to the “Plan for Project Completion”. Today time is come for the second large beta release. According to the Plan, the following tasks were planned to accomplish:

  • Add texture enhancement and hi-res texture load.
  • Rewrite the GlideHQ submodule from the Glide64 project to add OpenGL texture formats.
  • Lots of work need to be done in the plugin to support all the features of GlideHQ.


  • Since the plan for the previous release was not fulfilled on 100%, uncompleted works were moved to this stage. These are mostly bug fixes. I need to say few words about situation with emulation errors. It was planned that the project will reach compatibility level of Glide64 within month or two. My estimation of that work was based on assumption that legacy code (that is original code of glN64 plugin) is correct and just incomplete. I seriously mistaken here. I spent weeks on debugging since the previous release and all this time I stumble on issues in very core of the plugin's code. Since code of Glide64 and GLideN64 differs a lot these issues are hard to notice. In spite of my hard efforts compatibility level of Glide64 is still not reached. However, the situation is much better than with the previous release. Circa 80 issues closed on the bug tracker during this stage. Most of serious issues are fixed, and most of games work pretty well.

    According to the Plan, the main feature of this beta release is support of HD textures. I ported GlideHQ module to this project and adopted it to the new reality:
    • 3dfx texture formats are replaced by OpenGL ones.
    • texture compression is removed. This technique was useful for 3dfx cards which had 24 mb of texture memory at most. Since texture quality degrade noticeably after the compression, I removed it.
    • added new family of texture scalers - xBRZ.  xBRZ was invented after original GlideHQ was finished. Many people like how that scaler works, so now you may check yourself is it suitable for N64 textures.
    • improved texture library text messages output during HD textures load. You know how it looks with Glide64. With GLideN64 you may change font, font size and text color for these messages.
    Texture dumping is left untouched, but the plugin currently does not support it.

    Another mega feature of this release is support of LLE, that is Low Level Emulation. Just select LLE RSP plugin in the emulator to enable it. Besides new games support that feature has another practical use - you may easily find what causes particular graphic glitch: errors in HLE or bugs in core functionality.

    Other changes are not so global:
    • Implemented microcode for Star Wars - Shadows of the Empire
    • Implemented gamma correction feature
    • Implemented flat shading and prim shading
    • Lots of fixes and modifications in texture code.
    Note about non-windows platforms. Linux build worked well until I added texture library. Current code can be built but emulator can't load the plugin due to conflicts in included libraries. It is technical issue, I hope to fix it soon. The situation with Mac OS X is similar: I can compile the code but can't run it. Current release of Mupen64Plus for Mac does not support OpenGL 4. The problem is also technical.

    Next stage will be started in the New Year. The plugin will get new GUI and will be compatible with Zilmar's specs emulators. Of course, bugfixing will be continued.

    How to get the beta:
    • All project contributors with access to the forum may download the beta from GLideN64/New Year Beta Release subforum.
    • All project contributors with perk "Early beta for Mupen64Plus 2.0" will get the beta by email.
    • If you are not a contributor, you still may support the project
    I was too busy to make video materials to this release. You may check this cool comparison video, made by our forum member aquatakat:
    www.youtube.com/watch?v=1ux4mFG-cCw
    It shows difference between glN64 and GLideN64.

    And a few screen shots from Perfect Dark:
    Object highlight

    Motion blur
    Spy cam

    Night vision
    Coronas, mip-mapping, reflections
    X-Ray scanner
    Sky textures
    Horizon scanner
    IR scanner
    Multiplayer mode
    Multiplayer with simulants

    Happy New Year!


    Monday, December 1, 2014

    Widescreen hack

    Many people ask me: is it possible to implement the "widescreen hack"? They mean the "Adjust game aspect ratio to match yours" feature of  Jabo's Direct3D8 1.6 plugin which enables widescreen mode for games not intended to run in widescreen. Since this feature is a hack, it does not work with any game. You may check a compatibility list. I was unsure how it works, so I didn't promise that it will be implemented in GLideN64. Recently I got an idea how to make that feature and did a quick test. Check the result:

    normal 4:3 screen

    16:9 aspect with the hack enabled

    The hack is applied only to 3D objects, don't pay attention on stretched sprites.
    As I can see, proportions of 3D object remained correct. To be sure, I open wide screen shot in Paint and lay normal screen shot over it:

    It fits pretty well.

    Now back to the question: is it possible to implement the "widescreen hack"? It depends. The screen you see is not from beta, it's even not a work in progress. It is an experiment, pretty successful as I can see. I need time to complete it. Time is money. The project collected 8K funds and I'm overloaded with works planned to implement for these money. "Widescreen hack" is among tasks, which will be done with 10+K funds. BTW, another 10+ task, "port to Apple Mac OS X" is almost ready. You still can support the project - the more time I can work on this project, the more complete the result will be.


    Tuesday, November 25, 2014

    LLE is here

    As I explained in the previous article, low level emulation (LLE) is not magic wand which makes the emulation perfect. But it the only way to run games, which are not supported by HLE. And if you already have HLE plugin, you are one step from having LLE support as well. LLE plugin does emulation of RDP. HLE plugin does emulation of RDP plus high level emulation of RSP commands. That is,  HLE plugin is LLE plugin + HLE RSP. Of course, practical implementation of LLE mode in HLE plugin has nuances, but in general the situation is like that.

    Now to the news: since that week GLideN64 supports low level emulation. Of course, graphics glitches caused by difference between N64 graphics hardware and PC graphics cards are not gone. LLE by itself cannot ensure pixel-accurate emulation. But if you want to see for example Star Wars - Rogue Squadron in high-resolution with advanced texture filtering, GLideN64 will help you.

    Few screen shots from previously unsupported games:













    The secret way to get a beta build right now is here. The project needs your help!


    A word for HLE

    This is my old article, which I wrote before I announced my work on GLideN64. I decided to publish it here because it will be useful for my next post.


    Introduction.

    As you know, there are two approaches to emulation: Low Level (or traditional) Emulation, LLE, and High Level Emulation, that is HLE. HLE approach is possible when all software running on the emulated system uses a common library. HLE emulator implements this library as much effective as possible, without care how actual hardware does that job. Thus, HLE emulator makes some kind of shortcut in emulation process, bypassing actual emulation of some piece of hardware.

    HLE pros:
    • Tremendous speed increase in compare with traditional emulation

    HLE cons
    • If there are several version of the common library, each version must be implemented separately
    • If a game uses unknown version of the library, it can’t be run
    • Errors and incompleteness in library implementation cause various glitches

    LLE pros:
    • Being implemented once it will work for all software.

    LLE cons:
    • Requires much more computational resources than HLE.

    HLE vs. LLE in N64 emulation

    For a long time HLE was key feature of N64 emulation. All N64 games use a library for render audio and graphics. The library runs on powerful multimedia Reality Co-Processor, RCP. RCP actually consist of two parts: programmable Reality Signal Processor, RSP, which executes graphics and audio tasks, and Reality Display Processor, RDP, which draws the graphics in the frame buffer. The library, known as microcode, is loaded into RSP and controls its work. That is it defines how graphics and audio tasks must be performed. HLE emulators implement the microcode and thus bypass emulation of very powerful module, which can perform many scalar and vector operations per cycle.

    At the beginning of N64 emulation HLE was the only option to achieve full speed emulation, because Pentium II based PC were just few times more powerful than emulated system. Thus the first emulator capable to run commercial games was named UltraHLE. It was a great piece of software, but none of the game it run was emulated perfectly. Each game had visual glitches. Many emulators were released after UltraHLE, compatibility increased greatly, but graphics glitches are still with us. Most of people used to blame HLE for that.

    A word for HLE

    If in the beginning of N64 emulation LLE was not an option, 10 years after PC became powerful enough to run LLE full speed. LLE video and audio plugins were implemented, and today N64 emulators may not use HLE at all. However, graphics (and audio) glitches are still there. LLE plugins have the same (or even more) glitches as HLE ones. It proves that HLE approach itself is not responsible for the glitches.

    HLE plugin screen shot:


    LLE plugin screen shot:

    HLE is totally responsible for “unsupported microcode” problem. If some game uses custom microcode with unknown specification, such game can’t run with HLE. How many games still have “unsupported microcode” status? Ten at the most.

    HLE is partially responsible for incomplete microcode implementation. Some games use modified versions of common microcodes, and these modification not always correctly decoded and implemented. This is rare case too. Also, there is a chance that microcode implementation will be improved.

    All other graphics glitches are caused by difference between N64 graphics hardware and PC graphics cards. And this problem is common for HLE and LLE. N64 hardware has capabilities, which have no direct analogues in PC hardware. And while shaders allow programmers to reproduce most of N64 special effects, N64 work with frame buffer can’t be totally emulated with PC hardware.

    From the other side, PC graphics cards allow to greatly improve visual quality of emulated games. From the beginning, N64 emulators render games in resolution, which is much higher than the original one. FSAA, anisotropic filtering, texture magnification filters and finally hi-res texture packs make our favorite games look if not modern but at least descent.

    Already mentioned shaders not only allow programmers to emulate N64 special effects, but also can be used for features, which N64 could not dream of. For example, most of N64 games heavily use lighting to produce realistic image. Lighting is computationally intensive feature, and N64 can do it only per vertex. Besides, lighting calculation method used in N64 is very different from the one, used on PC hardware and thus N64 emulators do vertex lighting calculation in software. With shaders it is possible not only perform lighting calculation in hardware, but also do it per pixel. Look at the screen shots.

    Traditional lighting calculation:


    Per-pixel lighting:

    Close look:
    As you see, per pixel lighting calculation produces smoother and more correct color gradient. It looks better in dynamic, when light sources are moving. It’s not astounding image quality improvement, but it is nice anyway.

    Another example:

    This is very primitive implementation of cell-shading. It should look better with specially made “cell-shading” textures. The point here is that cell-shading effect is based on lighting calculation: we need to know light intensity to calculate it.

    Now I have bad news for HLE haters: these lighting-based effects can be done only with HLE. Because with LLE all vertex computations are done by RSP plugin and LLE video plugin is mere rasterizer.

    Friday, November 21, 2014

    Problem with CRT shader

    I need help with CRT shader. The problem is following: scanlines are vertical (click on image to see it in full size )

    I tried various versions of CRT shaders, they all work like this.The problem is especially bad when screen curvature is enabled:


    I started to experiment with simplest CRT shader I found, author: Themaister
    By default it also renders vertical scanlines.
    I found that if I replace calculation of omega variable:
    omega = vec2(3.1415 * rubyOutputSize.x * rubyTextureSize.x / rubyInputSize.x, 2.0 * 3.1415 * rubyTextureSize.y);
    by
    omega = vec2(2.0 * 3.1415 * rubyOutputSize.x * rubyTextureSize.x / rubyInputSize.x, 3.1415 * rubyTextureSize.y);
    it fixes scanlines:


    It's good, but I want to use more advanced shader,  like cgwg, Themaister and DOLLS CRT shader.
    However, it uses more complex mathematics, and I can't find where to tune it to get needed result.

    Other question: why these filters work for  bsnes? What did I wrong with OpenGL parameters to get this curse? The OpenGL code is very basic - just draw textured rectangle with CRT shader enabled.

    Thursday, November 20, 2014

    High-resolution textures WIP

    Hello,

    Attaching texture library to the plugin goes well. Most of things already work, and I want to share WIP screen shots with you.

    High-resolution textures packs, config options:

    Texture pack in action:



    Texture enhancement works also. I added new family of texture scalers - xBRZ.
    Config options:


    BRZ5X in action:




     I want to remind you that you still may support the project.

    Sunday, November 9, 2014

    The first monthly beta. Release notice.

    Hello everybody!

    The project is moving forward according to the “Plan for Project Completion”. Today we set the new project’s milestone: the first monthly beta. This topic is a kind of press-release. According to the Plan, the following two tasks ware planned to accomplish in October:
    • Fix stability issues
    • Implement missing functionality to achieve compatibility equivalent to Glide64
    1 . The first task planned on October was “Fix stability issues”. My experiments added a lot of mess into original code. I made massive code rafactoring to make the code clean again. I fixed many issues with program initialization and de-initialization, and now it is possible to run several games without closing the emulator after each of them. Switch between fullscreen and windowed modes, savestates loads also could crash the plugin. It is fixed. The task can be considered as completed.

    2. As you know, GLideN64 is based on sources of Orkin’s glN64 graphics plugin. glN64 compatibility was “fair” on its release time, and today it can be considered as “mediocre”. It was good enough for my experimental works, but not for a public release of the new plugin. During my experiments I made no special steps to increase original plugin’s compatibility. No new ucodes were implemented. Many bugs in legacy code were not fixed. Thus, plugin’s code on start of crowd-funding campaign consisted of:
    Original Orkin’s glN64 0.4.1 code + Linux port + Shaders + New frame buffer emulation + MupenPlus 2.0 port + GL ES port.
    During October I tried to eliminate the chasm between Glide64, which supports almost everything almost flawless, and GLideN64. Here the short list of completed works:
    • Hardware mip-mapping emulation.
    • Emulation of low-level triangles (used for sky/water in Golden Eye, Perfect Dark, Killer Instinct).
    • Implemented missing functionality in F3DDKR microcode (Jet Force Gemini, Mickey's Speedway USA)
    • Implemented LookAt functionality.
    • Implemented point lighting for Zelda MM.
    • Implement microcode for Star Wars - Shadows of the Empire.
    • Implemented Turbo3D microcode (Dark Rift)
    • Implemented ZSort microcode (Telefoot Soccer 2000 and other soccer games)
    • Implemented microcode for Conker's Bad Fur Day.
    • Implement Sprite2D microcode. Fixed 2D in many games.
    • Make new implementation for S2DEX and S2DEX2 microcodes. Fixed 2D in lot of games.
    • Implemented YUV textures load.
    • Fixed 32bit RGBA textures load.
    • Fixed palettes load.
    • Fixed bugs in Video Interface emulation (wrong aspect, flickering etc).
    • Implemented gamma correction.
    • Various fixes in all around the code. 
    To the end of October almost all emulation-related functionality of Glide64 was ported or reproduced in GLideN64. Users, who have access to weekly beta releases, may confirm that the plugin evolved greatly for this month. However, the chasm was too wide. Oliver found more than fifty serious issues. Thus, we decided to take one week for debugging. This week I worked hard to fix found issues, Oliver from his side opened the new ones. Most of found and fixed bugs resided very deeply in legacy code and I spent many hours to locate them. Currently the score of open and closed issues is equal.

    What does it means? The goal of the first phase is not reached. Functionality of the plugin is close to the target, but existing bugs spoil the impression. Thus, the further plan needs correction. Next goal is high-res textures support. Since existing bugs must be fixed, this work also will be continued and will be done in parallel with the main task. The second phase is planned to accomplish in November and new monthly build with high-res textures support has to be released in the beginning of December. I already lost one week on debugging, so most likely the second monthly release will be delayed, probably to the end of December. If I will finish with bug fixes before high-res textures will be ready, I’ll release an update. Also, I want to remind you that you still may support the project.

    I’m planning to make new videos which show the work in progress. So far, I can only show you the WIP screen shots (click to see full size image):