GoldenEye 007 Nintendo 64 Community, GoldenEye X, Nintendo 64 Games Discussion

[D1Hazel]

I want to start a project to optimize an emulator for Perfect Dark. I need an open-source emulator to start this off, and it has to play all the modes well enough (my main goal is to increase speed, not compatibility. It should play well enough as-is). It also needs to support decent multiplayer over internet (or else no one will want to use it). I want to eventually have it dynamically rebuild a temporary ROM based on the ROM name and a folder (of the same name as the ROM) with textures and levels in it, but that would be long down the road.

I also need to know why GE and Perfect Dark are so slow. I know they were wringing all the performance they could out of them, but I need specifics. Also, things that GE and PD don't use would be useful. Anything I could remove from the emulator without it affecting PD (GE compatibility doesn't really matter, thanks to GE:X ) would probably save a few if()s, which would at least make the code less complex and might save a few CPU cycles. Anything GE doesn't use that doesn't have an option in whatever emulator is picked could have more major (though likely not magic or even major) performance increases.

[zoinkity]

The primary reason they play slow under emulation is that graphics emulation is inherrently slow. The issue is that you have a complicated dedicated piece of programmable hardware that is poorly documented, and then you need to emulate it on another piece of dedicated video hardware.

Software-level processing is required. In particular any N64 game that uses the frame buffer requires a layer of emulation to handle it. Mind you, this is also presuming high-level emulation of the RSP. Low-level accurate emulation runs slowly regardless of game on any setup.

Normal processing really isn't a concern. Under ordinary gameplay, smoke generation, effect generation (ie. gunshots), and geometry load are the only three slowdown factors--assuming you don't have some ungodly loop running in the background. For instance, trying to look up a player's position when you're off the AI set table will cause it to scan all reserved presets until it triangulates your position, then scan them again to try to guess a path; it would do this indefinately until reaching the point. Another good one is rewriting the monitors or action blocks without putting into account breaks in the code.
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!

[D1Hazel]

So would we see a huge speed up if we "hijacked" the emulation so that the emulator rather than the emulation drew the things to screen?

[EternallyAries]

Well if you do some how find a way to make this emulator.

You need to make new plugins since with this new emulator wont work well at all with a only working perfect dark emulator.

It will be a pain to make.

All i say best to luck for you.
_________________
There totally nothing to read here.

[acceptable67]

You can make it from Visual Basic. I'd love to, but I'm not sure on how to run the .ROM, ect, to make it visual.
_________________

Rare wrote:

Perfect Dark Forever.