#68643 - NoLongerRegistered - Thu Jan 26, 2006 5:53 am
I was wondering if anyone wants a lib that is similar to libnds for the PC (as in linux, windows and mac). This way we can test code nativly on the PC and debug it easier. Not exactly a perfect replacement but i think it is nice to be able to play your DS games on PC or at least test it out.
I have some code that doesnt work too well but does the job for a tiled bg and rgb16 sprites. Is anyone interested helping in writing a full replacement?
#68644 - Normmatt - Thu Jan 26, 2006 6:04 am
thats what an emulator is for. and there are about 4 emulators atm: iDeaS, DeSmuME, DSEmu, DSEmu-ng and Dualis.
#68661 - doublec - Thu Jan 26, 2006 8:54 am
Why not work on one of the emulators and help get that up to a level that it can emulate everything libnds does?
#68695 - NoLongerRegistered - Thu Jan 26, 2006 12:04 pm
| doublec wrote: |
| Why not work on one of the emulators and help get that up to a level that it can emulate everything libnds does? |
I'll be happy to help out some emulator authors. The point is so we can run and test nativily and use breakpoints to step through source or PC only memory managers. You cant do that though an emulator also the game would run much faster.
I take it that no one is interested?
#68698 - acox - Thu Jan 26, 2006 12:25 pm
I think it is a good idea.
But I would go one level lower. Either:
1) Write a HPL (Hardware Presentation Layer) that simply wraps registers in inline function calls. Relayer ndslib on top of this. Implement it for pc.
2) (bit hazy on this one) Virtualisaion. Use page falts to trap access to DS registers on PC and have handlers implement whatever functionality was
supposed to be behind the regs. Or mod the binary so loads and stores go through a filter that looks for special addresses.
Then you can debug the ndslib code and through the ndslib code as well as your app's. Factors out the question 'is this bug in my app or my PC ndslib?'.
Some details to do with DMA and peripherals accessing memory to think about.
_________________
3D on GBA
#68734 - wintermute - Thu Jan 26, 2006 4:12 pm
| StealthEntity wrote: |
| doublec wrote: | | Why not work on one of the emulators and help get that up to a level that it can emulate everything libnds does? |
I'll be happy to help out some emulator authors. The point is so we can run and test nativily and use breakpoints to step through source or PC only memory managers. You cant do that though an emulator also the game would run much faster.
|
Speed of emulation isn't so much of an issue when single stepping and if an emulator implemented a gdb server then source level debugging of DS native apps could be a reality. See Visualboy Advance
http://www.devkitpro.org/debugging-with-vba-and-insight.shtml
#68748 - HyperHacker - Thu Jan 26, 2006 6:02 pm
I suppose you could implement an NDS subsystem, but it would basically just be an emulator built into Windows. Also, while you could probably create a version of PALib for PC, low-level things like direct memory accessing (many homebrew games do things like ((vuint16*)0x04001234) = 0x69 or some such) would need to be modified anyway. (Perhaps the writes could just be trapped, but it would probably be quite slow.)
The main issue is that DS is ARM7/ARM9, so no matter how it's implemented, emulation would still be required. Unless your PC happens to contain both of these.
#68979 - dovoto - Fri Jan 27, 2006 7:34 pm
LIBNDS is not currently abstracted to the point of making a realistic win API wrapper for it...
Although some functionality in libnds is high level (the 3D lib, some vram managment, some basic print functionality, and some simple IO for instance) much of the video hardware still must be controlled via direct hardware interaction through registers.
Allthough, since all registers are defined or enumerated it would be possible to create windows based headers for all of these that map writes to another area and then renders video based on the this (this would nearly be a full NDS 2D video hardware emulator). This would be a pain to implement and even more a pain to maintain though.
The 3D layer is probably wrapable right now although there are still significant enough differences between openGL and the DS hardware that it would be difficult to use the wrapper for 3D engine development.
Building your own abstraction layer on top of libnds would be the best way to go. This could be nothing more than wrappers for register writes and a bit higher level access to backgrounds and sprites and other video hardware...or it could be at a much higher level which is where a wrapper becomes most usefull.
Libnds is intended for low level access to hardware and is ment mainly as a base for people to derive full libraries from (such as PALIB). If interest is high enough (and other libs such as PALIB are not satisfying the interest for higher level access) I will look into developing a higher level api that is seperate from (but sits on top of) libnds.
_________________
www.drunkencoders.com