Basically, the system requirements might take a beating...A GeForce FX/ATI Radeon 9x00 card would be the absolute minimum. Also, depending IF I think of adding custom shaders (to go with the custom textures), it might go up even more (if a equivalent DX9 shader implementation is done as well)..
My main concerns on how viable the idea might be, and the end-user things....Like, would people complain if they need a recent video card to now run the plugin? Thats my main concerns. And also, I don't wont to take what I do to places where Rice doesnt like (like, with the overall direction..)
The first thing you must consider really when doing something like this, is it worth it? IE added complexity etc. I believe the biggest thing to look at is how it finds the textures to dump and substitute. Adding more processing will not improve things much in my POV. Adding more DX9 support will do nothing for Linux machines as well (OpenGL). (which I have as a matter of fact).
Cooliscool is working on something that scans the ROM for the custom opcodes (RDSP codes) that load DLists into the display. How does Rice's plugin operate? Finding textures and outputing a SANE texture (what's sane? Well lets look at what is considered insane instead? How about 320x6 textures of which 40 are loaded and dumped into the display). This seems to be in my perspective the biggest impedment for retexturing projects and this particular plugin. I don't know if Jabo's will be better in this regard. I suppose asking him what they are thinking about is perfectly sane.
The next issue with the texture dumping is SANE identification. Right now it dumps thousands of textures into 4 folders. This is very hard to pick through and look at. The only sane way I have found to deal with it is to list the images by modification date. Again this is a messy way to deal with things. I would prefer to have some XML file that indexed all the data files as they are dumped in chronological order. Also the same XML can include information about objects as they are generated and used. IE object type Tree (all tree DLists are likely to be identical) this texture is applied to Mr Tree and this .. etc etc. This way the textures are associated with objects. So if someone else writes a program to handle the texture dumps and make hirez versions, even if there are 40 textures that are for example the splash screen, they are all associated with the splash screen. Or if say Conker has 4 textures, all 4 textures are grouped with him. Makes modifying and finding that silly texture easier is all.
The plugin does need a few graphics bugs fixed on it admittedly. There are a few times it crashes PJ64.
Another feature that would be helpful (for me) is some sort of dump IF it loads the HighRez texture and if not why it wasn't loaded. Things like that are really helpful in debugging ones stupidity <--
Also important for retexturing projects is control of what's dumped. Yes, if I don't want 4bit textures I don't want 4 bit textures. If I want 4 bit textures I don't want them in an index BMP file I prefer PNG, with a transparency color if there is one in the texture. These little adjustments can make the current PITA that making hirez textures is more of a nusance instead.
Cyb