What's new

Rice's Plugin Source <discussion>

mudlord

Banned
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?
 
Last edited:

rabiddeity

Plugin Hacker
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

Banned
Only BMGLib.dll is needed...BMGlibPNG is only a version of BMGLib with PNG support, and nothing else.
 
Last edited:
OP
Enzo Dragon

Enzo Dragon

STFU, NAVI
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

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

Banned
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....
 
Last edited:

Cyberman

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

  1. 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.
  2. It would be good to have a single spot for people to download this update from (IE a single updated link in a post).
  3. 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
 
Last edited:

mudlord

Banned
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

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

  1. 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.
  2. It would be good to have a single spot for people to download this update from (IE a single updated link in a post).
  3. 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

1) Create a new thread: Unofficial Rice's Plugin Dev
2) Update the first post with a link to the newest build (or a website, which can keep links to all current builds).
3) Add "Unofficial" and increase build numbers for each so we won't confuse them.

Anyway, that's what I suggest.
 

Cyberman

Moderator
Moderator
New Thread

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
 
Last edited:

mudlord

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

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

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

Cyberman

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

Banned
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....
 
OP
Enzo Dragon

Enzo Dragon

STFU, NAVI
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

Moderator
Moderator
mudlord said:
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

mudlord said:
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

Enzo Dragoon said:
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
 
Last edited:
OP
Enzo Dragon

Enzo Dragon

STFU, NAVI
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

Banned
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

Plugin Hacker
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

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

Top