What's new

Announcement: Cycle-accurate N64 development underway.

F

Fanatic 64

Guest
I assume your software rendering won't look like this:
 

Attachments

  • softrender.png
    softrender.png
    33.2 KB · Views: 328
OP
MarathonMan

MarathonMan

Emulator Developer
I assume your software rendering won't look like this:

That looks a little grainy from memory. If you're talking about the lower-resolution graphics, then, yes, that is what the software renderer will produce -- same thing that a console would.
 

Nintendo Maniac

New member
If you're talking about the lower-resolution graphics, then, yes, that is what the software renderer will produce -- same thing that a console would.
Unless, you know, it's running in high-res mode (640x480 that is). Maybe such a thing could even be "forced" for games (like Mario 64) that didn't support it...?
 
Last edited:
F

Fanatic 64

Guest
That looks a little grainy from memory. If you're talking about the lower-resolution graphics, then, yes, that is what the software renderer will produce -- same thing that a console would.

I'm not talking about the 320x240 resolution, I'm talking about those blurry and distorted graphics. My real Nintendo 64 produces a clean image, while that is what Jabo Direct3D 8's software renderer produces.

Another example:
 

Attachments

  • softrender2.png
    softrender2.png
    65.7 KB · Views: 294
OP
MarathonMan

MarathonMan

Emulator Developer
I'm not talking about the 320x240 resolution, I'm talking about those blurry and distorted graphics. My real Nintendo 64 produces a clean image, while that is what Jabo Direct3D 8's software renderer produces.

Another example:

That's the whole point of software rasterization! My proposed render will produce pixel for pixel, luma for luma, the same image that a console would produce. If you have one hell of a computer, you should give MAME a go; angrylion already finished an implementation of one.
 
F

Fanatic 64

Guest
That's the whole point of software rasterization! My proposed render will produce pixel for pixel, luma for luma, the same image that a console would produce. If you have one hell of a computer, you should give MAME a go; angrylion already finished an implementation of one.

Thanks, just wanted to clear that doubt. I may give MAME a shoot, my computer (well, my processor, I doubt my integrated graphics chip will matter at all, so...) is decent so I guess I will at least be able to see it run .
 

DaFox

New member
Good to see that you are still active MarathonMan! And nice progress.

I also enjoy the Dolphin way of doing modules.
 

Zuzma

New member
Mame / mess is really cool except the thing is pretty unstable. Even mario 64 will lock up randomly in paintings or inside the castle. Hence the need for more research on the system itself. Actually I hope your findings can help their emulator out too MarathonMan.
 
OP
MarathonMan

MarathonMan

Emulator Developer
Realized (by accident) that I was doing something unbelievably clever and got a flat out ENORMOUS speed boost for some instructions (lqv, lrv, sqv, srv). I should be able to use the technique to wiggle out some performance of the other vector instructions, too. Completed all but a handful of the LWC2/SWC2 opcodes, and optimized them with SSE2/3.

I broke big-endian support pretty bad in the process, though... whoops.

EDIT: Got another (!) two major speedups. I was dual-issuing when I shouldn't have, and caught something else silly. Whoops. Today has been an outstanding today... decreased runtime by somewhere around 40% on the average case. Even my lowly, old Core 2 Duo @ 2GHz is able to run some of the benchmarks at 62.5MHz+ (worst case ones being somewhere around 44MHz). My "new" i7 is able to simulate the RSP at over 90MHz realtime for ALL microbenchmarks. I'm very pleased with this thing. :)
 
Last edited:

didado

New member
Hey nice work :)

I wanted to ask you a question about the input lag on emulators. I always see input lag related problems on nes, snes, sega megadrive and master system consoles but not with a n64 emulator.
Because timing in these games are essential, does it have a impact on your emulator?

There are getting more and more n64 usb controllers and converters (Tomee http://stoneagegamer.com/pcmacusbmoonlightn64controller.aspx , Retrolink etc) and it would be great if these can get the proper support. Xbox360 and Logitech pc controllers are the most common these days so native support would be great to.

Thank you for keeping us up to date. :happy:
 
OP
MarathonMan

MarathonMan

Emulator Developer
I'll look into it later on down the road and see what I can do.

Do you have that controller/do you recommend it? I'm in the market for a USB controller... (N64-style)
 

Nintendo Maniac

New member
I wanted to ask you a question about the input lag on emulators. I always see input lag related problems on nes, snes, sega megadrive and master system consoles
Even in bsnes, the dictionary example of an accurate LLE emulator?

--------------------------------------------------

Anyway, I have two concerns regarding this project, one about the "modules" and the other about saves and/or memory cards.

There is one big thing that I am leery of with dev-controlled plugins - regressions of any sort. In particular, the more accurate Dolphin HLE audio backend will completely replace the current HLE audio in version 4.0. The catch though is that the current HLE audio will play sound at 100% speed whether the game is at 75% or at 150%. The new HLE audio instead plays audio at the same speed as your gamespeed, and due to the dev-controlled modular approach of Dolphin, the user cannot choose to use the old HLE audio module. The old version, in particular, is useful if the user cannot run a game at 100% or they want to, say, play F-Zero GX at 90fps/150%.

My other concern is considerably less minor, but still a concern non-the-less. Even though this is all pretty much being written from scratch, are you considering being compatible with N64 save data from other emulators, such as the SRM and MPK formats? Also, what about the DexDrive .N64 memory card format?
 
Last edited:

didado

New member
Hello all :)

Even in bsnes, the dictionary example of an accurate LLE emulator?

I know Bsnes is accurate and i cant compare with a real SNES because i don't have one. ;)
Nestopia i noticed the lag there and i find it unplayable with vsync off because of the tearing.
But even with tearing it can not be the same as the original.
And for me its logical that there is lag because a emulator needs to translate it from: windows -> emulator -> screen. :teehee:

I hope i am wrong lol :chinese:

I'll look into it later on down the road and see what I can do.

Do you have that controller/do you recommend it? I'm in the market for a USB controller... (N64-style)

I saw this you-tube review of that controller and i'm positive about that analog stick. ;)
"Featuring an unbreakable metal analog stick".


I want to buy 4 of those controllers but i cant say if they are the best USB N64 controllers.
 
Last edited:

Nintendo Maniac

New member
Speaking of controllers, since not all of us use N64 controllers and many of us use gamepads with a SNES-style button-layout, being able to have per-game control settings will pretty much be a requirement...

Oh, and I would love you forever if we could map an N64 controller button to multiple PC keys/buttons.

EDIT: I'll stop there and not turn this into a request topic - I mean we don't even have any retail games running.
 
Last edited:
F

Fanatic 64

Guest
Even in bsnes, the dictionary example of an accurate LLE emulator?
bsnes is a Cycle-Accurate Emulator (like this one), not a Low Level Emulator. They are 2 different things, Low Level Emulation is basically the in-between accuracy of High Level Emulation (Like PJ64) and Cycle-Accurate Emulation (like this emulator).

My other concern is considerably less minor, but still a concern non-the-less. Even though this is all pretty much being written from scratch, are you considering being compatible with N64 save data from other emulators, such as the SRM and MPK formats? Also, what about the DexDrive .N64 memory card format?
As far as I know, Native Saves (like EEPROM, FlashRAM, MemPak, etc) are the same between emulators and the real N64, so they should work with this emulator too.

And is great to hear such optimizations are being made! It seems like even the current High-End processors will be able to run this at a good speed (that thing of MESS requiring a year 2020 computer to run at near-fullspeed can kiss my ***).

P.S. I noticed this thread title currently says "Announcement: Cycle-accurate N64 development underway.", which could lead to believe that you are building a Cycle-Accurate physical replica of a Nintendo 64 or something like that (trough know that you have to ask a moderator if you want to change the thread's title, moderators here are kind enough so you could ask them if you want).
 

Nintendo Maniac

New member
As far as I know, Native Saves (like EEPROM, FlashRAM, MemPak, etc) are the same between emulators and the real N64, so they should work with this emulator too.
Well I had to convert my .N64 DexDrive memory card save dumps to .MPK, and then had to re-save that .MPK via Project64 before I could use said .MPK in Wii64 (which itself is based off of Mupen64).
 
Last edited:
OP
MarathonMan

MarathonMan

Emulator Developer
Even in bsnes, the dictionary example of an accurate LLE emulator?

--------------------------------------------------

Anyway, I have two concerns regarding this project, one about the "modules" and the other about saves and/or memory cards.

There is one big thing that I am leery of with dev-controlled plugins - regressions of any sort. In particular, the more accurate Dolphin HLE audio backend will completely replace the current HLE audio in version 4.0. The catch though is that the current HLE audio will play sound at 100% speed whether the game is at 75% or at 150%. The new HLE audio instead plays audio at the same speed as your gamespeed, and due to the dev-controlled modular approach of Dolphin, the user cannot choose to use the old HLE audio module. The old version, in particular, is useful if the user cannot run a game at 100% or they want to, say, play F-Zero GX at 90fps/150%.

My other concern is considerably less minor, but still a concern non-the-less. Even though this is all pretty much being written from scratch, are you considering being compatible with N64 save data from other emulators, such as the SRM and MPK formats? Also, what about the DexDrive .N64 memory card format?

I won't budge on dev-controlled plugins, sorry. One of the thing that I dislike about modular plugins is that they encourage the community to fork off each other's work. This is good for projects with large developer bases, but not something like N64 emulation given how rare it is to find N64 emulator developers anymore. All my plugins will focus entirely on accuracy first and foremost. That being said, I'm also a performance nut and have been playing some tricks that I haven't seen anyone else in the community hasn't done yet, so hopefully performance isn't a concern. If it is, well, sorry...! Maybe I'll be able to do something about it down the road, but I'm striving for accuracy at the forefront because that's what I set out to do.

Probably won't be too hard; don't see why I couldn't have compatibility with other save states. If you or anyone else knows a little C, all it would involve in a few calls to fread() and fwrite() after looking up how both save states are structured.
 
OP
MarathonMan

MarathonMan

Emulator Developer
bsnes is a Cycle-Accurate Emulator (like this one), not a Low Level Emulator. They are 2 different things, Low Level Emulation is basically the in-between accuracy of High Level Emulation (Like PJ64) and Cycle-Accurate Emulation (like this emulator).


As far as I know, Native Saves (like EEPROM, FlashRAM, MemPak, etc) are the same between emulators and the real N64, so they should work with this emulator too.

And is great to hear such optimizations are being made! It seems like even the current High-End processors will be able to run this at a good speed (that thing of MESS requiring a year 2020 computer to run at near-fullspeed can kiss my ***).

P.S. I noticed this thread title currently says "Announcement: Cycle-accurate N64 development underway.", which could lead to believe that you are building a Cycle-Accurate physical replica of a Nintendo 64 or something like that (trough know that you have to ask a moderator if you want to change the thread's title, moderators here are kind enough so you could ask them if you want).

Heh. I looked at the MESS source and I'm crushing them in performance as far as executing the actual functional units goes. OTOH, my simulator is currently MUCH more accurate than MESS, and I haven't found a way to do dynarec (they do it, IIRC). So it'll be interesting to see how things turn out.

Forum title doesn't really bother me, but anyone can change it if they so please :p
 

Top