Rice's Plugin Source <discussion> [Archive]

mudlord

January 9th, 2007, 00:08

Okay, so now I ran into some issues with DirectX (of all things....)

Here's my compile log..Note that my current modifications only affect Config.cpp:

Compiling...
stdafx.cpp
Compiling...
RSP_S2DEX.cpp
RSP_Parser.cpp
OGLGraphicsContext.cpp
DXGraphicsContext.cpp
DXGraphicsContext.cpp(1933) : error C2660: 'ID3DXFont::DrawTextA' : function does not take 6 arguments
DXGraphicsContext.cpp(1940) : error C2660: 'ID3DXFont::DrawTextA' : function does not take 6 arguments
DXGraphicsContext.cpp(1947) : error C2660: 'ID3DXFont::DrawTextA' : function does not take 6 arguments
RenderTexture.cpp
GraphicsContext.cpp
FrameBufferDX.cpp
FrameBuffer.cpp
DeviceBuilder.cpp
OGLRenderExt.cpp
OGLRender.cpp
OGLExtRender.cpp
D3DRenderExt.cpp
D3DRenderExt.cpp(51) : error C2660: 'ID3DXSprite::Draw' : function does not take 5 arguments
D3DRenderExt.cpp(229) : error C2065: 'D3DXSPRITE_DONOTMODIFY_RENDERSTATE' : undeclared identifier
D3DRenderExt.cpp(229) : error C2065: 'D3DXSPRITE_DONOTSAVESTATE' : undeclared identifier
D3DRenderExt.cpp(229) : error C2660: 'ID3DXSprite::Begin' : function does not take 1 arguments
D3DRender.cpp
VertexShader.cpp
VertexClipper.cpp
RenderExt.cpp
RenderBase.cpp
Render.cpp
OGLFragmentShaders.cpp
Generating Code...
Compiling...
OGLExtCombiner.cpp
OGLDecodedMux.cpp
OGLCombinerTNT2.cpp
OGLCombinerNV.cpp
OGLCombiner.cpp
DirectXDecodedMux.cpp
DirectXCombinerVariants.cpp
DirectXCombiner.cpp
DirectXBlender.cpp
CNvTNTDirectXCombiner.cpp
GeneralCombiner.cpp
DecodedMux.cpp
CombinerTable.cpp
Combiner.cpp
CNvTNTCombiner.cpp
blender.cpp
OGLTexture.cpp
DirectXTexture.cpp
TextureManager.cpp
TextureFilters_hq4x.cpp
Generating Code...
Compiling...
TextureFilters_hq2x.cpp
TextureFilters_2xsai.cpp
TextureFilters.cpp
Texture.cpp
ConvertImage16.cpp
ConvertImage.cpp
Debugger.cpp
Video.cpp
Config.cpp
Generating Code...

---------------------------------------
It appears there is a problem with the D3DX libs...Is there any chance of downloading these updated D3DX9 headers and libs without downloading a whole download of the DX9 SDK (which is way too much for me to download)?

EDIT: Nevermind...Downloading the October 2005 release of the DX9 SDK...Seems that the recent ones have doubled in size (which is my main concern, as 500MB seems a bit much...)

mudlord

January 10th, 2007, 00:26

Sirmatto

January 10th, 2007, 15:56

Okay, so I managed to get the whole thing to compile correctly..Only problem now (and a very weird one) is that no graphics are shown..On either renderer (DirectX or OpenGL...

here's the attached plugin and updated BMGLib to prove it... No modifications were made to the source at all when I compiled it.

Maybe he used an older version of the library? Although newer libraries shouldn't break compatibility, you never know. Maybe we can coax Rice into popping in and giving a few pointers on how to build this.

Enzo Dragon

January 10th, 2007, 21:30

Aye. We really should be asking Rice about this. He said he wanted people building on his code, but there's not much we can do if none of us know how to compile it correctly.

mudlord

January 11th, 2007, 00:07

I managed to solve those issues (graphics now work as they should). It appears Visual Studio.NET 2003's C/C++ compiler compiled broken code..Updating to Visual Studio 2005 Professional completely fixes it (however, there was some deprecation warnings, but still works like it should)..

Cyberman

January 13th, 2007, 05:18

has anyone attempted to migrate it to cygwin et all? I haven't used MS compilors for a long time. I was quite jaded by VC 5.0 then I bought VC++7 ... argh what a pain.

Cyb

Enzo Dragon

January 13th, 2007, 15:59

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

It'd be sweet if someone could migrate this crap to other libraries. =/

Sirmatto

January 14th, 2007, 20:09

has anyone attempted to migrate it to cygwin et all? I haven't used MS compilors for a long time. I was quite jaded by VC 5.0 then I bought VC++7 ... argh what a pain.

Cyb

I tried to do a quick compile with MSYS+Mingw and got more errors than you can shake a stick at, although I'm sure a good chunk of them are from the fact that my DirectX headers and libraries aren't set up correctly.

Doomulation

January 14th, 2007, 21:08

Enzo Dragon

January 14th, 2007, 21:58

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!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!

mudlord

January 15th, 2007, 01:13

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

January 15th, 2007, 09:50

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

January 16th, 2007, 00:25

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.

Enzo Dragon

January 16th, 2007, 00:32

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

January 16th, 2007, 03:22

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

January 16th, 2007, 04:11

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

Sirmatto

January 16th, 2007, 15:53

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

January 16th, 2007, 19:20

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

January 16th, 2007, 21:50

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

January 17th, 2007, 04:18

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.

mudlord

January 18th, 2007, 00:32

I done what you specified :). Sources reupped, and recompressed.

Sirmatto

January 18th, 2007, 04:42

So Hacktarux responded to my post here (http://www.emutalk.net/mupen64/39762-compiling-windows-question-hacktarux.html). 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

January 20th, 2007, 05:20

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

January 22nd, 2007, 01:56

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)

Enzo Dragon

January 22nd, 2007, 21:42

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?

NES_player4LIFE

January 22nd, 2007, 21:43

good update mud

mudlord

January 23rd, 2007, 00:12

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

January 23rd, 2007, 00:39

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

Scott123456

January 23rd, 2007, 01:39

(like adjust of aspect ratio, for example).

thats all i really need:drool:

mudlord

January 23rd, 2007, 01:55

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

Cyberman

January 23rd, 2007, 02:14

Thanks for the detailed list of ideas, Cyberman :)
LOL :D

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)I've noticed that the bugs in the code are mostly in the OGL implementation.
That might be due to it's current structuring and use of p-buffers. I was a bit frustrated with how slow OpenGL changes (like this should have been in 1.4 or 1.3 not now) became accepted into the standard. However this may be due to Microsofts involvement in the comitee.

To answer your question, how do you implement rendering new textures using OpenGL without extensions or other fancy things that you have to find? That's the real question. I believe in DirectX this isn't a big deal.

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.... It's not a big deal to add this later on in my view. It's just an improvement over the filtering selections for the textures right? (at least I think so).

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....Ehh that's the bread and butter of the plugin. I've got to do much the same I suppose. WEEE.

Cyb

mudlord

January 24th, 2007, 00:19

LOL :happy:

I dunno whether to be happy or sad...But I did look over your long response and I do agree that there is some major issues to be dealt with it. Like with control over what needs to be dumped and how...

To answer your question, how do you implement rendering new textures using OpenGL without extensions or other fancy things that you have to find? That's the real question. I believe in DirectX this isn't a big deal.

There is one method to do this without extensions: Orkin provides the solution in glN64.....and the results speak for themselves. Framebuffers with zero speed hit...

It's not a big deal to add this later on in my view. It's just an improvement over the filtering selections for the textures right? (at least I think so).

Yes, its a improvement....but not a big deal. Besides, it will be a tech support nightmare....with the possibility of endless questions..........

rabiddeity

January 24th, 2007, 01:11

Sorry for the late replies, guys.

Sirmatto, what you're saying about the anonymous structs is important. My guess is that they're left over from the 1.83 code, but that's really no excuse for not fixing them. If you could post in the NRage Plugin thread (in plugins) with details about line numbers and files where these anonymous structs happen, it'd be very useful. (VStudio doesn't complain about them for some reason, but it's got a lot of its own quirks.) Just pipe the Mingw output to a text file and post that in that thread with a little note, and I'll get right on it.

mudlord, looks like you're the new Rice plugin manager. If I could make a suggestion about the features vs. fixes problem, maybe you could fork the plugin into two different versions. The stable branch (6.1) can have all the GUI bugfixes and minor tweaks, basically things that won't break compatibility with older video cards. Then you have a working branch (6.2?) where you can rip out the p-buffers code and replace it. When that's done, if it turns out that it's still compatible with the older cards, you can backport it to 6.1. When that's finished, you can start changing the filters in 6.2. Along the way if you find bugfixes or annoyances that won't break things, you can modify them in both 6.1 and 6.2. When you start finding bugfixes for 6.2 that you can't apply to 6.1 without massive changes in the code, then you make a note and tell people it's time to buy new video cards.

If you're going to have more than one person actively working on the code, it might not hurt to have a source control server, maybe Subversion or something similar. Even if you're working on the code by yourself, it keeps things a bit sane. It's nice because it lets you keep track of what changes were made, who made them, and when (and also whether the change was committed to both 6.1 and 6.2 lines). It's something I wish I'd done with NRage. If you're interested, I'll see about getting Subversion set up on my own server, and I'll let you use it for Rice once it works.

mudlord

January 24th, 2007, 02:41

mudlord, looks like you're the new Rice plugin manager.

I think so...I guess..I don't have much N64 hardware experience, though...:(..and I start university again this year (for a computing related degree), so I really dunno how much time I can spend on this...

If I could make a suggestion about the features vs. fixes problem, maybe you could fork the plugin into two different versions. The stable branch (6.1) can have all the GUI bugfixes and minor tweaks, basically things that won't break compatibility with older video cards. Then you have a working branch (6.2?) where you can rip out the p-buffers code and replace it. When that's done, if it turns out that it's still compatible with the older cards, you can backport it to 6.1. When that's finished, you can start changing the filters in 6.2. Along the way if you find bugfixes or annoyances that won't break things, you can modify them in both 6.1 and 6.2. When you start finding bugfixes for 6.2 that you can't apply to 6.1 without massive changes in the code, then you make a note and tell people it's time to buy new video cards.

That's a excellent idea. Like, one stable branch for the current fixes I already have in place, and one unstable one for the real amibitious things, like the updated OpenGL framebuffer things, cooliscool's and Cyberman's improvement strategies for improving high-res texture support, and the post-processing filters (if that is viable, but its definately not a priority)..Also, it would be a great idea for helping managing the port to GCC-based compilers (if it hasnt already been done already)

If you're going to have more than one person actively working on the code, it might not hurt to have a source control server, maybe Subversion or something similar. Even if you're working on the code by yourself, it keeps things a bit sane. It's nice because it lets you keep track of what changes were made, who made them, and when (and also whether the change was committed to both 6.1 and 6.2 lines). It's something I wish I'd done with NRage. If you're interested, I'll see about getting Subversion set up on my own server, and I'll let you use it for Rice once it works.

Thanks very much for the subversion offer! That seems like a great idea....

Cyberman

January 24th, 2007, 03:29

Subversion is a godsend mudlord.
IT is superior to CVS in so many ways it's not funny but most importantly it allows you to undo a screw up. It keeps all the file revisions also. You can still make a total mess if you want though, it just takes a lot more effort. However it keeps track of revisions much better than CVS with DIFF output as well. Look at SourceForges implementation with a web based viewer for the content.

As for managing things in the plugin, what is, is. No use worrying about what was done, the important thing is to decide what to do. Choose your time use wisely as I always say. I spend more time deciding how to do something than actually doing it. That may sound wrong but in the long run it saves time.

I think a development and stable branch is a good idea. It is probably up for much debate as to what to do about the texture dumping and the stable branch. I suppose bleeding edge (development branch) will only have things that do not contribute toward stability. In this regard one should take a clue from Linux and Apache on there organization.

So maybe with some thinking a reasonable set of staged goals will help for each branch. This concept should be easily maintainable using Subversion as well.

rabiddeity it always best to think about what one should say. Then it doesn't have that anoying sound of being hastely beat into the keyboard. So taking your time to reply is fine with me by any means. It's not like someones life was on the line ;)

Cyb

rabiddeity

January 24th, 2007, 08:15

I just thought of something... should we move this thread out of 1964 and into plugins, maybe? (And I think a sticky might be in order too...)

Sirmatto

January 25th, 2007, 02:26

Continuation of this (http://www.emutalk.net/showthread.php?t=39636).

I think a SF page is in order, but instead of just Rice, we should make it encompass any and all N64 plugins. Maybe this will entice people like Azimer and Orkin to upload sources for old plugins ;)

And rabiddeity, I'll get those error logs to you. I read that basically, Microsoft makes anonymous structs 'legal', against ANSI and ISO standards...there's EEE for you :)

Sirmatto

January 25th, 2007, 02:27

I just thought of something... should we move this thread out of 1964 and into plugins, maybe? (And I think a sticky might be in order too...)

Done (http://www.emutalk.net/showthread.php?p=371615).

mudlord

January 25th, 2007, 03:07

rabiddeity made the proposal of a subversion server on his site, so maybe that can be a possibility for this? And that way, other devs can easily contribute to whats on there, and plus, I admit I have been swayed a bit by Cyberman's explanation behind SVN...

Enzo Dragon

January 25th, 2007, 07:05

Cyberman

January 25th, 2007, 07:56

I think cyberman has a good point. As a guy who's played around quite a bit with re texturing, it is a royal pain to figure out which textures go where in game. Association by object would be a great implementation. Via DList yes

The only thing that might be problematic is that many objects share textures. How would this be dealt with?The data is grouped in a file referencing what it's associated with. Even if it's used in 4000 unique objects it's just one texture that way. The texture dumping itself doesn't change hugely. You can't really dump one big texture often with objects. If you look at Resident Evil's textures you'll see they use 32x64 64x64 64x32 32x32 and many other sizes for there models. If you have a file that has the information about Object # that was used (even if something is done repeatedly it will be done in a procedural manner meaning each object code generation will be likely a function being called over and over again). After a DList is stuffed into memory it gets all the translation etc. done to it. So... this means (as cooliscool has shown) they are discoverable.

As for those "extra's" you were talking about, aspect-to-ratio is a feature that is sorely missing from Rice's plug-in, and a set of different shaders that could be implemented simultaneously would be cool. I'm afraid this is not something easy to implement. It's also not particularly important either. I'm almost positive allowing weird texture aspect ratios will only end up them being scaled to the original texture sizes to begin with. I'm not sure if you will gain very much by implementing such a feature either.

So is what you are asking for is "I want to use a 320x220 texture with a 128x128 texture in game" kind of thing? Or are you asking for "I want to use a 300x300 texture with an in game 128x128 texture" either request is silly. It's likely one will scale the texture to a base 2 multiple of the original texture anyways. This is really going to KILL loading though. Sorry it's not really a feature the plugin should being doing. A plugin is a low level piece of software. Enhancement features are part of the handling of textures. Using precise Lazacross3 scaling of a texture that's not a multiple and has a different aspect ratio than the original is asking a bit much isn't it? Remember it does have to have a reasonable render rate.

Cyb

Cyberman

January 25th, 2007, 16:56

Well I could have moved the entire thread I suppose.

I could close this one instead, since the subject matter has changed.

Cyb

Enzo Dragon

January 25th, 2007, 23:38

I agree that it is not important, I was simply commenting that it would be "cool".

As for "aspect ratio", I am not talking about texture ratio (I have no idea how that would help anyone anyway), but rather the game's display ratio.

In other words, changing the game's default output from 4:3 (standard monitor) to 16:9 (widescreen monitor). The current public release of Jabo's plugin has this feature implemented.

More about aspect ratio: http://en.wikipedia.org/wiki/Aspect_Ratio

About the attachments:
The forum auto-resized them, so just know that even though two of them is smaller, that has nothing to do with it.
All three are screens of PJ64 running with Jabo's plugin.

1. 4:3 (standard).
2. 16:9 (widescreen)
3. A comparison, with the first image put on top of the second, to show the difference in output.

Cyberman

January 26th, 2007, 01:19

I agree that it is not important, I was simply commenting that it would be "cool".

1. 4:3 (standard).
2. 16:9 (widescreen)
3. A comparison, with the first image put on top of the second, to show the difference in output.Please be more careful when you use the term aspect ratio. Why because if you had called Display Aspect Ratio or View Port Aspect ratio, I think then I would have keyed in on it quite easily. Aspect ratio is a GENERIC term not specific to just displays and windows. It refers to the ratio of a rectangle vertical and horizontal measurements. This includes everything from monitors to paintings to pieces of paper.

As for implementing said feature, yes it's possible (I don't know about the coolness of it). I believe this is an adjustment of the display attributes for the 3d. IE the matrix in OpenGL. It shouldn't require teeth pulling. Not sure about direct3d or what it involves.

In any case that's up to the person twiddling the plugin. If they have time etc. Heh.. I would need VS2005 to actually work with it (I hate MS software so I rarely invest in any of it) in the current state of things.

Cyb

rabiddeity

January 26th, 2007, 07:34

Can you merge them? I think vBulletin lets you do that, right? Merge the other thread into this one, and then move the whole thing to plugins.

Also, it's a bit offtopic but there are a couple stale stickied threads in plugins too. As long as you're in there, maybe you could unsticky those?

rabiddeity

January 26th, 2007, 08:53

I would need VS2005 to actually work with it (I hate MS software so I rarely invest in any of it) in the current state of things.

Cyb

Yes, I'm having some major problems compiling under VS .NET (version previous to 2005). Apparently my compiler lacks support for "long long". Also, I can't seem to link against the static BMGlib libraries I've generated. If those are needed for compiling, they really really need to be in the source tree already, maybe with a text file telling where to download the full source.

Regardless, I think getting a Makefile together should be a priority so that we can compile with Mingw and/or gcc.

ALSO...

I've finally got the Subversion server working, and created repositories for nrage_input and rice_video. I've uploaded the files for the NRage plugin already. It would be nice to have a working tree with the Rice files in it, so that we can get everyone working on it. mudlord, I'm sending you a PM with the details; anyone else who wants source commit privileges please send PMs to him (basically if you want to be able to upload changes and such).

Doomulation

January 26th, 2007, 13:43

Apparently my compiler lacks support for "long long".

Well, it's just another way of writing __int64 or INT64, which works under previous compilers.

mudlord

January 27th, 2007, 03:13

Hi,

I did some research into this "aspect ratio" stuff...Several code samples I seen showed off how to do it without much trouble.

It certainly can be done, I'm just not sure exactly how much source changes are needed to be done to both renderers (Direct3D8/9 and the OpenGL one) to do it though without breaking anything in the process...but I did have a brief look into the OpenGL part to see how might it needed to be modified to do it.

Also, I had a look into the post-processing filters. The simplest way to do it is via D3DX effects..saves a lot of hassle with seperate PS/VS files, and I found plenty of code into how to do it simply, so that might be a possibility too...but thats simply a novelty, unless hardware 2xSai/Scale2x is considered important....

Cyberman

January 27th, 2007, 06:35

mudlord
I thought that it wasn't a big deal.

DirectX seems to have more stuff put with it, but then again it's MS supported.

rabiddeity

I suppose an automake capability might be helpful? Well I am uncertain under the monotone of windows of that but in any case. :D

Cyb

Sirmatto

January 27th, 2007, 21:54

Regardless, I think getting a Makefile together should be a priority so that we can compile with Mingw and/or gcc.

Mingw chokes to death on the source code, since it's heavily VS dependent. I threw together a rough makefile, but I haven't been able to get to the computer it's on. But if you want to see all of the errors that pop up, I'd recommend snagging Code::Blocks (http://www.codeblocks.org), as it can import .vcproj and .sln files and compile it with Mingw, that way it's easier to start knocking out the VS dependent code.

And I know I promised you a log output of all the Mingw errors for the Nrage plugin, but that makefile is on the same computer as the Rice makefile, but you can get pretty much the same output with Code::Blocks.

mudlord

January 29th, 2007, 02:02

I thought that it wasn't a big deal.

DirectX seems to have more stuff put with it, but then again it's MS supported.

I know, it isnt a big deal, but I'm personally interested in this sort of stuff (it certainally fascinates me). It would be a nice compliment to the hi-res textures I think (that way, proper cel-like shading can be done with the textures)...but I dunno...I already started on adding the stuff in to do this sort of stuff (the GUI now has options for this), only 3 snags now are: setting up correct shader matrixes (using D3DXMATRIX mat; , since the plugin uses this matrix for world projection, OR we could get the actual data processed from the plugin..), setting the shader to work on the right texture and whether to get the shader to post-process the textrects OR the fillrects on each shader pass...

And yeah, I totally agree, Direct3D has plenty of useful stuff. Like with render-to-texture (framebuffer stuff), Direct3D has native capabilities for accelerating this sort of things, but OpenGL however, there's many different non-native methods...

rabiddiety, what errors are you getting when you compile that static lib?

rabiddeity

January 29th, 2007, 04:33

Well, it's just another way of writing __int64 or INT64, which works under previous compilers.

Is it forwards compatible? In other words, can we replace long long with either __int64 or INT64 for better compatibility?

rabiddeity

January 29th, 2007, 04:38

rabiddiety, what errors are you getting when you compile that static lib?

No errors compiling the lib, but when I try to compile the Rice plugin against it, I get linker errors. It's loading the lib correctly, but I think I'm not compiling the lib right or something. Anyway, just including that lib somewhere in the source tree would help a lot. That way, I don't have to download BMGlib sources just to compile. Or could we use LoadLibrary and dynamic calls instead? I mean, aren't BMGlib.dll and BMGlibPNG.dll required anyway?

mudlord

January 29th, 2007, 05:09

Only BMGLib.dll is needed...BMGlibPNG is only a version of BMGLib with PNG support, and nothing else.

Enzo Dragon

January 29th, 2007, 08:46

Glad to see this is making progress! I'm also glad that my suggestions on shaders and aspect ratio are being taken into consideration.

Doomulation

January 29th, 2007, 09:44

Is it forwards compatible? In other words, can we replace long long with either __int64 or INT64 for better compatibility?

I would say yes. I believe they're defined within sdk headers or something. Otherwise it's easy to do platform or compiler specific defines so either way you'll win.

mudlord

January 30th, 2007, 00:08

New update....for the stable branch

Updated: BMGLib.dll not needed anymore...

rabiddiety, I will put up the static lib I made of BMGLib on SVN. I had zero problems with linking however...now I just need to find some nice Rice texture packs to test it out on...all my texture packs I have are for Jabo's new plugin....

Cyberman

February 1st, 2007, 06:02

I'm not sure what to do about this thread.

The first post is the problem as it's nothing to do with the actual updated version of the plugin. Merging the two threads created this problem.
It would be good to have a single spot for people to download this update from (IE a single updated link in a post).
I believe mudlord you might want to start setting the attachments with build #'s so people do not confuse this with the original Rice's release version. That way they'll know and you'll know what the heck they are playing with in other words. :)
The first problem is part of the second problem we don't have a first post for mudord to update. Like Rice's original post. So what to do? Ideas?

Cyb

mudlord

February 1st, 2007, 06:59

Hmmmm....

Maybe a single stickied thread relating to plugin updates (and binaries/documentation for the end users and texturers), and a second one dedicated to the development & technical discussions (for the devs and code contributers)?

I'll gladly add versioning, like build numbers etc, so people don't confuse this with the official thing (so, that'll be problem 3 solved.)...

Doomulation

February 1st, 2007, 14:20

Cyberman

February 1st, 2007, 21:24

Right so I made a new Thread and stickied it.
This thread is now the discussion thread, bug reports here. New Features here and in the developement thread are ok. Mostly I think you'll see any changes put in the developement thread.

Right so mudlord (re)attach new versions of the Video plugin (with build # possibly) into to the first post. Any revision notes attach in a new post (so there is a chronology) not sure about how many posts this will make, however the first post is the one that should have the latest version stuck onto it. Edit it to add what you want too. The rest you can post revision information or whatever (feature requests possibly too).

The rest goes in this thread :D

Cyb

mudlord

February 5th, 2007, 03:35

Cyberman

February 5th, 2007, 06:02

Thank you very much for all that :).

All the organisation stuff is done (1st thread is all fixed up). I also worked out a possible plan for the two different plugin builds, so I know what do to do, and we can add in the plans for work if any other people want to help. Just trying to make things easy for you and keep people from getting lost so that's my job!

At the moment, I'm stuck into implementing the two things Enzo Dragon requested, and at the same time, working out ways to get the plugin to compile under mingw, because at the moment, it won't co-operate without a fight...heheheheheh.....I got the DX9 devpack for mingw, so my DX problems with it are fixed, there's just the matter of getting BMGLib to compiler under mingw, I might need to make a makefile for it, since Code::Blocks is not exactly being helpful...Code::Blocks doesn't help? Well.. I'm useless when it comes to direct X so.. OH WELL! ;) LOL. BMGLib is just for loading the image files right? It doesn't have anything really too do with DirectX in particular? If not it should be generic enough to not require a lot of code migration. Unless there are a lot of WinAPI specific code in it.

The OGL framebuffer code is desperately in need of a rewrite...since implementing FBOs under the current code in place of p-buffers wont work under the current framework, so that'll be fun...LOL... Ehh OGL is a tough nut to crack. You might want to ask about rendering to buffers in GameDev.net's forums in OpenGL maybe.

The OGL and DX code are in seperate implementation files I've noticed. However technically they are implementing similiar functions (just different API's) if not identical functions correct? Hmmm this means if you implement a new 'feature' for example how textures are filtered you would have to reimplement everything you did in DX in OGL no? This seems a bit anoying and redundant too me. At the moment I can't think of an elegant way to partition these without the redundancy of reimplementing the wheel with a different toolset (IE OGL versus DX).

16:9 versus 4:3 is not easy to do. Some games might not work too well off the top of my head comes Yoshi's Island. (2d game).

Cyb

mudlord

February 5th, 2007, 06:31

BMGLib is just for loading the image files right? It doesn't have anything really too do with DirectX in particular? If not it should be generic enough to not require a lot of code migration. Unless there are a lot of WinAPI specific code in it.

Yep, BMGLib is used for loading hi-res textures. BMGLib looks actually quite clean and portable, its just Code::Blocks doesn't like how I'm loading up the MSVC projects (it keeps throwing a tantrum when it comes to compiling time)...Maybe I can just make a fresh Code::Blocks project for it. Hopefully it will work ok then.

Ehh OGL is a tough nut to crack. You might want to ask about rendering to buffers in GameDev.net's forums in OpenGL maybe.

The OGL and DX code are in seperate implementation files I've noticed. However technically they are implementing similiar functions (just different API's) if not identical functions correct? Hmmm this means if you implement a new 'feature' for example how textures are filtered you would have to reimplement everything you did in DX in OGL no? This seems a bit anoying and redundant too me. At the moment I can't think of an elegant way to partition these without the redundancy of reimplementing the wheel with a different toolset (IE OGL versus DX).

Rendering to buffers is how the Glide3x wrapper for Glide64 Wonder ++ works with HWFBE. It simply takes a texture, packs the texture into a FBO, to do the texture copy (thus, zero speed hit for AGP/PCI-E based cards), and renders the output. Maybe a similar system can be for Rice's, that should stop people complaining about thier framebuffer speeds being crap. (but the current implementation is somewhat limiting that..because of how it uses the p-buffers..)

And yeah, its correct that they are using similar functions, and that each renderer is in seperate C++ source files. And adding nice and fast FBO's would mean, like you saying, reinventing the wheel quite a bit, since OGL p-buffers are quite messy in how they are implemented in the plugin atm....

Enzo Dragon

February 5th, 2007, 23:00

16:9 versus 4:3 is not easy to do. Some games might not work too well off the top of my head comes Yoshi's Island. (2d game).Correct. Some games do not look great in forced 16:9. For example, it seems that some games actively calculate where to put display textures based upon the distance from the edge of the screen, making for some strange results. For example, Mario Kart's track map system does not work very well, in so that the player's display dot appears to be off the track, or in the wrong position.
I doubt you'd have the same sort of problems with Yoshi's Isle, though, but I'm going to look into how games react to it now, since I have some free time on my hands.

Overall, though, I still think it'd be worth implementing for use with the games that do not react badly with it. Mario Kart looks fine, even with the minor screw-ups, and CBF, Zelda64 and Mario64 all work beautifully.
So far, the only game that is unplayable at 16:9 is 1080, and I'm not really sure why.

Cyberman

February 6th, 2007, 00:41

Yep, BMGLib is used for loading hi-res textures. BMGLib looks actually quite clean and portable, its just Code::Blocks doesn't like how I'm loading up the MSVC projects (it keeps throwing a tantrum when it comes to compiling time)...Maybe I can just make a fresh Code::Blocks project for it. Hopefully it will work ok then.Well if you don't need to have the projects be the same nusance, I can't think of a reason why not :D

And yeah, its correct that they are using similar functions, and that each renderer is in seperate C++ source files. And adding nice and fast FBO's would mean, like you saying, reinventing the wheel quite a bit, since OGL p-buffers are quite messy in how they are implemented in the plugin atm....I looked over the code more, well my thinking is that not much can be done by having to implement parallel code blocks. It's just a fact of life, unless you want to have a DX plugin and a seperate OGL plugin. (I see that as a bit silly). So basically what the problem with OGL is entirely with the p-block implementation. Hmmm I'll look at it I suppose, I would rather look at how the texture selection and dumping process works :D

Correct. Some games do not look great in forced 16:9. For example, it seems that some games actively calculate where to put display textures based upon the distance from the edge of the screen, making for some strange results. For example, Mario Kart's track map system does not work very well, in so that the player's display dot appears to be off the track, or in the wrong position.
I doubt you'd have the same sort of problems with Yoshi's Isle, though, but I'm going to look into how games react to it now, since I have some free time on my hands.Perhaps returning one set of dimensions and having the display at another would clear up the display textures are pasted and it might also remove the issues with Yoshi's Isle. IE bluff the game. For example 854x480 would return, 640x480 however it's actualy pitch would be 854. Ditto for 1068x600 and 1366x768, 1600x900 etc. This means games such as Yoshi's will just be in the center of the display instead of filling the display. It might mean a few will look a bit odd depending on how much is off to the side of the display :D

Cyb

Enzo Dragon

February 6th, 2007, 02:04

I just tried Yoshi's Isle with Jabo's plugin set to force aspect ratio, and the game looks fine, except for the sort of things I mentioned about Mario Kart, and some problems that are strictly related to Jabo's Plugin. Yoshi's shadow is not directly under him, and his distance away from you depends on how far away from the edges of the level you are.

What you've suggested, Cyberman, sounds reasonable, though I'm not sure if I fully understand what you mean.

mudlord

February 6th, 2007, 02:06

Correct. Some games do not look great in forced 16:9. For example, it seems that some games actively calculate where to put display textures based upon the distance from the edge of the screen, making for some strange results. For example, Mario Kart's track map system does not work very well, in so that the player's display dot appears to be off the track, or in the wrong position.
I doubt you'd have the same sort of problems with Yoshi's Isle, though, but I'm going to look into how games react to it now, since I have some free time on my hands.

Overall, though, I still think it'd be worth implementing for use with the games that do not react badly with it. Mario Kart looks fine, even with the minor screw-ups, and CBF, Zelda64 and Mario64 all work beautifully.
So far, the only game that is unplayable at 16:9 is 1080, and I'm not really sure why.

So, some games make heavy use of the Z-buffer? Hmmm, its weird that 1080 screws up in 16:9, maybe it might work in anamorphic?

Perhaps returning one set of dimensions and having the display at another would clear up the display textures are pasted and it might also remove the issues with Yoshi's Isle. IE bluff the game. For example 854x480 would return, 640x480 however it's actualy pitch would be 854. Ditto for 1068x600 and 1366x768, 1600x900 etc. This means games such as Yoshi's will just be in the center of the display instead of filling the display. It might mean a few will look a bit odd depending on how much is off to the side of the display

so, we are saying we keep the games original calculations for depth and ratio, but we do it on the graphics API end, so the game has zero idea what happened???

rabiddeity

February 6th, 2007, 03:46

mudlord, I've added and committed 2 new files that let you open and compile the project under VS.NET (Visual Studio 7). Files are called "Video 7.sln" and "Video 7.vcproj"; if it doesn't work you can blame me. :shifty:

mudlord

February 6th, 2007, 03:55

Cool...So now, that means that VS.NET 2003 is now a suitable compiler platform now for the plugin? I guess now I will update the docs to reflect this.

rabiddeity

February 6th, 2007, 04:05

Not quite yet, you need to replace "long long int" with "__int64" and there are a couple other issues. If you don't mind, I'll fix them in one commit as soon as I get it to compile without warnings. If you have any problems with the commit, feel free to roll it back.

One more thing, please move the BMGLib stuff into the trunk. In other words, move the /bmglib/lib folder to /trunk/lib, make sure the .h files are in there, put the .lib file exactly where it needs to be, and then make sure the /bmglib tree is gone from the root; basically, if you need it to compile the code, it should go into the trunk. (Putting it under version control also ensures we're all working with the same version of the lib files too.) That way anyone can pull the trunk and compile and it should work.

edit: still getting linker errors from VS .NET, from the BMGLib.lib file posted. Gonna see if I can work it out on my own.

mudlord

February 6th, 2007, 04:22

I performed that subversion management task.

I really don't mind what changes you make. :) Having support for more compilers just opens up the opportunities for more devs to get involved. :)

rabiddeity

February 6th, 2007, 05:34

I performed that subversion management task.

I really don't mind what changes you make. :) Having support for more compilers just opens up the opportunities for more devs to get involved. :)

Got it, needed to change the project's default calls from __fastcall to __cdecl. That fixed some things, but now I've got some other errors to wade through. I'll get back to you.

Cyberman

February 6th, 2007, 06:26

so, we are saying we keep the games original calculations for depth and ratio, but we do it on the graphics API end, so the game has zero idea what happened???Right the game keeps all it's information the same, the API handles the extra stuff to the side. Although depending on how the game implements cliping we might have to do some cliping adjustments. Might be good to try this on a complete 3d games first like CBFD Super Mario 64.

Another thing to check would be the screen's aspect ratio For example my one of my Samsung's is a 4:3 display with 1280x1024 resolution the other is 1440x810. If you know the native display resolution and actual aspect ratio this helps immensly making the image look right. (ACK that reminds me I need to adjust my Xwindows aspect ratio to 16:9 I've had this stupid thing almost a Year and haven't changed my X display settings LOL).

Argh it looks like source forge changed to SVN 1.4 without warning people or someone else did on a project. What a pain. I hate it when people update and make everyone else update as a consequence.

Cyb

rabiddeity

February 6th, 2007, 09:14

Yay, I got it to compile under DX9!

OK, here's what I needed to change:

BMGLib.lib file-- I needed to recompile it. Your version included calls to ftol2_sse (needs to link to libcntpr.lib). You should remove the driver DDK from your include path when compiling BMGLib, or specifically tell your IDE to ignore it. I compiled with just Windows SDK and DirectX 9 SDK as my include paths. This should make it possible to compile without requiring libcntpr.lib (and as a nice side benefit not require kernel calls), and will hopefully still work on your system. I'll hold off on pushing this to the server for now, because it seems to be giving me duplicate symbol errors under DirectX8 compile.

Calling conventions: changed all from __fastcall to __cdecl. If you had tried to compile a debug binary, you would have run into this issue as well. We might be able to switch this back later, but since the BMGLib.dll file is compiled on __cdecl, we need to call it like that. Changed in all the .vcproj files, including yours.

Removed references to $(Emu1964Dir) in .vcproj files, and replaced them with sane defaults.

Changed "Optimize for Windows Application" to FALSE in Video 7 and Video 7.10.vcproj; this will produce unstable code when used for a DLL.

Changed long long int to __int64 in UCodeDefs.h

Still doesn't link right under dx8 mode here, but I think it's because I lack the proper libraries or don't have something set up right.

rabiddeity

February 6th, 2007, 09:37

OK, now that I can compile it, let's take a look at what needs fixin.

I'm looking at a slew of implicit conversion warnings, double to int and double to float. I've fixed a couple of them by changing exp to expf, things like that (change from funcs that take a double and return a double to funcs that take a float and return a float). It's no faster, but it at least shuts up some of the compiler warnings.

The rest that I didn't fix, well those involve taking an abs of a float or double and only requiring an int in return... if I remember properly there are a couple functions in the Mesa library that do those sort of things really fast. I'd rather use those than (int) casting, which is dog slow, so I'll leave those alone until we can get an optimization team to look through it.

BTW, which functions in the video plugin are currently the slowest? The least stable? (This is a question for both the D3D and OpenGL portions individually.)

Cyberman

February 6th, 2007, 19:31

There are a few bugs in the plugin that aren't obvious in most games.
Resident Evil 2 brings MOST of these out. First there appears to be a depth sort issue with the background textures and 3d. Without hacking the game (gah), my guess is this has to do with another obvious bug in the game. Certain static 3d objects in the game are the original game size and location. The obvious one is when you enter the RDP and go to the computer you see this weird flickering spot on the screen that doesn't relate to anything in the evironment. Bullets and Ink Ribbon are correct and in the right place. Just not the monitor flicker. This isn't likely the games fault. :) As for depth on the display, hmmm not sure where this might be happening. Obviously it's NOT the game and ALL plugins have this issue last I checked.

My guess is there is some depth sorting issue and it's neglecting a 3d object or two that are implement uniquely in the game (flickering light objects only I might point out).

Wire Frame mode has a missing feature, or a bug, it doesn't clear the display between frames so it looks weird. Obviously textures etc aren't visable in this mode, so it might be good to clear the display between frames. Jabo used on is 1.6 Beta a nice features of making the textures transparent on 3d objects. This might be good for 2d surfaces all together.

Is there a dumping/debugging version of the updated plugin?

Cyb

mudlord

February 7th, 2007, 00:24

Is there a dumping/debugging version of the updated plugin?

I'll do a compile of the debugger build ASAP...

rabiddeity

February 7th, 2007, 00:24

You can compile as Debug but you probably want to compile against a Debug BMGLib; call it BMGLibDbg.lib

Does anyone have a version of d3dx8.lib they can send me? Newest DirectX SDK doesn't include it. Or should we just abandon the DX8 line? I don't think that's unreasonable, as everyone should have 9.0c by now, even the Win98 users.

mudlord

February 7th, 2007, 00:54

Here's a link for that D3DX8 lib file (and some others):

Here (http://www.microsoft.com/downloads/details.aspx?FamilyID=fc60231e-895d-489d-b796-e0fcac82b553&DisplayLang=en)

I don't see the problem with dumping DX8 support, at least it will make the source code cleaner! (by not having seperate DX8 specific things) And besides, the DX9 code is quite stable and works from my testing...Only problem I can see
is people moaning about upped requirements, but meh.....Windows 95 support is deprecated by Microsoft anyway....:yawn:

Currently, the most severe problems in the plugin are:

* Framebuffers (easily the least stable, as motion blur seems to be a major problem, often leading to crashing. The P-buffer code in the OpenGL section is particulary horrendous. The current render targets code for Direct3D need to be tuned up for speed, though.)
* Depth buffers (for example Zelda OoT and the sun, and coronas in the two Zelda games and PD. Many other games have problems too with this, however RE2 has a particular issue to do with depth as well.)
* Texture mapping errors (like with BK, SM64's sky textures and some other games with texturing problems...)
* A size problem with dumping hi-res textures

I might even start writing a compatibility list for the plugin, to go in the documentation...to document what might need to be fixed.

rabiddeity

February 7th, 2007, 09:23

I might even start writing a compatibility list for the plugin, to go in the documentation...to document what might need to be fixed.

That would be a great start. Also, if any fixes depend on other fixes or might be affected by other fixes, you should write that down (i.e. if we change from p-buffer code in OGL, will it require changing a bunch of code for depth buffers too?)

mudlord

February 8th, 2007, 00:11

Cool, I'll get right on it, I guess now I betta start playing through some games (which will be fun...) :)...

And...I did a debugger build. The main issue with it is that BMGLib seems to have a problem with compiling this way, which means the debugging plugin crashes whenever hi-res texture loading/dumping...But I don't see why people would use a debug build for playing games though...:P...the debugger functions all work great BTW.

Enzo Dragon

February 8th, 2007, 01:09

I think RE2 might not run because of core emu, rather than video plugin crap. I say this because as far as I know, it doesn't run on any emu or any video plugin.

From what I know about RE2, the cart itself is different from other 64 carts to begin with. The game spans two carts, first off, and it probably has an on-board mod. I can't find a lot of info on it, though. =/

mudlord

February 8th, 2007, 03:10

Also, RE2 uses a custom sound system for voice compression (seems to be MusyX, from my sources..), which is very picky on timing....So, I agree about the core issues. I managed to get RE2 to run on Mupen64 0.5.1 and the latest PJ64 beta fine, with no problems, though...Main graphics issues for this game though are the flickering and depth buffer problems...

Cyberman

February 8th, 2007, 07:25

RE2 is fully playable last I checked on PJ64 1.6 with the latest RDB (8/13/2006). Sure there are bugs in the audio, however I've played the whole game through (without the audio working 100%). Thank goodness for gamefaqs huh? :D

Back to the actual graphics bugs, I don't know how RE2 handles the depth sorting, I noticed that the plugin incorrectly puts forground and background objects of the 2d layers in the display all together the way it is now. This likely indicates that the background information is stored in a buffer that is then 'die cut' and put to the display in a certain order. Perhaps steping through a scene to see how it's being assembled from the plugin's standpoint might be a good idea.

Now some thoughts on what the GAME is doing that might provide clues as to what the plugin SHOULD be doing. FF7 uses a tiled background etc for it's scenes. RE2 uses 3d objects for interaction therefore it doesn't support a detailed multilayered background like FF7. However FF7 assigns a DEPTH to each layer in the background so that it knows when a character is in front of or behind an object. The same is likely what RE2 is doing. The cut out sections are sorted by depth and pasted in order of depth (along with the models and such). From observation some 3d objects are obscured by the background. I believe the bug is directly related to the weird scaling issues that are present with certain 3d objects. Running the game in the original display dimensions does not make things magically work however. (I tried it trust me). I suggest instead of pointing fingers at different things such as the 'core', one should look at how the GPU on the N64 thinks it's supposed to work.

How about finding test sections of the game to use for debugging, that is how I found out how the battle models worked in FF7. It's also how someone deciphered the animation format. Thank goodness PJ64 has save states to peer into to see what's up huh?

Cyb

mudlord

February 8th, 2007, 08:04

I suggest instead of pointing fingers at different things such as the 'core', one should look at how the GPU on the N64 thinks it's supposed to work.

I think I didn't point my fingers at the core, I only agree with the audio being core/RSP related (which it is). I know that its purely a video plugin related matter.

I noticed that the plugin incorrectly puts forground and background objects of the 2d layers in the display all together the way it is now. This likely indicates that the background information is stored in a buffer that is then 'die cut' and put to the display in a certain order. Perhaps steping through a scene to see how it's being assembled from the plugin's standpoint might be a good idea.

Z-buffering, perhaps? Explains why Glide64 requires HWFBE for perfect emulation for this game, since it uses the depth buffers...

The same is likely what RE2 is doing. The cut out sections are sorted by depth and pasted in order of depth (along with the models and such). From observation some 3d objects are obscured by the background. I believe the bug is directly related to the weird scaling issues that are present with certain 3d objects. Running the game in the original display dimensions does not make things magically work however.

Sounds like a definate depth buffer sorting issue...not so sure about the scaling, I better check this out to see how the plugin is doing it though...

How about finding test sections of the game to use for debugging

Opening scenes are definately great sections for debugging this. There is noticable sorting errors, like with the car objects etc...

Thank goodness PJ64 has save states to peer into to see what's up huh?

Yep!

Cyberman

February 8th, 2007, 16:47

I think I didn't point my fingers at the core, I only agree with the audio being core/RSP related (which it is). I know that its purely a video plugin related matter.Twernt you I was refering too. :D

Z-buffering, perhaps? Explains why Glide64 requires HWFBE for perfect emulation for this game, since it uses the depth buffers... My guess is yes, it manually sorts through the displayed objects possibly but using of course the 'microcode' from the RSP/RDP (and the PDQ too many abreviations dude).

Sounds like a definate depth buffer sorting issue...not so sure about the scaling, I better check this out to see how the plugin is doing it though...Well unfortunately I could give you images tell cows moo like parots, however that won't be too helpful. Apart from seeing the weird flaw. Of note it only happens on CERTAIN objects, those that flicker in the game, light sources such as the computer monitor, card swipe machine, the shutter controls etc. I think the 3 stones you stick into that piece on the wall also show some of the errors. Ribbons and bullets are positioned correctly (just visable from every direction) and the storage locker is correct.

Opening scenes are definately great sections for debugging this. There is noticable sorting errors, like with the car objects etc... Ehh I've been using that to test the depth issues. The scene with the computer in the main hall that is where you'll find the weird positioning and scaling issues. I noticed SOME of the object is obscured so it might actually be doing the depth sorting, just on the wrong scale. IE the depth buffer might not be scaled acording to the 3d object sizes.

Cyb

Enzo Dragon

February 8th, 2007, 21:50

Ah. I wasn't aware it was fully playable! I guess I'm stuck in the past? Sorry for the incorrect info.

Rice

February 9th, 2007, 17:24

Guys,

I just stopped by. I am very happy that the source code has been picked up by your guys. Thanks very much.

RE2 renders the scene backgrounds as static 2D sprites + static 2D depth buffer sprites. To support such functions, the depth buffer texture needs to be load into the depth buffer directly (after conversion / enlargement / value renormalization ...). Most video cards do not support depth image loading feature, at least not may ATI 9600 card, so I left such feature out.

There are some thing could be done to get around such a depth buffer usage, but nothing will be easy.

Cyberman

February 9th, 2007, 22:25

Guys,

I just stopped by. I am very happy that the source code has been picked up by your guys. Thanks very much. We thought you died... we had the funeral all planned too ... sigh.

RE2 renders the scene backgrounds as static 2D sprites + static 2D depth buffer sprites. To support such functions, the depth buffer texture needs to be load into the depth buffer directly (after conversion / enlargement / value renormalization ...). Most video cards do not support depth image loading feature, at least not may ATI 9600 card, so I left such feature out.Hmmm I played RE2 for the PS1 last night, the RE2 version for the N64 is mostly the data from that ported. Obviously they had to do some interesting things to make it work. As for why the depth buffer issues yeah that makes more sense than anything else I can speculate about. This explains why you dump the entire background as you do.

There are some thing could be done to get around such a depth buffer usage, but nothing will be easy.I wonder if this is similiar to the problem in Banjo Kazooie and the jigsaw mess there? Eventually such things will need to be supported). As for a way around the problem, how about switching between Orthogonal view matrix and a perspective matrix to do the trick at least for OGL (DX I have no clue about). This is what we are doing with Q-gears and the background scenes in FF7. (of course we aren't using DX at all).

Anyhow great to see you are alive Rice. :)

Cyb

Enzo Dragon

February 9th, 2007, 23:25

I wasn't going to mention it because I wasn't sure there was a fix for it, but I figure I may as well:

Whenever I am playing a game in full screen, my computer goes nuts if another window opens (like an instant message, for example). The game ends up becoming stuck in full screen, and the taskbar and any other open windows flicker in and out of view rapidly.

It is sometimes possible for me to fix this by clicking my emu on the taskbar, though alt-tabbing does nothing but flicker whichever window I set focus to slower (unless it is the emu, in which case nothing happens, but nothing is fixed). While this is going on, though, pressing esc does not fix anything.

Also: Rice, it's nice hearing from you!

Rice

February 10th, 2007, 04:40

X-Fi6

February 11th, 2007, 01:56

Hmm, I'm look forward to this. :) It's about time someone continued Rice's work that he left.

mudlord

February 12th, 2007, 01:13

"Banjo Kazooie and the jigsaw mess" are some other ways to use the rendering buffer. What the game do is to render the scenes, then switching back buffer to another memory location, so the earlier rendered scene is left in the memory and the game uses it as a big texture (the jigsaw pieces, etc).

My current implementation tries to detect such back buffer memory pointer changes, and save the back buffer (copying back from video card memory to PC main memory). The current implementation may have problems, or bugs, with certain situations, in which such detection fails.

Thanks for that info, it explains to me why you were doing those backbuffer reads . Now it makes sense to me exactly why you are currently doing framebuffer things the way you are doing, its definately helpful now realising how exactly things are done now, to try and improve those things....:)..

Also, IIRC, most new video cards support hardware render to texture...Maybe that can be used to accelerate these framebuffer read/writes? I've been contemplating that for some time, but it might be a tough cookie to beat....

I wasn't going to mention it because I wasn't sure there was a fix for it, but I figure I may as well:

Whenever I am playing a game in full screen, my computer goes nuts if another window opens (like an instant message, for example). The game ends up becoming stuck in full screen, and the taskbar and any other open windows flicker in and out of view rapidly.

It is sometimes possible for me to fix this by clicking my emu on the taskbar, though alt-tabbing does nothing but flicker whichever window I set focus to slower (unless it is the emu, in which case nothing happens, but nothing is fixed). While this is going on, though, pressing esc does not fix anything.

Nuts....sounds like a config code bug...And BTW, I worked out a simple solution to your aspect ratio request. We simply calculate the ratio from the full screen resolution values, thus enabling support for 16:10 etc....:), now I just need to work out how to do the exact same thing for DirectX...hmmmm

Enzo Dragon

February 12th, 2007, 01:42

BTW, I worked out a simple solution to your aspect ratio request. We simply calculate the ratio from the full screen resolution values, thus enabling support for 16:10 etc....:), now I just need to work out how to do the exact same thing for DirectX...hmmmmNice! I will certainly be looking forward to that.

rabiddeity

February 13th, 2007, 00:14

Thanks for that info, it explains to me why you were doing those backbuffer reads . Now it makes sense to me exactly why you are currently doing framebuffer things the way you are doing, its definately helpful now realising how exactly things are done now, to try and improve those things....:)..

Cool... If it wasn't immediately apparent before, you should add comments to explain the purpose of the backbuffer reads. Add comments to the code block and commit!

mudlord

February 13th, 2007, 00:21

Cool... If it wasn't immediately apparent before, you should add comments to explain the purpose of the backbuffer reads. Add comments to the code block and commit!

Sure thing. :)

Nice! I will certainly be looking forward to that.

Here's a little something for you to play with, it might not be that stable since I haven't tested it..its based off my development branch....but, enjoy anyway...as I explained, I didnt do a DX equivalent, yet....

EDIT: Attachment removed...I'm sure the relevant people have a copy of it....

Enzo Dragon

February 13th, 2007, 14:56

I don't have my computer set up for OpenGL, anyway. I probably should get around to doing that, though.

Probably. Though I am not sure how I would go about doing it.

Doomulation

February 13th, 2007, 16:58

For Windows OpenGL is already set up, so to speak... and I'm assuming you use that.

Enzo Dragon

February 16th, 2007, 10:25

For Windows OpenGL is already set up, so to speak... and I'm assuming you use that.Whenever I try to use OpenGL as my render engine, PJ64 crashes after loading the ROM. This leads me to believe that I don't have the right libraries.

Cyberman

February 16th, 2007, 16:41

Considering the current implementation of the OpenGL is somewhat unstable in the plugin, and that it uses features not supported by the default OpenGL drivers (IE it's 1.3 or 1.1) I suspect that you might want to hold off until the destablizing factors AND...

mudlord suggestion put what version and the vendor of the OGL drivers are in the plugin config. ALSO you should have a button that says "Paste settings to clipboard" this will give a complete dump of what card DX and OGL versions they've got along with all the settings for the plugin.

Save people guessing work (and lots of picture posting of the multitude of tabs).

Cyb

Rice

February 17th, 2007, 03:29

PJ64 crashes (when you stop a game) with this plugin in OGL is PJ64's known problem with any OGL video plugins. It might have been fixed in new PJ64 versions.

mudlord

February 19th, 2007, 03:41

mudlord suggestion put what version and the vendor of the OGL drivers are in the plugin config. ALSO you should have a button that says "Paste settings to clipboard" this will give a complete dump of what card DX and OGL versions they've got along with all the settings for the plugin.

I might do something to output the OGL version supported (which is returned from the drivers). Vendor stuff is quite easy to do (I'm very sure there are functions in OpenGL to return them).

As for the settings dumpings, maybe it can log all the settings into a easy-to-read TXT file...But the "paste to clipboard" idea sounds more practical...

PJ64 crashes (when you stop a game) with this plugin in OGL is PJ64's known problem with any OGL video plugins. It might have been fixed in new PJ64 versions.

From what I heard, Zilmar did some threading changes to how plugins are loaded. These changes currently affect DX plugins, and not the OGL ones...I might bring this up with him, though.

EDIT: Well, researched the updated vendor stuff, and yep, 100% possible, using glGetString....I might do a updated stable build this week, depending on how busy I am with other commitments, like university and my work with ziggy on Hacktarux's Glide3x wrapper...

Enzo Dragon

February 21st, 2007, 06:46

I might do a updated stable build this week, depending on how busy I am with other commitments, like university and my work with ziggy on Hacktarux's Glide3x wrapper...Good times

klasa

February 21st, 2007, 07:44

Should I post feature requests in this thread?
Well, if it's wrong aome moderator will likely replace it :P

Here they go:
- removal of the high res texture size limit (so 8 times bigger would be possible)
- support for replacing big textures (like the top-view from link's house in OOT)
- checkboxes to choose if you want a certain texture-type to be dumped (ci__bmp, ci_bmp_with_pal_crc, etc.)

by the way: you're doing a greeat job in improving the plugin!

mudlord

February 21st, 2007, 08:10

It might be moved....

So, basically, you want some more flexibility and control over the texture dumping process?

Well, heres what I think about those requests:

1) Is there any real reason for the texture size limit to be increased? (if its technically feasible to do in the first place, without breaking texture loading in the process)?
2) The extra control for dumping textures sounds pretty cool, and is something I look forward to doing. But then, some people might not like that, I'll have to see what people think first before going ahead.
3) I'm not quite sure on the best approach to handle the big textures..though...

rabiddeity

February 23rd, 2007, 00:56

mudlord, what's the technical limitation on texture sizes, not for dumping but for loading and using in-game? Is it a limitation of graphics cards? API? The texture loading code?

mudlord

February 23rd, 2007, 01:09

I'm pretty sure its a limitation of the texture loading code. Most new video cards support texture sizes of up to 4096x4096 (so its not a video card or API problem)..Problem is, how those textures would be mapped right when loaded, since they would be so big....

Also, I'm gonna do that framebuffer code commenting right now...

klasa

February 23rd, 2007, 06:58

I wanted you to know that the preview version complains that d3d9_27.dll is missing. But when I've downlaoded the file it worked again, maybe you can include it or something? (When i put the file in the windows dir I only sayw no. 28, 29 and 30)

EDIT: When I try to open a rom, it scans for textures, then turns black, and then vista states that there's a problem, and that it needs to shut down PJ64

mudlord

February 23rd, 2007, 07:27

I havent tested the plugin under Vista, yet (since I havent acquired it, and the required video/sound/virtual drive drivers for my system)..so, I really don't expect it to work wonders with it.....I'm surprised it even loaded...

As for the d3d9_27.dll error, I will bundle it from now on. Thanks for that :).

klasa

February 23rd, 2007, 07:42

Well, the stable version works under vista (in case you didn't know) :P

mudlord

February 23rd, 2007, 07:58

Must be a thing with DX9 and Vista.....Isnt DX9 emulated under it????

klasa

February 23rd, 2007, 09:31

I've just tried with OpenGL, and I got the same error, it checks for the textures, then a black screen, and then vista says PJ64 has stopped working...

EDIT: Nevermind, OpenGL doesn't work with the stable version either.

Doomulation

February 23rd, 2007, 11:58

I wanted you to know that the preview version complains that d3d9_27.dll is missing. But when I've downlaoded the file it worked again, maybe you can include it or something? (When i put the file in the windows dir I only sayw no. 28, 29 and 30)

Just for your reference, downloading the latest version of DirectX and installing it installs those d3d9_xx.dll files.

klasa

February 23rd, 2007, 16:19

I've tried and downloaded/installed http://www.microsoft.com/downloads/details.aspx?FamilyID=2DA43D38-DB71-4C1B-BC6A-9B6652CD92A3&displayLang=en , and it still gives me the same error

mudlord

February 24th, 2007, 00:20

If your using Vista, it could be due to the OpenGL implementation...

I tested out the stable version in DX and OGL in XP, and I noticed no real anomalies, I haven't tested out the hi-res texture loading thoroughly though...I mainly tested on Super Mario 64 and Zelda OoT....

I did some work on the texture loading issues last night, and I managed to find where it broke (I have a fair idea where..). I'll post a solution when its stable enough, though, without glitching up in the major games that people retexture...

klasa

February 24th, 2007, 07:18

I found out the problem! The plugin crashes once a highres texture is loaded onto the screen (try starting zelda with only the logo files in the dir).

If you're not using high res textures, there seem to be no problems.

mudlord

February 24th, 2007, 11:13

Thank you very much for confirming what I thought...:D

That info has been a great help. :)

Cyberman

February 24th, 2007, 21:53

mudlord
Could you dump information to a file (This would be an advanced option obviously) what file name the game loads for hirez textures, and WHERE it started looking as well? I've never been able to get hirez textures to work that I've made. So I thought I was insane or something, if the plugin gives feedback as to what it's looking for.. that will help emmensely in naming the textures.

On a side note, it might be good to have a clean and definative information bit of what gets dumped where in the texture dumping thing. Actually what I would like most is to allow it to dump textures and stuff them into neat seperate directories. In a game textures get loaded as needed for an area. On start up a bunch of textures get loaded and dumped to the screen. It would be nice to dump groups of textures that are loaded about the same time into the same directory. That makes it easier to figure out what they belong too.

I ramble.

Cyb

Enzo Dragon

February 24th, 2007, 22:11

The shaders you've implemented thus far are nice, mudlord. I'm quite impressed.

One thing I'm wondering: What do you mean by "make the frame buffers more 'pleasan't"?

mudlord

February 25th, 2007, 23:06

Could you dump information to a file (This would be an advanced option obviously) what file name the game loads for hirez textures, and WHERE it started looking as well? I've never been able to get hirez textures to work that I've made. So I thought I was insane or something, if the plugin gives feedback as to what it's looking for.. that will help emmensely in naming the textures.

On a side note, it might be good to have a clean and definative information bit of what gets dumped where in the texture dumping thing. Actually what I would like most is to allow it to dump textures and stuff them into neat seperate directories. In a game textures get loaded as needed for an area. On start up a bunch of textures get loaded and dumped to the screen. It would be nice to dump groups of textures that are loaded about the same time into the same directory. That makes it easier to figure out what they belong too.

I ramble.

Logging like that sounds like a cool idea, and shouldnt be that hard. (your request for showing OpenGL info was pretty damn easy to do, and that will be in the next stable build).

Dumping in seperate directories based on texture type.....thats a great idea too...Maybe that can also be with klasa's request, by having control over what exactly is dumped. I'll do a seperate "hi res texture" dialog box in the GUI for all hi-res texture stuff, that way, all the hi-res options are isolated, thus making it easier to identify.

The shaders you've implemented thus far are nice, mudlord. I'm quite impressed.

One thing I'm wondering: What do you mean by "make the frame buffers more 'pleasan't"?

Actually, those shaders are read from external files....:D Thus, coders can make thier own shaders, and they don't have to be "implemented" per se. All that was added is a mechanism and shader C++ class to read the shader files, and compile them on the GPU. Therefore, shaders can be used in conjunction with hi-res texture projects, like if you want a complete hi-res texture pack, that processes the models, and not just the textures....but I'm glad you like the toon/sketch shaders..

What I was saying about the framebuffers being more pleasant, is that atm, they are slow. I know there are methods for accelerating them (Jabo showed some of them off in his demonstration for MK64's billboard being emulated at full speed), it needs to be a case of them being implemented, since most plugins these days support HWFBE (Jabo's, Orkin's and Gonetz's plugins support it).

Enzo Dragon

February 28th, 2007, 07:58

Just got around to checking out the newest build, and the "set aspect ratio" option appears to do nothing. I also noticed that I did not have the choice to set my render engine.

mudlord

February 28th, 2007, 08:24

Just got around to checking out the newest build, and the "set aspect ratio" option appears to do nothing. I also noticed that I did not have the choice to set my render engine.

Huh? Now this is weird......you not having a choice to set render engine is even weirder.....I find both issues incredibly perplexing......:unsure:

EDIT: Tested switching render engines, works fine for me. I'm currently in the middle of doing some major testing with texture packs and implemented features, only trouble is finding working links to the nice texture packs in the past.....:(

Rurounin

March 6th, 2007, 23:40

...
1) Is there any real reason for the texture size limit to be increased? (if its technically feasible to do in the first place, without breaking texture loading in the process)?
...

Textures stretched over huge areas like large grasspatches, rocks or other vast areas is very blurry compared to the other textures you've replaced eventhough you scale them up 4x the size, if you could throw it up to say 8x, 16x or more (depending on how stretched it is) i think that'd make a huge difference in keeping the overall sharpness at the same level.

P.S: i didn't read every post i just skimmed through the thread but i don't think i saw anyone replying to this.

mudlord

March 7th, 2007, 01:27

Textures stretched over huge areas like large grasspatches, rocks or other vast areas is very blurry compared to the other textures you've replaced eventhough you scale them up 4x the size, if you could throw it up to say 8x, 16x or more (depending on how stretched it is) i think that'd make a huge difference in keeping the overall sharpness at the same level.

Oh alright, but then, what about VRAM usage? Adding this to around 16x or 32x could really hurt video RAM usage, unless you have a 256MB card or higher...Sure, they'll look nice, but then users might complain about added requirements.

Maybe this can be for a per-case basis, like the re-texturer can note that when it uses 8x or higher textures, and let end-users know of the possible consequences.

Rurounin

March 7th, 2007, 01:47

Yeah i guess if you make an already big texture 16x the size it might be a problem but if you ask me there isn't really any reason to cap it, the more freedom the better, it's up to the texturer to make it work properly.
For example you could offer an extra zip to replace the "super" high res texture with a lower res one for the people with lower VRAM.

Cyberman

March 7th, 2007, 03:23

Apart from load times getting rediculously long? :D

That will horribly affect performance is what I would like to point out.

mudlord I suggest rescaling the textures based on available VRAM. IE say someone tries to load a 16x 64x64 texture which comes out to 4 megabytes of VRAM by the way. It first checks if there is enough available VRAM then loads it. This is a HUGE texture by the way. 1024x1024. If it is used a LOT (IE big performance penalty) the plugin could REDUCE it (inspite of it's original massive size) until performance isn't so bad (this requires some regular checking of the impact of textures on performance). I would suggest loading the original textures then run one frame with the originals, then load the hirez one and check the difference in frame rendering time. If it's under the 'choosen' frame rate everything is fine. If a huge difference start scaling the hirez texture down tell it has a sane rendering rate. If it ends up down to the original texture size then use the original texture.

I suggest also having in the advanced options a MAX texture scale setting.
IE 2x 4x 8x 16x 32x 64x. You can grey out really big ones if there isn't enough VRAM (IE check VRAM).

Cyb

mudlord

March 7th, 2007, 04:51

Apart from load times getting rediculously long?

But as we know, people want better graphics :evil: ...we better give what they want. :matrix:

That will horribly affect performance is what I would like to point out.

Yep, Rice did a discussion a while back into the effects of high scaling levels on RAM usage (I still have a copy of the forum's threads)...and the consensus from there was 4x scaling levels were the most reasonable back then.

mudlord I suggest rescaling the textures based on available VRAM. IE say someone tries to load a 16x 64x64 texture which comes out to 4 megabytes of VRAM by the way. It first checks if there is enough available VRAM then loads it. This is a HUGE texture by the way. 1024x1024. If it is used a LOT (IE big performance penalty) the plugin could REDUCE it (inspite of it's original massive size) until performance isn't so bad (this requires some regular checking of the impact of textures on performance). I would suggest loading the original textures then run one frame with the originals, then load the hirez one and check the difference in frame rendering time. If it's under the 'choosen' frame rate everything is fine. If a huge difference start scaling the hirez texture down tell it has a sane rendering rate. If it ends up down to the original texture size then use the original texture.

I suggest also having in the advanced options a MAX texture scale setting.
IE 2x 4x 8x 16x 32x 64x. You can grey out really big ones if there isn't enough VRAM (IE check VRAM).

Hm, so as part of the checks, we check the amount of memory. AFAIK, there is no simple way to return a value of VRAM in either DX or OGL APIs (Glide seems to have a function for this though...). And according to video RAM values, we load the textures...and do checks so that the card renders them at a decent FPS..that is chosen by the end-user or retexturer.

For those options, they can go into the new hires texture option box I'm pondering. Sorry bout the lack of binary releases atm (University is one of my main priorities atm) though...I must seriously get my ass more in gear :p....and nuckle down on this ^^...

Cyberman

March 7th, 2007, 06:32

Well mudlord releasing something that isn't well thought out will just waste your time, so think things over first.

The only way I know of guessing memory available is knowing the cards VRAM memory and estimating from the various things you have done with (IE current screen resolution number of buffers you are using, the textures and there sizes you are using etc.) This can be done but requires a little work on texture management. However it is true over a 4x texture size, things aren't too good.

It might be interesting to use non power of two textures. This might be possible by splitting the single texture into some integer multiple of textures (IE 3x of a 64x64 texture becomes 4 128x64 and 1 64x64 texture). Just one of Cyb's random crazy thoughts ;)

Also do your studies, this is ONLY a hobby no matter how fun.

Cyb

mudlord

March 7th, 2007, 07:49

Well mudlord releasing something that isn't well thought out will just waste your time, so think things over first.

Very true...:). Thanks for the advice :).

The only way I know of guessing memory available is knowing the cards VRAM memory and estimating from the various things you have done with (IE current screen resolution number of buffers you are using, the textures and there sizes you are using etc.) This can be done but requires a little work on texture management. However it is true over a 4x texture size, things aren't too good.

k, In DX9, it is possible to return maximum VRAM amount via IDirect3DDevice9::GetAvailableTextureMem (there might be a equivalent function in DX8), and in OGL it is possible to use glAreTexturesResident() in a way to return amount of VRAM, so my understanding was incorrect. But your correct, its quite hard to work out running VRAM usage.

It might be interesting to use non power of two textures. This might be possible by splitting the single texture into some integer multiple of textures (IE 3x of a 64x64 texture becomes 4 128x64 and 1 64x64 texture). Just one of Cyb's random crazy thoughts

Also do your studies, this is ONLY a hobby no matter how fun.

Hmm, then cards with NPOT support will be a requirement. Or maybe a optional feature?

Rurounin

March 7th, 2007, 13:26

Cyberman

March 7th, 2007, 16:34

Well, i'm not saying you should make every texture huge (say 1024x1024), just one or two where needed, shouldn't be that bad right?
Besides, those really really small textures like say 16x16, with 4x, 64x64 is many times not enough, i don't remember what game i was messing around with i realized that but i found it very annoying.
This first depends on texture management of the game and the card. I can't really see anything useful beyond 4x4 even then the poly count on the models is so low no amount of texturing will improve things much more ;)
More seriously, judicious use of large textures is fine, the limit is not 1024x1024. I think you should take a dose of reality here. That is a MONSTEROUS texture. Most shadow buffers are 1024x1024 MAX. On NWN2 they use a 2048x2048 (simple math makes this 16M) but they turn that off if you have a 128M card. You shouldn't need anything beyond 512x512 on a retextured tile. Even on a grassy plain that looked pixelized at 64x64 you still are running at 8x the original texture and likely pushing the pixel to pixel ratio from texture to display. (IE you might have to zoom up on it to take advantage of the higher resolution).

mudlord It's possible to use your own bilinear filter to stretch the texture to an odd size (or LOAD the texture as a odd size). The biggest issue you will have is spanning accross the multiple textures you are using. It's a LOT of work. However it wold allow 3x 5x 6x and 7x textures. It's something to toy with latter, because implementation now likely would break things. (maybe a branch to play with on it).

squall_leonhart

March 7th, 2007, 23:47

This first depends on texture management of the game and the card. I can't really see anything useful beyond 4x4 even then the poly count on the models is so low no amount of texturing will improve things much more ;)
More seriously, judicious use of large textures is fine, the limit is not 1024x1024. I think you should take a dose of reality here. That is a MONSTEROUS texture. Most shadow buffers are 1024x1024 MAX. On NWN2 they use a 2048x2048 (simple math makes this 16M) but they turn that off if you have a 128M card. You shouldn't need anything beyond 512x512 on a retextured tile. Even on a grassy plain that looked pixelized at 64x64 you still are running at 8x the original texture and likely pushing the pixel to pixel ratio from texture to display. (IE you might have to zoom up on it to take advantage of the higher resolution).

mudlord It's possible to use your own bilinear filter to stretch the texture to an odd size (or LOAD the texture as a odd size). The biggest issue you will have is spanning accross the multiple textures you are using. It's a LOT of work. However it wold allow 3x 5x 6x and 7x textures. It's something to toy with latter, because implementation now likely would break things. (maybe a branch to play with on it).

actually, its not turned off, depending on the framebuffer, the game has a list of cards, that it enabled/disables options for.

the geforce FX and radeon 9500+ both are capable of rendering up to 4096x4096 texture sizes

most shadows these days. are not stencil, so they do not have texture limits, they are rendered via the shader pipeline and applied directly onto textures already in the core.

...and instance of example, is the fact that 4x4 Supersampling can only work at 1024x768 and lower, as it renders the texture at a higher resolution (4096x3072) and scales it back (which is why 4x4 is such a performance killer)

this is why i believe Rice's plugins can only scale the texture up to 4x

Rurounin

March 8th, 2007, 02:08

Cyberman

March 8th, 2007, 04:04

Why deny the people wich has the VRAM capabilities to use it because people with less VRAM can't handle it?
I honestly don't get it.
Sure it might be a very few huge textures but if you have say 512 MB VRAM it sould take quite a few of those huge ones to get it to whine, sure not too many have that much and neither do i but i think it's more or less safe to say that the VRAM standard today is 128 MB wich would probably be able to handle more than 4x where needed in most games.

I take it depends alot on the games too, there's a huge difference in the amount of textues in say Mario Kart 64 compared to Conker BFD so yeah, i've said it before, it's up to the texturers to not overdo it.
I guess that would add extra work as to optimizing it and scaling down and up testures on small and big areas, a small sacrifice for more freedom and better results if you ask me.

That being said i'm no graphics card wizzie, i just know what i missed from the first day i tried it out.

And i'm NOT saying we should make every texture in every pack 2048x2048, i just say i'd like the possibilty if i was one of the few with 512 MB VRAM, i myself would never go above 1024x1024 just to make it more compatible and provide a lower res pack scaling down the biggest textures for those who would be having trouble handling it.

You could perhaps add the ability to choose what vram you have and allow the texturer to set the minimum requirement in an config file or something.

I'm sure this came out messy but i'm tired so i'll just leave it as it is.That suggestion was made in this post (http://www.emutalk.net/showpost.php?p=374858&postcount=137) as for choosing I suppose one could use atomagic methods to determine it and if you can't determine it allow someone to set it. There are ways of doing that. Since most windows machines have direct X on them I suppose using DX to find the VRAM amount is one way (See this POST by mudlord (http://www.emutalk.net/showpost.php?p=374880&postcount=140)). I'm not thrilled by the thought but technically if you have a lot of VRAM to begin with this is a good indicator of memory for textures.

I think you should reconsider your idea that "HEY I have RAM I should have big textures". Unless you plan on doing all those textures yourself. Doing hirez textures is a heck of a lot of work. It's easy to make a hirez texture but it's not easy to make a good one (IE better than the original with a bilinear or bicubic filter on it).
As I mentioned after a certain amount, you won't be able to even enjoy the higher resolution textures. So you can have 256 1 M size textures, will this actually make it look better at 1280x1024 or 1600x1200? Really you are reaching beyond the models too look good. As a marketing expert once said "well you can only improve the looks of a VW so much before it looks absurd".

squall_leonhart
Mmmm read here where Rice discusses in great detail (http://www.emutalk.net/showthread.php?t=26561) about big textures (I suggest you BOTH read it please).

The problem is you are reaching the limits of the game itself not just the textures.

Cyb

Rurounin

March 8th, 2007, 05:10

Cyberman

March 8th, 2007, 06:31

Let's get this straight, i'm taking about the really stretched out textures when i talk 8x+, those who looks blurry no matter how much you work with it (a situation mentioned in that thread), not the ones already looking good at 4x the size, so you won't be needing to zoom out alot to be able to enjoy it as it will have the same sharpness as the surroinding textures wich are at 4x, and as i've stated before that's just very few textures if any for each game but it will make a huge difference.
And yes, i'm pretty confident in my PS skills to be able to make really high res textures, the problem would be making a huge amount of them, especially without a proper digital camera, i'd have to rely on free textures on internet, but that's not what i'm talking about either, just a few super high res a game and the rest just normal high res or maybe even standard res, kinda like this guy (http://www.emutalk.net/showpost.php?p=263054&postcount=11) demonstrates.

Also, what i meant with choosing VRAM was to pick whatever ram you have from a list with less than 32 VRAM to 1GB VRAM or more, compare your choice with the config file provided in the texture pack and then have it warn if it's too low or whatever.
But yeah, nothing as fancy as your suggestion no :P
Hehehe at least you read it! I thought I was just talking to walls!

I'm uncertain what "PS skills" are but I'm sure you can make a texture :D

As I suggested to mudlord keeping tabs on textures in RAM and roughly basing what to do with a hirez texture should be adequate to allow big textures. If the plugin doesn't think it has enough memory for an HR texture downsampling it works fine. From how you were going on it sounded like you wanted all huge textures (which as you agree is absurd). As long as the plugin can get a clue about the VRAM size on the card then it has a clue how much memory it can use for textures. This is what GPU plugins for the playstation do (although none have hirez texture abilities). This requires little if any configuration (apart from maybe having to tell the plugin how much VRAM the card has) either

Cyb.

Doomulation

March 8th, 2007, 09:35

The way I see it is this... why put a limit on what the creators can do? If they want to do useless 4096x4096 textures, then why not let them? Who are we to say it's right or wrong?
If the card can't handle it, then you already mentioned downscaling them might help.
Not saying it's necessary or that they should be, but what if an author, for whatever reason, wants them? as long as it doesn't put sticks in the wheel, why not allow it?

Sirmatto

March 8th, 2007, 16:06

I don't know the possibility of this, but I randomly thought of it the other day. With Jabo's new plugin coming out, supporting a new way of using hi-res textures, there are a lot of texture-makers holding out until the new plugin is released, which makes me think that it is actually a better way of handling textures. This sort of brings me to my point of: why don't you (Mudlord), maybe try to contact Jabo, and see if he's willing to work with you and unify, at least, the code base for textures. This way, there won't be two radically different sets of textures for the same game floating around, and it makes it so that when someone retextures a game, they can be confident that everyone can use them, no matter their plugin, emulator or even operating system choice.

This is somewhat like zilmar's (if I remember correctly) plugin specs a long time ago, which made plugins interchangeable, rather than having a bunch of incompatible plugins floating around.

Cyberman

March 9th, 2007, 01:13

That sounds like a good plan. I think the use of a key file (what textures are where they are located in the pack etc) and unified ID for a unique texture should do it. The key files could reside in a directory called hireztextures and the location of the data files would be relative to that path location (IE the correct ROM name) and the path's specified in the key file. The key file could be loaded up when the ROM is started and the GPU is initialized. At that point finding the HR textures is up to the GPU itself. Perhaps a 'Format' attribute as well to specify what the file type is might help as well.
How the key file is generated is a completely different matter. It just needs to do something like

<texturepack>
<name>Djippi's Toilet Paper Link</name>
<author>Djippi</author>
<url></url>
<texture>
<name>Young Links Face</name>
<ID>AC432567EE45DC12A0</ID>
<Path>/Link/Young/Face.png</Path>
<Type>PNG</Type>
</texture>
...
</texturepack>And the header needs to conform to XML standard. Paths will be an issue however since there is an incompatibility of Asian symbols and european/US symbols (it's not a big deal between europe and the US). So some sort of specific character encoding should be specified to keep the TP's universal.
Anyhow at startup I guess the plugin only needs to read the key file that represents the name of the game right? (IE "DUKE NUKEM ZERO HOUR.key"). This is a simple data base and it might work well for people trying to orginize there Texture Packs with a tool.

This does not include the fact some image textures are split between multiple textures. Adding multiple ID's too a texture could be an option by using something like <subtexture></subtexture> to wrap all the elements of the whole image into an array.

The two things that would need standardized then is texture Identification method and key file format/location.

Cyb

Doomulation

March 9th, 2007, 20:15

Unicode? It was built to work with all languages, after all.
It's quite possible to save files in Unicode format (Notepad in XP allows it, for example).

Cyberman

March 9th, 2007, 21:34

Unicode? It was built to work with all languages, after all.
It's quite possible to save files in Unicode format (Notepad in XP allows it, for example).Errr Ummmm... Ok.. I think you kind of missed something. :D
XML header selects the document encoding format. All XML documents are based on a unicode standard. Unicode covers a large range of encoding formats. UTF-8 with western encoding is just one example. What was concerning me is someone using UTF-8 with asian symbols (legal to do with the mod symbols), and someone trying to extract a pack with said path encodings. This would be a disaster if for example someone tried that in the US because in the majority of cases said paths wouldn't be legal. I had this problem when trying to install a program localized for Japan once. It's not something easy to fix. I think specifying the encoding very specifically is necessary to prevent incompatibilities. This includes paths.
I don't want to get to the point of having to specify a TP format for distribution really. I suppose though it might become necessary. The Key File specifies where to find things from the HR directory and the Game ID. There is also the problem of ROMS being mangled (there names CRC's because of a bad dump etc). Even if you use a ROM CRC, this method of identification can vary. That is another issue as well. I don't know how to fix that kind of problem to be honest.
The only thing I can think of is having a way to see if the TP will work with a specific ROM ID. It might require creating a list of game keys it works with. IE Zelda 1.0 1.1 1.2 with the key information on them. Making it more specific is less flexible but things can degenerate quickly.

The key file's purpose is not obvious, but it is something to be generated by the plugin FOR a tool. So for example the tool loads up the key file and finds the paths specified (for the original textures) it then allows one to look for specific textures and organize things. The key file then can be moved to the HR directory after certain images are replaced the old paths can be ignored (because the key file is processed when the game is started not while the game is running and validating the existance of the texture path is part of that).

I've been working on making a tool to make texture matching with the games easier. However without a KEY file from the plugin this is quite difficult to do without it. The Key file can or should contain more information to help organize the data I guess is what I'm contemplating. It's not just a handy reference for the plugin to load textures.

Cyb

mudlord

March 10th, 2007, 00:56

I don't want to get to the point of having to specify a TP format for distribution really. I suppose though it might become necessary. The Key File specifies where to find things from the HR directory and the Game ID. There is also the problem of ROMS being mangled (there names CRC's because of a bad dump etc). Even if you use a ROM CRC, this method of identification can vary. That is another issue as well. I don't know how to fix that kind of problem to be honest.

The only thing I can think of is having a way to see if the TP will work with a specific ROM ID. It might require creating a list of game keys it works with. IE Zelda 1.0 1.1 1.2 with the key information on them. Making it more specific is less flexible but things can degenerate quickly.

From the ROM RDB perhaps?

<supported>
<rdb>C3B6DE9D-65D2DE76-C:50</rdb>
<rdb>2577C7D4-D18FAAAE-C:50</rdb>
<rdb>6BFF4758-E5FF5D5E-C:4A</rdb>
<rdb>C9C3A987-5810344C-C:4A</rdb>
<rdb>3E5055B6-2E92DA52-C:45</rdb>
</supported>

EDIT: I also made a small list of what has to be change for compatibility with Jabo's texture packs:

* Textures have to go in textures-load in emu directory
* Dumped textures have to go in textures-dump folder in emu directory
* Texture CRCs have to be identical
* Identifier methods have to be honoured
* Tex format guidelines have to be honoured
(such as all JPG, all PNG, NO BMP)
* The video plugin has to hook a menu in emu ROM browser for texture ZIP pack selection
* Video plugin MUST read from ZIPs if packs are bundled in ZIPs
* The plugin has to load "pack.xml" if bundled in ZIP
(otherwise, can load from textures-load arbitrary, but cannot be turned off)

Enzo Dragon

March 27th, 2007, 12:15

mudlord

March 28th, 2007, 03:36

I'm still alive and still check this thread often, first off.

Second, I fixed the issue I was having with selecting my render engine and all of that, but I still haven't been able to get the beta aspect ratio bit working. However, this might have to do with the render engine; I read somewhere on here that PJ64 wasn't the best with openGL?

Either way, I'm going to try a different emu later to see if that fixes my problems - otherwise, it may be that I screwed up my OGL libraries when I tried to "fix" them.

Thanks for dropping on this, I'm still working on this, ya know, its just for me college is really eating up my time atm (I got several assesments, including a Python programming proj).

I'm glad you fixed that renderer prob, but yeah, the aspect ratio control is as you say, beta...heheheh, I'm gonna see about doing a proper fix for it that still does it right..

And, I somewhat think PJ64 has a issue with OGL too..I dunno, its funny, I don't know yet if its to do with threading and such, or whether just Project64 1.6/1.7 plays not nice like other emus, with regards to OpenGL cleaning up on exit...

mudlord

April 3rd, 2007, 03:23

Also, I had a look into the whole hi-res code. It seems Rice just set a 4x limit on the scaling factor of textures. I guess we could tweak that, to gain support for higher textures (we could through in compression on BMP CIs, since PNG supports colour indexing). But then we run into the issues as describe earlier. First things first though, getting BMGLib to work right on all games, and not just two...Which is plain weird, as I did nothing to mess with BMGLib when compiling a dynamic library like the official release..and upon testing that, the same thing happens with games other than SM64...:unsure:

EDIT: Okay, compatibility with Jabo's texture packs is not going to happen. There is really too much different variables (different things) if the packs are going to be working (and working right) between each plugin.

Cyberman

April 6th, 2007, 20:53

Hmmm the TP format differences are that large?

It would be nice if one could converse with Jabo about it, as this would be a serious problem for repairing Rice's plugin.

Not a good thing really. Did Jabo give you his specs for TP's? If so where are the specs? The solution may be adding a 'import' tool to convert them. As you know no one will be developing new TP's for Rice's plugin due to Jabo's new plugin support for HR textures. This essentially means 0 support for the plugin by people making TP's as a consequence.

In your prior post the RDB data looks to be the best idea or method. Some textures might have different MD5 or CRC data. That could make things highly bothersome in make a single pack for all versions. There is the possibility of having multiple tables to hash the CRC's. It's highly unlikely 2 32 bit CRC's of seperate images will match. It's a 1 in 4 billion chance I believe. So a list of CRC's (seperate) with a reference to the proper texture file would work. This is becoming more a database application isn't it?

As a side note, is it possible to allow a program to link to the DLL via a socket to read data it's generating etc. ? Sort of like a Data pipe for debugging or in this case texture dumping information. The application might be able to handle creating much of the TP structure information while the game is 'played' through. IE things like load screens etc. Just an idea to have a seperate program from the DLL to handle that stuff. It would be interesting to know what kind of data one could get and how to arrange it etc. Might be useful for planing TP's as the game dumps data.

I digress though.

Cyb

mudlord

April 7th, 2007, 03:10

OK, I'm back..

Well, there are a huge amount of changes between Jabo's and Rice's plugin. With consultation with Jabo and Smiff on the PJ64 beta forums, its seems that technically it is unable to happen, due to how the two different plugins handle emulation....

The problem is, Jabo's plugin uses only MD5 checksums for texture identification. It uses no other identification methods, but its interesting how only PNG files are used for textures. Secondly, because of this sole use of a MD5 for checking, core differences between how the plugins handle texturing makes support not possible, or being optimistic, extremely difficult, because of how the two different plugins have thier very own methods of doing emulation. Also, Jabo explained how he doesn't want a "standard" of hi-res textures made by his plugin, so to comply with Jabo's ideals, the plugin won't switch h-res texturing methods. Besides, Jabo raised very valid points on how they are recruiting new talent to make new texture packs...:)..so that texture packs can be made natively for it. And like you said, no one would be making texture packs for this when the public release of 1.7 rocks around, mainly due to emulation improvements (which I admit, over the weeks I'm betatesting 1.7, are extremely nice).

In your prior post the RDB data looks to be the best idea or method. Some textures might have different MD5 or CRC data. That could make things highly bothersome in make a single pack for all versions. There is the possibility of having multiple tables to hash the CRC's. It's highly unlikely 2 32 bit CRC's of seperate images will match. It's a 1 in 4 billion chance I believe. So a list of CRC's (seperate) with a reference to the proper texture file would work. This is becoming more a database application isn't it?

Yeah, indeed. Its pretty unlikely for that method not to work :). And yep, its pretty much going that way ^^

As a side note, is it possible to allow a program to link to the DLL via a socket to read data it's generating etc. ? Sort of like a Data pipe for debugging or in this case texture dumping information. The application might be able to handle creating much of the TP structure information while the game is 'played' through. IE things like load screens etc. Just an idea to have a seperate program from the DLL to handle that stuff. It would be interesting to know what kind of data one could get and how to arrange it etc. Might be useful for planing TP's as the game dumps data.

That actually is a quite clever idea . I can see its applications, and heck, whatever helps me debug this is a good idea.

Cyberman

April 7th, 2007, 06:09

OK, I'm back..

Well, there are a huge amount of changes between Jabo's and Rice's plugin. With consultation with Jabo and Smiff on the PJ64 beta forums, its seems that technically it is unable to happen, due to how the two different plugins handle emulation....You mean a large number of differences?
Hmmm that's too bad, however I don't think it is as bad as all that. However the problem might be in where and how the textures are being loaded. That is extremely difficult to fix unfortunately.

The problem is, Jabo's plugin uses only MD5 checksums for texture identification. It uses no other identification methods, but its interesting how only PNG files are used for textures. Secondly, because of this sole use of a MD5 for checking, core differences between how the plugins handle texturing makes support not possible, or being optimistic, extremely difficult, because of how the two different plugins have thier very own methods of doing emulation. Also, Jabo explained how he doesn't want a "standard" of hi-res textures made by his plugin, so to comply with Jabo's ideals, the plugin won't switch h-res texturing methods. Besides, Jabo raised very valid points on how they are recruiting new talent to make new texture packs...:)..so that texture packs can be made natively for it. And like you said, no one would be making texture packs for this when the public release of 1.7 rocks around, mainly due to emulation improvements (which I admit, over the weeks I'm betatesting 1.7, are extremely nice).
Are there patent issues on using MD5? It's actually superior to CRC in terms of acuracy. MD5 is just plane amazingly acurate, it is however extremely intensive on the CPU. If Jabo can provide the format information, I don't think conversion is impossible. Rice's method of storing the data is good, however there has always been something bugging me, portability and how to do it.

There is no easy solution, the portability issue brings up the morass of the library DLL needed for texture loading and dumping as well. Using raws for both is questionable but doable.

Is a binary format TP a good or bad idea is the next question. I don't like having to compile a whole bunch of data (it's slow). However it does keep the data structuring simpler for the plugin. It wouldn't have to look through a pile of files. Hmmmm. More to ponder. Porting the data might be an issue of prior packs, although parsing through a huge list of files might be adequate for a quicky porting util I suppose. Argh this makes my head spin LOL.

So I've heard it adds lots of things. The adjustable aspect ratio etc.

Yeah, indeed. Its pretty unlikely for that method not to work :). And yep, its pretty much going that way ^^
Ehh though it's too bad that Jabo's checks the textures likely in a different point so that makes MD5 data and CRC data compatibility improbable at best.

That actually is a quite clever idea . I can see its applications, and heck, whatever helps me debug this is a good idea.

I was thinking that it would offload creating the XML information reguarding the files and allow in real time a way of seeing what images are being dumped in game. IE a tree of the data and file list to allow you to pause the game and examine the textures dumped. That might help people with making TP's also.

Cyb

Doomulation

April 7th, 2007, 15:01

It's highly unlikely 2 32 bit CRC's of seperate images will match. It's a 1 in 4 billion chance I believe.

Wow, 1 to 10 ^12% chance? Last, I looked, 255 ^ 4 equals roughly 10 ^ 9 (4 228 250 625)! ;)

toe_head2001

April 9th, 2007, 01:43

This is a really cool plugin update, thanks!

mudlord

April 10th, 2007, 03:20

Are there patent issues on using MD5?

That is something I'm not sure about.

MD5 is just plane amazingly acurate, it is however extremely intensive on the CPU.

I agree with ya there, though Jabo's plugin does texture dumping and loading pretty quick...

If Jabo can provide the format information, I don't think conversion is impossible

That's exactly the whole trouble. Jabo's texture packs use only MD5 for texture identification for hi-res info. There is no real format specs. Everything is done by the MD5 checksums, and so there is no data specifying in the filenames whether its a CI texture or not. Thats because the MD5s are all unique, like you elaborated on about MD5's strengths. And so, the checksums are the only identifying things (which I can see why then Jabo made the format simple for his plugins, since there is only one method, MD5, and only one image format, PNG).

There is no easy solution, the portability issue brings up the morass of the library DLL needed for texture loading and dumping as well.

The good news is, I made it no longer a bloated library :). It now only loads the formats we use (BMP/JPG/PNG), and all other format support is removed. Now, its actually quite petite and slim. And the specs for BMGLib talk about cross platform compatibility being quite good.

I was thinking that it would offload creating the XML information reguarding the files and allow in real time a way of seeing what images are being dumped in game. IE a tree of the data and file list to allow you to pause the game and examine the textures dumped. That might help people with making TP's also.

Oh alright :)

Wow, 1 to 10 ^12% chance? Last, I looked, 255 ^ 4 equals roughly 10 ^ 9 (4 228 250 625)!

Holy crap! I guess then there will be zero issues with texture usage then....heheheheheh.

Legend

April 10th, 2007, 08:17

Hey Mudlord, are you planning on helping to get Rice's Video compatable with PJ 1.7 again. I'm not sure what happened with this but as you probably know, fullscreen hasn't worked for awhile and causes a full system lock. I'm just not sure where Zilmer and yourself stand on this issue so that's why I'm inquiring. Thanks as always.

Also, I noticed in Brunswick Pro Bowling, the floors are missing with your "stable" version. With identical settings, tried the original Rice's build and it works perfect.

Cyberman

April 10th, 2007, 16:40

Wow, 1 to 10 ^12% chance? Last, I looked, 255 ^ 4 equals roughly 10 ^ 9 (4 228 250 625)! ;)
1 billion = 9 digits
1 trillion = 12 digits. Please keep your numbers correct.
Also it's not 255^4 it's 256^4 which is the same as 2^32 which is 4294967296.
Just because you know something doesn't mean you shouldn't think about what's being said first .

1 billion is about the limit of CRC32 I'm parinoid enough that I would use it for small spans. 2^25 leaves enough headroom in probabalistic issues of the CRC algorythm. IE ~32meg.

That's exactly the whole trouble. Jabo's texture packs use only MD5 for texture identification for hi-res info. There is no real format specs. Everything is done by the MD5 checksums, and so there is no data specifying in the filenames whether its a CI texture or not. Thats because the MD5s are all unique, like you elaborated on about MD5's strengths. And so, the checksums are the only identifying things (which I can see why then Jabo made the format simple for his plugins, since there is only one method, MD5, and only one image format, PNG).Hmmm if the MD5 is computed off the same textures AND you can generate a set of CRC's on the same data then it's a non issue. As long as the information that you are generating the check information on is the same it will be consistant. If the information changes then things will be different and incompatible.

I suppose the MD5 data can be dumped out with the CRC data? Then one can take the TP's made for Jabo's plugin and compare the data with the XML database information generated by Rice's new and improved plugin. That's the reason I wanted to stream the data out that way. It might make porting JABO's TP's easier. What size MD5 is he using?

Cyb

Doomulation

April 10th, 2007, 22:52

1 billion = 9 digits
1 trillion = 12 digits. Please keep your numbers correct.
1 milliard = 9 digits
1 billion = 12 digits
Apparently the Americans twisted the word "billion" to replace milliard and to bump down the whole scale. In many other languages, milliard comes between million and billion.

Also it's not 255^4 it's 256^4 which is the same as 2^32 which is 4294967296.
My mistake, yes... I'm used to numbers 0 through 255 because that's what you'll get on a computer. But of course that's 256 different possibilities.

1 billion is about the limit of CRC32...
1 milliard :P And about 4 milliard possibilities.

Cyberman

April 11th, 2007, 04:31

You mean this (http://www.uni-bonn.de/%7Emanfear/numbers_names.php)?
If I remember correctly it was not used in US English because it (the use of the milliard system) introduced even more irregularity to the language. IE it created more inconsistancy (which is just what everyone needs inconsistant mathematical terms). I suppose from now on Giga should be used hence forth. At least a googleplex is still a googolplex ;)

Cyb

mudlord

April 11th, 2007, 11:25

Hmmm if the MD5 is computed off the same textures AND you can generate a set of CRC's on the same data then it's a non issue. As long as the information that you are generating the check information on is the same it will be consistant. If the information changes then things will be different and incompatible.

I suppose the MD5 data can be dumped out with the CRC data? Then one can take the TP's made for Jabo's plugin and compare the data with the XML database information generated by Rice's new and improved plugin. That's the reason I wanted to stream the data out that way. It might make porting JABO's TP's easier. What size MD5 is he using?

Yeah, I can agree with you there. As long as we try to output the same MD5's as Jabo's, then this might occur. However, I haven't got a clue on how Jabo performs his texturing, and I'm sure he has his reasons for not disclosing info like that. Which means basically, the hardest part is getting the MD5's the same.

But then we have your idea of the data base for cataloging textures to help simplify the process of porting them. Which means, for those logging functions, I need to check out the real nitty gritty of how best to do it it seems. I would imagine of making changes to the basic texturing core to do this right in both APIs.

As for info on the size, he made a very vague remark of "a simple md5, nothing fancy". Which means, my guess its the default 128-bit hash size. However, I do want to respect his wishes of not having his texture pack format a standard, which means this functionality will be import only, when and if its added. :)

Sirmatto

April 11th, 2007, 15:58

A heads up, on this (http://www.emutalk.net/showthread.php?t=40441) thread Hacktarux was reminded of when he originally promised to release his port of the Rice code ;) So again, he says he'll clean it up and release it, which may or may not help you out, Mudlord. But maybe someone will take it and merge the Linux code into yours.

jackschmidt

April 12th, 2007, 03:19

Are there patent issues on using MD5?

As far as I know, md5 is open. The algorithm is freely available and there are tons of code posted online that do md5. That makes either the patent open or not patentable anymore.

Cyberman

April 13th, 2007, 23:52

Yeah, I can agree with you there. As long as we try to output the same MD5's as Jabo's, then this might occur. However, I haven't got a clue on how Jabo performs his texturing, and I'm sure he has his reasons for not disclosing info like that. Which means basically, the hardest part is getting the MD5's the same.
Rice's plugin does it with the data that's loaded right? (IE when the program attempts to load it from the ROM into the texture RAM).

But then we have your idea of the data base for cataloging textures to help simplify the process of porting them. Which means, for those logging functions, I need to check out the real nitty gritty of how best to do it it seems. I would imagine of making changes to the basic texturing core to do this right in both APIs.Well I was thinking of dumping the CRC/MD5 data and use a seperate program to handle that. IE a simple CRC32 MD5128 filepath for each texture dumped. I'm not sure which format is best for dumping etc. in terms of images.

As for info on the size, he made a very vague remark of "a simple md5, nothing fancy". Which means, my guess its the default 128-bit hash size. However, I do want to respect his wishes of not having his texture pack format a standard, which means this functionality will be import only, when and if its added. :)
Are you against a more databased oriented approach? I've been looking at SQLite (which is a VERY small database engine). It might make packaging the whole texture thing MUCH much simpler (and rather easy to play with).
The images can be stored as BLOBs (Binary Large OBject) and all the information about the textures IE CRC32 MD5 sum etc can be stored with them. Empty BLOB references mean use the old texture for example if there is a Database match. It also means later one can add images as well.
Let me see this leaves it as 2 databases 1 set of BLOB information (CRC MD5 BLOB) and 1 set of texture information (CRC MD5 height width depth and anything else useful such as original file dump path etc.). The idea is that one won't have to think about putting the textures in the right directory and finding the image file that needs replaced would be a snap as well. End result is fewer file fiddling and simplifying the plugin's view of things. Interesting thing about SQLite is it's quite small. You can prune it down to 100K I've header. Package it with both the texture manager and the plugin things could be quite easy. Old TP's can be converted using the texture manager likely.

As for indexed images (IE paletted images) how does Rice's plugin handle those?

Cyb

mudlord

April 14th, 2007, 02:59

A heads up, on this thread Hacktarux was reminded of when he originally promised to release his port of the Rice code So again, he says he'll clean it up and release it, which may or may not help you out, Mudlord. But maybe someone will take it and merge the Linux code into yours.

thats good news! :)

As far as I know, md5 is open. The algorithm is freely available and there are tons of code posted online that do md5. That makes either the patent open or not patentable anymore.

Ok. Great.

Rice's plugin does it with the data that's loaded right? (IE when the program attempts to load it from the ROM into the texture RAM).

for that, it does it when the textures are dumped and loaded. I'm not sure if it processes it on TMEM, yet.

Well I was thinking of dumping the CRC/MD5 data and use a seperate program to handle that. IE a simple CRC32 MD5128 filepath for each texture dumped. I'm not sure which format is best for dumping etc. in terms of images.

Oh alright, thanks for clearing it up. :)

Personally, I'm not against the approach of using a database format for using textures since there obviously seems to be great benefits for the end users. And for the indexed images questions, there seems to be two different criteria when dumping: the plain CI images (in BMP), and the CI by RGBA (PNG). What seems redundant to me is though why shouldnt both criteria be both PNG? As for the specifics on palleted image use, i will have to get back to you on that.

Legend

April 14th, 2007, 03:42

The crashing problems started with build 47, and its threading changes.

So, as consolation, versions before that particular build will work.
for that bowling bug, try this. it fixes dkr and zelda, so it could potentially fix your bugs.

The BMG file is not valid on either PJ 1.7 and 1.6. I have to use the old BMG and then it doesn't see you version. Please check it out. :(

Also, are you saying that because of the new threading changes it would involve alot of change to RiceVideo to get to work.

EDIT:Also, the "Development" one does not boot roms, it is selectable in the vid plugin section, but does not work.

jackschmidt

April 14th, 2007, 03:43

And for the indexed images questions, there seems to be two different criteria when dumping: the plain CI images (in BMP), and the CI by RGBA (PNG). What seems redundant to me is though why shouldnt both criteria be both PNG?
I'd like to participate but I'm not familiar with Rice's code and I am no N64 emulator developer so pardon me if it's off base and I sound like a crackpot. Wouldn't bmp produce totally uncompressed images that would at least yield images without sacrificing any detail? I do think there are subtle differences between PNG and BMP though I cannot remember it right now.

I don't know if this helps but this link gives a comparison between some of the different image formats.
http://www.iceteks.com/articles.php/imageformats/1

mudlord

April 14th, 2007, 13:42

The BMG file is not valid on either PJ 1.7 and 1.6. I have to use the old BMG and then it doesn't see you version. Please check it out.

That is plain weird. The new BMGLib is not compatible with old rice video versions, however that doesnt excuse it not working on your system. It all works for me...have you got the MSVC2005 runtimes installed? I'' probably compile a different version. And I did test that bowling game, and it works perfect now...like the old rice video builds...

Also, are you saying that because of the new threading changes it would involve alot of change to RiceVideo to get to work.

Probably, it might just be a single fix, OR it might require completely overhauling how the plugin functions just for PJ64 1.7....

EDIT:Also, the "Development" one does not boot roms, it is selectable in the vid plugin section, but does not work.
Odd....works for me fine when using shaders and otherwise...Might as well compile another version for that too....

mudlord

April 14th, 2007, 13:47

Wouldn't bmp produce totally uncompressed images that would at least yield images without sacrificing any detail? I do think there are subtle differences between PNG and BMP though I cannot remember it right now.

The thing is, PNG is 100% lossless. So, PNG will yeild the exact same quality as BMP, and we also enjoy compression from it, which will make texture packs smaller :). And then since PNG supports colour indexing, that could mean BMP will be made redundant. :)

jackschmidt

April 15th, 2007, 06:24

The thing is, PNG is 100% lossless. So, PNG will yeild the exact same quality as BMP, and we also enjoy compression from it, which will make texture packs smaller :). And then since PNG supports colour indexing, that could mean BMP will be made redundant. :)

You bring up a good point. I thought PNG was lossy. My bad. It does seem BMP is a bit redundant. Maybe PNG was an after-thought implementation?

Legend

April 16th, 2007, 08:04

mudlord

April 16th, 2007, 08:46

The "Stable" release has no BMGlib so the plugin is not selectable. The "Development" plugin with its DX9 file is also not selectable in the plugins, whereas before it was-so it worst now. Also, your info about "update 8" is the same as the info for "update 7".

I believe you are mistaken..

Those DLLs no longer require BMGLib.DLL. To put it in plain English, BMGLib is inside the plugins. Thus, the plugins still use BMGLib, however, the end user no longer needs to manually put the DLL in the emulator folder, since ALL BMGLib code is now inside the plugin, and not as a external component anymore.

Also, for the DX9 plugin, you must install a very recent version of DirectX or put that d3dx9_30.dll in the emulator root directory, like Direct64.

As for versioning, it would be helpful to note that those are two completely different code branches. One uses a pure DX9 base, while the other (the stable branch and the one in the main "trunk"), uses the same basic codebase as Rice's last public release.

Cyberman

April 16th, 2007, 14:41

Personally, I'm not against the approach of using a database format for using textures since there obviously seems to be great benefits for the end users. And for the indexed images questions, there seems to be two different criteria when dumping: the plain CI images (in BMP), and the CI by RGBA (PNG). What seems redundant to me is though why shouldnt both criteria be both PNG? As for the specifics on palleted image use, i will have to get back to you on that.
First the primary motivation using the database approach is too make manipulation of the data easier, which makes the end users happier. Dealing with 5000 textures is a pain. If they are all neatly packed as BLOB information and retrieved for the database program from a big database I think things will be easier all around. Less disk space, less disk fragmentation, fewer files, less mess all these benifit the programmer and the user. Downside is that SQLite is a 2.5m code chunk (yes 2.5 meg .C file), but it's not likely you need to do much with that.

At the high level end of things the database files can be created for each ROM the plugin sees and the images can be dumped. I know duke nukem zero hour had 6000 images and I only made it half way through the ROM. I suspect much of this can be eliminated by tacking an incrementing index to each image record. Merging the format to say dumping only PNG and allowing JPG and PNG for HR textures is likely a good idea. For HR textures the program just needs to look for a database in the highrez texture directory with the correct name. If an image isn't in that database then it's loaded normally. Obviously when a game is started this database will need to be spun through to find all 'hit' values for the CRC or MD5.

Anyhow I am babbling again.

Cyb

Legend

April 16th, 2007, 23:10

mudlord

April 19th, 2007, 05:38

OK, I now have Microsoft Visual C++ 2005 redistributable installed. I have all the right files in the right place and are using the DirectX9.0c. I still cannot even see the dlls in the plugin selection. Niether the stable or the dev. in any emu, even after a restart of the computer. What am I missing here? Does no one else have this issue? Do I need to sign up and get hold of Visual C++2005 SP1 or something?

EDIT: I can select the DEBUG version just fine, though when trying to load a rom I recieve an error message:"Cannot initialize DX8, please check Direct settings".

EDIT2 - I just also installed .NET framework 3.0 and the very latest DirectX runtime components and I still cannot view either the "Stable" or the "Development" files in the plugin chooser. I also still get the same error when trying to boot the "debug".

This is by far the weirdest thing I ever seen...:(

I'm really sorry you are having issues with it atm, but from my own testing, the plugin loads fine (and works great) for me...I'm starting to get quite stumped where it fails for you, since you have all the dependancies for it currently. And no, you don't have to get a hold of the Visual Studio Service Pack 1, thats only useful with you have the compilers. (so it in no way effects the end-users)

In the source, I found that compiler optimizations caused the most issues. They are the ones that caused the issues with BMGLib (to do with hi-res textures). It strikes me as very strange that the C++ compiler settings are causing the plugin to not work for you..since processor specific optimizations were turned off, while still allowing for SSE. Maybe via IM I can try to fix things for you.

Again, I deeply apologise for those issues.

First the primary motivation using the database approach is too make manipulation of the data easier, which makes the end users happier. Dealing with 5000 textures is a pain. If they are all neatly packed as BLOB information and retrieved for the database program from a big database I think things will be easier all around. Less disk space, less disk fragmentation, fewer files, less mess all these benifit the programmer and the user. Downside is that SQLite is a 2.5m code chunk (yes 2.5 meg .C file), but it's not likely you need to do much with that.

Hmm, that will help with package distribution :). But the plugin size will blow out...but meh, I suppose we can trim that code chunk, and up the compression on the DLLs...(but that translate to higher RAM usage, due to DLL compression loader overhead...). And I managed to get my hands on the SQLite library, btw.

At the high level end of things the database files can be created for each ROM the plugin sees and the images can be dumped. I know duke nukem zero hour had 6000 images and I only made it half way through the ROM. I suspect much of this can be eliminated by tacking an incrementing index to each image record. Merging the format to say dumping only PNG and allowing JPG and PNG for HR textures is likely a good idea. For HR textures the program just needs to look for a database in the highrez texture directory with the correct name. If an image isn't in that database then it's loaded normally. Obviously when a game is started this database will need to be spun through to find all 'hit' values for the CRC or MD5.

Hmm, those are nice ideas :). Having a log of what textures are actually used definately trims down the file some somewhat. I guess it wouldnt make be much effort to make all texture dumps PNG...well, I see a logical flaw in what you said. You said to "dumping only PNG and allowing JPG and PNG for HR textures"...but that means we need JPG first too :evil: ..but blah, thats not important (which means now, we can ditch BMP). What we need is a rethinking of how to do HR, since its embedding in the graphics base, too, to allow for SQLite implementation.

Doomulation

April 19th, 2007, 14:26

And no, you don't have to get a hold of the Visual Studio Service Pack 1, thats only useful with you have the compilers. (so it in no way effects the end-users)

Well, from my knowledge and experience, SP1 seems to want a different runtime module to work properly. The old runtime module, when installed, didn't want to work with SP1 compiled apps.
If it helps anything, I have a link to the up-to-date module: http://www.eluni.net/downloads/vcredist_x86/vcredist_x86.exe

Legend

April 19th, 2007, 23:18

YOU'RE THE MAN DOOM!!! Finally it works!! Mudlord you need to post this link in the download thread. I guess the version I downloaded from Microsoft a couple days WAS an older set. When I installed this, it said that it was "removing older files and updating to the newest". So there we go.

The Stable works fine (including Brunswick Bowling). The Development one though still gives me the DirectX9 error upon trying to boot a rom.

Doomulation

April 20th, 2007, 00:33

Glad I could help.

Cyberman

April 20th, 2007, 05:21

Hmm, that will help with package distribution :). But the plugin size will blow out...but meh, I suppose we can trim that code chunk, and up the compression on the DLLs...(but that translate to higher RAM usage, due to DLL compression loader overhead...). And I managed to get my hands on the SQLite library, btw. SQLite isn't a DLL and it only adds 250K tops with careful removal of features you don't need this can shrink a fair amount. Also you can make multiple tables into a single database. SQLite is not good for HUGE databases, but really this is a small database with at most 10000 elements. We need at least 2 tables for HR TP's maybe 3. A table of valid ROM ID's, a table of HR BLOB stored textures there CRC32 and MD5 data. The advantage of SQLite not being a DLL is that it doesn't ADD as much as a DLL to the code size. At runtime that's a different matter. :D

The end result though is just 2 databases 1 for the TP and the other is the DUMP database. The TP database will be the only thing end users would need. I don't see the point of compressing the database information though. Namely because the largest volume data (Images) are already compressed.

Hmm, those are nice ideas :). Having a log of what textures are actually used definately trims down the file some somewhat. I guess it wouldnt make be much effort to make all texture dumps PNG...well, I see a logical flaw in what you said. You said to "dumping only PNG and allowing JPG and PNG for HR textures"...but that means we need JPG first too :evil: ..but blah, thats not important (which means now, we can ditch BMP). What we need is a rethinking of how to do HR, since its embedding in the graphics base, too, to allow for SQLite implementation.BMP is a waste of space, implementation wise and storage wise. There is no point unless people are adament on using MS Paint or something for texture enlargement.
Performing a startup listing of tags that will hit (as HR textures to load from the DB) shouldn't be hard. Then the database can be querried for the proper BLOB data on a hit. Since it only does this with things IN the database everything else should be the same. I think the changes wouldn't be over all that major.

On the dumping side of things, I can see some issues. If you check DUMP, then things get more interesting. I believe Rice has a texture cache in memory right? (not in the display card but in the computers memory). I've noticed if I've run a ROM without Texture dumping checked and then checked it, the plugin will begin spining through a huge list of file names. I believe a small adjustment to the current system (such as uniform dump of file type). A seperate tool can be made to extract / view PNG files from the dump database. This same tool can be used for creating the hirez TP's. I suppose as part of the 'processing' chain it can call external programs to edit the textures for the texture pack and add them to it. The dump format likely should have one table for ROM ID's, one table with CRC, MD5, dumped image, and one table with CRC, MD5 and image information (Height Width pixel depth). Perhaps with some tweaking on the tool merging and spliting textures will be possible (IE load screens made up of numerous 320x6 16 bit textures can be edited and enhanced as a single image then automatically split into seperate files for the TP).

Cyb

mudlord

April 20th, 2007, 09:50

Well, from my knowledge and experience, SP1 seems to want a different runtime module to work properly. The old runtime module, when installed, didn't want to work with SP1 compiled apps.
Oh alright, I wasnt aware of the compiler changes, if any, as I didnt bother to check the patch's changelog :sombrero: ..Least we now know it does...Thanks for the mirror of the runtimes BTW.

The Stable works fine (including Brunswick Bowling). The Development one though still gives me the DirectX9 error upon trying to boot a rom.
Thats excellent! ^^ I'm happy now that Brunswick Bowling is now working perfect for you. As I noticed, the fix from that, also fixed loads other games, and it should now be on par with the official release, I think :).

Do you have FSAA enabled in the DX9 plugin? If so, turn it off. The development build uses a preliminary (and quite incomplete & buggy) implementation of hardware render to texture via DirectX render targets (hardware render to texture is one of the techniques in hardware framebuffer emulation), and this method is not compatible with FSAA, due to API limitations. So, if you have FSAA on, turn it off basically.

SQLite isn't a DLL and it only adds 250K tops with careful removal of features you don't need this can shrink a fair amount. Also you can make multiple tables into a single database. SQLite is not good for HUGE databases, but really this is a small database with at most 10000 elements. We need at least 2 tables for HR TP's maybe 3. A table of valid ROM ID's, a table of HR BLOB stored textures there CRC32 and MD5 data. The advantage of SQLite not being a DLL is that it doesn't ADD as much as a DLL to the code size. At runtime that's a different matter.

I meant the main DLLs (the actual plugins). :) Thats where I was refering about the compression on the DLLs, I didnt mean the SQLite code. Currently, the plugins are compressed with UPack, atm..

BMP is a waste of space, implementation wise and storage wise. There is no point unless people are adament on using MS Paint or something for texture enlargement.

Indeed, and besides, PNG supports CI indexing, so the issues of "*ci.bmp" are mute. Also, I noticed a consensus that CI BMPs dont really get dumped or need to be useable in TPs, but I guess a bit more input from the retexturers would be nice to see. In the meantime for the current pack format, maybe the texturers could just port thier CI bmps to PNG (preserving filename, except for extension and internal image format), and I could just change the BMP handling to just load from PNG files.

Cyberman

April 20th, 2007, 12:36

I meant the main DLLs (the actual plugins). :) Thats where I was refering about the compression on the DLLs, I didnt mean the SQLite code. Currently, the plugins are compressed with UPack, atm..
Duh. :D heheheh I'm thinking compressing the DLL is not going to change things a whole lot to be honest. I would rather it use more disk space than use more RAM when loaded. What you gain in smaller DLL space you loose in RAM. Which is more precious RAM or disk space? :)

Indeed, and besides, PNG supports CI indexing, so the issues of "*ci.bmp" are mute. Also, I noticed a consensus that CI BMPs dont really get dumped or need to be useable in TPs, but I guess a bit more input from the retexturers would be nice to see. In the meantime for the current pack format, maybe the texturers could just port thier CI bmps to PNG (preserving filename, except for extension and internal image format), and I could just change the BMP handling to just load from PNG files.BMP == anachronism :D
As for converting, I was thinking it might be feasible to make a tool to efficiently convert dumped texture sets and TPs, or at least more efficiently than what currently is available. I suppose one can just as effectively scan for all those BMP's and convert them into PNG's. Since the CRC information is part of the file name, that helps. However I'm not sure what the deal is with the CI CRC's. Didn't Rice generate a second CRC for the palette used on those textures?
The one tool, too bind those TP's together, and RULE THEM All muhahaha ;)

On converted TP's the only issue I can think of is lack of MD5 values (it's not a crying shame really since that is for being able to convert Jabo's TPs to the RTPF {Rice's Texture Pack Format}).

Cyb

Doomulation

April 20th, 2007, 13:09

Duh. :D heheheh I'm thinking compressing the DLL is not going to change things a whole lot to be honest. I would rather it use more disk space than use more RAM when loaded. What you gain in smaller DLL space you loose in RAM. Which is more precious RAM or disk space? :)

Well, correct me if I'm wrong, but as all EXEs, all DLLs get loaded into memory. The bigger the size, the more the memory. I'm not sure how these compression programs work, though... Do they add overhead code to uncompress the module in memory?

Sirmatto

April 20th, 2007, 16:02

Well, correct me if I'm wrong, but as all EXEs, all DLLs get loaded into memory. The bigger the size, the more the memory. I'm not sure how these compression programs work, though... Do they add overhead code to uncompress the module in memory?

From the Wikipedia page for UPX:

UPX uses a lossless compression algorithm called UCL, which is a free implementation of the proprietary NRV, Not Really Vanished, algorithm.

UCL has been designed to be simple enough that a decompressor can be implemented in just a few hundred bytes of code. UCL requires no additional memory to be allocated for decompression, a considerable advantage that means that a UPX packed executable requires no additional memory.

Doomulation

April 20th, 2007, 17:20

UPX uses a lossless compression algorithm called UCL, which is a free implementation of the proprietary NRV, Not Really Vanished, algorithm.

UCL has been designed to be simple enough that a decompressor can be implemented in just a few hundred bytes of code. UCL requires no additional memory to be allocated for decompression, a considerable advantage that means that a UPX packed executable requires no additional memory.

That makes it even better. Less diskspace and less memory overhead, but maybe at the cost of a little more cpu power.

Legend

April 20th, 2007, 22:50

Ok, yes, AA needs to be turned all the way down for the DX9 plugin to work. Hopefully that's noted somewhere that I missed.:sombrero:

It would be nice if a different reg. entry could be used for the DX9 plugin so the "stable" can use AA at the same time.

PJ1.7 now gives me that "Failed to allocate memory" message and refuses to ever boot a rom dispite attempting tens of time. God, PJ1.7 is so finicky now. But with PJ1.6, the Development plugin works fine.

mudlord

April 22nd, 2007, 06:59

Ok, yes, AA needs to be turned all the way down for the DX9 plugin to work. Hopefully that's noted somewhere that I missed.

Its noted in the DirectX SDK docs....:evil: ..but thats cruel. I will write some unified docs for boths stable and dev branches, and a FAQ, in this this very fact will be discussed in depth.

It would be nice if a different reg. entry could be used for the DX9 plugin so the "stable" can use AA at the same time.

Sure thing dude, where do you want it? Or maybe a INI hmmm...rabiddiety already gave me some code from nrage's plugin that'll do the trick....although it needs a bit of hacking.

About the PJ64 beta problems, I personally just want to wait for things to stabilise in the core, before doing any more drastic changes. To me, theres not much point doing beta work now because PJ64 is undergoing very big changes atm with the core....as you noticed.

I'm not sure how these compression programs work, though... Do they add overhead code to uncompress the module in memory?

Yes :). PE compression programs often add a compression loader stub as a extra section in the EXE/DLLs PE header. Often, these apps encrypt certain PE sections,which contain the code & resources. The EXE/DLL is then modified by the app to load that code section for the compressor first, which then loads the rest. This also holds true for copy protections as Safedisc, SecuROM and StarForce (though Starforce is a shitload more "controlling" than the rest, like in the new 4.0x branch and its insane & draconian methods to do DRM on a OS/hardware level. Tages, is different to all these, as it is embedded as C/C++ headers and libs, so it gets in the source code, which makes things hell of a lot harder to crack.)and Armadillo (used in apps like FRAPS,and the Sam and Max episodic games).

Which is more precious RAM or disk space?
That is a tricky question...I would take the RAM, but then I don't want to take up too much HD space....but then we got the argument about 160 > GB hd's these days...

mudlord

April 24th, 2007, 07:42

k, legend, here's a update to try....It'll not interfere with the official and stable branch plugins so your FSAA settings are safe....i also added a nice small reg key deleter to automate complete removal of the plugin's reg settings....

I might just drop the compression on the DLLs, save time for me, and plus, no fake virus warnings from shitty AV apps ^^..

edit: attachment removed, will be public soon anyway...and besides, I started to see these builds popping up on places like AEP Emulation tho...same with the unofficial wrapper updates (popping up on a French emulation site...)....:unsure:

Legend

April 24th, 2007, 08:56

Works fine...thanks for the update! On a side note: Is Hydro Thunder compatable? It crashes for me a couple seconds after boot on both of your versions (I don't have the official anymore). The other games I tried worked fine.

mudlord

April 24th, 2007, 09:50

That was one game which I havent played with Rice's plugin. Its good the update worked for you, I'll do a update (with the new docs), and then I'll most likely get stuck into the database/hi-res texture work.

I usally use Glide64 and Jabo's plugins for it, so that it actually new for me..I guess I'll get the last binary Rice did (since we know things can break by compiling in a certain way....), and have a play around with that. The main games I tested with Rice's are the ones with the texture packs, so....yeah...

Doomulation

April 24th, 2007, 12:39

Well, you could always use a place to upload binaries that only those interested in the dev can access. No uploading attachments. That way the executables won't be snatched, if you would like it.

Cyberman

April 25th, 2007, 04:41

Since it's extremely immature to take dev libraries and use them as if they were the safest thing, (Like hey I got the latest and greatest.. whoops my entire computer don't work now it's all mudlord's fault Wahhhh!) I'll ask Martin about it. He might have a good suggestion.

Please Kiddies DON'T download unofficial builds and test builds, unless you WANT something to go wrong. We are not responsible for you driving off a cliff, THINK about it.

Cyb

mudlord

April 26th, 2007, 02:47

Cyb, I took your message and put it in the sticky, that should stop idiots from complaining to me personally about it screwing thier PC...I should put a disclaimer on PJ64 beta use too....I'll try to see about finding a safe place to put the dev alphas (like the one I gave to Legend)....since I dont want to see builds like this popping up on AEP all the time....

BTW, I started to completely overhaul texture dumping/loading. BMP loading is now a thing of the past and all CI images are now in PNG (which saves retexturers a crapload of time in weeding through images). It seemed the plugin, in TextureFilters.cpp (oddly enough), converts palleted images to RGBA on loading, which is how it handles colour indexed images. A 32-bit CRC is used for tex verification, and tex loading/dumping is done on RDRAM, while not emulating TMEM while doing it . I really got to clean up the source some more though....

Doomulation

April 26th, 2007, 03:24

Well, I do believe I can help with a safe place if you don't want to find it elsewhere. I can arrange a private FTP for dev builds.

mudlord

April 26th, 2007, 03:40

Well, I do believe I can help with a safe place if you don't want to find it elsewhere. I can arrange a private FTP for dev builds.

That would be brilliant :), thanks for the offer..:)

klasa

April 26th, 2007, 06:47

I was wondering...
In Paper Mario, when I save my textures as an png (with alpha layer) it seems that the game just sees... ehm... GIF-transparency (transparent on/off, if you get it :P)
Would there be a way to make the plugin, or game (dunno who'se the culprit) force to see the alpha layer?

And please, whatever you do with texture dumping, also put the palette in the filename. Because for things like the font in Paper Mario, it's a hella lot easier that you can just change something in that name to make an different colored font. If you had to get every letter+variation of the letter dumped...

mudlord

April 26th, 2007, 08:48

In Paper Mario, when I save my textures as an png (with alpha layer) it seems that the game just sees... ehm... GIF-transparency (transparent on/off, if you get it )

That doesnt seem right....unless they are dumped as RGB..(without the alpha channels) Does it occur with the official versions?

Doomulation

April 26th, 2007, 13:27

I created a dev ftp. I'll PM the ftp, username and password.
Feel free to PM around to whomever wants access.
I set quota to 100 mb. That should do plenty, right?
Also remember that the dev builds can only be accessed from the FTP. Try to get them off HTTP and you'll get a Forbidden error. So there.

Also, if you want, I could make two accounts. One for the developer, to upload and delete builds and one for the public, to download builds.
If there is anything else you need, you need only ask.

mudlord

April 29th, 2007, 04:43

A 100MB will be perfect. the current system is fine as is :)

Legend,

I checked out that Hydro Thunder prob, it works with build 46...but messes up with the later builds...sorta like the screen changing prob....

Whats weird though is that I got it to work on build 49, after messing with build 46....

Iconoclast

April 29th, 2007, 04:54

Three things.

One: Write Back & Reload and Basic & Write Back setting for Rice's are the two rendering-to-texture settings that have chances of crashing some games at some point (Star Wars RS, World Driver Championship, Stunt Racer 64, Gauntlet Legends, etc.) most respondingly on the 1.7 beta through returning errors like "interface.c" and things that have little to do with emulation. There is something in these two rendering-to-texture settings that causes problems in some games that don't in the other settings. Could be something required for them to work; could also be something nasty in the sourcecode or compilation process.

Gauntlet Legends, the only one of these games crashing with these settings BUT also using rendering-to-texture to fix issues, will only crash until you use Basic render-to-texture or lower and then back up to the crashing settings after getting through that point to survive without a crash, restarting the ROM and returning to the same point where the crash would normally occur (probably a thing with FX 5200s, I'm guessing).

Two: 5.9.9 has something in it that emulates Star Wars RS and Shadows of the Empire WAY differently, and in better ways, therefore requiring different INI settings. Turns out my INI config for RS was really for the 5.9.9 plugin...Whatever it is, these things should become options, if possible, for extra config improvement.

Three: It would be nice to change the window resolution as well as other settings DURING emulation if this can be achieved; would help things a bit for texture mapping accuracy tests.

klasa

April 29th, 2007, 09:55

Finally found some time to make the screenshot...
Here is how it looks with rice's last version, and the textures I've used.

mudlord

April 29th, 2007, 12:47

Finally found some time to make the screenshot...
Here is how it looks with rice's last version, and the textures I've used.

Brilliant! I'll see bout doing something bout that,in the next process of refining hi res textures, and adding Cyb's database engine.

could also be something nasty in the sourcecode or compilation process.

Main nasties in the compilation are the compression, which mangles the PE headers, compiler optimizations, and settings used when using threading runtime libraries. Recently, I switched BMGLib to use the same multithreaded runtimes as the plugin...

Two: 5.9.9 has something in it that emulates Star Wars RS and Shadows of the Empire WAY differently, and in better ways, therefore requiring different INI settings. Turns out my INI config for RS was really for the 5.9.9 plugin...Whatever it is, these things should become options, if possible, for extra config improvement.

Hmmm, I'll see bout getting the source to 5.9.9....

Three: It would be nice to change the window resolution as well as other settings DURING emulation if this can be achieved; would help things a bit for texture mapping accuracy tests.

That is possible, the windowed res code needs to be changed to resize the main emulator window (which is simply a case of Win32 API use), since just unlocking windowed reses from being changed manifests with issues dealing with the main emu window,due to the window not being resized...heheheheh

And Legend, I double checked Hydro Thunder, it definately works with newest 1.7 builds. I'm using Jabo's newest sound plugin tho :).

Iconoclast

April 29th, 2007, 18:34

Okay, and, also, I forgot something else.

You know how, when you want an animated GIF of something from an N64 game, you want to hold the screenshots button down with a very low FPS, and sometimes remove the background from the main object through animation editing?

Well, it's difficult to do with Rice's because of the JPEG compression. Obviously, it's still possible, but I hate JPEG compression, and it adds thousands of colors to images due to a simple loss of quality and makes optimizing to 256 colors much less pretty, having being impossible to restore to its original quality. That's why I'm stuck just pressing F2, Alt+PrtScrn, paste into AS, repeated, frame-by-frame of the animation.

I mean, I could use a plugin like glN64, which saves screenshots in .bmp, but I want to use either Rice's or Jabo's 1.7. Through retexturing, you can remove the background beforehand from the rectangular animation you are recording instead of erasing all those pixels after being pasted into an animation.

Better yet, maybe have a feature in Rice's that can continually log PNG/BMP screenshots for each frame until the user presses a key. All I want at least is an option to use PNG compression instead, which Jabo doesn't seem to be focused on right now.

Legend

April 29th, 2007, 20:00

Well, no games crash the emu like Hydro Thunder for me. Right after game boot, the emu crashes. It works PERFECTLY when I use OpenGL, but when I go back to DirectX, CRASH!! I tried toggling EVERY option for DirectX, but nothing prevents this. BUT, since no one else runs into this and I don't really care, its probably nothing for you to worry about. :)

mudlord

April 30th, 2007, 07:32

Legend

April 30th, 2007, 18:48

That was with all the PJ64s, including 1.6. And if it works fine on Opengl mode, then how could it be a RDB problem? But again, you have work to do, don't even worry about this.:)

mudlord

May 1st, 2007, 02:04

And if it works fine on Opengl mode, then how could it be a RDB problem?

Well, true. I havent payed much attention to the details of what you said about it..but since your willing to let this issue slide, meh...the game works flawlessly for me though. But its completely inexcusable that it wrecks up with your PC..:( . It should have been perfect all along...but then, I guess perfection itself is quite hard to chase though...:)

Iconoclast

May 1st, 2007, 05:14

Thanks to Doomulation for the server space and mudlord for giving me participation, from here on I will be uploading my changes to the 5.9.9 and 6.1.1 plugin configuration files on the given FTP, and new ini updates will hereon be posted by mudlord on each plugin release.

So, as I came to review a question I was asked, I had a look at why I thought 6.1.1 was better for Rogue Squadron than 5.9.9. Turns out, I was wrong. They're pretty much the exact same for this game, though 5.9.9 is better for Shadows of the Empire. I thought that you needed Normal Color Combiner checked in 5.9.9 config but not 6.1.1 config to fix some issues. But then I thought, wait, why do I have Force Buffer Clear checked on 6.1.1? Duh! Obviously, back then, I was still learning about the risks of Rice's settings, although I could've sworn there was a reason...so yeah, they're about equal. Except, in the in-game emulation attempt, 5.9.9 is very hesitant but occassional with showing the GUI graphics, whereas 6.1.1 holds them on for longer.

This is my configuration for 6.1.1 for the United States version of this game.

{ec4ba2664fd9ad2e-45}
Name=Rogue Squadron
AccurateTextureMapping=1
NormalAlphaBlender=1
NormalColorCombiner=1
ForceScreenClear=1
FrameBufferEmulation=2
RenderToTexture=2
ScreenUpdateSetting=1May as well use the same thing for 5.9.9 again as it turns out.

Accurate Texture Mapping only affects the N Logo bitmap at the very beginning of the ROM, whereas the graphics look slightly better with the setting disabled. Normal Alpha Blender if on will make the N Logo invisible but not affect any other area of the game with what can be seen using the plugin for now. All Star Wars games seem to be designed to not like this option being on, and as well as you may expect Normal Color Combiner. Force Screen Clear fixes afterimages of shitty alpha emulation attempts, screen update on VI origin update (NOT after screen is drawn) is the only setting that makes frame update constant and working throught the whole game, and hiding rendering-to-texture effects and frame buffer drawings I thought was necessary because Basic Framebuffer and Write Back rendering-to-texture are both settings that crash in the game at some point, so I took that as a sign.

poly_pusher

May 5th, 2007, 19:09

just wanted to say you're doing some great work. Would love to see more custom dx9 shaders utilized in n64 roms.

mudlord

May 6th, 2007, 02:43

thanks. :)

During coding there was a large number of changes to the renderer to pull those off...

First of all, it uses multiple render targets. The code creates a render target, like a framebuffer. All post processing occurs on the render target texture. Then the shaders do thier work, and its rendered back to the main screen buffer. This is very similar to how gulikoza's dosbox DX9 shader imple. works. Of course, there are issues on slow DX9 cards...it was fun though seeing them in action. But then again, there's more important things in the plugin to tend to, like the 1.7 probs, and updates to hi-res texture rendering. I admit I've been a bit lazy with working on this in the last few days, since I have currently other important things to tend to (university, mainly, got 2 programming assesment tasks to do...)

toe_head2001

May 13th, 2007, 06:22

Thank you my good man. One thing, I don't get it, why the discontinue of executable compression?

mudlord

May 13th, 2007, 10:11

One thing, I don't get it, why the discontinue of executable compression?

There was a interesting discussion a while back about what actual benefits this even offered...

One of the reasons for dropping it is to save RAM. Executable compressors generally add a extra section in the EXE/DLL as a loader for the compressed sections. One of the side effects of this, is that increased memory usage can be a issue, due to the decompressor decompressing the compressed sections into RAM upon init...

So, a tradeoff was done for speed over size. Plus,as you noticed, RAR compression does a decent job in keeping size down on download, so it seems a bit pointless compressing it anyway. Another benefit is that some antivirus programs sometimes detect the packed content (the executable data) as malware/viruses. This is definately the case for using packers different to the common ones (UPX, ASPack, etc...) like FSG, kkrunchy, MuCruncher, Petite etc..(even though they offer better compression than UPX)..

So thats basically why: The speed tradeoff and a workaround for overprotective virus scanners. Not to mention we need all the speed we can get since MS Visual Studio 2005 completely b0rks code by its optimizations which are insanely unstable with code like this....Oh well.

mudlord

May 15th, 2007, 05:28

Can you please refrain from asking those sort of questions in this thread? The other thread is meant for discussions like the question you asked. You'll see you got a answer in there (if only I was a mod, then I could look after my own threads....I can only dream I guess....)

BTW: The builds got a repack. It seems from that Icono noticed, signing didnt work on his legit version due to licensing issues with my version. Thus, to make myself legally indemnifiable, and to avoid the possible warning messages, archives are repacked with 7-Zip. WinRAR can still read them though.

The Siskoo

May 15th, 2007, 13:59

JHdD

May 16th, 2007, 20:42

Good job it is a great plugin :D.
But could you host the files in a zip or rar archive (or make a self-extractor)?
Because I don't think that the "mainstream" pc user has 7Zip installed.

JHdD

mudlord

May 17th, 2007, 01:25

Hello,

I dont"t know if you're interesting by this, here some settings to improve some games :

- GT 64 Championship Edition (E) [!] --> Increase Texture Rec
- GT 64 Championship Edition (U) [!] --> Increase Texture Rec
- Mario Golf (J) [!] --> N64 Framebuffer --> Basic Framebuffer , Rendering to Texture --> Basic Render To Texture
- Mega Man 64 (U) [!] --> Increase Texture Rec
- Parlor! Pro 64 Pachinko Jikki Simulation Game (J) --> Increase Texture Rec
- Puyo Puyo 4 - Puyo Puyo Party (J) [!] --> IncTexRectEdge

Of course I am interested in this. :), I'll let Icono know of these updates :)

Good job it is a great plugin .
But could you host the files in a zip or rar archive (or make a self-extractor)?
Because I don't think that the "mainstream" pc user has 7Zip installed.

JHdD

You don't need 7-Zip...the newest WinRAR supports 7-Zip unpacking.

As for a self eextractor, I am pondering the use of a NSIS installer to be one (since they support LZMA compression)

Iconoclast

May 17th, 2007, 02:23

.zip format is the most widely supported, obviously, but has a relatively inferior compression for downloads. Trust me, it'll make your downloading life a lot easier if you get 7-Zip (7-Zip.org) or WinRAR; they compress better and decompress faster than Windows XP's built-in method.
Hello,

I dont"t know if you're interesting by this, here some settings to improve some games :

- GT 64 Championship Edition (E) [!] --> Increase Texture Rec
- GT 64 Championship Edition (U) [!] --> Increase Texture Rec
- Mario Golf (J) [!] --> N64 Framebuffer --> Basic Framebuffer , Rendering to Texture --> Basic Render To Texture
- Mega Man 64 (U) [!] --> Increase Texture Rec
- Parlor! Pro 64 Pachinko Jikki Simulation Game (J) --> Increase Texture Rec
- Puyo Puyo 4 - Puyo Puyo Party (J) [!] --> IncTexRectEdgeI do the INI configuration for Rice's Plugin. I already have quested to configure all versions (even hacked) of all 64 ROMs from #-Z, currently on D, and when I get to these games, I promise to take this post of yours into consideration. Thank you for your suggestion.

However, for Mario Golf, I have already set these the last time I tested this game. I have set rendering-to-texture to Basic & Write Back and am using the same setting for N64 Frame Buffer. Still, I will remember to revise this to lower settings if I find the minimum when I come to that game after the D-L games first.

I will be making configurations for 5.9.9 and Rice's Daedalus (games working better on these plugins than 6.1.1) as well, so hopefully these will be added to the Config archive in the release following my uploading them (merely a reminder).

As for a self-extractor, I thought of one suggestion. Maybe keep the .7z archive but have an additional installer for the plugin that automatically moves all the files to the right directory? I know somewhere you should be able to get the software to make an installer like that, though a self-extracting 7-Zip obviously won't do it.

Best hopes for the vindictive return of Rice's Video Plugin.

Cyberman

May 17th, 2007, 03:57

Is it possible to put another compilor into the chain than VS2005? If I remember correctly you can alter the tool chains. GCC has a much better back end for optimization. I know that using MS intrensics makes REALLY bad MMX code too. If one could use the GCC compilor to make the whole thing I suspect you would have less optimization issues. Of course then you have to worry about all the MS specific code you dumped into the plugin. Nothing is easy is it? :D

Cyb

mudlord

May 17th, 2007, 04:26

About 2-3 weeks ago, Rice was telling me that you can use VS2003, since thats what he used when he was maintaining the plugin.

What I am waiting on (and I bet others are too), is for Hacktarux to release his Linux port of Rice Video, which uses GCC. I bet from that, we can unify sources, and then we both have a much better method on maintaining the code for open source compiler systems like mingw/GCC :).

EDIT:

Maybe keep the .7z archive but have an additional installer for the plugin that automatically moves all the files to the right directory? I know somewhere you should be able to get the software to make an installer like that, though a self-extracting 7-Zip obviously won't do it.

NSIS uses LZMA.....(same compression as 7-Zip), and it has worked great in the past for me as a installer system. I don't really see the harm in writing a installer for things....:)

Cyberman

May 17th, 2007, 04:46

Read that again. Do not post on it unless you are the developer(s) for the plugin. From now on you will get points for doing so. I repeat you have NO excuse for disreguarding the rules stated in the thread. DON'T POST ON IT. This means YOU. Unless you are part of Emutalk staff or on the developement team DO NOT POST IN THE THREAD. It's VERY hard to keep the thread short and too the point for people to find the plugin and read the developement and changes on the thread if you indiscrimently post on it. This is very RUDE behavior and disrespectful of the hard work mudlord has put into the plugin, if he has to moderate he's wasting time dealing with childish behavior instead of doing what he needs or wants to do.

This thread EXISTS so that thread has pertinent information to people who are using the plugin only. Discusion of the plugin belongs here, this includes QUESTIONS and coudo's. It's nice you compliment mudlord but don't do it there, that actually makes things messy for him.

Mudlord asked NICELY once, now you continue to disrespect his request and ignore the notice near the first post in the developement thread. So now we have to do things the hard way.

Cyb

Sirmatto

May 17th, 2007, 15:55

What I am waiting on (and I bet others are too), is for Hacktarux to release his Linux port of Rice Video, which uses GCC. I bet from that, we can unify sources, and then we both have a much better method on maintaining the code for open source compiler systems like mingw/GCC :).

He did say to ask him if he forgets, since it's something he's been meaning to do ;)

mudlord

May 18th, 2007, 02:28

He did say to ask him if he forgets, since it's something he's been meaning to do

Yep, I gave him a nice and friendly reminder a few seconds ago 'bout the source code release...:)

JHdD

May 18th, 2007, 11:19

If I start Project64 I get this error:
Failed to load the plugin C:/Program Files/Project64 1.6/plugins/RiceVideoStable.dll

Cyberman

May 18th, 2007, 16:12

Yep, I gave him a nice and friendly reminder a few seconds ago 'bout the source code release...:)Luke... use the source. :D
Well I know how it is to forget things. So this is understandable, but I doubt he has the same problems I do. LOL

mudlord

May 19th, 2007, 11:05

Luke... use the source.
Well I know how it is to forget things. So this is understandable, but I doubt he has the same problems I do. LOL

Classic line from a classic movie. Ah the memories...but then forgetting things is part of being human. We all stuff up sometimes, anyway.

If I start Project64 I get this error:
Failed to load the plugin C:/Program Files/Project64 1.6/plugins/RiceVideoStable.dll

Installed the MSVC2005 SP1 runtimes by any chance?

JHdD

May 19th, 2007, 17:02

Installed the MSVC2005 SP1 runtimes by any chance?

The what? :S

The Siskoo

May 19th, 2007, 17:15

Take a look on this link :
http://www.emutalk.net/showthread.php?t=39868

And look this question :
C) Why won't the plugins load?

:)

Cyberman

May 19th, 2007, 17:32

Classic line from a classic movie. Ah the memories...but then forgetting things is part of being human. We all stuff up sometimes, anyway.
Unfortunately yes. However that's what other people are for, to compensate for our own .. uhhh what was I saying? :D

I believe an installer for the plugin might be a good idea, it would save people the hassle of unziping a package and finding where to stuff everything. It may be necessary in the future as well since there is likely to be more than just a DLL to deal with. Inno Setup is very good (combine that with a DLL dependancy walker and you are in business) though I don't like 'EXE'cutable installers, they are darn convienent.

Back to doing 'STUFF' :D

Cyb

Iconoclast

May 19th, 2007, 20:21

Yes, that is what I suggested from before.

Maybe give an option between a .7z file containing all of the files and an installer that puts the files in the right directory and gives you an option of which components to install? ("I don't the damn debug version!") Or that is by giving an option I mean attaching both.

mudlord

May 21st, 2007, 00:57

I believe an installer for the plugin might be a good idea, it would save people the hassle of unziping a package and finding where to stuff everything. It may be necessary in the future as well since there is likely to be more than just a DLL to deal with. Inno Setup is very good (combine that with a DLL dependancy walker and you are in business) though I don't like 'EXE'cutable installers, they are darn convienent.

Back to doing 'STUFF'

"Through the miracle of science, that can be arranged!"

- Dr Farnsworth, Futurama
(http://www.emutalk.net/showpost.php?p=380220&postcount=24)

EDIT:

Back to doing 'STUFF'
I have to clean up general things a bit more in that area too in regards to that "stuff", depends on how busy (or lazy...) I am. That installer took around 1/2 hour to fully script and do all the GFX, and from my testing, seems very rock solid as a base. I'll upload the scripting for it, later....(uses Nullsoft Install System, I don't really like Inno Setup's script format, mainly because I am used to NSIS :geek:)

Back to work for both of us, hey Cyb? :)

Maybe give an option between a .7z file containing all of the files and an installer that puts the files in the right directory and gives you an option of which components to install? ("I don't the damn debug version!") Or that is by giving an option I mean attaching both.

Hmmm, figures....PJ64 1.6 and 1.7 are around 2.3MB, and I don't hear dialup users complaining..okie dokie, what the hell :saddam:

Yay for simplicity! (we'll need it.....plus it lets me track how many people got thier hands on it)

Cyberman

May 22nd, 2007, 17:46

"Through the miracle of science, that can be arranged!"

- Dr Farnsworth, Futurama
(http://www.emutalk.net/showpost.php?p=380220&postcount=24)

EDIT:

I have to clean up general things a bit more in that area too in regards to that "stuff", depends on how busy (or lazy...) I am. That installer took around 1/2 hour to fully script and do all the GFX, and from my testing, seems very rock solid as a base. I'll upload the scripting for it, later....(uses Nullsoft Install System, I don't really like Inno Setup's script format, mainly because I am used to NSIS :geek:)

Back to work for both of us, hey Cyb? :)I've made some progress now with the db Engine so there is hope at the end of the tunnel. I just wish he would stop blarring his stereo! :D I've been so tired lately it sucks. I have too many things going on at once in my head. PSoC I2C SQL C++ m8C I2C bootloader ARGH.

Ahem Ok I feel better now. Glad to see your installer is working. A single installer is awesome with choices too. :D

Cyb

total_n00b

May 22nd, 2007, 18:14

first of all, sorry for my bad english and if this question was already asked please don´t delete this entry

how can i use rice´s video correctly to bring rogue squadron running?
i have directx 9 already, but i really don´t know how to use the plugin
is there anywhere a crashcourse?

mudlord

May 23rd, 2007, 00:46

I've made some progress now with the db Engine so there is hope at the end of the tunnel. I just wish he would stop blarring his stereo! I've been so tired lately it sucks. I have too many things going on at once in my head. PSoC I2C SQL C++ m8C I2C bootloader ARGH.

Coolness! I might add a extra tab in the config to allow for the new retexturing/filtering capabilities....I still gotta fix up completely the 1.7 issue, tho debugging that has proven to be quite a large PITA...especially when the emulator deadlocks the whole system.....

Ahem Ok I feel better now. Glad to see your installer is working. A single installer is awesome with choices too.

Thanks :). Glad you like it.

first of all, sorry for my bad english and if this question was already asked please don´t delete this entry

Nah, its ok. I only get really peed off if people post in the stickied thread, who are not authorised to do so (the EmuTalk staff are perfectly fine to do so, also people who are on the team are fine as well....)

how can i use rice´s video correctly to bring rogue squadron running?
i have directx 9 already, but i really don´t know how to use the plugin
is there anywhere a crashcourse?

Iconoclast can answer this better than I can, since he did testing with this game.

Basically, atm, it is unplayable in Rice Video.
This is due mainly to the fact the game uses a custom heightmap microcode. The game basically takes a 2D monochrome texture, and applies elevation calculations on the co-processor, using the texture as a guide in where to calculate. This creates the 3D terrain in the game (Wikipedia has a great article explaining how heightmaps in general work).

However, Rice Video doesn't emulate this technique. Which means, the ground and possibly other things, is not emulated. Which makes the game unplayable. Your best bet for this game is to:

A) Use the PC version
B) Use a LLE video plugin

Iconoclast

May 23rd, 2007, 01:36

Yes, that's right; no three-dimensional objects will show in Rice's Video Plugin, only two-dimensional.

If you really want to see how it's going in Rice's, just download the RiceVideo6.1.0.ini file to the Plugin folder.

Also, LLE graphics plugins probably look worse on this game than the one that comes with Nemu64. Your best way to emulate this game is to install Nemu64 and disable Audio HLE from the Debug menu. That's as closest to playable as you're ever going to get in emulation of the game.

mudlord

May 23rd, 2007, 08:03

just a little notice....the Rice Video installer script is now uploaded to the "usual spot"....

squall_leonhart

May 25th, 2007, 11:34

suggestion.
change renderer method without having to end the rom.

...i dunno if this is possible under any emulators other then PJ64 1.7 though

mudlord

May 27th, 2007, 01:41

I am somewhat very displeased with you posting in here. Didn't you read the message? It said "DO NOT POST HERE". It says so for a reason. Next time, post in the discussion thread, and NOT this one. I really wonder sometimes why humans explictly IGNORE instructions, when they are told not to do something, and instead they do what they are not supposed to do. I really wish I didn't have to waste my breath saying this, I got loads of better things to do instead of trying to talk to one person who ignores what I and others have asked.....

As for the request on ingame renderer switching....If it only possibly will work on 1.7 beta, I don't see the point. I'm not going to do something just for one emulator, that would mean Mupen and 1964 would have to be capable of the same thing. On top of that, I'm very happy how it is. I don't see the need for it to be changed.

squall_leonhart

May 28th, 2007, 14:15

First this thread will be HEAVILY moderated. Do NOT post problems with the plugin here. That is the DISCUSION thread. New Features might be OK this is primarily to be a one stop thread to get the plugin from. (first part of thread) any addition will be specifically about features implemented or suggested so it's in one place. Discussion is for bugs. I will move anything about a bug to the discussion thread, unless it's by mudlord.

Anything about USING the plugin (this is not a feature) goes in discussion. This is entirely about developement and suggestions. These questions will be moved to discussion. The old thread is now the discussion thread.

Have fun (I've stickied this thread too).

Cyb

mine was a suggestion.

you should ask cyberman to change his post if you don't want suggestions in there. i would'nt have posted there if cybermans post didn't say i could.

mudlord

May 29th, 2007, 01:58

Oh alright, thanks for letting me know. I shouldnt have flown off the handle, but when people do stuff against my wishes, I get very pissed off...Especially when I asked nicely first :). And plus, it wastes my time when I could be doing more important things.

Now thats out of the way, I thnk that doing your request would involve quite a fair bit of renderer changes. It might be possible to do this on other emus, not totally sure at this stage.

Cyberman

May 29th, 2007, 06:12

squall_leonhart

May 29th, 2007, 06:40

You did neglect to read the subject line . I thought I had adjusted the message as well, ahh well life goes on I'll fix it, sorry about that.

All prior suggestions have been in this thread (aspect ratio option for example and better control over file dumping etc.)

mudlord need to try an SVN checkout soon,you don't plan on images > 2gigs in size do you? (inside joke)

Cyb

i read the subject line, but your post seemed to negate it :/. so i just followed your post.

Ahwell,... these things happen :/

Oh alright, thanks for letting me know. I shouldnt have flown off the handle, but when people do stuff against my wishes, I get very pissed off...Especially when I asked nicely first :). And plus, it wastes my time when I could be doing more important things.

Now thats out of the way, I thnk that doing your request would involve quite a fair bit of renderer changes. It might be possible to do this on other emus, not totally sure at this stage.

the plugin might be able to handle the change internally, it will likely require a massive rewrite of the way the plugin handles the api and graphics process

Cyberman

May 29th, 2007, 07:03

mudlord does the plugin handle it's own configuration or does it pass this job to the emulator? I know you can change plugin settings for graphics on the fly with the playstation by running PSXemucheater which I believe shuts down the graphics plugin and then sets it's configuration then restarts the plugin. IE the settings ocure outside the actual plugin.
So a QUICKIE way to implement this would be to use a Passthrough plugin that becomes the big brother of the graphics plugin instead of the emulator.
As long as you can invoke said big brother plugin with a key sequence (ala CTRL-K in the cheat software for playstation emulation). It can shut down the real GPU plugin and invoke it's configuration menu, then unload and reload the DLL with the new settings. Reconfiguration on the fly without that horrible aftertaste ;)

Cyb

squall_leonhart

May 29th, 2007, 07:33

aye, exactly, but i think it might be possible without a dummy loader, although i don't know zot about programming, theres no reason its not possible... lol, VBA for instance can change from ddraw > d3d > opengl without requiring a restart, it just reinit's the display thread.

mudlord

May 29th, 2007, 08:48

mudlord need to try an SVN checkout soon,you don't plan on images > 2gigs in size do you? (inside joke)

Heheheheh, its rabbiddiety's server. I uploaded my latest non alpha code to the main thread, as well as the brand new installer system.

mudlord does the plugin handle it's own configuration or does it pass this job to the emulator?

The plugin uses its own management system for configuration. This is one of the main things I am currently rewriting for the next builds (I might do a quick alpha for ya)...The emu just intercepts the calls to the video plugin, but I'm not sure how zilmar does his changing plugin code for PJ64 1.7 (allows for plugins to be changed on the fly)

aye, exactly, but i think it might be possible without a dummy loader, although i don't know zot about programming, theres no reason its not possible... lol, VBA for instance can change from ddraw > d3d > opengl without requiring a restart, it just reinit's the display thread.

Depends really on the threading, Rice left over some threading code for the plugin tho....but it seems quite incomplete.