Menu
What's new
By:
Filters

Basic Emulation Question

ShadowTH

ShadowTH

It's cold here...
Just a simple question.
See
The emulator of X videogame acts as an interpreter of the rom, reproducing the same commands as the console and showing you the result of the interpretation of the rom. That is emulation right?

As far as I know, the videogame acts as the same with any game you play, no games change the hardware.
So, see, PJ 64 runs, for example, Mario Kart perfectly. If it runs this game okay, why other games do not run, since running one game or other the hardware and the functions keep being the same?

What is the reason?
 
fivefeet8

fivefeet8

-= Clark Kent -X- =-
All games on any system doesn't use the same routines or programs.. They are unique and each adds it's own ways to use the hardware.. Emulators are also not perfect.. Plus, even games that look perfectly emulated, aren't really perfect yet.. ;)

Hardware functions are the same, but the way the software uses them are quite different sometimes..
 
OP
ShadowTH

ShadowTH

It's cold here...
so a perfect emulator would be an interpreter that can perform any routine or functions that X game demands?

Because, for example, it is noted that, PJ64 doesnt run any Lucasarts game perfectly... All of them are buggy or dont even run. Its like a Lucasarts programming way that differs from the others and require some thigs that the others dont?
 
Teamz

Teamz

J'aime tes seins
some games use propriety chip to display graphics and it is not related to the CPU
 
OP
ShadowTH

ShadowTH

It's cold here...
but some emulators like zsnes emulate games like SF and SMW2 that use additional chips without majors problems, and as far as i know, there arent much 64 carts with additional chips around...
 
zorbid

zorbid

New member
The main proble is the emulation of the grapic chip, the RSP/RDP. The current processors are too slow to emulate it in low level (= reproduce it's exact behaviour). What is nice is that most N64 games share the same way of using the chip (microcodes or ucode). If you understand how the microcode works, you can pick the display information and translate it into D3D/OpenGL/Glide and use a PC 3d accelerator to generate the graphics. This allows you to use the kewl features of your 3D card, such as higher resolutions, FSAA, anisotropic filtering, and so on...

The problem is that some games have special microcodes that haven't been figured yet, and the games that use these won't work untill someone (fairly competent) takes the time to understand them.
 
OP
ShadowTH

ShadowTH

It's cold here...
Hummm
Now it makes more sense!
Thanks! ;)

And Zorbid: LOOK THERE! A THREE HEADED MONKEY!
 
C

Cobra95

New member
Current systems cannot emulate an N64 at full speed through a code-by-code interpreter--which is what emulators of 16-bit systems do. N64 emulators must rely on high-level emulation, which assumes that games developers are going to use the high-level rendering API of the N64 hardware, which can be mapped (more or less) to a standard API of 3D hardware on modern PCs, typically Direct3D or OpenGL. Even this is too simplistic an explanation, but I hope it helps you to reach the correct mindset to understand the problem.
 
OP
ShadowTH

ShadowTH

It's cold here...
Ahnnn Dont wanna be a pain in the ass, but your explanation was way too technical to me with my zero programmations and notions of programations skills! :)
 
C

Cobra95

New member
API: Application Programming Interface. It's a canned set of functionality which works in a standard way across all hardware which conforms to that API. Hence, your 3D graphics application should work on, for example, both NVidia Geforce cards and ATi Radeon cards if you use the Direct3D API.
 
OP
ShadowTH

ShadowTH

It's cold here...
Ahh I see!
So, instead of making an emulator that in wich game, X game is compatible, and Y game that was compatible in an early version is not anymore, isnt it kinda smarter to do a compilation to work just with X game? And so several compilations, one for each game?
 
C

Cobra95

New member
:? I'm confused. Are you asking if it would be better to compile a different version of the emulator for each game? That would be a development nightmare.
 
OP
ShadowTH

ShadowTH

It's cold here...
Hum
Why is that?
Get the source of the current version, 1.5
Doesn''t the developers test almost every game? And try to correct all the bugs that this game has?
So, grab the source, work just for example on Rogue Squadron.
Make it 100% and close the source and release PJ RS Version.
Correct all the bugs in OoT and release the PJ OoT Version.
Something like bleemcast....
Most games woudn''t need that, and just do that with, like, the 50 most popular games! PJ as far as I know, has more then 2 years... All this time they could have done this and I guess the results would be better...
 
C

Cobra95

New member
Because you would have multiple projects, each with its own history of revisions and bug fixes. Even if you use conditional compilation flags, it would multiply the effort. Trust me: that isn't practical. It's much more sane to implement special behavior for particular games all under the same project, and all compiled together.
 
OP
ShadowTH

ShadowTH

It's cold here...
but and those bugs that appear in new versions and didnt happen in early versions?
like, THPS 3 runs much better on 1.4 then 1.5...
 
C

Cobra95

New member
Bugs can be introduced at any time. Sometimes the author might do something that fixes a problem in one area while inadvertently causing a problem somewhere else. This kind of sophisticated programming is definitely not for the faint of heart. Developers are human, and can't foresee all the consequences of their revisions. My suggestion is that you keep several consecutive versions of each emulator you use, to handle cases like the one you mentioned. But the goal, of course, is to handle all games well in the latest and greatest public release.
 
You must log in or register to reply here.

Top