The N64 situation

[xiongxioi]

I wonder if all these problems can be solved by pandora 2's 3ghz+ multicore processing power. Full speed robotron 64 would be another milestone of portable retro gaming!


Happy birthday, Exo!

Not sure if itl be 3ghz, most likelty 1.7 ~ 2 ghz quad, but if that setup cant pull it off, nothing can

:wacko:you are right, we just have to wait and see. Get our wallet ready and be prepared for a lethal blow!


Just a side note: Tegra 3 is like 5 cortex-a9 stick together with lots of other things, how powerful is that? Is it suitable for retro gaming?

 

[elwing]

they will also ship in 4 Months

I believe they can pull that off, they did it with the Panda1.5, i received it 2 months after ordering it, which was last friday.


But lets go back ontopic, before we attract mods


The mods are lurking everywhere, they feast on users that offtopic too much.

Strange, the delay for a pandora 1.5 should have been 3 months... are they really pandora 1.5???

 

[Foxgod]

they will also ship in 4 Months

I believe they can pull that off, they did it with the Panda1.5, i received it 2 months after ordering it, which was last friday.


But lets go back ontopic, before we attract mods


The mods are lurking everywhere, they feast on users that offtopic too much.

Strange, the delay for a pandora 1.5 should have been 3 months... are they really pandora 1.5???

Yep, overclocks to 1250 mhz.

 

[craigix]

Okay, made the test with top - and it seems the stuttering IS CPU related, however, it's a bit weird.


I tried Super Mario Kart which runs perfectly except for some occassional stutterings.


The stutter occurs when CPU Idle goes to about 1% (so CPU is fully used).


Most of the time, mupen runs using about 40 - 70% CPU (even while playing). Sometimes it suddenly goes up to 90%, often just for half a second.


I wonder what causes these peaks? They're happening in gameplay and they seem random to me.


I remember an older version was suddenly hanging for 2 - 3 seconds when playing Mario Kart, after that continuing without any issues.


This seems to be the same thing, but the hang only occurs for a couple of milliseconds.


Is this some bug?

Ed did you by any chance try the different resolutions just to give us an indication if the GPU is involved too?

 

[Null]

The mods are lurking everywhere, they feast on users that offtopic too much.

That's why the previous 2 needed to be disposed of. h34r:

 

[Stephane Hockenhull]

I read his post but wouldn't you like to see some FPS and further data to make sure it's accurate?


I've not done much programming with modern GPU hardware so I'm not up to speed on why passing the (presumably) low poly count N64 data could be taxing, but I'd like to understand what is going on to make it slow.

the N64 uses almost exclusively 4bpp palettized textures, which the SGX does not support directly.


the N64 "GPU" is a 62.5Mhz fixed-ish graphic pipeline, the SGX is at 110/200Mhz using programmable pixel shaders (bigger overhead).


N64 games like the Zeldas used a lot of alpha blending and alpha test, the SGX is slow with alpha blend and alpha test enabled.


the N64 allows easy(ish) access to the framebuffer, the SGX uses deferred rendering where frame buffer access and reuse causes a full rendering pipeline flush.


the SGX 530 in the OpenPandora isn't that much faster than an N64 (really) and that's when used normally (native OpenGL ES deferred rendering), not for emulating a rasterizing co-processor.

 

[Stephane Hockenhull]

It's not just polygon count but what the fragment shaders have to do per-pixel to emulate N64's combiners and what have you. You can get an idea of what the shaders can be doing here:


http://code.google.c...derCombiner.cpp


There's up to three texture accesses and one of them (noise) has dependent coordinates which is a performance penalty on SGX. SGX530 can only do 1 TMU operation per clock max, so it's not a texturing powerhouse. Also, any textures with any alpha can (depending on the hackAlpha setting) cause fragment discards which is another achilles heel of the architecture.

really, I would not be surprised if heavily optimized software rendering on the ARM Cortex-A8 at 1250 Mhz (in N64 native resolution of 320x240 or 256 × 224) wouldn't be faster than using the SGX 530 GPU for N64 rendering.


the N64's GPU is so different from the SGX, properly pipelined ARM code could work around the dependant coordinate / address calculation stalls, at roughly 10x the clock speed the ARM can do more TMU ops in the same time


bilinear and tri-linear filtering would slow this down a lot but there are tricks to work around this.


we'd get uglier but faster texturing.