Mupen64Plus Video

[Exophase]

I wonder why some games would be so much more GPU demanding than others. Is there a lot of alpha blending or testing in Banjo Kazooie? Is it because it's using more complex combiner modes than the other games? If an identity pixel shader is used does the speed improve?

I think that, barring alpha, you should be paying for zero or one texel lookups per pixel (shouldn't be a bottleneck) and color blending handled in the pixel shader. For a given resolution the costs should be fairly constrained regardless of input. Other fill-related bottlenecks are unlikely; you should be able to handle 8x overdraw before the depth comparator rate falls beneath the texel rate.

If it is complex color combining and/or alpha then these are things that should take more fill on a real N64 too, and hopefully the 640x480 games will be lighter on this.

I think 320x240 -> 640x480 is going to be the mode of choice, but I've been pushing for correct aspect ratio options all along.

Failing a 400x240 mode in the LCD, you should be able to use the OMAP3530's display module scalers. There are two of them, and the current driver on the Pandora kernel supports access to them. notaz can tell you more about how to set them up, but I know that he helped zodttd get them working. The setup I've been hoping for is that a scaler is used whenever you try to set the LCD into a resolution different from 800x480. The other scaler would be used for the same thing but for TV out.

The scalers will use more memory bandwidh, so if a lower resolution mode in the LCD really does exist then it'll be preferable for when you really want full 400x240.

 

[fusion_power]

850MHz? Wow, I hope the battery drainage isn't that high on this Settings ^^
Very nice Video. I wonder, how much FPS can be squeezed out of the Pandora with more optimizing.

Are games like GoldenEye and StarFox far more taxing and not likely to work yet, or have they just not been tried? (I have no idea of the requirements on the hardware for games like Banjo/Mario compared to ones like GoldenEye).

Banjo like most Rare games pushed the n64 to it's limits - in fact there's some slow down playing this on a real n64. The follow up to GoldeEye - Perfect Dark is probably the most taxing n64 game

So when Banjo Kazooie works good, the most other N64 games working better/faster?

The scalers will use more memory bandwidh, so if a lower resolution mode in the LCD really does exist then it'll be preferable for when you really want full 400x240.

Is it possible to render N64 Games in 400x240 with correct Aspect Ratio? So a real, unstretched widescreen image is displayed? AFAIK in 3D Games this should be more easy to do.

 

[craigix]

I'll make a video of this new build as soon as it's uploaded.

I've got all evening to do it.

 

[Exophase]

Is it possible to render N64 Games in 400x240 with correct Aspect Ratio? So a real, unstretched widescreen image is displayed? AFAIK in 3D Games this should be more easy to do.

Generally speaking, not really. Anything accomplished is a hack. Granted, N64 emulation as we know it is largely a hack to begin with, but this would be much less of a faithful one. I don't know if the 3D output is really sufficiently high level enough to apply something in the emulator. Chances are that the games themselves would have to be hacked. I don't know if a real N64 can support widescreen output, at least in its internal representation. At least such that the emulator won't be forced to reject it.

 

[Prometheus]

Um.. If you're going to quote that thread, at least quote the relevant part:

My bad. I was quoting that part for the mention of Star Fox 64, and forgot about the GoldenEye stuff. Sorry!

 

[ari64]

Banjo like most Rare games pushed the n64 to it's limits - in fact there's some slow down playing this on a real n64. The follow up to GoldeEye - Perfect Dark is probably the most taxing n64 game

So when Banjo Kazooie works good, the most other N64 games working better/faster?

Banjo Kazooie was one of Rare's first N64 games. It doesn't exercise the N64 hardware as much as their later games, so it's not as difficult to emulate.

 

[borgqueenx]

i actually never heard of this game, but it made me download it seems a kind of game with super mario 64 gameplay.

 

[ndbsolar]

i actually never heard of this game, but it made me download it seems a kind of game with super mario 64 gameplay.

Your kidding right?

 

[Paradox]

i actually never heard of this game, but it made me download it seems a kind of game with super mario 64 gameplay.

Your kidding right?

heard of it, but never played it. looks like a carbon copy of mario

 

[MiniSinisterMinister]

The original N64 rarely achieved a good framerate with most games. Especially some Rare games like Perfect Dark have an awful framrate even on the original hardware and to an extent affecting gameplay, lol. So I guess the emulation on the Pandora can already be called pretty "authentic".

I am just waiting for an 32X and Saturn announcement and I am really happy with the emu support on the Pandora.

 

[skyeyemachine]

i actually never heard of this game, but it made me download it seems a kind of game with super mario 64 gameplay.

Your kidding right?

heard of it, but never played it. looks like a carbon copy of mario

It's really not, if you ask me. Sure, there's a lot of platforming in it and there are other obvious similarities, such as the use of picture frame portals and Jiggies, which behave essentially the same as stars in SM64, but it definitely has its own flavor to it. There's more story and humour, Banjo and Kazooie both have a greater pool of abilities than Mario does (Kazooie can shoot eggs like bullets, for example; there's a greater variety of combat moves; there are sequences where you change into other animals to tackle specific challenges), and there's a greater emphasis on puzzles and unique challenges over raw platforming. I quite enjoyed it when I first played it, more than I did Super Mario 64, although that one's certainly fun as well.

 

[Exophase]

The original N64 rarely achieved a good framerate with most games. Especially some Rare games like Perfect Dark have an awful framrate even on the original hardware and to an extent affecting gameplay, lol. So I guess the emulation on the Pandora can already be called pretty "authentic".

This comes up a lot, but non-fullspeed in emulation is not like choppy framerates on the real thing. If it's not emulating 60, where frames are actually vsync/s (and 50 for PAL) then it won't be running at the correct speed. It could be emulating more instructions per frame than the real N64 would, and it could have better fillrate and whatnot, but if it's not emulating the correct number of frames per second then the in-game timing and music won't be right.

I am just waiting for an 32X and Saturn announcement and I am really happy with the emu support on the Pandora.

32X is probably a given at this point but don't hold your breath on Saturn.

 

[andys]

To avoid bumping the main thread, as it is a bit dated...

Goldeneye was made by Rare. Who pushed the N64 to its limits using custom uCodes

glN64 has support for the Perfect Dark and GoldenEye ucodes. It doesn't support Conkers Bad Fur Day though.

EDIT: While I'm here... Ari64, I hope you don't mind me asking, but does Star Fox 64 run ok, by any chance?

Starfox 64 is one of the better running games. Currently the training mission is about 12-15 fps@500mhz and 20-25 fps@850mhz with no frameskip. Games without many textures seem to have the best performance. Its a pity our sgx driver always converts to a swizzled format, i suspect this is a bottleneck for Mario Kart 64.

Isn't there an extension to upload non-swizzled textures?

Might this improve things somewhat?

GL_Img_Texture_Stream I believe it is (PowerVR newsletter #11)

Not read up about it other than the fact that it exists.

I have no idea if it would be helpful at all.

I guess the alternative is a texture cache - write protect the page the textures are in, and only upload if they are modified? No idea if this is sound, but it might help (unless of course they DMA into local RAM first or something)

 

[Exophase]

I guess the alternative is a texture cache - write protect the page the textures are in, and only upload if they are modified? No idea if this is sound, but it might help (unless of course they DMA into local RAM first or something)

N64 only has 4KB of texture cache, which has to be DMA'd into and obviously will be constantly modified. I don't know if HLE gets around this any - it's possible.

N64 emulators have to employ texture caches anyway to convert formats. Probably the way it works is that any time something is recognized as a "new texture" operation the texture is hashed in some fashion and checked to see if it exists in the cache, if not it's added. So long as there is definitely such an operation writes don't have to be tracked. Otherwise, the DMAs themselves would have to contribute towards this. It'd be better if the driver accepted pre-swizzled textures, since then that could be incorporated into converting the texture to a cached format. Uploading non-swizzled textures has its own disadvantages, but could be a fallback if the game is detected as constantly generating new textures. This will always have a speed hit though.

I can't imagine Mario Kart 64 is doing something that awful when my Celeron 400 could do a pretty good job emulating it with only a TNT1.

 

[Adventus]

I think 320x240 -> 640x480 is going to be the mode of choice, but I've been pushing for correct aspect ratio options all along.

Don't worry, ALL the options are already available. You can render at any resolution supported by the SGX and upscale to any window dimension. In my config file there's options like: framebuffer enable, framebuffer width, framebuffer height, framebuffer bilinear, window width, window height, window xpos, window ypos. As well as options to disable different rendering paths (like alpha test, fog, clipping, etc) and a few rdp clamping modes. I just happen to like the widescreen modes.

Isn't there an extension to upload non-swizzled textures?
Might this improve things somewhat?
GL_Img_Texture_Stream I believe it is (PowerVR newsletter #11)
Not read up about it other than the fact that it exists.

Yeah, I'm aware of this extension, I posted about it in the Development forum. I'm pretty sure it's not implemented in the drivers we're working on. I'll put some effort into adding it when it's supported but it'll be a config option, most games would probably work better without it because of the texture caching.

N64 emulators have to employ texture caches anyway to convert formats. Probably the way it works is that any time something is recognized as a "new texture" operation the texture is hashed in some fashion and checked to see if it exists in the cache, if not it's added. So long as there is definitely such an operation writes don't have to be tracked. Otherwise, the DMAs themselves would have to contribute towards this. It'd be better if the driver accepted pre-swizzled textures, since then that could be incorporated into converting the texture to a cached format. Uploading non-swizzled textures has its own disadvantages, but could be a fallback if the game is detected as constantly generating new textures. This will always have a speed hit though.

Precisely. It uses a texture cache which generates a CRC of the data, it works pretty well in my experience. The textures are stored in a strange memory layout on the N64 (and they sometimes have palletes, etc), so a bit of time will always be spent converting them.

I think that, barring alpha, you should be paying for zero or one texel lookups per pixel (shouldn't be a bottleneck) and color blending handled in the pixel shader. For a given resolution the costs should be fairly constrained regardless of input. Other fill-related bottlenecks are unlikely; you should be able to handle 8x overdraw before the depth comparator rate falls beneath the texel rate.

The combiners actually support 2 texture look ups per pixel, Banjo Kazooie often uses this mode with 2 cycle combiners. There is a fair bit of alpha and alpha testing in banjo kazooie. I've also been offloading stuff into the vertex shader to make the rendering more streamlined, so lower resolutions might free up some more time for it to do its stuff. It might be a good idea to have say 3 different vertex shaders aswell so i don't have to branch in them for the different rendering types (ie triangles vs texrects, fog).

I can't imagine Mario Kart 64 is doing something that awful when my Celeron 400 could do a pretty good job emulating it with only a TNT1.

Yeah I'm not so sure myself, but there's a fair bit more texture uploads (consistently about 2 per frame) than other games. Its either that or my texture rectangle rendering is much slower than my triangle rendering (quite possible, theres zero batching occuring on rectangles), but its hard to tell because the texture probably isn't swizzled until its actually used. Texture uploads are slow though, I was uploading a 402x320 texture each frame on an iphone 3GS and i couldn't get more than ~25 fps.

 

[Exophase]

Yeah I'm not so sure myself, but there's a fair bit more texture uploads (consistently about 2 per frame) than other games. Its either that or my texture rectangle rendering is much slower than my triangle rendering (quite possible, theres zero batching occuring on rectangles), but its hard to tell because the texture probably isn't swizzled until its actually used. Texture uploads are slow though, I was uploading a 402x320 texture each frame on an iphone 3GS and i couldn't get more than ~25 fps.

These textures are all more or less never before seen, right? I wonder where it'd be getting all this fresh texture data from.

 

[Adventus]

Yeah I'm not so sure myself, but there's a fair bit more texture uploads (consistently about 2 per frame) than other games. Its either that or my texture rectangle rendering is much slower than my triangle rendering (quite possible, theres zero batching occuring on rectangles), but its hard to tell because the texture probably isn't swizzled until its actually used. Texture uploads are slow though, I was uploading a 402x320 texture each frame on an iphone 3GS and i couldn't get more than ~25 fps.

These textures are all more or less never before seen, right? I wonder where it'd be getting all this fresh texture data from.

Yeah i don't think the cache is failing, it does improve over time. You have a different texture for each orientation for each character, but i also have a suspicion that there's a set of mipmap textures. It could easily be 16 orientations x 4 mipmaps x 8 characters = 512.

 

[Dead1nside]

I'm really pleased that a game that by all accounts is one of the harder to emulate is playing so well already. Everyone who is working on this are doing such a tremendous job - thank you.

I don't know the theoretical or likely limits of the emulation capability of the N64 but I'm pleased that there are reports that the Pandora can overclock quite well, hopefully without putting too much strain on the lifespan of the Pandora.

Thanks again, look forward to the next video

 

[Exophase]

I'm really pleased that a game that by all accounts is one of the harder to emulate is playing so well already. Everyone who is working on this are doing such a tremendous job - thank you.

I don't know the theoretical or likely limits of the emulation capability of the N64 but I'm pleased that there are reports that the Pandora can overclock quite well, hopefully without putting too much strain on the lifespan of the Pandora.

Thanks again, look forward to the next video

According to Ari64 it's one of the easier to emulate, I think you should be listening to him above others.

 

[Dead1nside]

According to Ari64 it's one of the easier to emulate, I think you should be listening to him above others.

Oh, I don't read the developer thread much, of course you're right the developers are the ones to be listening to, I just thought they said that in general the Rare games pushed the N64 the hardest and presumably would be the hardest to emulate.