I have a good news: new Public Release is near!
As you know, GLideN64 is actively developed open source project. Source code modified almost daily. You may build current state at any moment, or download weekly WIP builds. Thus, you may ask: what is so important in new Public Release and how it will differ from WIPs?
Current Public version 1.2 released 6 July 2015. It was the last version funded by GLideN64 Crowd-funding Campaign Launched on Indiegogo. Since that I'm working on the project at my spare time. Of course, development slowed down. From the other side, open source attracting other resourceful developers to the project, who made many useful changes in code and helped me with ideas or advice. Thus, the work never stopped. Plugin constantly evolved and at some moment I started to feel that all these hundreds of changes deserve to be marked by a new milestone. This milestone is the new Public Release. This time there will be no private beta testing period. My current goal is to fix remaining regressions and clear some stuff. After that I will can say - new release is ready. New translation files also would be nice to get, but not must.
I am preparing set of articles explaining what is new in the upcoming release in compare with the old one. Since most of new features available via users options from user interface, let's compare GUI for both versions.
Note: new version will have new redesigned GUI, but it is more convenient to use current old-style one for comparison.
Full screen resolution
So, you want to finally get rid from these black boarders, which eat useful space on your screen. This feature is for you! It works as standard crop in graphics editors: cuts parts of the image from all sides and stretches the rest on entire screen. Simple like that. However, there are several things you need to know about that feature to use it properly.
Crop has two modes: auto and manual. In auto mode plugins tries to detect empty space and remove it. There are many ways to add black boarders. Auto detection method analyses scissor set by the game. Scissor is a standard tool in computer graphics. It defines rectangular area. All pixels outside that area automatically discarded. If scissor is less than frame buffer size, image will have empty boarders, which plugin can crop. Auto crop will fail if game uses other methods to make the boarders. In that case you need to use Manual mode. In that mode you need manually set width for horizontal and vertical areas to cut. Values you provide are numbers of pixels to crop in native resolution. That is, if game's original resolution is 320x240 and it uses borders with 12 pixels width, you need to set 12. That value will be scaled to get correct result in output resolution you selected. If you will set too large value to crop, you may lost useful part of the image. How to find the right value? Either try to increase crop one by one until black borders will be totally removed, or you may make screen shot in native resolution and find boarder width in a graphics editor.
Another note: crop works as post-processing filter. It works only if frame buffer emulation is enabled, as all other post-processing filters. Frame buffer passed to Video Interface, which applies crop if necessary and puts result on screen. I already explained, what Video Interface is and how it works. One important fact is that VI can add its own black borders and it usually adds one-two empty lines. These lines not removed with Crop. Keep it in mind.
|Waverace in wide window with auto Crop|
This is new feature made by users request. In this version of GUI it is named as "Render at constant factor of native resolution". What it is for? When frame buffer emulation is disabled, plugin renders graphics in screen resolution defined by user. All graphics elements scaled to fit the screen. The scale defined as Screen Width / Original Width; Screen Height / Original Height. It is clear that if game uses 320x240 resolution, but screen has 1024x768 size, the scale will be fractional. There is a belief that fractional scale leads to additional glitches and it is right to use only those resolutions, which are integer factor of the original one. Thus users asked me to support render at constant factor of native resolution. It is not hard to do with frame buffer emulation. Frame buffer can have any internal resolution. Video Interface will scale it to user-defined screen resolution. Low-res buffer will be stretched to screen resolution, hi-res buffer will be shrunk to it. Also, you may set factor to 0. That will set that option off, so internal resolution will be the same as screen resolution.
Two important notes:
- Factor 1 means "render in original resolution". This is most accurate emulation mode. Higher resolution often causes additional glitches, especially in 2D graphics. Thus, that mode is recommended for pure 2D games.
- If you use Crop, part of the image will be cut and rest stretched to the screen. You may set high factor of native resolution and get internal resolution above the screen one. Thus, your frame buffer will still be larger than screen area after crop and resulted image quality can be better.
|Normal rendering (left) VS native resolution (right)|
Anti-aliasingIt remained the same. The only news is that AA is now supported on Android devices with GLES3.1 compatible GPU, thanks to Francisco Zurita efforts. If you want to use GLideN64 on Android, Mupen64Plus FZ is your choice.
Other Video options
All other options remained the same.