N64 Stuff & Pj

[Doomulation]

Oh yeah... there's some stuff that I'd like to know like that...
Anyway,

I wonder... what is actually the frame buffer emulation?
The copy DList and copy buffers?

I think I know some of what they do, at least the copy buffers, which seems to copy data to the memory, used as a cache or something? Some games look in there at certain moments to get some data. One example is Paper Mario I think. The dark rooms, at some of them, it's completly dark, even though using Watt, it's still dark, since I think it is looking for data in the cache.

And when disabling the light, it looks there again for the new graphics, I think. I haven't tested this. Correct me if I'm wrong.

And I think that, using LLE, that would be the same speed as a real n64. However, using the copy buffers, the game runs like at 6 fps even at my computer. So, my guess, is that it would be too slow even on a 3 GHz computer. And so, I guess that the real n64 only copies the buffers when needed. Isn't there any way for Pj to detect this? Or maybe is requires a hack so the emulator knows when to do it.

And there's the advanced options. Like Force Normal Blending. There's no blending errors on the real n64? It must know when to use and not use it. Since, sometimes, some walls gets kindof transparent when using this, but it fixes some texture problems. There is no way for pj of finding out when to use it? Maybe this requires a hack too?

And for the motion blur:
Why is it so hard to emulate? Is it that it can only be emulated in LLE or what? And I know it's not a matter of frame buffer emulation, 'cuz I tested that and it didn't work.

???
Hmmmmmmmm...

 

[mmcoder]

I'm not an N64 emu programmer, but I would guess that the frame buffer emulation is slow because it's being emulated, whereas with the N64 it's always there in hardware. As for it getting fixed, noone was working on PJ64 the last time I checked!

 

[Tesla-Guy]

framebuffer is effects which are using n64 rdram to appear, and the connection between the gfx card and its ram is very slow(pc) so they appear slow, that's what i understood from what lemmy said to me when i asked him. btw jabo's plugin doesn't emulate framebuffer nicely. one example of framebuffer effect is when you press the start button in OOT. the image is supposed to fade away. When you use a certain option in framebuffer, can't remember which, the image changes slightly but it doesn't fade...

 

[Tesla-Guy]

And I think that, using LLE, that would be the same speed as a real n64. However, using the copy buffers, the game runs like at 6 fps even at my computer. So, my guess, is that it would be too slow even on a 3 GHz computer. [/B]

it has nothing to do with the proccessor speed.

 

[Doomulation]

Oh, thx for the info.
The fade-away effect is in Zelda MM too I think?
What about the motion blur then?

 

[Glowstick]

Frame buffer. I believe this is when the nintendo hardware takes a snap shot of the screen and displays it in the level. A good exaple of this is when you are racing in mario kart and you can see the lead racer in the big T.V. before you enter the tunnel on the first level. the emulation is very slow when you have this effect on, I think it is proceser dependant. its not a suported feature on most video cards and the cpu has to take alot of cycles to emulate this feature. So yes a P5 7 ghz would probable be needed to have it work smothly. I just dont get why it slows the whole system down when it copys the frame for zelda? maybe its constantly send frame buffer information. Hey Jabo have you tried to make the frame bufer emulation only kick in right as you press start? Just so when you want to switch to your inventory screen in zelda it would display properly? You could make a new tick under frame buffer emulation....

 

[Doomulation]

Frame buffer. I believe this is when the nintendo hardware takes a snap shot of the screen and displays it in the level. A good exaple of this is when you are racing in mario kart and you can see the lead racer in the big T.V. before you enter the tunnel on the first level. the emulation is very slow when you have this effect on, I think it is proceser dependant. its not a suported feature on most video cards and the cpu has to take alot of cycles to emulate this feature. So yes a P5 7 ghz would probable be needed to have it work smothly. I just dont get why it slows the whole system down when it copys the frame for zelda? maybe its constantly send frame buffer information. Hey Jabo have you tried to make the frame bufer emulation only kick in right as you press start? Just so when you want to switch to your inventory screen in zelda it would display properly? You could make a new tick under frame buffer emulation....

Jabo did never really work with the frame buffer emulation really much. That's why it isn't emulating everything correctly in it. I think that, if n64 emulation is to continue, frame buffer must be emulated! And it must go faster than just 6-7 fps. Dome games requires it.

The odd thing, though, is that is some dark rooms in Paper Mario, when enabling copy buffers, the screen is diaplayed, however, when disabling this effect, the screen is still the same. I mean, it's still light.

 

[Glowstick]

can you send me a save state?? or give a link to one? also do these rooms work when you emulate clear?

 

[Doomulation]

can you send me a save state?? or give a link to one? also do these rooms work when you emulate clear?

Have no states now, sorry.
All my roms works with emulate clear for what I know.
I dunno if I had it set to emulate clear when entering in those rooms, though. Perhaps that's the problem?

 

[Glowstick]

Could be you should have a look see...

 

[Doomulation]

Could be you should have a look see...

Ah, yes, I'll do that.
I'm not sure how the emulate clear works. Hehe...
Oh, do u know why it was made as an option? Is it slower or does it not work in some games?

 

[Glowstick]

I think some games need it because they require frame buffer emulation.. It just emulates a transparent picture to the framebuffer so it doesnt take any processing power.. that way it displays it with out color. just like emulate black and emulate white.

 

[Doomulation]

I think some games need it because they require frame buffer emulation.. It just emulates a transparent picture to the framebuffer so it doesnt take any processing power.. that way it displays it with out color. just like emulate black and emulate white.

Oh, I see...
That's kindof cool. That means that using copy buffers, lens would work, even w/o emulate clear. But it's just hell-of-a slow.
Hmmm... then emulate clear should work with that, too. Perhaps a diffrent result.

....wait, I think I did use emulate clear. In Shy Guy's tow box, when the first black screen came.

Cool!
Hehe... thx for the info.

 

[songoku]

Some Conf

I'd use Set Buffers Black with Zelda, since it seems to solve some menu problems, though I haven't tested a lot yet, so there could be some trouble.
About blending, Geforce MX seems to cause some errors with this, try use "change blending mode..." and see what happens also with some other features enebled (why not, even "force normal blending..."). With Jabo Direct3d 1.3, things seems to go better, at least for the blends, but some other things are not perfect, as Lens of Truth (after all, there must be some reason for doing a new version ).
Well, that's all about what I set usually...
See you

 

[Doomulation]

Re: Some Conf

I'd use Set Buffers Black with Zelda, since it seems to solve some menu problems, though I haven't tested a lot yet, so there could be some trouble.
About blending, Geforce MX seems to cause some errors with this, try use "change blending mode..." and see what happens also with some other features enebled (why not, even "force normal blending..."). With Jabo Direct3d 1.3, things seems to go better, at least for the blends, but some other things are not perfect, as Lens of Truth (after all, there must be some reason for doing a new version ).
Well, that's all about what I set usually...
See you

Well, since emulate clear is just about the same as emulate clear, I think that lens would work in previous versions as well. Just enabling copy buffers. However, it will be slow!

I'll try emulate black. I always check the invalid blending-box. And I have GeForce2 MX400. I'll test those on both versions, to see any changes/effects.

 

[Azimer]

The CFB is a part of RDRAM which is exactly what it says... a Color Frame Buffer. The VI (Video Interface) is responsible for displaying graphics to the screen, and it does this by the data it finds in the CFB. Most N64 games use two CFB, one being a primary and the other being a backbuffer. They swap between each DList. So the first one is being read while the second is being written to. Now HLE emulation doesn't even bother with updating the CFB in RDRAM. This is fine and dandy for 99% of all emulation time. But some games require its use for a texture. Or they might require the depth buffer (also in RDRAM) to be used for information. Both when done in HLE are never updated so the game has graphical errors.

Now the way Jabo emulates them, I am not too sure, but I have a good guess. Emulate Clear emulates the clearing of the CFB and/or the Depth Buffer. The RDP usually does this with a FillRectangle command which I am sure Jabo passes right to clearing RDRAM. Copy DList, I believe just copies from the Video RAM on the graphics card to the RDRAM after each dlist (very slow). Copy Buffers, I am not too sure the difference compared to Copy DList. Set Buffers black just zeros out both Depth Buffer and CFB. I will see if I can get Jabo to add commentary. I am kinda interested myself.

 

[Doomulation]

The CFB is a part of RDRAM which is exactly what it says... a Color Frame Buffer. The VI (Video Interface) is responsible for displaying graphics to the screen, and it does this by the data it finds in the CFB. Most N64 games use two CFB, one being a primary and the other being a backbuffer. They swap between each DList. So the first one is being read while the second is being written to. Now HLE emulation doesn't even bother with updating the CFB in RDRAM. This is fine and dandy for 99% of all emulation time. But some games require its use for a texture. Or they might require the depth buffer (also in RDRAM) to be used for information. Both when done in HLE are never updated so the game has graphical errors.

Now the way Jabo emulates them, I am not too sure, but I have a good guess. Emulate Clear emulates the clearing of the CFB and/or the Depth Buffer. The RDP usually does this with a FillRectangle command which I am sure Jabo passes right to clearing RDRAM. Copy DList, I believe just copies from the Video RAM on the graphics card to the RDRAM after each dlist (very slow). Copy Buffers, I am not too sure the difference compared to Copy DList. Set Buffers black just zeros out both Depth Buffer and CFB. I will see if I can get Jabo to add commentary. I am kinda interested myself.

Hmmm...
Yes, I say it's kinda intresting, too. I just love stuff that has to do with programming
Anyway, I know that copy buffers is *A LOT* slower (I mean it) than copy dlist. The first one goes in ~5 fps, the second in ~25 fps on my computer. I guess that the emulation will never be perfect on this point. It requires a speed-up between the memmory and the graphics-card.
But isn't there already? I mean, games requires communication between memmory and the graphics-card? Doesn't it?
Oh well...

 

[Doomulation]

Now, it's the motion blur.
I know it's not working in zelda mm. However, I've noticed a smiliar effect on paper mario enabling copy buffers and using the last star spirit. It's a kindof motion blur thing. So what is this? Why is the motion blur so hard to emulate? And it seems that the motion blur is being half-emulated in paper mario. Well, maybe it isn't motion blur, but anyway...

 

[Jabo]

Yah azi, that's about the size of it, the biggest problem with emulating the frame buffer in terms of performance is that memory is byte swapped, otherwise you could use a tricky DMA sequence with the nvidia controllers. OpenGL has all sorts of weird ass options for frame buffer control, because, well, it's OpenGL, it's intended to be flexible as hell. Direct3D is marketed at games and stuff.

 

[Smiff]

motion blur is all done in software on the 64, depending how the game devs did it, PJ may or may not reproduce it... thats about the size of it i tink.