What's new

Rice's Plugin Source <discussion>

OP
Enzo Dragon

Enzo Dragon

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

Emulator Developer
"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.

Such back buffer memory pointer monitoring function is also very confusing. It may need to be turned on for many games, but it may slow down the performance, so it is turned off by default.

As I remember, the current code should support Banjo games just fine, as far as the right options are turned on.
 

mudlord

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

Enzo Dragon

STFU, NAVI
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
Nice! I will certainly be looking forward to that.
 

rabiddeity

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

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

Enzo Dragon

STFU, NAVI
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.
 
Last edited:

Cyberman

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

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

mudlord

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

klasa

New member
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

Banned
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

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

Banned
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

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

mudlord

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

Top