Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #1351  
Old 5th August 2014, 08:09 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Sorry about delays in response.
ReyVGM I didn't reply right away because I still don't know the answer to your question about GoldenEye 007. I would have to debug that saved state of the GE credits you sent, and I haven't had time to try that yet. I've been busy fixing the OpenGL screen capture implementation I've written so that it logs the VI-filtered screens, and ran into a lot of multi-thread bugs with zilmar's plugin system.

My guess for now is that GoldenEye probably has the 440x330 frame buffer, scaled horizontally to 640x330, and the TV handles the upscale to 480 lines? Sounds pretty off...I honestly don't know, but I intend to find out. I'll temporarily skip over your question, but it's a good one.

Quote:
Originally Posted by ReyVGM View Post
Isn't there a way to output both images, but with different file names? That way you avoid using that .dib extension. Or, can there be an option to select what kind of image you want? That way I can just click on the filtered one and avoid getting a non-filtered screenshot? Sometimes I might want to have both images, yes. But other times I would rather just have the filtered ones.
I could take votes on this matter...whether to clutter the configuration GUI with more options like, output non-filtered, output VI-filtered, or output both? It seems somewhat extraneous, when I can just give both of the screenshots. In the meantime before majority overrules, I kinda think people should be made aware that there is a N64 video card RGB pixels buffer (the raw video image) and a filtered and upscaled screenshot intended for TV monitor adjustments (the VI-filtered screenshot). If I default to only outputting only one of them and not both, users will be under the false impression that it's the way all screenshots should be. I personally think that both are equally as accurate, for different reasons.

As for avoiding "filename.bmp" vs. "filename.dib" and instead going for, "file1.bmp" vs. "file2.bmp" ... maybe, but on Windows DIB seems to be as widely supported as BMP is, even in Windows Explorer thumbnail previews. So I don't know of a reason why to make them both the same file extension like you suggest? I think the DIB extension is more correct an analogy to VI filters...the VI upscale and filters prepares the raw, unfiltered image to be "device-independent" of various monitor screens (apart from the extra bonus of giving a better anti-aliased look etc.), and DIB extension means "device-independent". So currently I like my alternating .bmp and .dib extensions analogy better, and it helps sort by file extension in Windows Explorer so you can group all the VI-filtered screenshots away from the non-filtered ones.

Quote:
Originally Posted by ReyVGM View Post
Wait, so what does that mean to games like Goldeneye and its weird resolution? Does that mean that the screenshot will be upscaled or downscaled from the original res?
Oh, upscaled for sure. I really doubt that it will convert GoldenEye's 440x330 into a VI-filtered 640x240 ... probably something like 640x330? Like I wrote at the top of this message, it's a good question. I haven't found out precisely what happens yet, but there's almost no way it's being downscaled.

Quote:
Originally Posted by ReyVGM View Post
The capturing program I have only takes a pic of what the screen is showing. That's why so far I've only been able to capture games that are 320x240 or 640x480.
Sounds like you're using an old version of this plugin?
Should be using the latest version.

Go to Options -> Configure Graphics Plugin -> Screen Resolution Formula, pick "User-defined" and set any custom resolution you want.
Reply With Quote
  #1352  
Old 5th August 2014, 08:17 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

GeneralGiantPanda, you actually managed to get half the speed of the plugin in this thread, when compiling under Debug mode? I find that to be impressive. Me I only get like, less than 1% of the Release build speed when running the Debug build.

Quote:
Originally Posted by V1del View Post
I might try to port this to m64p for the lulz when I get some time, if anything would be a good opportunity to familiarize myself with the plugin specs
Good luck! Because I hope that fails and the arrogant distraction that is the Mupen64Plus plugin system keels over and dies.
Nothing wrong with learning different plugin specs though.

Quote:
Originally Posted by RPGMaster View Post
Lol serious? You either choose debug or release. I think by default, its on debug.
I think by default, it's on Release, unless he's not opening the official VC project files I supplied in the source release.

Quote:
Originally Posted by RPGMaster View Post
Lol what? It shouldn't delete the DLL. Maybe I missunderstood what you're saying ;/ .
It actually can delete the DLL while building if the build failed for some reasons (either compile- or link-time errors, can't remember which).

Last edited by HatCat; 5th August 2014 at 11:50 PM.
Reply With Quote
  #1353  
Old 5th August 2014, 11:53 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

I can't call glReadPixels to take screenshots inside CaptureScreen() unless the plugin is run from within 1964 or *sometimes* pj64 (if I initialized the HGLRC in InitiateGFX() instead of RomOpen()). On Mupen64, it inevitably fails because the OpenGL context isn't shared with the same thread that called CaptureScreen, as the one that called RomOpen/InitiateGFX. Damn this multi-threaded shit is aggravating.

So I need a sync hack...within CaptureScreen(), I can set a synchronization variable to TRUE to call glReadPixels the next time UpdateScreen() is called. It's a perfectly working solution but sort of ugly...really hope there's a way to just handle all the screenshot logging within CaptureScreen locally.

Just calling ANY gl function, even glGetError(), not just glReadPixels(), crashes Project64 1.6 faulting OPENGL32.DLL (but on mupen64, does not crash, yet simply reports GL_INVALID_OPERATION, citing a suddenly nonexisting GL context).
Reply With Quote
  #1354  
Old 6th August 2014, 02:11 AM
ReyVGM ReyVGM is offline
Project Supporter
Senior Member
 
Join Date: Mar 2014
Posts: 212
Default

Quote:
Originally Posted by HatCat View Post

Sounds like you're using an old version of this plugin?
Should be using the latest version.

Go to Options -> Configure Graphics Plugin -> Screen Resolution Formula, pick "User-defined" and set any custom resolution you want.
Oh I haven't used the new plugin yet. I'm actually not playing anything lately. But I am waiting for the plugin that will show the Goldeneye credits correctly like that image you posted some pages ago. Can I get those results with the current plugin?
Reply With Quote
  #1355  
Old 6th August 2014, 02:47 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

WOOOOOOOOOO!
Got glReadPixels VI-filtered screenshots working now.

In bitmap.h:
Code:
enum {
    STAGE_CAPTURE_THREAD = -1,
    STAGE_CAPTURE_PENDING = 0,
    STAGE_REFRESH_THREAD_CAPTURE
};
extern int thread_stage;
In bitmap.c:
Code:
int thread_stage = STAGE_CAPTURE_THREAD;

void capture_screen_to_file(char * path)
{
...
    if (thread_stage < STAGE_CAPTURE_PENDING)
    {
        thread_stage = STAGE_CAPTURE_PENDING;
        return;
    }
    thread_stage = STAGE_REFRESH_THREAD_CAPTURE; /* called by UpdateScreen */
... // glReadPixels and screen capture file output went here
In main.c:
Code:
EXPORT void CALL UpdateScreen(void)
{
...
    if (thread_stage == STAGE_CAPTURE_PENDING)
    {
        thread_stage = STAGE_REFRESH_THREAD_CAPTURE;
        capture_screen_to_file(filepath);
    }
Quote:
Originally Posted by ReyVGM View Post
Oh I haven't used the new plugin yet. I'm actually not playing anything lately. But I am waiting for the plugin that will show the Goldeneye credits correctly like that image you posted some pages ago. Can I get those results with the current plugin?
Ah haha, nope I'm afraid not. Been trying to do a new release, but it's not coming out for some reason! The current build in this thread does come close to those results I showed you for GE007, but it uses the uncontrollable glDrawPixels and/or NN minification to shrink the image, which looks slightly less sharp than what I've improved it to now.
Reply With Quote
  #1356  
Old 6th August 2014, 03:28 AM
GPDP GPDP is offline
Senior Member
 
Join Date: May 2013
Posts: 146
Default

http://i.imgur.com/67OM2xC.jpg

A close-up shot of what this plugin looks like with inserted scanlines on my CRT PC monitor. Other than the increased sharpness and better colors, it is otherwise identical to how the same game looks like on my N64 through my CRT TV.
Reply With Quote
  #1357  
Old 6th August 2014, 03:46 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Hideous.

Maybe you didn't see the post I wrote earlier, but I was asking if you'd be fine with me just drawing black, solid lines horizontally across the screen (found a portable way to implement this type of scanline filter in GL 1.1).
I was fine considering implementing a "scanline filter" of this sort:


But I'm not sacrificing portability to make my monitor look like some ugly-ass TV.
Reply With Quote
  #1358  
Old 6th August 2014, 03:58 AM
GPDP GPDP is offline
Senior Member
 
Join Date: May 2013
Posts: 146
Default

No one is asking you to do otherwise. I don't know what you're reading into my post. All I implied is that if you were to display this plugin in 640x480 fullscreen on a PC CRT, and added scanlines through whatever method (including what you're suggesting), you get an extremely accurate image to what the real thing looks like on a CRT (you know, what most people played their N64 on back in the day). It was supposed to be a testament to the accuracy of this plugin.
Reply With Quote
  #1359  
Old 6th August 2014, 04:01 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

Quote:
Originally Posted by HatCat View Post
Maybe you didn't see the post I wrote earlier, but I was asking if you'd be fine with me just drawing black, solid lines horizontally across the screen (found a portable way to implement this type of scanline filter in GL 1.1).
I was fine considering implementing a "scanline filter" of this sort:
YO! Dat pic looks tight son.
Quote:
Originally Posted by HatCat View Post
I can't call glReadPixels to take screenshots inside CaptureScreen() unless the plugin is run from within 1964 or *sometimes* pj64 (if I initialized the HGLRC in InitiateGFX() instead of RomOpen()). On Mupen64, it inevitably fails because the OpenGL context isn't shared with the same thread that called CaptureScreen, as the one that called RomOpen/InitiateGFX. Damn this multi-threaded shit is aggravating.
I agree with you about multi-threaded. I have no idea how that stuff works. Maybe I should learn it ;/ . Also 1964 ftw .
Quote:
Originally Posted by HatCat View Post
Good luck! Because I hope that fails and the arrogant distraction that is the Mupen64Plus plugin system keels over and dies.
Nothing wrong with learning different plugin specs though.
Lol . It's a shame no zilmar spec emulators are in active development ;/ .
Quote:
Originally Posted by HatCat View Post
It actually can delete the DLL while building if the build failed for some reasons (either compile- or link-time errors, can't remember which).
Oh haha, forgot about dat.
Reply With Quote
  #1360  
Old 6th August 2014, 04:13 AM
GPDP GPDP is offline
Senior Member
 
Join Date: May 2013
Posts: 146
Default

Anyway, for what it's worth, yes, a simple scanline filter would be nice. I forget, however. Is it possible to run this plugin at 640x480 fullscreen? If so, it would be perfect for my setup.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 11:06 AM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.