2 Players Simultaneusly? -Nds Question

[borgqueenx]

Exophase, would ds emulation be possible on the pandora with a minimum of 15FPS?
If someone would ofcource have the time to create it?

can you take a gamble and explain why yes/no?

 

[Exophase]

I don't know, it's too difficult to know something like this without trying it. This is assuming that you're referring to a DS emulator that executes the game at the proper speed but skips 3 out of 4 frames. If you just mean a DS emulator that runs at 1/4th speed all around (no frameskip) then I I'm sure that's possible.

 

[borgqueenx]

I don't know, it's too difficult to know something like this without trying it. This is assuming that you're referring to a DS emulator that executes the game at the proper speed but skips 3 out of 4 frames. If you just mean a DS emulator that runs at 1/4th speed all around (no frameskip) then I I'm sure that's possible.

alright...maby we'l get lucky and some dev tries to make it

thansk for the response

 

[EmuGuy]

1. I know we can connect Pandora to the Tv but, it would be possible to play a emulator game 2 players simultaneously, one with Pandora's pad and the other with the Ps3 bluetooth controller?? With Pandora connected to TV so the screen is not a problem for the players.

This is absolutely the dream setup I hope to have at some point in Pandora's life. NHL'94 mostly. Hoping of course for network/Internet play as well, but that's a bigger dream, I think.

 

[rabidpoobear]

1. I know we can connect Pandora to the Tv but, it would be possible to play a emulator game 2 players simultaneously, one with Pandora's pad and the other with the Ps3 bluetooth controller?? With Pandora connected to TV so the screen is not a problem for the players.

This is absolutely the dream setup I hope to have at some point in Pandora's life. NHL'94 mostly.

Um, this should be incredibly easy if the controls for the emulator are customizable. Should be able to use ps3 bluetooth controllers for both players if you wanted to.
[edit]
nvm this has already been answered.[/edit]

 

[Cpasjuste]

I did try desmume for fun on my pandora board. Since i know nothing in asm, there is no optimisation at all. On 2d games, i get around 10 fps or less while the cpu is clocked at 800mhz, either when using sdl or openglES for 2d rendering.

 

[rabidpoobear]

I did try desmume for fun on my pandora board. Since i know nothing in asm, there is no optimisation at all. On 2d games, i get around 10 fps or less while the cpu is clocked at 800mhz, either when using sdl or openglES for 2d rendering.

That's actually not as bad as I thought it would be, 10fps is playable on some games. I have a DS anyway, but this is interesting. on a side note, is 800mhz the highest your CPU is stable, or just the highest you've tested it to?

 

[Exophase]

This is always ambiguous. Is 10fps the runtime speed (ie 1/6th realtime performance) or the number of frames rendered after frameskip, with the realtime performance being some unknown quantity? I would never even considering playing any game at 1/6th speed.

DesMuME is a dead-end for this/the upcoming generation of ARM handhelds the same way VBA was for the last generation of handhelds. It isn't aggressively optimized enough. Trying to optimize by converting any amount of the C++ code to ARM ASM would give you relatively small gains compared to an emulator that has a much different architecture.

What a DS emulator on Pandora needs is:

- A dynamic recompiler. Preferably a good one that translates a lot of ARM idioms seamlessly, has a very optimized memory interface (possibly with MMU assistance) and reschedules for Cortex-A8. Thumb to ARM optimization would be good if anything uses Thumb on DS, otherwise that'd just be nice for GBA emulation.

- Fast DMA that doesn't go through a huge memory architecture every access. DesMuME doesn't optimize this.

- A fast 2D software renderer. There are a lot of things that DesMuME does that are not fast, like iterating every sprite every scanline, performing Z combining instead of Z ordering, checking window per-pixel instead of per-span, not packing line buffer data aggressively, a slow mode switch per-pixel that's even worse than a function pointer, blending per layer which is both slow and inaccurate, blending that's probably not very fast (uses huge tables which probably chew cache and no bit-packing); the list goes on. It's doing a lot of stuff per-pixel that it doesn't need to be and some stuff per-line that it doesn't need to be.

- Fast batched geometry conversion. DesMuME does have SSE2 code for this, but for Pandora we'd obviously need NEON instead.

- Fast 2D/3D integration - I haven't looked much at what DesMuME does here so I can't say if it's doing things "badly", especially since I haven't done any of this stuff myself. But it seems to be very important that framebuffer objects and/or pixel buffer objects are used in order to composite the software and hardware rendered surfaces together as quickly as possible. What remains to be seen is whether or not this compositing (and final color adjustment) can itself be done in hardware instead of software. If anything it can be done by the DSP, and per-frame.

All of these things are very significant, and most of them would require a major redesign to DesMuME. If you wanted to start with DesMuME as a base you could still reuse a significant amount of code for the portions that aren't as speed critical, like the many peripherals (SPI, RTC), backup memory, possibly game card access in general, possibly sound (actually DesMuME has a pretty efficient audio core). But I wouldn't personally want to try to shoehorn designs together. That might just be me.

 

[rv6502]

and you could just buy a DS and the games instead of pirating them :angry:
they're still in store and its smaller than a Pandora.

I just would like to play Mario Kart with my girlfriend... she has the ORIGINAL game.. I am not going to buy a NDS only fot that.
I have spent all my money in Pandora!!

I love your logic. :blink:

I could extend the justification for not buying X for having spent money on Y for hours.

my wife need a another car to use while I drive to work, so I'm going to take yours.
I'm not going to buy another car only for her: I have spent all my money on Pandora.

 

[rv6502]

as well as the hardware toon inking post-processing

"Toon shading" is just a malformation of paletted textures.

I said toon inking.
the colorized 1 pixel outline around polygons with different polygon ID.

 

[rv6502]

- A dynamic recompiler. Preferably a good one that translates a lot of ARM idioms seamlessly, has a very optimized memory interface (possibly with MMU assistance) and reschedules for Cortex-A8. Thumb to ARM optimization would be good if anything uses Thumb on DS, otherwise that'd just be nice for GBA emulation.

most of the code on DS is Thumb by default (although the ratio of what gets executed vs space is different)

the AI code is likely to be executed once per frame and/or be so large as to not fit in the cache anyway so the smaller size makes Thumb a better fit.
the type of operations for AIs also matches the Thumb instruction set well with little benefit from the full ARM instruction set.

from test I made on the actual console with actual games recompiling them in both instruction sets the overall performance difference was negligible but the code size made all the difference.

having a few selected engine looping functions compiled in ARM made a good improvement, I'm guessing most commercial games would follow this pattern.

 

[Exophase]

It would be nice if this board still had post-merging..

I said toon inking.
the colorized 1 pixel outline around polygons with different polygon ID.

Your terminology is pretty new to me, but I would think there are ways to approximate this with shaders or stencils. I will have to see if DesMuME handles this in its 3D renderer, and if so, how. I think dropping this feature altogether wouldn't exactly make the emulator useless, though. Kind of like how no one cares that gpSP doesn't emulate mosaic. I have not received even a single complaint.

Actually, the feature looks very limited. How many games use it? There are only 8 available edge colors, and edge marking applies to the entire scene instead of just selected polygons. I guess one way to emulate it would be to draw wireframes using XOR combination in OpenGL, where the polygon ID is drawn. Then render the wireframes again, this time with their edge color, using the alpha (I'm assuming alpha is part of color) in the framebuffer with alpha test to draw only the indexes that had non-zero on the first pass. Since you're just drawing wireframes these passes should be pretty fast. Of course, one can see how this could be optimized with shaders. The overall polygon counts of DS games is quite low so I think the SGX could keep up.

most of the code on DS is Thumb by default (although the ratio of what gets executed vs space is different)

the AI code is likely to be executed once per frame and/or be so large as to not fit in the cache anyway so the smaller size makes Thumb a better fit.
the type of operations for AIs also matches the Thumb instruction set well with little benefit from the full ARM instruction set.

from test I made on the actual console with actual games recompiling them in both instruction sets the overall performance difference was negligible but the code size made all the difference.

having a few selected engine looping functions compiled in ARM made a good improvement, I'm guessing most commercial games would follow this pattern.

Execution ratio is all I care about, not amount of code.

I'll have to find out for myself what games use - another person who develops on DS says he analyzed games in an emulator (don't remember his exact method) and didn't find a lot of Thumb usage. I would think the number one reason to use Thumb over ARM would be to save main RAM space, but I think that your code shouldn't take that much space to begin with. Maybe I could modify DesMuME to track this, so I can do my own checks. I know that on GBA Thumb was taking up maybe 60% of the execution time. GBA has an obvious reason to use Thumb when it has to execute a majority of its code over a 16bit bus.

At any rate, I hope you're right because Thumb that's optimized back into ARM can be as much as 20-30% fewer instructions than instructions naively converted to ARM. Thumb instructions also have lighter register pressure. Recompiled code on Pandora would have to be in ARM/Thumb-2 blocks (doing Thumb blocks even for Thumb code would be crazy), so it's easy to see how this is beneficial.

Here's an example of the optimization I mean: http://exophase.devz...mb_optimize.txt

 

[rv6502]

I'll have to find out for myself what games use - another person who develops on DS says he analyzed games in an emulator (don't remember his exact method) and didn't find a lot of Thumb usage. I would think the number one reason to use Thumb over ARM would be to save main RAM space, but I think that your code shouldn't take that much space to begin with. Maybe I could modify DesMuME to track this, so I can do my own checks. I know that on GBA Thumb was taking up maybe 60% of the execution time. GBA has an obvious reason to use Thumb when it has to execute a majority of its code over a 16bit bus.

At any rate, I hope you're right because Thumb that's optimized back into ARM can be as much as 20-30% fewer instructions than instructions naively converted to ARM. Thumb instructions also have lighter register pressure. Recompiled code on Pandora would have to be in ARM/Thumb-2 blocks (doing Thumb blocks even for Thumb code would be crazy), so it's easy to see how this is beneficial.

Here's an example of the optimization I mean: http://exophase.devz...mb_optimize.txt

the DS still has a 16bit bus to main memory so code density still help, altho the cache makes the difference less pronounced.

code size depend on the game type and how the game was developed, rush jobs using 10 AI programmers fresh out of school in large game studios will create a huge amount of almost-duplicate AI code (which could have been done with 1 experienced programmer within the same time frame but that's another story).

I tried with recent GCC versions and the difference is now almost inexistent due to GCC 4.2 using the ARM inst. set much more efficiently vs older GCCs and other compilers.
with GCC 4.2 ARM code can end up much smaller than Thumb code.

but that's not what was used in commercial games.

and often GCC does dumb things in Thumb mode, as if the optimizer only looked at 2 instructions.
where looking at 3 instructions would allow collapsing them into 1, but looking at only 2 did not provide any possibility.

nice work on the translator/optimizer btw.
is it already implemented in code or you are hand-testing the principles ?
what was the test code sample from ?

 

[Exophase]

nice work on the translator/optimizer btw.
is it already implemented in code or you are hand-testing the principles ?
what was the test code sample from ?

Thank you. I implemented maybe 2/3rds of it, but this was over 2 years ago. I'd like to do a complete implementation in a Thumb recompiler.

The code was from some GBA game. Which one, I don't remember ;D