Could you try these controls and let me know how they work out?
I don't think using the keyboard for A/B would be a good idea. The keyboard is more spongy than normal buttons. Maybe mapping the C buttons to the keyboard would be better, since there not used so often.
Actually the hinge is normal. It has 2 detents one open and one closed as that is all that is available in that size. Pretend like it is one of those slide open phones where the screen and keyboard are always parallel. The DS lite has an extra detent position but that was custom for them and the hinge MFG would not sell that version to us (Nintendo owns it). When in use you will find that it is most useable with the lid fully open anyway. You can still open 90 degrees and sit on a desk to watch movies and such but if you pick it up and flap it around like a Wii controller it will move.
Hmmm, thats a bit disappointing, i'm not surprised by it having two dents but i thought the hinge would be stiffer so it could rest at 45 degrees or something. I might have to mod it
. Maybe a thin bit of rubber between the joints will increase the friction enough.
Also it's been mentioned before with another Mupen64plus video but are we currently rendering at the game's proper resolution or are we exceeding it? If so will cutting it back help more?
We are exceeding it in most cases. The n64 does support 640x480 resolution (or there abouts), but it was pretty much only used for text and HUDs.... Most games rendered 3d at 320x240.
Adventus: Can you tell wether optimized graphics would make the emulator faster? I would be working on that then. However, if the SGX is almost idle and only the CPU is responsible for the slow-downs I wouldn't waste my time as I don't have much knowledge about the N64 hardware (besides the fact that it also uses an MIPS CPU)
Basically all games seem to be CPU limited, the only game that I've tested that seems to run significantly faster at lower resolution is Banjo Kazooie. About 50% of the time is spent in the gfx plugin transforming vertices and performing draw calls. One problem is that the N64 had lower level access to its gpu hardware and hence there is very little batching occurring. Apart from shifting more work to the vertex shader (or the OGL driver magically getting faster), The other major optimisation i can think of is a reordering backend that captured all the vertices and states and at the end of the frame reordered them so there were less draw calls / state changes. This would require alot of work and might end in a net loss.
1) Does the gles plug in use hardware acceleration or is it all rendered in software?
2) Has sound been tried how much of a performance hit does sound have?
3) Have other clock rates been tried and what are the effects on performance?
4) Is there any obvious or low hanging fruit in optimization that is not yet implemented?
5) Is the direction of the emulation development more towards speed or compatibility?
1. It is hardware accelerated, NEON is used for transformations and SGX for rendering.
2. It has been tried, one of the standard mupen64 audio plugins compiles and works out of the box.
This video shows super mario with sound at 600 and 800 mhz. The OS i'm working with at the moment doesn't seem to want to output any audio, i tried mplayer / xmms.
3. Yes other clocks have been tried. It seems to scale pretty much linearly with clockspeed, so 20fps at 800mhz would be 15fps at 600mhz.
4. Not that I can think of.
5. Both. The dynarec is not super compatible at the moment because it hasn't had enough time to mature, not because of optimisations (A few cpu opcodes haven't been implemented yet).
What's with the intermittent black screens in S&P?
Some framebuffer effect causing problems? Can it be fixed?
Yes, I believe its a post processing effect applied to the framebuffer. I don't think it can be fixed without totally destroying performance.
