You are not logged in.

Read the FAQ and Knowledge Base before posting.
We won't make a 3DS/2DS emulator.



#1 2011-03-13 23:58:07

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

devkitPro and homebrew compatibility notes

As of 13-july-2012, these are the known incompatibilities:

* The GDB stub may be flaky.
* libnds method of reading the RTC (handling interrupts each second) is not emulated
* libfat support is flaky

Offline

#2 2011-07-20 01:27:41

alexAG76
Member
Registered: 2011-07-20
Posts: 3

Re: devkitPro and homebrew compatibility notes

Hello, I'm running DeSmuME_dev.exe (0.9.7 dev+ x86) under Windows on my homebrew .nds file.  Where do I find the "nocash debug prints"?  They don't appear in the console used to launch DeSmuME_dev.  I even tried using the 8MB debugger under the Emulation Settings.

Here is a snippet of the code I'm using to generate the output:

    consoleDemoInit();
    consoleDebugInit(DebugDevice_NOCASH);
    // ...
    std::cerr << "This message went to std::cerr.\n";
    fiprintf(stderr, "This message went to stderr.\n");

It compiles, but I can't find "This message..." anywhere.  Thanks for reading.

Edit: I made the version more specific.
Edit: I added a fiprintf call, still couldn't find its output.
Edit: Added newline to fiprintf call.

Last edited by alexAG76 (2011-07-20 01:40:53)

Offline

#3 2011-07-20 06:01:57

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: devkitPro and homebrew compatibility notes

shows up in the console window for me. i didnt do anything peculiar at all. either post your zipped project, or look for something earlier in your program which is destroying the process. 8mb debugger mode is not useful to you.

Offline

#4 2011-07-20 19:53:49

alexAG76
Member
Registered: 2011-07-20
Posts: 3

Re: devkitPro and homebrew compatibility notes

I was finally able to get the output to display by running DeSmuME_dev.exe from a Command Prompt.  It did not work from a Cygwin bash shell, nor did it work from an Eclipse Run Configuration.  I must use Command Prompt only.

Is this odd?

Offline

#5 2011-07-20 22:06:38

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: devkitPro and homebrew compatibility notes

yes, it is odd. desmume has very deranged console output code that doesn't work very well. it is trying to be both a console mode program, and a windows mode program. i have discovered since then that it is 100% impossible to do a good job at this. i can only do a 90% good job, and you have been the first person to notice the 10% bad job.

i have been considering making a command line tool which will run desmume.exe in commandline mode. come on IRC if you want to encourage me to do it sooner and be a test user.

Offline

#6 2011-07-23 01:23:58

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: devkitPro and homebrew compatibility notes

I am pretty sure that since 0.9.7, the console code has been reworked. A consequence of this will be better support in bash. I just spent several hours researching, tweaking, and validating the behaviour of desmume's console operations, considering that I may apply the lessons and best practices to some other emulators.

In bash, desmume works as well as anything else.
In cmd.exe, desmume works as well as anything else _if_ you launch it with "cmd.exe /c desmume.exe" Some kind of workaround like this is definitely necessary, as cmd.exe will always want to get control back immediately after launching a windows gui app. If that gui app then tries to operate the console, you end up with a confusing glitch fest. With that cmd /c approach, things work normally.

If you want to enjoy this thoroughly validated behaviour, compile a recent svn build yourself or get it from emucr. Note that recent svn builds should have made the nocash debug print statements work in non-dev builds since there was no recorded history of it ever interfering with a retail game, so emucr builds should work for you.

Offline

#7 2011-08-29 21:17:11

alexAG76
Member
Registered: 2011-07-20
Posts: 3

Re: devkitPro and homebrew compatibility notes

Thanks for going above and beyond my expectations with this. The truth is, I was just happy to have found a means to see the output.  :-)

I have to run in dev mode to simulate FAT support, anyway.

By the way, I got Boost (C++ library) unit tests to run and print summary output. Because I couldn't write main myself, I had to use a static variable's destructor (!) to perform the infinite loop at the end, after main exits.

Offline

#8 2011-08-29 21:36:06

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: devkitPro and homebrew compatibility notes

man atexit and see if that works. but if youre testing in desmume, theres no reason you have to go into an infinite loop. the emulator will just sit there when main exits (and libnds turns the power off)

Offline

#9 2012-07-13 05:43:25

KazoWAR
Member
Registered: 2009-09-19
Posts: 47

Re: devkitPro and homebrew compatibility notes

I am currently using r4315, RTC fails to update. there is a RTC example with devkitpro.

Offline

#10 2012-07-13 17:38:22

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: devkitPro and homebrew compatibility notes

ah, yes, thats a known issue that we've never sorted out. libnds requires interrupts to fire each second. we dont emulate those interrupts, because it is unclear how an emulator should do that to keep pace with realtime when coping with pauses etc.

Offline

#11 2012-07-14 01:47:12

KazoWAR
Member
Registered: 2009-09-19
Posts: 47

Re: devkitPro and homebrew compatibility notes

OK, just wondering. I been messing with a video player that uses the RTC to keep the video sync'd with the audio. Works perfect on a DS Lite and No$GBA, but fails on DeSmuME and a 3DS because the RTC seems to not update.

Offline

#12 2013-09-10 12:58:55

rajveer
Member
Registered: 2013-09-10
Posts: 3

Re: devkitPro and homebrew compatibility notes

I'm having some compatibility issues with my homebrew ImpulseDS:

- 3D picking doesn't seem to work, I tried with libnds's picking examples which failed too so it seems like an issue with this method of picking. Maybe off-screen rendering isn't supported?
- Textures don't seem to work, I have them enabled but I only get black models. This goes for my splash screens too.

Any help would be appreciated smile

Offline

#13 2013-09-10 17:19:21

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: devkitPro and homebrew compatibility notes

"off-screen rendering" works fine and cant have anything to do with this problem.

the problem is caused by desmume's very poor implementation of GFX_POLYGON_RAM_USAGE. We tend to have an excessively high number being tracked for that counter internally; if we returned that incorrect number faithfully, it would result in some games malfunctioning. So we just return 0.
You could read 32bits from that register, and it would work. Those arent forced to 0 since no known games are using it. But in general i dunno what to do about this. I guess most emulators would have a hack mode for it.

regarding textures (or lights) black, you must be doing something unusual or out-of-spec. Doesnt mean its wrong, but it means it might depend on timing in a way that would nondeterministically fail on hardware or depending on the flash card used.  your vram is getting uploaded OK. it doesnt look like the palettes are. have you tried this on hardware?

Offline

#14 2013-09-10 19:03:40

rajveer
Member
Registered: 2013-09-10
Posts: 3

Re: devkitPro and homebrew compatibility notes

Thanks for the speedy reply! When you say you just return 0 regarding GFX_POLYGON_RAM_USAGE, what do you mean? Currently I am reading from GFX_POLYGON_RAM_USAGE before and after pick testing so if that register isn't forced to 0 then where do you return 0?

Regarding the texture/light issue, everything works fine on hardware, I've tried on both a DS and DSi with multiple flashcards (DS-X, Acekard 2i and an older version with a CycloDS before I lost it). I can't see anything that I could be doing out of the ordinary, I'm using libnds's texture management system, here's a code snippet of my texture loading code (note: a frame here is a texture):

//Load texture into RAM then VRAM
char *mem = fileLoad(texLocation);

glGenTextures(1, &frame->id);
glBindTexture(0, frame->id);
glTexImage2D(0, 0, (GL_TEXTURE_TYPE_ENUM) frame->format, frame->sizeX, frame->sizeY, 0, TEXGEN_TEXCOORD | (frame->wrapX << 16) |
	(frame->wrapY << 17) | (frame->flipX << 18) | (frame->flipY << 19), (u8*)mem);

//Free Texture from RAM
free(mem);

gl_texture_data* texture = (gl_texture_data*)DynamicArrayGet( &glGlob->texturePtrs , frame->id );
frame->texParam = texture->texFormat;
	
//If this format has a palette, load it into RAM then VRAM
if(!StrEqual(palLocation,(char*) "NULL",&palLocation[4], 4))
{
	mem = fileLoad(palLocation);
		
	glColorTableEXT(0, 0, frame->paletteCount, 0, 0, (uint16*) mem);
		
	//Free Palette from RAM
	free(mem);
	
	gl_palette_data* palette = (gl_palette_data*)DynamicArrayGet( &glGlob->palettePtrs , texture->palIndex );
	frame->paletteAddress = palette->addr;
}

glBindTexture(0, 0);

Last edited by rajveer (2014-04-11 17:59:28)

Offline

#15 2014-04-11 18:00:29

rajveer
Member
Registered: 2013-09-10
Posts: 3

Re: devkitPro and homebrew compatibility notes

Is there any update to this, or anything I can do to help figure this problem out? As said above, this code has never failed on me on any combination of DS devices and flashcarts.

Last edited by rajveer (2014-04-11 18:01:17)

Offline

#16 2014-04-11 19:15:58

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: devkitPro and homebrew compatibility notes

there is no update. to debug the problem i suggest you fiddle around with how your palettes are uploaded.

Offline

Board footer

Powered by FluxBB