What's new

Rice's Plugin Source <discussion>

mudlord

Banned
You should upload the binary, mudlord, if it's working correctly, and the source.

Sure, no problem, I'll also upload the updated BMGLib's source, too...that should solve problems with people not being able to find it....


If there's any asm in there, then be careful. Because there's not even a standard at how asm is interpreted. In Microsoft's and Intel's way, it's "mov dest, source", but mingw does it the other way, I believe: "mov src, dest"
Beware!

I checked, and there is definately x86 assembly in there. There's assembly code for the MMX/SSE detection, and for some other purposes....
 

Doomulation

?????????????????????????
That's straight retarded. I'd go as far as to say that that is bad for the industry, and drives a $%^#ing monopoly.

Fascists!

I don't believe there's monopoly here. Just that there is no standard on how assembly is to be written so different compilers do it different ways. Microsoft just follows Intel's way to do it (Intel and Microsoft's compilers interpret asm the same way).
 

mudlord

Banned
Okay, here's the binary (with zero code modifications), with my source, and BMGLib...

EDIT: Reupped BMGLib and Rice Video sources, made them much more compact, for bandwidth sake.
 
Last edited:
OP
Enzo Dragon

Enzo Dragon

STFU, NAVI
I don't believe there's monopoly here. Just that there is no standard on how assembly is to be written so different compilers do it different ways. Microsoft just follows Intel's way to do it (Intel and Microsoft's compilers interpret asm the same way).
Ah. I was thinking of something totally different. My bad.

Downloading your binary now, mud.
 

rabiddeity

Plugin Hacker
If you need someone to rip out the asm I'm game. Work on the NRage plugin is slowing down anyway, or at least it will once the Win9x issues get resolved.
 

mudlord

Banned
That would certainly be cool. From what I seen so far, the assembler code is all inlined, so it might need to be ported to C/C++...
 
Last edited:

Sirmatto

Member
I did a quick load of the VC7 project file with Code::Blocks and attempted to use Mingw as the compiler. I significantly lessened the errors I got before, since I now have DirectX set up properly, but the errors seem to be tied to VC specific code, but someone else with better VC knowledge should confirm this.
 

Sirmatto

Member
Also, I remember Hacktarux ported Rice's plugin to Linux a while back for Mupen64, but didn't release the source code, since Rice didn't want it released at the time, so maybe, now that Rice has released it, we can get him to release his version, since it might be more cross-platformish than the Windows version.
 

Cyberman

Moderator
Moderator
You can PM him about it or post in the MUopen asking him. I suggest PM ing him about it first. He's busy if I remember correctly. I suggest you use your utmost tact too. :D

Cyb
 

rabiddeity

Plugin Hacker
I've got a way you can cut the size of the current source down a lot. Remove the file Video.ncb (it's an Intellisense database for Visual Studio). VS will regenerate it, and nobody else needs or wants it. You can also remove Video.suo (user options file) to cut back a bit more flab.

For the BMGLib source I'd use a compression system that optimizes across the whole volume, like rar, 7z, or bz2, since there seem to be several duplicate files. That should save emutalk.net some bandwidth, heh.
 

Sirmatto

Member
So Hacktarux responded to my post here. And he definitely seems willing to share his version of the source, if he can find it, or even port the newer version of the plugin if he has time.

And rabiddeity, while you're hanging around here, I might as well pick your brain: I was looking through your source for the NRage plugin, and I noticed there's a few instances of some anonymous structs, which, while Microsoft likes, most conforming compilers don't. I'm just curious if (and why) you put those in there or if they are left over from the 1.83 version of the source. I'm going to try to get it compiling with Mingw, although it's a spare time thing that could take me awhile.
 

mudlord

Banned
Thats excellent news! :)

In the meantime, I'm going to fix up the last remaining issues with the Windows GUI options, namely missing tooltips and other related things...Also, it seems that the OpenGL framebuffer code uses P-Buffers (an pretty out of date render-to-texture method)....

I was contemplating, if its feasible, to reimplement OpenGL render to texture using framebuffer objects (which will help out with cross-platform compatibility). It seems that the plugin already has a framebuffer texture cache implemented, so it might be possible to do this (also, FBOs are much more cleaner to implement (much less code), and somewhat more efficient). Also, FBO's can also be processed by shaders...if custom GLSL shaders are implemented.....). My main concern, is whether this is technically possible, and the end-user side of things, as people might complain about increased system requirements etc..)..
 

mudlord

Banned
As promised..here's a new Rice Video build...All GUI problems should be pretty much fixed now...


Changes (only affect GUI):

New: Tooltips for hires texture/dumping options, etc.....
Updated: Grammar and typographical errors
Fixed : Dialog items sharing tooltips (due to conflicting resource ID numbers)
 
OP
Enzo Dragon

Enzo Dragon

STFU, NAVI
I'm amazed that emus run at all with my Intel video chip, no less full-speed without any problems. I'm wondering, roughly how taxing would the implementations you contemplated above be?
 

mudlord

Banned
I'm amazed that emus run at all with my Intel video chip, no less full-speed without any problems. I'm wondering, roughly how taxing would the implementations you contemplated above be?

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..)
 

Cyberman

Moderator
Moderator
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 <-- :D

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
 

mudlord

Banned
Thanks for the detailed list of ideas, Cyberman :)

As for the FBO idea, I see several possible things to come out of it. Only issue, like you explained, is, what actual use would the change make? One thing I can really see out of it is much simpler code, which could mean easier maintenance for this sort of thing (while the current OGL render to tex code is, IMO, quite inelegant, but maybe thats just due to how p-buffers are meant to be implemented, I guess)

Those ideas for post-processing I brought up were just novelty things I thought about, and I agree that it doesn't really help out with what needs to be straightened out first, but to me, their more of a extra than a need....

I'll certainly have a look at the hi-res texture code to see exactly how the whole retexture thing operates, then I guess we can work from there....
 

Top