F
I assume your software rendering won't look like this:
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...?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...?
Really?! That'd be great! To be honest, I really don't think a 320x240 polygonal-3D image will look very pretty at all on anything other than an SDTV, and even then it can look like a jaggie-fest at times (Majora's Mask comes to mind).I'll keep it in mind, though!
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:
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.
Even in bsnes, the dictionary example of an accurate LLE emulator?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?
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)
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).Even in bsnes, the dictionary example of an accurate LLE 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.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?
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).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.
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?
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).