Beta Mupen64Plus

[fusion_power]

Currently... you can't.

Thats sad.

Open the graphics settings in the menu, edit

framebuffer width=...the width of the resolution you want to set...
framebuffer height=...the height of the resolution you want to set...

framebuffer should be enabled (framebuffer enable=1) of course but thats the default now (otherwise the OpenGLES driver hangs in LOZ:OOT and other games). E.g.

framebuffer width=400
framebuffer height=240

(default is 800 x 480)

The original N64 had a resolution of 256 x 224, 320 x 240 and 640 x 480, depending on the game)

You can also set it in the 'per-rom' settings.

I'll see what can be done regarding better frameskip.

I also tried to get a original 4:3 aspect ratio so Mario Isn't that fat like in full screen stretch. I simply changesd the resolution in the text config file to 640x480. But this made the 4:3 screen aligned to the left side and kept artifacts of the Emulator Menus onto the right. Does your method set the 4:3 in center and without any artifacts outside of the game screen Area? Would be cool if there were pre-sets for each game, I don't know the best values and correct resolutions for all of the N64 games (this also would be helpful for the rest of the per-game settings because I have no clue what is the best cfg for each game. ^^"" )

 

[bzfrank]

I think currently thats not possible. Beside - I don't think that each game should run at its 'native' resolution, on an analog TV screen long ago it was ok but not on a LCD screen. Rescaling introduces artefacts.

For a 3D system like the N64 its not a problem to scale the output to some other resolution that fits the pandora screen better. The only reason I can see is to speed up things (the smaller the framebuffer, the faster it can be drawn, especially when it comes to texture fill), to do so just keep the aspect ratio of the pandora as for the framebuffer.

The framebuffer setting can also be in gles2n64rom.conf - set for each game separately.

 

[fusion_power]

That's what i've thought. Smaller resolution makes game faster.
Is Mario64 a 320x240 game? So I could set it to this res and double it up to full screen (4:3), should make it faster than in real 640x480, at least onto the PC it always boosts 3D games when lowering the resolution.
How should a config look to have this values? I don't have much experience yet with Mupen. ^^"

Does activating the N64 fog actualy makes the game faster? And costs Anti Aliasing more speed in combination with a lower res than having higher res without AA? Is AA actualy available onto the Pandora?

 

[Esn]

Well, yes, there would be two reasons:
1) to speed up emulation
2) to make the experience authentic

I do know that not all of the N64's games were 3D, and some games were never meant to be played at a widescreen aspect ratio, as in they have messed up elements because of the new aspect ratio.

So yes, it would be nice if there was an option to have the original resolution and aspect ratio (or just the original aspect ratio), with black bars on the sides.

That's one thing that I think would help - the other is, of course, better frameskip, and I wish you luck with that! That would also be really helpful.

 

[bzfrank]

Just implemented a different frameskip algorithm. It now does not just drop a frame now and then but changes the frame render rate dynamically if it encounters a lag in targetFPS. As soon as the game speeds up again the frame render rate restored again. Seems to work fine so far but needs more testing.

 

[Esn]

Just implemented a different frameskip algorithm. It now does not just drop a frame now and then but changes the frame render rate dynamically if it encounters a lag in targetFPS. As soon as the game speeds up again the frame render rate restored again. Seems to work fine so far but needs more testing.

Thanks! If it indeed works well, this would make many more games playable.

 

[fusion_power]

every speedup helps.
I tested Mario 64 in 400x240 res and it seems to run better. Now I have to find out how to activate some kind of anti aliasing or at least more blurry stuff to hide the rough edges.
I also tested Lylat Wars, it was marked as running good in the table. But it is far away from Full Speed, even with Overclocking. There is no "smooth" gaming possible. I played this game to death on the N64 so I know how it should feel. But at the moment, even with OC it is not really playable. "Full Speed" for me means it, no frameskip, no Slowdowns, no delay. You really need timing and exact movement later in the game so frameskip is no option. But I do more setting experiments, maybe I can get more out of the Pandora. I want sound so I play with it of course. I hope this has no impact in FPS. ^^

 

[Esn]

You really need timing and exact movement later in the game so frameskip is no option.

If the automatic frameskip is good, it will feel exactly like fullspeed. I know because I played the Sonic games to death through DrMD on the GP32, which had excellent frameskip. Even when the framespeed slowed down to 12fps, controls were tight and the music never skipped. I really don't mind skipped frames as long as it means that the game itself doesn't stutter or slow down; I would count that as fullspeed.

 

[bzfrank]

Almost, to avoid 'oscillation' I needed to delay the application of the frameskip a few frames. So when a complex scene starts it takes a few frames until it slowly kicks in. Otherwise the frame rate would vary all the time making smooth game play impossible (most noticeable in racing games). The same is true when the complexity eases, it now takes a bit until frame rate changes back.

 

[Esn]

Um... what exactly is wrong with oscillation? (if I'm understanding this right)

Yes, the frame rate varied all the time in DrMD, and that was perfectly fine. If it is "delayed", I imagine the speed of the game itself would suffer, rather than just the framerate... and that's a lot less forgivable.

I'd like the soundtrack to be fullspeed, with not a single skip or slowdown. That's the surest way to tell if a game is running smoothly.

 

[fusion_power]

You really need timing and exact movement later in the game so frameskip is no option.

If the automatic frameskip is good, it will feel exactly like fullspeed. I know because I played the Sonic games to death through DrMD on the GP32, which had excellent frameskip. Even when the framespeed slowed down to 12fps, controls were tight and the music never skipped. I really don't mind skipped frames as long as it means that the game itself doesn't stutter or slow down; I would count that as fullspeed.

As long as the control input has no delay I'm fine with Frameskip.
But better than Frameskip is no Frameskip. ^^ I mean, we have a 600+ MHz OMAP Chip, we have a fat SGX unit (look what SGX can do on a crappy iPhone), we have DSP an NEON and skilled coders, what should prevent N64 emulation to be full Speed onto the Pandora? I played Ultra HLE onto an 266MHz PC ages ago and it worked. All I had else was an VooDoo2 GFX Card with only 8MB VRAM.

 

[Exophase]

I played Ultra HLE onto an 266MHz PC ages ago and it worked. All I had else was an VooDoo2 GFX Card with only 8MB VRAM.

UltraHLE was also a lot less compatible. But the real advantage it had (and the biggest impediment to performance on Pandora) is the very light-weight API Glide gave you, which I guess was a close enough match to the N64 feature set UltraHLE emulated.

glN64 spends a lot of time in the OpenGL ES 2 drivers. They're optimized for modern games which aren't written with emulating N64 features in mind. Cheap state changes for N64 turn into expensive state changes on Pandora. I'm sure a lot of it is related to how the drivers were written but some of it could also be fundamental to the TBDR style graphics. For instance, alpha test can slowdown rendering throughput by 2x and is currently enabled for all textured primitives.

Almost, to avoid 'oscillation' I needed to delay the application of the frameskip a few frames. So when a complex scene starts it takes a few frames until it slowly kicks in. Otherwise the frame rate would vary all the time making smooth game play impossible (most noticeable in racing games). The same is true when the complexity eases, it now takes a bit until frame rate changes back.

IMO buffering a frame or two in advance is good for allowing some low-pass filtering of frame skip (so the buffer will absorb a single frame or two being off).. but of course that introduces more input latency so if done should only be optional.. the audio in isolation can also be buffered at an optional rate just to avoid skips (sorry if it's already variable, I have no idea)

 

[Esn]

IMO buffering a frame or two in advance is good for allowing some low-pass filtering of frame skip (so the buffer will absorb a single frame or two being off).. but of course that introduces more input latency so if done should only be optional.. the audio in isolation can also be buffered at an optional rate just to avoid skips (sorry if it's already variable, I have no idea)

I don't think it is. But I'd rather the underlying control of the game itself was at the correct speed and with no input delay, at the cost of uneven framerates.

 

[Exophase]

I don't think it is. But I'd rather the underlying control of the game itself was at the correct speed and with no input delay, at the cost of uneven framerates.

... I said it's good for hiding speed dips, then went on to say that not everyone would want it so it should be optional, what are you disagreeing with exactly?

 

[Esn]

No idea.

I just know that I didn't notice any delay in controls as the price for accurate speed on the GP32. Maybe it was there but really minor.

 

[HackModford]

You really need timing and exact movement later in the game so frameskip is no option.

If the automatic frameskip is good, it will feel exactly like fullspeed. I know because I played the Sonic games to death through DrMD on the GP32, which had excellent frameskip. Even when the framespeed slowed down to 12fps, controls were tight and the music never skipped. I really don't mind skipped frames as long as it means that the game itself doesn't stutter or slow down; I would count that as fullspeed.

I agree... better frameskip atleast

 

[Exophase]

No idea.

I just know that I didn't notice any delay in controls as the price for accurate speed on the GP32. Maybe it was there but really minor.

And I'm sure it didn't do any excessive buffering or frameskip smoothing.. But here's the thing, old 2D games typically have pretty stable CPU and graphics utilization. In the case of Genesis emulation graphics utilization was probably the biggest driver for frame time. The active layers and layer settings wouldn't change much and the number of active sprites wouldn't usually fluctuate dramatically (ie, wouldn't change by 100 between frames). It's not like a 3D game where the level of scene complexity can change a lot as the camera moves around.

Auto frameskip is great here over static frameskip not just because it's adaptive over long term changes like playing different levels, but because it creates a non-integer average frameskip over high-frequencies, that you normally can't specify with manual frameskip. This sort of averaging happens over a threshold that's still too fast to be really obvious when taken down from 60Hz. But with N64 games you're usually starting at 30Hz or even 20Hz, so each skipped frame has a bigger visual impact and instability is more obvious.

 

[Esn]

Thanks for the explanation, Exophase. Also, I know this is a bit out-of-topic, but what about automatic frameskip in emulators of computers such as DOSBox? Most of the games are also 2D, but I've heard people say that auto-frameskip there is a lot more difficult than in 16-bit consoles for some reason (to the extent that nobody has ever implemented it).

 

[bzfrank]

Exophase, you explained it well, thanks!

Esn, don't worry - you can configure things if you don't like the defaults. There will be additional settings in the config that control auto frameskip behavour. How fast it kicks in, the max skip factor, etc.

 

[Exophase]

Thanks for the explanation, Exophase. Also, I know this is a bit out-of-topic, but what about automatic frameskip in emulators of computers such as DOSBox? Most of the games are also 2D, but I've heard people say that auto-frameskip there is a lot more difficult than in 16-bit consoles for some reason (to the extent that nobody has ever implemented it).

How beneficial frameskip is depends on how much work is done per frame (preferably autonomously) entirely by the GPU hardware, ie hardware acceleration. Old 2D PCs games had very little in the way of hardware acceleration. You had a framebuffer which presented a single layer and the ability to change its offset per-pixel for fast scrolling without having to redraw the screen. But it was up to the CPU to fill in the new background graphics as they appeared, and draw in sprites by first drawing background over where the sprites were and then drawing the sprite manually at a new location.

So it's probably not that you can't do frameskip, but that you'd only be skipping the redrawing of a flat framebuffer, which probably isn't that expensive. You wouldn't be able to skip all of the stuff that the CPU is tightly integrated in performing.