#32655 - Ramzy - Fri Dec 24, 2004 5:04 pm
Given the improvement in visuals, sound and control layout, would it be technically possible to emulate the SNES flawlessly on the Nintendo DS?
#32658 - abigsmurf - Fri Dec 24, 2004 5:40 pm
as the GBA is capable of 60-90% speed emulation depending on the game, the DS should easily be capable of beating that. I would say that it should be capable of around full speed without any frameskip but it's hard to know for sure without any homebrew so far. We may even see emulation of things like CPS-II. Not sure about Neo Geo though and if PS1 gets emulated to playable speed I would be extrmely impressed
one issue would be the DS' smaller vertical resolution than the SNES but this could be fixed by some filtering or even having the bottom of the display appear on the second screen.
#32679 - dagamer34 - Fri Dec 24, 2004 11:56 pm
| abigsmurf wrote: |
as the GBA is capable of 60-90% speed emulation depending on the game, the DS should easily be capable of beating that. I would say that it should be capable of around full speed without any frameskip but it's hard to know for sure without any homebrew so far. We may even see emulation of things like CPS-II. Not sure about Neo Geo though and if PS1 gets emulated to playable speed I would be extrmely impressed
one issue would be the DS' smaller vertical resolution than the SNES but this could be fixed by some filtering or even having the bottom of the display appear on the second screen. |
32 vertical lines are missing on the DS when compared to the SNES resolution, however it's not as bad as what the GBA spat out in scaled mode. And there will probably be enough CPU power left for sound processing!
_________________
Little kids and Playstation 2's don't mix. :(
#32695 - gladius - Sat Dec 25, 2004 3:41 am
I can't speak for SNES emulation in general, but my SPC emulator (SNES sound chip) runs at close to full speed on the GBA minus cubic interpolation, and with some not so great mixing. If we get access to the 8 sound channels I wouldn't have to do mixing in software any more (depending on the interface to the sound channels...), so there would be time left over on the arm7 to do other stuff :).
Course, that hinges on how much ram the arm7 has access too. But I'm optimistic.
#32723 - Ramzy - Sat Dec 25, 2004 10:18 am
The Nintendo DS has 16 sound channels, though.
#32729 - Lupin - Sat Dec 25, 2004 11:36 am
I guess best would be to take the GP32 SNES emu and just port the code, the only thhing you'd have to change is system specific stuff
_________________
Team Pokeme
My blog and PM ASM tutorials
#32731 - Ramzy - Sat Dec 25, 2004 12:23 pm
| Lupin wrote: |
| I guess best would be to take the GP32 SNES emu and just port the code, the only thhing you'd have to change is system specific stuff |
Easier said than done, I believe. Perhaps we could port the existing SNES emulator on the GBA?
#32740 - tssf - Sat Dec 25, 2004 4:09 pm
That's assuming the DS' sound chip doesn't work like the GBA's soundchip, which used software processing and used the two main channels usually 1 for Left, and the other channel used for Right.. Though from what I can tell just by listening, the DS' sound is like the GBA..just much enhanced. (Metroid is mainly recorded music, I can tell that just by listening, too) 8 pannable channels would require 2 channels each in that regard. The plus side would be that there wouldn't need any software processing on the music just to play back an 8-channel piece, which also means more CPU power for other things.
From the sound of it, the DS' sound chip is still 8-bit, just higher resolution.. (I'm guessing normally 32000Hz, or something like that..There's certainly more power for it, unlike the usual 8000/16000Hz on the GBA)
#32748 - ravuya - Sat Dec 25, 2004 7:45 pm
| Lupin wrote: |
| I guess best would be to take the GP32 SNES emu and just port the code, the only thhing you'd have to change is system specific stuff |
Much easier said than done. The GP32 SNES emulators are so tightly woven with the hardware performance-wise that I'm willing to bet they rely on a lot of the tricks and glitches of the GP32.
_________________
Rav (Win/Mac/Linux games for free)
#32804 - Guspaz - Tue Dec 28, 2004 4:35 am
Well, the DS has a LOT more power... It may be possible to implement PROPER scaling finally.
And by proper, I mean a nice bilinear filter to scale down the image smoothly. This would produce much nicer (Thogh a bit less sharp) image than the current nearest-neighbour transform.
#32898 - skforty - Wed Dec 29, 2004 2:25 am
| Guspaz wrote: |
Well, the DS has a LOT more power... It may be possible to implement PROPER scaling finally.
And by proper, I mean a nice bilinear filter to scale down the image smoothly. This would produce much nicer (Thogh a bit less sharp) image than the current nearest-neighbour transform. |
Honestly, have you even checked the specs for each system.
GP32 CPU - 32 Bit RISC CPU (ARM9), 133/166MHz
Nintendo DS CPU - ARM946E-S (Running at 67 MHz) Processor - ARM7TDMI (Running at 33 MHz)
Ummm, I am no mathematician, but i would say 166>67+33
So actually, the GP32 is ALOT more powerful than the DS in terms of CPU.
#32903 - tepples - Wed Dec 29, 2004 2:48 am
The GP32's video is a dumb frame buffer. The Nintendo DS has tile hardware, sprite hardware, and 3D hardware. How much of the GP32's power is spent on graphics rendering tasks that the DS could handle in hardware? (Yes, I know that the DS's 2D hardware doesn't support Super NES subtractive blending if its blending model is like that of the GBA, but optimizing the common case until a game actually turns on subtractive blending should still prove useful.)
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#32910 - TJ - Wed Dec 29, 2004 4:37 am
Yes, the GP32 runs nearly everything on the main CPU.
That is why while the GP32 is much more powerful than the GBA on paper; few games on it have matched the GBA in terms of graphics.
The GP32 could never render anything near DS quality visuals.
#32913 - kerrle - Wed Dec 29, 2004 4:53 am
I don't think we'd really need to worry about video scaling; given that there is only a slight difference in the vertical, it would probably be better if you could just set a vertical offset per-game.
Personally, I'd rather play Super Mario World missing 8 pixels at the top and the lowest row of blocks on the bottom than have a distorted aspect ratio - most games wouldn't be a problem at all this way.
#32922 - tepples - Wed Dec 29, 2004 6:25 am
Except square pixels is a distorted aspect ratio. A real NTSC TV displaying a real Super NES console's signal will "scale" the screen, stretching each pixel at a ratio of 40:33 horizontally. Notice how Game Boy mono games look slightly stretched when played through a Super Game Boy adapter. Perfectly scaling a 256x232 pixel screen to the DS's square pixels would mean taking a 232 pixel tall chunk of the screen and interpolating it down to 192 pixels. Given that the DS has no hardware texture filter other than frame-to-frame coordinate jitter, interpolation will have to be done either by subpixel scroll jitter (PocketNES's method) or by some sort of alpha blending.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#32926 - kerrle - Wed Dec 29, 2004 8:09 am
I'll completely grant that that is true; I hand't thought of that.
However, given the fact that we're talking about a screen that's actually lower resolution than the original SNES screen, I don't think it would be worth losing detail and introducing aliasing to correct the minor difference in aspect ratio.
Obviously, though, that'll be a matter of taste - some people would prefer absolutely correct aspect ratio for a loss of small details, while others would rather just have it per-pixel correct for the pixels available.
#32927 - netdroid9 - Wed Dec 29, 2004 8:09 am
| tepples wrote: |
| Except square pixels is a distorted aspect ratio. A real NTSC TV displaying a real Super NES console's signal will "scale" the screen, stretching each pixel at a ratio of 40:33 horizontally. Notice how Game Boy mono games look slightly stretched when played through a Super Game Boy adapter. Perfectly scaling a 256x232 pixel screen to the DS's square pixels would mean taking a 232 pixel tall chunk of the screen and interpolating it down to 192 pixels. Given that the DS has no hardware texture filter other than frame-to-frame coordinate jitter, interpolation will have to be done either by subpixel scroll jitter (PocketNES's method) or by some sort of alpha blending. |
Can't you simulate a ratio of 40:33 (Or something like it) with square pixels (1:1)?
#32929 - kerrle - Wed Dec 29, 2004 8:12 am
Also, I was under the impression that the SNES ran in 256x224 most of the time.
#32956 - tepples - Wed Dec 29, 2004 5:53 pm
Yes, most Super NES games run in 256x224 pixels, but 256x232 pixels (and the resulting black bars at the top and bottom) is what you want when scaling down to a 256x192 pixel window with aspect correction. And given a good random jitter, would scaling introduce that much perceptible aliasing?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#33011 - kerrle - Thu Dec 30, 2004 2:43 am
For a stationary screen, like Tetris? No, not really; that'd be fine.
But for something with a fair amount of scrolling, yes, it might. But like I said in my post, this would end up being a matter of taste, in the end.
#43878 - Ethos - Fri May 27, 2005 3:45 pm
Maybe try using the 3D capabilities to diplay.
Add a 256x256 texture.
Create a quad that spans the screen, and grab the rect of 256x232 from the texture and map it to the quad.
Let the gpu do the scaling :)
To change the output, just directly update the memory in the texture (not supported in ndslib...have to do it yourself).
_________________
Ethos' Homepage (Demos/NDS 3D Tutorial)
#43893 - Chetic - Fri May 27, 2005 6:51 pm
I really like the hardware 3D idea.
Is anyone working on a SNES emulator yet?
_________________
Packin':
Grey DS with FlashMe v7
1Gbit XG2T 2005 (Neoflash compatible)
GBAMP, Supercard CF, 512Mb Magic Key 3 and EZFA 256Mbit
#43897 - ErUs - Fri May 27, 2005 7:15 pm
im working on a nes emulator :o
#43907 - assassda - Fri May 27, 2005 10:30 pm
somebody convert pocketSNES and fix the buttons and were mostly set
#43908 - welshwarrior - Fri May 27, 2005 10:47 pm
And add Sound and fix slowness
#43912 - Vixus - Fri May 27, 2005 11:28 pm
Gosh, if I got to play SNES games on my DS, I wouldn' t complain!! But wouldn't the emulator + ROM data get lost everytime you switched the DS off?
_________________
TunnelVision Website - Bringing DS multiplayer to the masses.
#43913 - Diskun - Sat May 28, 2005 12:05 am
| Vixus wrote: |
| Gosh, if I got to play SNES games on my DS, I wouldn' t complain!! But wouldn't the emulator + ROM data get lost everytime you switched the DS off? |
Nope, if Darkain finishes the development of his Nintendo DS File System (along with DarkStar) ;)
Greets
#43914 - IxthusTiger - Sat May 28, 2005 12:05 am
not if you used PassMe, WifiMe, or FlashMe and a GBA Flash cart
#43928 - Vixus - Sat May 28, 2005 9:21 am
| IxthusTiger wrote: |
| not if you used PassMe, WifiMe, or FlashMe and a GBA Flash cart |
Yes, it gets lost when you use those methods...
Diskun: That's awesome news!
_________________
TunnelVision Website - Bringing DS multiplayer to the masses.
#43929 - Veg - Sat May 28, 2005 9:50 am
You only lose the data if it's in the temporary memory - i.e. if you've downloaded it wirelessly.
If it's on the flash cart, it'll be there until you choose to format the card.
#43937 - J_akob - Sat May 28, 2005 12:28 pm
The harware idea is really what sounds best to me. Consider the image rendered on a texture. If you are playing an RPG you could zoom in to read important text, if it's unreadable, and zoom out to play it fullscreen. PSMS and PGEN on the PS2 use a similiar technique, rendering the image on a textured surface. But then again we would probably lose the ability to render the image on both screens (80% on top and 20% on the bottom to display a HUD like in Super Mario World) because we still haven't figured out how to display 3d on both screens (it's still controversial, there's a lot of chatter about it on a differant thread).
_________________
Bill
The eyes are the windows to the
skull my friend.
Dave
Don't you mean soul?
Bill
To those that have one, yes.
#43940 - strager - Sat May 28, 2005 1:42 pm
The easiest idea (for the user, not the programmer) is to have an option at the beginning of the rom (a menu, for instance), or have it controlled by a double-tap to the touch screen (to access a menu, etc.), since there are no extra buttons.
If you go with the 3D idea, wouldn't you have to do all the tile and sprite dirty work via software? That wouldn't be OK in time-critical games, I am guessing.
Correction: the menu could BE the touch screen. :-)
#43947 - tepples - Sat May 28, 2005 3:49 pm
| strager wrote: |
| If you go with the 3D idea, wouldn't you have to do all the tile and sprite dirty work via software? |
You'd already have to. The GBA display model doesn't support subtractive blending or priority per tile. Or were these added to the DS's 2D core?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#44028 - kwekee - Sun May 29, 2005 5:31 pm
Is anyone actually working on a snes emu right now or are you guys just speculating?
#44039 - tepples - Sun May 29, 2005 7:21 pm
I don't know of anybody who has publicly announced working on one. We need to analyze the requirements of Super NES emulation in the context of the Nintendo DS hardware (apparently what you call "speculating") so that we know what kind of design-time optimizations to make.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#44157 - kwekee - Mon May 30, 2005 6:53 pm
ah ic thanks for the explanation ^^