Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #1711  
Old 16th March 2015, 05:38 PM
V1del V1del is offline
Project Supporter
Senior Member
 
Join Date: Feb 2012
Posts: 442
Default

Keyboard shortcut should be (tm) Alt+Enter but not entirely sure
Reply With Quote
  #1712  
Old 16th March 2015, 05:56 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

Yeah that's the way it works in win32 mupen64 (as well as any other emu I've ever known), but nothing I hit on the keyboard seems to take me out of full screen mode on mupen64 0.5. Have to press Alt+Enter or something to switch to the main mupen64 window and end emulation to get out of full screen. Which I guess isn't such a big deal as long as I can play stuff in full screen. :3
Reply With Quote
  #1713  
Old 16th March 2015, 06:23 PM
V1del V1del is offline
Project Supporter
Senior Member
 
Join Date: Feb 2012
Posts: 442
Default

I dug out an old m64p 1.5 32bit version I had lying around from the days were glide napalm was only available as a 32bit plugin and it works there, the mupen64 I have around is incompatible with my current libs and I didn't feel like rebuilding, so idk maybe it was really broken at that time, other buttons that may be used for fullscreen are F11 or F10 maybe it used one of these?
Reply With Quote
  #1714  
Old 16th March 2015, 07: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,256
Default

Looking at it more, Alt+F11 does seem to trigger the window mode between full screen and back within X itself, but it doesn't call the plugin spec function "ChangeWindow" within Mupen64, in the same way that clicking the "full screen" button through the Mupen64 0.5 GUI seems to. When I click the full screen button in mupen it does call ChangeWindow and alternate back and forth between my windowing code and my full screen management code, but I have not found a keyboard shortcut to invoke this in the Linux port of mupen.

So I'm glad I found out about the Alt+F11 shortcut, but that only works within the distro itself, not a part of Mupen64's design.
Reply With Quote
  #1715  
Old 16th March 2015, 07:57 PM
oddMLan's Avatar
oddMLan oddMLan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jan 2009
Location: Parappa Town
Posts: 210
Default

It would be nice if other LLE plugins emulated the VI filters.

GLideN64 currently only emulates gamma correction, AFAIK.
By the way, what are the other VI filters besides gamma correction? Reverse dithering, divot filtering (I dunno what that even means lol), etc?
Reply With Quote
  #1716  
Old 16th March 2015, 08:28 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

dragonminded compiled some partial summaries about them in his RCP notes.

The main reason most plugins can't emulate the filters is because they don't even rasterize the image, just draw triangles straight to your own PC video card's frame buffer.
Reply With Quote
  #1717  
Old 16th March 2015, 08:38 PM
oddMLan's Avatar
oddMLan oddMLan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jan 2009
Location: Parappa Town
Posts: 210
Default

Quote:
Originally Posted by HatCat View Post
dragonminded compiled some partial summaries about them in his RCP notes.

The main reason most plugins can't emulate the filters is because they don't even rasterize the image, just draw triangles straight to your own PC video card's frame buffer.
Couldn't them be emulated through shaders?
Reply With Quote
  #1718  
Old 16th March 2015, 09:13 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

Shaders is just an alternative, more challenging method of implementing a later stage of the solution, with less maintainability/readability but performance and GL ES compliance in the payoff. Whether or not you will use shaders is a question that needs answering after the earlier, more significant stage of the problem.

So that doesn't replace the problem, which as I said, is that the plugins draw triangles straight to your own GPU's frame buffer. The VI filters cover the full 640x480 screen...no method of drawing any number of triangles onto the viewport to build Mario's face or whatever is going to filter the entire screen, just that portion of it. So the fundamental issue with them again is that they do not rasterize the image like the RDP does, or even write it as pixel memory to RDRAM so that it can be read as a bitmap and filtered, either through laborous software engineering or OpenGL shaders or whatever else.
Reply With Quote
  #1719  
Old 17th March 2015, 05:56 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

Quote:
Originally Posted by HatCat View Post
That leaves only a few things left to do before releasing.
  • give RDRAM dump files more convenient file names
  • ...
Think I can cross this one off now.

I loaded Mario64 in mupen and went to the File Select screen, then hit "Configure Graphics" 3 times from the menu (on Linux this is the only way to dump RDRAM, as it doesn't have a GUI for the DllConfig to have a button to do it) and it did these 3 RDRAM dump files (in order of dumping):
Code:
RCP_003DAA80_00013016.bin
RCP_0038FA80_00013016.bin
RCP_003B5280_00013016.bin
So for all 3 RDRAM dumps, VI_CONTROL_REG (or VI_STATUS_REG) was set to: 0x00013016, which serves mostly to tell us that the frame buffer is 16 bits per pixel (the low hex figure is 6 which is an even number; if it was an odd number like 7 it would mean it was a 32-bit frame buffer). Therefore, in my program I hit the '4' key to switch to 16-bit-per-pixel disassembly mode (or just enter 4 in the command-line).

The 3DAA80, 38FA80, 3B5280 are all the varying frame buffer starting addresses in RAM. Even though the picture is completely motionless and still (this is just the File Select screen in Mario and I am not moving the hand or anything), the frame buffer is constantly being relocated elsewhere it would seem, and triple-buffered.

Normally I could just drag and drop the RAM dumps into my program, and it would open up the pixel map and I can use the arrow keys to scroll down far enough until I eventually find the frame buffer, but I think it would be easier to just enter VI_ORIGIN_REG as the entry point to the raster data on the command line:
Code:
./PixD RCP_003DAA80_00013016.bin 3DAA80 4 320 240
... where "4" means 2^4 = 16 bits per pixel disassembly mode, 320 is how wide I want the pitch to be, 240 is how many rows of pixels I want my program to show, and "PixD" is the name of my tool I am looking at including with the next release of the plugin.



Now here is an interesting piece of info.
I tried resizing my window (+/- keys) to be 320x240 instead of 320x237, but it's impossible without scrolling up to an earlier address, because 3DAA80 is too late into the RDRAM to contain 320x240 worth of 16-bit pixels. It can only hold 320x237 worth, which means the game really is literally only reading and writing 237 rows of pixels for the native resolution. (Actually most games write 240 and not 237, just that the VI can only DAC 237 of the scanlines causing black bars at the bottom, but since SGI with all their technical knowledge had a hand in the making in this game I guess they literally DMA only 237 rows instead of 240 of them.)
Reply With Quote
  #1720  
Old 19th March 2015, 06:17 PM
ReyVGM ReyVGM is offline
Project Supporter
Senior Member
 
Join Date: Mar 2014
Posts: 212
Default

In another forum someone posted a Donkey Kong 64 glitch:

"I found a weird and unique graphical glitch with this plugin. Somehow it doesn't seem to get the resolution right in the original Donkey Kong arcade in Donkey Kong 64 - for whatever reason, Pauline's head gets cut off. All the other graphics appear to be correct."

Angrylion:


Jabo



Here's a save state, just press "B" to enter.
https://www.sendspace.com/file/zg0fd4

Quote:
Originally Posted by HatCat View Post
Whether by "raw images that supposedly come out of the output hole", you're referring to the filtered or non-filtered screenshots, either way they are possible without emulators. The filtered screenshots were achievable in the same way that dsx recorded that GoldenEye credits video, and the non-filtered screenshots also do not require the invention of emulators. Anything that can copy and write pieces of N64 RDRAM during execution on the real hardware can take them, such as a GameShark Pro. Because of that, I also had help from ExtremeDude2 in getting real N64 screenshots without the VI filters applied to them, independent of relying on emulators.
I see. I did not know that was possible. I always thought capture cards were the only way for old systems and even using those, the screens would always come out filtered (for every system, not just N64).


Quote:
So in other words, VI emulation is only hardware-correct if I emulate some of it but not all of it? The emulator doesn't really need to emulate the VI's real N64 output behavior insofar as the 640x480 resolution itself, only the filters that are meant for that resolution?
Don't take what I said the wrong way. I was pretty much only talking about screenshots. Remember that has been my main interest since day one. For the actual emulation and behavior, you are on the right path.


Quote:
Unless you were just generalizing when you said that, and you were interested only in emulating some aspects of what comes out natively? For example, don't emulate the VI to produce the N64 640x240 or 640x480 resolution, but emulate only the filters and apply them to the wrong resolution. Because that's being inconsistent.

You are right. I mean, I wasn't generalizing, but I guess that's what I would really like, for screenshot purposes. A way for the screenshot engine to apply the filters to a non-standard resolution.

For the actual emulation though, it should be 100% accurate, I'm not debating that.

Quote:
Then you want not what comes out of the output hole but a personal modification of the sequence used to produce it.
Pretty much I suppose.
I'm not asking to modify how the plugin handles the emulation, framebuffer, filter or anything like that. But, just for screenshots, as an additional option (since you are already adding options), could it be possible to add something like that, even if it's not correct behavior?

Last edited by ReyVGM; 19th March 2015 at 06:39 PM.
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 12:36 PM.


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