Announcement: Cycle-accurate N64 development underway.
- Thread starter MarathonMan
- Start date
OP
MarathonMan
Emulator Developer
- Thread Starter
- #522
Fortunately, "simple 1990s" MIPS pipelines were very pervasive, so a lot of things have been documented in that respect. Right now, I'm just passing along the bare minimum state via variables from stage to stage in order to get emulation to work. I'm not as concerned with all the clocking-related signals yet; but I'll probably use experimentation for that later on when the time comes.
The problem has been correctly implementing the model, with performance in mind, and finding bugs. There are so many edge cases in modeling the actual pipeline that are hard to catch, and I've had a difficult time debugging things.
. I can't wait to try it out!squarepusher2
New member
Permit me to ask - what exactly are those 'platforms not supported by RetroArch'? Unless you mean Windows Mobile/Phone I can't really think of any - and well, who'd want to cover that thing really...
Last edited:
F
Fanatic 64
Guest
PowerPC-based Mac OS
iOS
Solaris
Any DOS
Any UNIX
...Just to name a few non-ancient examples. You can take a look at how many operating systems RetroArch does not support by yourself.
Besides, do we really need to go back to the defending RetroArch argument?
squarepusher2
New member
Err... we support iOS and UNIX just fine. And certain people have ran it on PowerPC-based Macs just fine.
But somehow I doubt PowerPC-based Macs will have the horsepower to run CEN64 very well, as well as any 'DOS-based computer' - so what exactly is your point?
But somehow I doubt PowerPC-based Macs will have the horsepower to run CEN64 very well, as well as any 'DOS-based computer' - so what exactly is your point?
squarepusher2
New member
LOL at DOS being a 'non-ancient example' BTW - we sure we're talking about the same 16-bit OS here with near/far pointer malarky and all sorts of other crap that makes porting to it not really practical unless you specifically target it?
Last edited:
squarepusher2
New member
Problem being there is that RetroArch is not a 'third party library' at all, but merely a 'frontend' (one of many in fact) to a generic API (libretro).
All I ask is that people briefly educate themselves on what it is if they are going to dismiss it out of hand.
Last edited:
Calm down. Nobody is telling that RetroArch is bad or anything...
squarepusher2
New member
Which isn't my point (and you didn't see me getting mad at all in fact - so no need to be telling me to 'calm down') - but here is the point you might be missing all along -
My point is that to call it a 'library' is to - well - not get what it really is - and frankly, forget the name 'RetroArch' for a second and focus instead on Libretro. RetroArch is nothing other than a Libretro player (the official reference implementation done by us). Libretro is an API that allows you to implement a game or an emulator. You then depend on video/audio/input drivers inside the frontend ports to do most of the heavy lifting. This way, you can save yourself time not having to write frontend-specific duties for every single platform out there, and you get all the benefits of the API in general - one single codebase to target all platforms, the ability to get rewinding for free if you implement serializing of savestates properly (and free rollback netplay that way as well) - as well as shader capabilities in the frontends which is second to none.
Unless you are planning to do all that yourself (and I don't see why anybody would at this stage and whether or not most could do the implementations just as well themselves), a libretro port makes a lot of sense - since it is otherwise impossible to treat each platform as first-class citizen. This entire project has been made with the specific intent of taking a heavy weight off a game/emu authors' shoulders and letting him focus on stuff that is important (ie. actual core emulator code) instead of having to screw around with frontend stuff.
We as an emu community should be thinking of working together rather than all of us sticking to our own stuff and reinventing the wheel dozens of times. Which is the sole reason I entered this thread hoping that instead of blank 'not interested' responses I could instead demystify some stuff about what RetroArch/libretro is and isn't. If I can be blamed for anything, it is for caring and *trying* at least to be somewhat cooperative.
Last edited:
OP
MarathonMan
Emulator Developer
- Thread Starter
- #532
My point here is that you don't have to go bash your head against the wall to get the system to compile on Android.
Most N64 emulators are generally bound to Windows or some other platform; CEN64 is like bsnes/higan in that you can link it against libretro, your WM Phone, or even an ARMv8/AArch64-based system, and not have to think about it.
F
Fanatic 64
Guest
To be honest, I actually saw this conflict coming... Although I didn't realize squarepusher2 was in fact Themaister.
squarepusher2
New member
It's amazing really how many times you've been wrong over the course of just one/two pages - this is just the latest instance of that it seems. I am certainly not Themaister.
MarathonMan said:
Not Mupen64 Plus though, which is what we're targeting as a libretro port right now. The other N64 emus indeed will never receive a libretro port (by us at least) just because of the fact that their codebases are so Win32-centric.
F
Fanatic 64
Guest
Well, that you are a developer of RetroArch is what I meant to say, I imagined it would be Themaister because he is the creator.
And again, do we really need to keep fighting about RetroArch in this thread?
squarepusher2
New member
There is no conflict at all - you keep saying there is but there isn't one. All I attempted to do was clear up some misconceptions concerning RetroArch/libretro. I wish MarathonMan the best of luck with the project.
OP
MarathonMan
Emulator Developer
- Thread Starter
- #538
Very slowly. I've been swamped in deadlines as of late.
I've more or less given up at merging in other RDP plugins. They are not designed to fit into a simulator and I was spending more (as little as I have) trying to shoehorn something in than I found beneficial.
I was trying to use angrylion's RDP plugin for PJ64 at first, but it used DirectDraw to blit straight to the screen, instead of copying the frame to RDRAM and allowing the VIF to display the image (if I understand correctly, this is how the console does it). I currently know zilch about Windows-specific things, and I wasn't having a fun time anyways, so I stopped going down that path.
So, instead, I've begun writing a (currently) closed-source simulator for the RDP. The performance, so far, after implementing earlier stages of the RDP is downright awful. There's a ton of signals begin generated and it's hard to correctly produce all those signals in an efficient manner. I haven't had enough time to play with the code to see if it's something that just needs a lot of hand-tuning, or if it's entirely unfeasible. I'm really hoping it's not the latter.
I'll (hopefully?) be getting my hands on a i7-4770 this week, so I'll be able to see what kinds of help Haswell can give in light of performance issues.
Daedalus is already on both PC x86 and PSP MIPS. Also Java, OSX, Linux and Android(ARM, X86, MIPS) are planned. That will be 5 platforms, and sub-platform(Java) on 3 different processors and 6 total ports. We already have 2 and 3 different coders working on three of the others.
The RDP renders into the RDRAM. The VIF never writes to the RDRAM, it reads pixels from the RDRAM, processes them and outputs one color component per VI cycle. The VIF part of the job is represented in my function rdp_update(), which reads pixels from the emulated RDRAM, processes them and writes them into an off-screen DirectDraw surface, which represents the VI coordinate space, or, if you will, TV image coordinate space. There's thus no conceptual difference between the real hardware and my plugin, your claim is unsubstantiated. rdp_update() function implements various filters that the VI applies correctly, but it might not update certain VI registers properly, mainly because the Zilmar's plugin spec doesn't support the required level of synchronization between the RDP and CPU.