What's new

Announcement: Cycle-accurate N64 development underway.

DETOMINE

New member
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:
 
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 :D

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.
 
OP
MarathonMan

MarathonMan

Emulator Developer
Ok, on a related note then, what about the N64's integrated "hi-res" 640x480 mode? Games like World Driver Championship and Perfect Dark have such a mode as an in-game option, so proper emulation would require this function to emulated anyway. Would it not be a stretch to suggest that such a thing could be forced to run at all times as stop-gap to polygonal resolution independence?

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?
 

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....
 
Last edited:

DETOMINE

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....

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...
 

Azimer

Emulator Developer
Moderator
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.
 
Last edited:
OP
MarathonMan

MarathonMan

Emulator Developer
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.

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. :p
 

mrmudlord

New member
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.

Glide64 actually used a hybrid approach to do RDP emulation: some usage of low level command parsing along with the rest being HLE.
 
OP
MarathonMan

MarathonMan

Emulator Developer
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.
 
OP
MarathonMan

MarathonMan

Emulator Developer
Actually, I'm using RAID-Z1 now. RAID-10 is too much overhead for me... I have almost 5TB of data.
 
OP
MarathonMan

MarathonMan

Emulator Developer
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. :)
 
Last edited:

Nintendo Maniac

New member
finished all the "official" instructions.
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
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...

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.
 

Top