Type: N64 Emulator video plugin (under community development)
Licence: GPL 2.0
Targeted: All 1964 emulator users
Supported Emulators: All windows-based emulators with plugin support (1964, Project64, Mupen64plus)
Requirements: MS C++ Redistributable Package
Latest Download: http://www.emutalk.net/threads/54166...munity-version
Release Date: 10/14/2009
Source Code: Google-Code SVN
BUGS: PLEASE CHECK THE ISSUE LIST BEFORE REPORTING A BUG!
- added support for a WIP folder for enabling the reloading of newly designed
textures of retexture artists. WIP has to be a direct subfolder of the main
folder of the hires pack. Nested folders are possible
- fixed a bug with texture dumping
- fixed the counter display for texture loading. Now it indicates the real
amount of loaded textures and does not restart at 1 for each sub folder
- adjusted displayed messages
- added hint for caching option (forgot to port this from my private codebase
- started to comment the hires code in TextureFilters.cpp. It should now be
veeery easy understandable even for beginners
- CRC-fix avoids slowdown in Castlevania, Smash Brothers and probably other games, when hires is enabled
- Support for static hires backgrounds as used in Zelda
- Experimental texture caching (check options). This has still improvement potential (texture compression)
but might nevertheless be quite usefull with large hires textures
- No rechecking and reloading (in case of enabled caching) of hires-textures. if a savestate is loaded or if you
switch between fulscreen & window mode. This avoids nasty wait time
- Fix to avoid crashing under Vista and Windows7
- Some smaller things
- Fixes ported from the Linux version of Rice
1964Video is based on the latest version of the Rice-plugin, meaning the version 6.1.4, which included some changes of Mudlord.
Afterwards the community involvement started as Gitech requested some improvements for supporting the development of his
Castlevania-LOD hires pack. Subsequently the plugin changed once again it's name to "Aristotle's Mudlord & Rice Video".
Well, as you might have already guessed, adding the name of each author to the plugin name might become a little unhandy by
the time. Thus the plugin had been renamed once again by death--druid to 1964Video and the source code has been transfered
to an svn.
The development of the plugin has now moved from a one-man-show towards a (hopefully) community-driven approach. That way,
we hope getting more people involved into actual development and to foster the progress of this great plugin, which - even if not yet
being the most advanced one - was the initial plugin pushing N64 emulation to the next level by introducing hires texture support (Rice).
The initial version of the plugin (r30, 10/10/2009) also contains some fixes, that have been applied by the folks of Mupen64plus, a multi
platform N64 emulator, to the linux version of the Rice plugin (thank you guys!). Furthermore, some ideas have been taken from Glide64,
which is the reference video plugin for 64 emulation atm (great work folks!).
At first, the plugin has to be brought to a state that makes it easier accessible by potential new developers. Death-druid did with
the transfer towards a maintained svn already the first step in that direction. Furthermore the source code has to be documented for
allowing a better understanding. All applied changes have already been documented - more to come.
The general target is of course the improvement of the existing plugin. As usually everyone just has a limited amount of time, he/she is
able to dedicate to such leisure activities, additional developers are needed. Thus any interested dev is warmly invited to join up at the svn.
Finally, it's of course all about having fun!
This thread is meant for publishing the latest versions of the plugin, sharing information about development progress, obstacles, ideas to
the community and for providing feedback regarding the releases towards the developers.
This thread is not meant for nagging about "when do you release" or "when do you support". I guess feature requests should be allowed but
don't expect a guarantee for implementation. If you really badly want it, it's community-driven - you are free to do it yourself. Please always
keep in mind, if the devs lose the fun and therefore interest, you'll lose the contribution.