Well, for 2D systems like the GB, GBC, and GBA, there is no such thing as textures (yes, even when accounting for all the scaling and rotation the GBA does). The proper term is HD Tile Replacement. This is already possible with GBE, as it allows you to specify your own custom tiles greater than the GB's 8x8 limitations. The code is there in GBE's master branch, and it works. I posted a build for it, but not a lot of people took a look at it. See here on EmuTalk.net -> http://www.emutalk.net/threads/55007-GB-Enhanced?p=452812&viewfull=1#post452812
Screenshots for proof:
http://i3.minus.com/ibtWMxaH9B8ZBb.png (and yes, those Pokeballs look terrible, but you get the idea)
http://i.imgur.com/hylaHhz.png
The thing is, this only works for original GB games. GBC and GBA games require more advanced techniques. I have working code that adds the same functionality to GBC games, but properly getting it to work requires a better user interface (the CLI + text files is doable, but sub-par as you can imagine) and a more unified approach to LCD emulation with cleaner code, hence why I'm waiting for to GBE+ mature.
For 2D sprites, you can do bilinear or trilinear interpolation. However, with OpenGL, it's easy enough to draw the entire game screen to a texture, then tell OpenGL to perform filtering on that texture, but imo bilinear filtering looks horrible no matter what you do. Scaling filters dedicated to pixel art do a much better job at being as smooth or as sharp as you like. For the sake of completeness, I see no reason to exclude bilinear or trilinear filtering for 2D, especially since I'm not big on forcing others to accept my own preferences like that.
As for copying stuff from Desmume, I'll reference their codebase, but remember, I'm doing this as a learning experience, as a way to challenge myself, and as a way to become independent from Desmume itself (I have a small list of things against it at any rate).
A JIT recompiler will definitely be a part of any DS emulator I eventually get around to making, and in fact I might have to experiment with a JIT for the GBA portion. Let's just say that making really fast, 100% C++ ARM interpreters isn't easy. I basically have a majority of the code necessary for the DS' ARM interpreter sitting right in front of me (in the form of my current GBA CPU code) but I can tell right now it's not optimized enough to reliably run DS games at enjoyable speeds.
Screenshots for proof:
http://i3.minus.com/ibtWMxaH9B8ZBb.png (and yes, those Pokeballs look terrible, but you get the idea)
http://i.imgur.com/hylaHhz.png
The thing is, this only works for original GB games. GBC and GBA games require more advanced techniques. I have working code that adds the same functionality to GBC games, but properly getting it to work requires a better user interface (the CLI + text files is doable, but sub-par as you can imagine) and a more unified approach to LCD emulation with cleaner code, hence why I'm waiting for to GBE+ mature.
For 2D sprites, you can do bilinear or trilinear interpolation. However, with OpenGL, it's easy enough to draw the entire game screen to a texture, then tell OpenGL to perform filtering on that texture, but imo bilinear filtering looks horrible no matter what you do. Scaling filters dedicated to pixel art do a much better job at being as smooth or as sharp as you like. For the sake of completeness, I see no reason to exclude bilinear or trilinear filtering for 2D, especially since I'm not big on forcing others to accept my own preferences like that.
As for copying stuff from Desmume, I'll reference their codebase, but remember, I'm doing this as a learning experience, as a way to challenge myself, and as a way to become independent from Desmume itself (I have a small list of things against it at any rate).
A JIT recompiler will definitely be a part of any DS emulator I eventually get around to making, and in fact I might have to experiment with a JIT for the GBA portion. Let's just say that making really fast, 100% C++ ARM interpreters isn't easy. I basically have a majority of the code necessary for the DS' ARM interpreter sitting right in front of me (in the form of my current GBA CPU code) but I can tell right now it's not optimized enough to reliably run DS games at enjoyable speeds.