ZSNES Performance Questions

[tcaudilllg2]

- of the 500Mhz recommended to run ZSNES, is it known approximately how these mhz are divided between tasks? If not, how might it be?
- which is performed faster: the interpretation of program source or the graphics rendering/PPU? Why? To what degree is sound processing a burden?

[grinvader]

- of the 500Mhz recommended to run ZSNES, is it known approximately how these mhz are divided between tasks? If not, how might it be?

90 MHz stoeling your bike
90 MHz haxxoring in the yuor RAWMZ
90 MHz in ur base, killing ur dudes
90 MHz drinking your beer
90 MHz raping lolis
50 MHz emulating the snes

- which is is performed faster: the interpretation of program source or the graphics rendering/PPU? Why? To what degree is sound processing a burden?

Current versions of zsnes' main bottleneck is copying to vram, iirc.

[I.S.T.]

- of the 500Mhz recommended to run ZSNES, is it known approximately how these mhz are divided between tasks? If not, how might it be?

90 MHz stoeling your bike
90 MHz haxxoring in the yuor RAWMZ
90 MHz in ur base, killing ur dudes
90 MHz drinking your beer
90 MHz raping lolis
50 MHz emulating the snes

[Kajuru]

I ran Zsnes in my 086.

[tcaudilllg2]

So what's the deal with the PPU bottlenecks?

Here's something I imagine is quite bothersome.

http://en.wikipedia.org/wiki/Super_Nint ... stem#Video

The PPU may be instructed to latch the current pixel position at any time during image output, both by game software and by the device attached to controller port 2. The game software may then read back this latched position. The PPU may also be used for fast 16-bit by 8-bit signed multiplication.[49]

To synthesize that WITHOUT drawing all the pixels in some parallel process seems to me very complicated. To put a simulation of the draw in the main loop would require that it made 64,000 pixels a frame... which is ridiculous.

How did you guys handle this?

What about the VRAM is slow?

[grinvader]

What about the VRAM is slow?

Sending data to it.

[declan]

Do the SNES PPU's have 65816 cores like the CPU?

[pagefault]

So what's the deal with the PPU bottlenecks?

Here's something I imagine is quite bothersome.

http://en.wikipedia.org/wiki/Super_Nint ... stem#Video

The PPU may be instructed to latch the current pixel position at any time during image output, both by game software and by the device attached to controller port 2. The game software may then read back this latched position. The PPU may also be used for fast 16-bit by 8-bit signed multiplication.[49]

To synthesize that WITHOUT drawing all the pixels in some parallel process seems to me very complicated. To put a simulation of the draw in the main loop would require that it made 64,000 pixels a frame... which is ridiculous.

How did you guys handle this?

What about the VRAM is slow?

Simple... We use SIMD

And most of the time it's only 114 688 bytes per frame if you are looking at a 256x224 frame with a 16bpp (yes I know it's 15bpp but we pad a bit for performance reasons).

[creaothceann]

Do the SNES PPU's have 65816 cores like the CPU?

No.

[Exophase]

Hope it's okay if I respond to this kind of old thread.

So what's the deal with the PPU bottlenecks?

Here's something I imagine is quite bothersome.

http://en.wikipedia.org/wiki/Super_Nint ... stem#Video

The PPU may be instructed to latch the current pixel position at any time during image output, both by game software and by the device attached to controller port 2. The game software may then read back this latched position. The PPU may also be used for fast 16-bit by 8-bit signed multiplication.[49]

To synthesize that WITHOUT drawing all the pixels in some parallel process seems to me very complicated. To put a simulation of the draw in the main loop would require that it made 64,000 pixels a frame... which is ridiculous.

How did you guys handle this?

What about the VRAM is slow?

There's no need to interleave pixel processing with CPU processing in order to emulate the raster position, which is not at all dependent upon what is being drawn. If you know how many cycles have passed since the beginning of the frame (or more likely the beginning of the scanline) then you can figure out the position directly because it's drawn in a deterministic way. Chances are that not a lot of games rely on horizontal positioning, though.

As of right now I don't think any SNES emulator interleaves pixel operations with the rest of the emulated operations, or has any other provisions for emulating mid-scanline raster effects (what the SNES will allow you to do I'm not 100% certain of). As far as byuu has indicated, there are no SNES games that strictly rely on this and won't work being rendered a scanline at a time. Nonetheless, I know he is at least working on a version of BSNES that can emulate this correctly.

[grinvader]

I'm gonna delete every post that goes beyond my gag reflex on stupidity now.

If you got beef with it, PM me and maybe I'll tell you how stupid your post was... I mean, answer them.