Rice's Plugin Source <discussion>

[Cyberman]

Thanks for the detailed list of ideas, Cyberman

LOL

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]

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]

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]

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]

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]

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]

Rice's Plugin continuation thread

Continuation of this.

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]

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.

 

[mudlord]

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]

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.

The only thing that might be problematic is that many objects share textures. How would this be dealt with?

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.

Although I have little to put forward on the technical level of all of this, I think that the idea of two separate builds is excellent.

 

[Cyberman]

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]

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]

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]

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]

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]

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]

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]

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]

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.

Cyb

 

[Sirmatto]

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