ExtremeDude2
Member
There is also the GC versions of OoT/MM that run at 480p I believe :3, and they can be run in an n64 emu 
Announcement: Cycle-accurate N64 development underway.
- Thread starter MarathonMan
- Start date
I think it is a little too early to speak of 480p or so. We will probably have some technical demos, then maybe (I certainly hope so ) some games, then depending of the code, it will maybe be possible to hack around a little to have a brighter result. Let's not rush things too much. :teehee:
) some games, then depending of the code, it will maybe be possible to hack around a little to have a brighter result. Let's not rush things too much. :teehee:
F
Fanatic 64
Guest
There is also the GC versions of OoT/MM that run at 480p I believe :3, and they can be run in an n64 emu
The Nintendo GameCube emulator is what makes the game run at 640x480 @ 30 FPS. If you run the ROM on Project64 with the internal resolution forced at 640x480 and default framerate, or on a real Nintendo 64, you'll see it internally runs at 320x240 @ 20 FPS.
ExtremeDude2
Member
Aww
OP
MarathonMan
Emulator Developer
- Thread Starter
- #45
It's certainly possible. To be completely honest, most of my reverse engineer and research efforts have been devoted to writing the VR4300 and RSP cores. I still have to delve into the RDP before I make any 'real' claims
Nintendo Maniac
New member
OK, one last question relating to polygonal rendering
Things like anti-aliasing and anisotropic filtering in emulators are done on the Direct3D/OpenGL side of things, no? Therefore they should be able to be easily enabled in a manner similar to any other Direct3D/OpenGL program, correct?
Things like anti-aliasing and anisotropic filtering in emulators are done on the Direct3D/OpenGL side of things, no? Therefore they should be able to be easily enabled in a manner similar to any other Direct3D/OpenGL program, correct?
mrmudlord
New member
How frigging hilarious.
You want LLE/cycle accuracy but want your HLE related shit like antialiasing/anisotropic filtering/hires textures, too?
Oh God....People just don't get it. Software rendering wil make AA impossible, unless you want to murder framerates and such with extra filtering on rendered spans like bumping up internal rendering resolution.
I don't get you cycle accuracy people. You want cycle accuracy but want inaccurate shit like bumped resolutions too? Thank god now someone else has to deal with putting up with the crap....
You want LLE/cycle accuracy but want your HLE related shit like antialiasing/anisotropic filtering/hires textures, too?
Oh God....People just don't get it. Software rendering wil make AA impossible, unless you want to murder framerates and such with extra filtering on rendered spans like bumping up internal rendering resolution.
I don't get you cycle accuracy people. You want cycle accuracy but want inaccurate shit like bumped resolutions too? Thank god now someone else has to deal with putting up with the crap....
Last edited:
And there you go again...
People want to play good old games, if possible in high quality. They are just asking, MarathonMan can do whatever he wants...
Although I don't agree with the delivery method, mudlord has some accurate points. I do believe a hybrid approach can potentially be feasible but not with software. I also don't believe RCP HLE is the demon everyone makes it out to be for compatibility.
Now that I finished reading the thread in its entirety I wish the author good fortune. I'd love to see something new with N64 emulation.
Now that I finished reading the thread in its entirety I wish the author good fortune. I'd love to see something new with N64 emulation.
Last edited:
OP
MarathonMan
Emulator Developer
- Thread Starter
- #50
Thanks, that means a lot coming from someone who's been around the community for a bit, to say the least.
As mudlord said (though maybe a bit harshly), AA/AF/etc. don't make any sense right now. My initial focus is a cycle-accurate, pixel-accurate, etc. emulator and that is hard enough as it is! My initial goal is to emulate the N64 as closely as humanly possible, at whatever cost. At a later time, if there's enough interest, I can add all kinds of goodies (though I, myself, would rather reminiscent and play OOT in 240p!).
Nintendo Maniac
New member
The thing was, I completely forgot about the existence of software rendering. I'm so used to things like Dolphin where software rendering pretty much requires a Sandy/Ivy Bridge i7, so it never crossed my mind that such a thing would be playable at all. Of course I completely forgot that the DeSmuME uses software rendering by default and requires much less CPU, and I would imagine that DS-level polygonal 3D would be much closer to the N64 than the GameCube/Wii (though the DS lacked texture filtering and was a lower resolution...)
So yeah, with software rendering usually AA+AF is automatically out of the question. Hey, we all have our derp moments.
So yeah, with software rendering usually AA+AF is automatically out of the question. Hey, we all have our derp moments.
mrmudlord
New member
Glide64 actually used a hybrid approach to do RDP emulation: some usage of low level command parsing along with the rest being HLE.
Nintendo Maniac
New member
That's what happens when someone *COUGHmeCOUGH* has a derp-moment and makes a comment that makes themself look like a noob; it has the tendency to cause awkward silences.
OP
MarathonMan
Emulator Developer
- Thread Starter
- #55
It's been over a month, any updates?
Lost a pair of drives simultaneously in my RAID-5*, death in the family, proposal deadlines, the holidays, etc. etc., so unfortunately I've made virtually no progress in the last month.
Project isn't dead, though.
* had semi-recent offsite backups, so I only lost a commit or two.
May I suggest using RAID-10 instead?
HDD are cheap, your data aren't... (This sentence would make a great ads, don't you think
?)
OP
MarathonMan
Emulator Developer
- Thread Starter
- #57
Actually, I'm using RAID-Z1 now. RAID-10 is too much overhead for me... I have almost 5TB of data.
OP
MarathonMan
Emulator Developer
- Thread Starter
- #58
So, as I was saying... project isn't dead! :spam:
I made a good deal of progress on the RSP simulator. However, I've found that I'm spending too much time for my liking on tracking down hard-to-find bugs. So, I wrote an assembler for the RSP to assist in test generation and regression testing. Yay.
https://github.com/tstache1/rspasm
Requires yacc/lex/C99. There might be a few bugs, and only assembles a handful of instructions (see writer.h), but the lexer is fully-functional. It'll be done within the week, I hope.
Cheers!
EDIT: jk, finished all the "official" instructions. Short of directives, I now have a full-blown assembler.
I made a good deal of progress on the RSP simulator. However, I've found that I'm spending too much time for my liking on tracking down hard-to-find bugs. So, I wrote an assembler for the RSP to assist in test generation and regression testing. Yay.
https://github.com/tstache1/rspasm
Requires yacc/lex/C99. There might be a few bugs, and only assembles a handful of instructions (see writer.h), but the lexer is fully-functional. It'll be done within the week, I hope.
Cheers!
EDIT: jk, finished all the "official" instructions. Short of directives, I now have a full-blown assembler.
Last edited:
Nintendo Maniac
New member
Would this be the microcode that was included in the official N64 SDK? That is, not the custom stuff like was used in games like Rouge Squadron and World Driver Championship.
EDIT: for some crazy reason I'm not getting notified of replies even though I've selected that option...
F
Fanatic 64
Guest
Correct me if I'm wrong, but isn't reversing microcodes a HLE thing? As far as I know LLE and Cycle-Accurate emulators can emulate those game's GFX without having to reverse the microcodes individually, that's the reason why Jabo, Rice, Glide, etc can't emulate those games but z64 and MESS can.