What's new

Announcement: Cycle-accurate N64 development underway.

OP
MarathonMan

MarathonMan

Emulator Developer
Perhaps you could implement the plugin spec for graphics (and use an existing plugin at the moment) and as you get more and more things done? You remove it?

That's certainly an idea. Though I'm a little bit concerned about how "different" the interface is with my simulator -- it could turn out to be quite the wrapper and make a mess of things.
 

mrmudlord

New member
With all due respect, thats something that sounds reasonable. Have completely *optional* plugin support for video plugins only.

That way, CA people get what they want, the rest get what they want too.
 
OP
MarathonMan

MarathonMan

Emulator Developer
With all due respect, thats something that sounds reasonable. Have completely *optional* plugin support for video plugins only.

That way, CA people get what they want, the rest get what they want too.

I always said that I was going to support RDP plugins. They'll just be static plugins instead of dynamic plugins to prevent dll and so files from flying all over the place.
 

Azimer

Emulator Developer
Moderator
I don't want to single anyone out but can we please stay on topic with MM's project. If the post has nothing to do with MM's developments, perhaps it belong in another forum post instead of here. I'd hate to see people get the ban hammer for being passionate about emulation.

I don't believe there is anything necessarily wrong with plugins. It allows other people to contribute in different ways. However, the problem with the PJ64 spec is that it never updated to fix anything. I had so many problems with audio because I didn't have enough information to emulate the registers accurately. The register emulation belonged in the core, not the plugin.
 
Last edited:

Remote

Active member
Moderator
Agreed, stop rambling about random stuff that doesn't add to this thread. Imagine if Shakespeare had a Mudlord :p


If the plugin specs are static perhaps you could use/interface your core with 1964js?
 

squall_leonhart

The Great Gunblade Wielder
Agreed, stop rambling about random stuff that doesn't add to this thread. Imagine if Shakespeare had a Mudlord
tongue.gif


He does,

see: Hamlet, and The Tempest.

If the plugin specs are static perhaps you could use/interface your core with 1964js?

why would he want to introduce inferiority into his code?. JS engines still operate as restricted virtual machines (and no, im not confusing them with JavaVM) and are not truly dynamic. the current JS Recompilers are static and utilise prediction and predefined jump tables to 'guess' the best possible result.

ugh, not to mention the relative memory requirement ballooning for execution during heap collection.

Looking back in the thread, optimised (and minimal) memory use is one of the goals Marathonman has achieved so far.

Btw, thanks for the warning Remote, i'll treasure it. ;D
 
Last edited:

Remote

Active member
Moderator
Who knows, perhaps he doesn't want to use js in his code, and more importanly, neither of us gets to decide if he does. :p
 
OP
MarathonMan

MarathonMan

Emulator Developer
so..... this is still on track to interpret Rogue squadron at 60fps right ;D

To be honest, I'm not sure. It's hard to put a figure on the performance right now. The VR4300 core is now bouncing around the libultra scheduler, and the RSP manages to execute whatever little code is DMA'd to it... from how things seem so far, I'd like to say that it's going to be playable (I would like to use my own emulator, after all...).

The slowdowns right now are due to the fact that I'm not simulating the caches and have to use the bus to communicate with the RDRAM on a per-cycle basis. I also don't stall on RDRAM. That being said, I can still sift through ~50 million instructions on a powerful machine, so I'm hoping that the IPC of the actual console is somewhere around that range.

EDIT: On the plus side, there won't be any "oh, does it run X game or Y game well?". Really, for a simulator, all games are equally challenging. If it runs one game well, it should run them all well (within reason).
 

Remote

Active member
Moderator
Btw, thanks for the warning Remote, i'll treasure it. ;D

Do it you crybaby! And see how much more interesting the latter part of your reply is compared to what you first wrote:p


I think it's pretty cool with a cycle accurate N64 emulator in progress and my suggestions was mainly that you could use a preexisting plugin to get the visual part while working on the core and then just remove support for it and swap it with a software renderer.
 

squall_leonhart

The Great Gunblade Wielder
Do it you crybaby! And see how much more interesting the latter part of your reply is compared to what you first wrote:p


I think it's pretty cool with a cycle accurate N64 emulator in progress and my suggestions was mainly that you could use a preexisting plugin to get the visual part while working on the core and then just remove support for it and swap it with a software renderer.

well, i was on my way out the door for reals, i just wanted to throw that tidbit out beforehand and save the spot to edit more later :D

(within reason).

like how RARE games completely abused the actual console :p
 
OP
MarathonMan

MarathonMan

Emulator Developer
like how RARE games completely abused the actual console

I was just saying: don't try to compare the game with the lowest known requirements and compare it to Conkers. :teehee:

Whoo hoo. Interrupts being handled well enough for Super Mario 64 to start running its way around libultra. I can even see the OS scheduling different threads (due to the large streams of LWC1/SWC1 during context switches). :)

Couple more unimplemented instructions that are likely causing things to break shortly after that though...
 

didado

New member
I was just saying: don't try to compare the game with the lowest known requirements and compare it to Conkers. :teehee:

Whoo hoo. Interrupts being handled well enough for Super Mario 64 to start running its way around libultra. I can even see the OS scheduling different threads (due to the large streams of LWC1/SWC1 during context switches). :)

Couple more unimplemented instructions that are likely causing things to break shortly after that though...

:bounce::bounce::bouncy::bouncy::bouncy::pacman: .. So exciting to hear with the brain from me that cannot handle all the technical stuff.. :D
 
Last edited:

Nintendo Maniac

New member
Random thought regarding being "polygon accurate" - wouldn't this also allow external textures? I know some fan translations like Sin and Punishment (pre-virtual console) use external textures for english text.
 

zoinkity

New member
Pretty sure it's the only translation that relies entirely on texture packs. That's mostly because they were too lazy to encode and reinsert them (although you can use upsclaed images easier this way). It's not like the compression isn't known either.
 

mrmudlord

New member
Random thought regarding being "polygon accurate" - wouldn't this also allow external textures? I know some fan translations like Sin and Punishment (pre-virtual console) use external textures for english text.

Why do you people care anyway? You people want cycle accuracy, and that includes LLE of the RDP, too.
 

Top