Reply
Thread Tools
zerojay's Avatar
Posts: 2,669 | Thanked: 2,555 times | Joined on Apr 2007 @ Halifax, Nova Scotia, Canada
#11
Originally Posted by torx View Post
what makes you say that?
Experience. Also, touchscreen buttons really suck.
 
ArnimS's Avatar
Posts: 1,107 | Thanked: 720 times | Joined on Mar 2007 @ Germany
#12
Originally Posted by zerojay View Post
Experience. Also, touchscreen buttons really suck.
Well as far as speed on an N800 goes, here's some figures for various games on the (slower) ARM 920

http://wiki.gp2x.org/wiki/DrPocketSNES
 
Posts: 474 | Thanked: 30 times | Joined on Jan 2006
#13
N800 graphics access is extremely slow relative to the GP32. This is fixable with PowerVR drivers. N800 memory bandwidth is relatively low compared to the GP32. This is probably fixable with engine tweaking.

The N800 -could- "emulate" games at full speed. The trick is to write a compatible SNES opcode translator and rewriter: it's the difference between a VM and a JIT. I'm sure the ARM work generalizes nicely, but the graphics layer is more of a problem.

Touchscreen buttons do suck, especially without multi-touch.
 
zerojay's Avatar
Posts: 2,669 | Thanked: 2,555 times | Joined on Apr 2007 @ Halifax, Nova Scotia, Canada
#14
Originally Posted by aleksandyr View Post
N800 graphics access is extremely slow relative to the GP32. This is fixable with PowerVR drivers. N800 memory bandwidth is relatively low compared to the GP32. This is probably fixable with engine tweaking.

The N800 -could- "emulate" games at full speed. The trick is to write a compatible SNES opcode translator and rewriter: it's the difference between a VM and a JIT. I'm sure the ARM work generalizes nicely, but the graphics layer is more of a problem.

Touchscreen buttons do suck, especially without multi-touch.
I haven't even thought about the fact that multi-touch isn't possible on the N800 screen. Yeah, I'll just stick with my PSP for emulation.
 
ArnimS's Avatar
Posts: 1,107 | Thanked: 720 times | Joined on Mar 2007 @ Germany
#15
Originally Posted by aleksandyr View Post
N800 graphics access is extremely slow relative to the GP32.
It depends if you are thinking 640x480 at 60fps or 320x240 at 25 fps. For the latter, graphics bus performance is unrelated as it is asynchronous operation and there is plenty of bandwidth.

Originally Posted by aleksandyr View Post
This is fixable with PowerVR drivers.
How is this relevant? Is this even going to be implemented? If so, how would it accelerate blits compared to SDL or Framebuffer + Xsp pixel-doubling?

Originally Posted by aleksandyr View Post
N800 memory bandwidth is relatively low compared to the GP32. This is probably fixable with engine tweaking.
Yes, there are hacks to make the gp2x Emus use the MMU, which speeds up the PPU tremendously. I have Nokia-optimized memmove and memcpy that can give around 2x performance boost over standard c libs.

Originally Posted by aleksandyr View Post
The N800 -could- "emulate" games at full speed. The trick is to write a compatible SNES opcode translator and rewriter: it's the difference between a VM and a JIT. I'm sure the ARM work generalizes nicely, but the graphics layer is more of a problem.
Are there any SNES emus that use this JIT technique?

Originally Posted by aleksandyr View Post
Touchscreen buttons do suck, especially without multi-touch.
[/QUOTE]
I agree, but they are the only alternative to a BT keyboard or Controller. They work ok for me for RPG games.

Lets hope nokia makes a tablet that has better dpad and right-hand side buttons.

Last edited by ArnimS; 2007-07-18 at 14:48.
 
DataPath's Avatar
Posts: 124 | Thanked: 34 times | Joined on Mar 2007
#16
Originally Posted by ArnimS View Post
Are there any SNES emus that use this JIT technique?

It wouldn't provide much, if any, benefit for SNES. The opcode emulation is simple enough - the huge performance killer is that you have to emulate from 3 to 5 different processors running simultaneously at different clock speeds, that must all be synchronized.

Almost all emulators, and ALL of the popular ones, fudge this synchronization since it doesn't matter for most games.

The one emulator that I'm certain keeps all the individual processors properly synchronized (bsnes) requires a really beefy desktop system to run at full speed. And although he doesn't fudge the synchronization, he does fudge the PPU internals a bit with a line-based renderer instead of a dot-based renderer.
 
Posts: 474 | Thanked: 30 times | Joined on Jan 2006
#17
IIRC SNES opcode JIT techniques power the PSP emulator, although they call it dynamic recompilation or something. Likewise for the NDS-based SNES emulators.

It makes sync a much saner prospect.
 
ArnimS's Avatar
Posts: 1,107 | Thanked: 720 times | Joined on Mar 2007 @ Germany
#18
Btw for some interesting code for ARM optimizations (memory, graphics)

svn checkout http://arm1136j-s.googlecode.com/svn/trunk/ arm1136j-s
 
ArnimS's Avatar
Posts: 1,107 | Thanked: 720 times | Joined on Mar 2007 @ Germany
#19
Originally Posted by zerojay View Post
I haven't even thought about the fact that multi-touch isn't possible on the N800 screen. Yeah, I'll just stick with my PSP for emulation.
Don't need multi-touch for the slow/rpg style games. Fast games would suck with the dpad anyway.

{bump] Who wil be our hero?

http://reesy.gp32x.de/DrPocketSnes.html

http://pupnik.de/DrPocketSnes_Nokia_The_Horror.tgz

Last edited by ArnimS; 2007-10-28 at 07:41.
 
DataPath's Avatar
Posts: 124 | Thanked: 34 times | Joined on Mar 2007
#20
Originally Posted by aleksandyr View Post
IIRC SNES opcode JIT techniques power the PSP emulator, although they call it dynamic recompilation or something. Likewise for the NDS-based SNES emulators.

It makes sync a much saner prospect.
Do you have ANY clue what you're talking about? Dynarec would do NOTHING for synchronizing emulation of the different processors. Really. Absolutely nothing.

If you want to make a snes emulator faster, follow the basic rules of optimization - find out what the slowest part is, and optimize THAT. I promise you - it's not the opcode emulation.

In fact, the least accurate/fastest emulators fudge the synchronization between the different processors, doing it as rarely as possible without breaking games, and then try to make up the difference with hacks that fix some of those games.

The most accurate/slowest emulators synchronize all the emulated processors _every_ bus cycle of every chip, and is capable of bringing low-end modern systems to their knees.

Last edited by DataPath; 2007-10-28 at 14:38.
 
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 22:27.