Software Render Plugins?
- Thread starter Turtleneck
- Start date
mightyrocket
Banned
Shouldn't there be a kinda bootdisk to load the necessary files of windows which are needed to run N64-emulation only. If someone can make this, it will increase speed very much too!
The Khan Artist
Warrior for God
Kahenraz said:
Mupix. 'Nuff said.
hmm...i have an older notebook, a dell lattitude CPi-A, and sure, it is a low end system, not all of us have a 128mb video card, so a software renderer is hardly a stupid request, and don't lecture about cpu power needed when the point of a software renderer is to allow the runing of an emu on a low-spec system, wich the user's of these systems don't expect the plugin to produce what a hardware accelorated plugin would...this is the ugliest thread i've ever seen, the moderators aught to be more strict than this...and why is it that psx soft gpu's are all over the place, yet not one good n64 soft gpu? the awnser is a matter of attitude toward to scene. we've got spoiled gamers with thier daddy-bought systems, thinking anything less than 2ghz is crap...the developers of emulators don't write thier emu's for 2 or 3 ghz systems, and they'd love to see thier emu's played on everything. i'm sure they'd love to see a n64 emulator on a 200mhz ipaq or on the dreamcast. the deveolpers aren't about running a beautiful console like the n64 caged in a ugly desktop simply because that desktop has a 1 gb of video ram or something crazy...its about the game
Last edited:
OP
Turtleneck
Freelance Cartoonist
- Thread Starter
- #68
lowtek said:
Man, o'man, I've finally found someone who feels the same way as me. That's why I'm finally getting a job this summer, to pay for my senior dues and get a new comp... instead of sitting there being a home hermit waiting for my parents to pay for everything.
I also agree with your views on software emulation, lowtek. Man, if someone would just make a software emulator for N64... It'd make ripping songs so much easier.
Reznor007
New member
Hopefully the MAME guys will get around to N64 hardware soon, since there are a few arcade games that use an N64 motherboard and some of the PCB's have been bought to be dumped.
MAME will low level emulate the RCP, which will make things work basically as good as the real hardware. There won't be a need for each plugin to support any particular ucode that a game might use, as if you really emulate the RCP the core emulation will handle the ucode stuff, and just give the renderer things to draw and a raw audio stream to output. It would definitely make USF stuff easier(and more accurate), as mentioned.
MAME will low level emulate the RCP, which will make things work basically as good as the real hardware. There won't be a need for each plugin to support any particular ucode that a game might use, as if you really emulate the RCP the core emulation will handle the ucode stuff, and just give the renderer things to draw and a raw audio stream to output. It would definitely make USF stuff easier(and more accurate), as mentioned.
Doomulation
?????????????????????????
No, no, no, no, NO! You don't know what you're talking about, so don't come in as if you did know anything!lowtek said:
Hell, even jabo's plugin works on almost all cards. Is it really too much to ask to UPGRADE to even a GF2 mx or something? They're cheap as hell and they work perfecly!
Even if you were to emulate at a lower quality with software, do you think it would matter? NO! It would still be too slow!
If you were to be able to play a software plugin, then you'd need a high-end processor...and guess what, those only come with high-end computers...and guess what (again), high-end computers usually (not always, though) comes with a gfx card that CAN handle, for example, jabo's plugin!
Yeah, right...try rendering a n64 scene ONLY IN SOFTWARE. Let's see if you can run it...
Let me remind you that uHLE ran fast because of hacks (core) and glide (very fast api).
Reznor007 said:
When will you understand that sound is fully emulated at a low level since the first release of Project64 ? As for the gfx being low level emulated and/or software rendered, although most of the things needed to start implementing such thing have been figured out, i see no interest in spending time on this as i know results would be worse than current solutions on current hardware...
Reznor007
New member
Without the RCP fully LLE'd I wouldn't really consider sound LLE since the RCP shares audio tasks with the R4300.
And I fail to see how LLE graphics(with a hardware renderer like PSX emulation) could be worse than HLE graphics, unless you are talking about speed, but with a decent CPU it wouldn't matter much.
And I fail to see how LLE graphics(with a hardware renderer like PSX emulation) could be worse than HLE graphics, unless you are talking about speed, but with a decent CPU it wouldn't matter much.
Reznor007
New member
Doomulation said:
A software renderer for N64 wouldn't be bad at all. MAME has a software Voodoo renderer and games that use it(CarnEvil) work at reasonable speeds(50%) on my computer(AthlonXP 3200+). And according to www.aarongiles.com who happens to be the guy working on that driver, the main bottleneck is the R5000 emulation.
Quick spec comparison:
Midway Seattle hardware:
R5000 at 150-200MHz(differs per game)
ADSP2115 Sound at 16MHz
3dfx Voodoo graphics ~50MHz
N64:
R4300i at 93.75MHz
RCP ~62.5MHz
Turning off the emulation of the Voodoo's bilinear filtering gains basically no speed
Reznor007 said:
RCP=RSP+RDP
RDP is only used for gfx tasks.
If the RCP is used for audio tasks, only the RSP is used, and detecting it's an audio task is very easy. When it's detected, the task is executed at a low level. I don't see how audio can be emulated at a lower level...
LLE graphics could be we worse than HLE because Nintendo has never documented some parts of their custom chips. It can be approximated to work most of the time, but there'll always be some game or another that'll have some glitches.
That's totally different than emulating voodoo hardware that is much simpler and also very well documented since 3dfx has open the source code of their drivers before its end.
And if you don't believe us that the n64 gfx chip is taking a LOT of cpu power, take my software gfx plugin on source forge, add some code to display graphics on windows, compile it and you'll see how slow this thing can be... :/
Doomulation
?????????????????????????
Right, so hacktarux said it all. And at a 3200+ XP processor, it runs at 50%. I mean, HELLO?! 50% at such a fast processor, and for voodoo to boot! Voodoo has always been a damn fast api... how slow do you think the n64 would be?Reznor007 said:A software renderer for N64 wouldn't be bad at all. MAME has a software Voodoo renderer and games that use it(CarnEvil) work at reasonable speeds(50%) on my computer(AthlonXP 3200+). And according to www.aarongiles.com who happens to be the guy working on that driver, the main bottleneck is the R5000 emulation.
Quick spec comparison:
Midway Seattle hardware:
R5000 at 150-200MHz(differs per game)
ADSP2115 Sound at 16MHz
3dfx Voodoo graphics ~50MHz
N64:
R4300i at 93.75MHz
RCP ~62.5MHz
Turning off the emulation of the Voodoo's bilinear filtering gains basically no speed
Reznor007
New member
It's emulating the Voodoo, not using it. And like I said, it's not the Voodoo emulation causing the slowness, it's the R5000 emulation(R5000 is much more powerful than R4xxx). Also, the sound chip takes about 1GHz alone to emulate.
And Voodoo is not an API, Glide is...but that's not the point. It was fast because the hardware was fast, and MAME emulates the chip.
And Voodoo is not an API, Glide is...but that's not the point. It was fast because the hardware was fast, and MAME emulates the chip.
Reznor007
New member
Hacktarux said:
I was under the impression that some aspecs of the sound were still HLE, as many games have odd audio(Rush2049, Hydro Thunder, etc).
Figuring out the undocumented things in the N64 GPU is at least semi-practical as there is at least some documentation around. MAME dev's frequently have to reverse engire entire chips. The current emulation of Sega Model 1 hardware 3d graphics is a result of 3 years of reverse engineering work done with absolutely no documentation, and the V60 CPU core is done from lots of RE work as the documentation for it was destroyed under a court order.
Of course it's always possible. But when you reverse rare arcade hardware, generally you only have to make something like 10 games working. On a console there are hundred games, if you don't have all infos, you approximate some stuffs, you check it with your games, but it's very rare that there's no game programmed in an odd way that has some problem because of your approximation. The RSP lle informations are undocumented and has been reversed by zilmar. It works for audio tasks in most ucodes. But there are still some rare ucodes used in some games that do not work correctly with it.
Don't think there's no approximation in MAME, just by reading aaron's page, you can see there are a lot. It's hard to transpose what have been achieved on one particular hardware to another.
Btw, are they using a dynarec for this r5000 core ? With a dynarec it shouldn't be that much a problem. If they do not want to use dynarec for portability reasons, they can at least implement some kind of opcode cache like i did for mupen64 core, it's much faster, don't have more compatibility problem than the interpreter and is still portable. Maybe they have already implemented such thing ? I'm asking because i'm curious and you seem to follow mame developpemnt closely so maybe you know
Don't think there's no approximation in MAME, just by reading aaron's page, you can see there are a lot. It's hard to transpose what have been achieved on one particular hardware to another.
Btw, are they using a dynarec for this r5000 core ? With a dynarec it shouldn't be that much a problem. If they do not want to use dynarec for portability reasons, they can at least implement some kind of opcode cache like i did for mupen64 core, it's much faster, don't have more compatibility problem than the interpreter and is still portable. Maybe they have already implemented such thing ? I'm asking because i'm curious and you seem to follow mame developpemnt closely so maybe you know
Reznor007
New member
MAME has an interpreter and recompiler for MIPS R4600 and R5000. The speeds I mentioned are on the current recompiler, but as it says on Aaron's site, he is rewriting it for better speed(2x estimated speed). The interpreter is MUCH slower, and I only tested that with Killer Instinct 1/2 arcade (R4600@100MHz).
MAME tries to have as few "hacks" as possible, but sometimes they will be put in temporarily until a more accurate method is possible. The thing about DCS HLE on Aaron's site is actually a speed thing. It's works fine in LLE mode, but he made an HLE version to speed up the driver to make it easier to work on. Other things like MAME supporting CPS2 is done in a hack-ish way by using decrypted data from the board because no one has figured out the actual encryption format. There have been cases where fixes were done that had no apparent effect at all, but were done for accuracy(ex. fixing CPS1/2 layering even though it didn't cause any visual problems).
People have asked MAME devs about N64 stuff before, and one dev (who has worked on N64 for a commercial game company) said that with a recompiler for the 4300 and RCP, and a hardware rasterizer that it could probably be done LLE on about 1.5-2GHz.
MAME tries to have as few "hacks" as possible, but sometimes they will be put in temporarily until a more accurate method is possible. The thing about DCS HLE on Aaron's site is actually a speed thing. It's works fine in LLE mode, but he made an HLE version to speed up the driver to make it easier to work on. Other things like MAME supporting CPS2 is done in a hack-ish way by using decrypted data from the board because no one has figured out the actual encryption format. There have been cases where fixes were done that had no apparent effect at all, but were done for accuracy(ex. fixing CPS1/2 layering even though it didn't cause any visual problems).
People have asked MAME devs about N64 stuff before, and one dev (who has worked on N64 for a commercial game company) said that with a recompiler for the 4300 and RCP, and a hardware rasterizer that it could probably be done LLE on about 1.5-2GHz.
Hacktarux said:Of course it's always possible. But when you reverse rare arcade hardware, generally you only have to make something like 10 games working. On a console there are hundred games, if you don't have all infos, you approximate some stuffs, you check it with your games, but it's very rare that there's no game programmed in an odd way that has some problem because of your approximation. The RSP lle informations are undocumented and has been reversed by zilmar. It works for audio tasks in most ucodes. But there are still some rare ucodes used in some games that do not work correctly with it.
Don't think there's no approximation in MAME, just by reading aaron's page, you can see there are a lot. It's hard to transpose what have been achieved on one particular hardware to another.
Btw, are they using a dynarec for this r5000 core ? With a dynarec it shouldn't be that much a problem. If they do not want to use dynarec for portability reasons, they can at least implement some kind of opcode cache like i did for mupen64 core, it's much faster, don't have more compatibility problem than the interpreter and is still portable. Maybe they have already implemented such thing ? I'm asking because i'm curious and you seem to follow mame developpemnt closely so maybe you know
Have you seen Qemu?
http://fabrice.bellard.free.fr/qemu/