ttursas

Here's our dswifilib enabled multiplayer (single player coming after we get multiplayer fully working) shooter game, Wright Flight (project name): http://users.tkk.fi/~vhelin/nintendoDS.html The game is quite incomplete, but currently you can shoot and damage the other players, collide with the backgrounds, and uhh configure the keys, on the fly. Anyway, a new release will be out this weekend, and I'll post more updates when I release new versions, to this forum: http://forum.gbadev.org/viewtopic.php?p=104817#104817

It works! I guess... And I hope it does work tomorrow as well... Anyway, I disabled all dynamic memory allocations from the sgIP_Config.h, and made wHeapAllocInit() to use a static buffer. Could be fixed prettier, but this works for me. Yay!

Seems that on the ARM9 side when it gets an IPC_FIFO_NOT_EMPTY interrupt (after sending that one UDP packet to my PC server), and calls Wifi_Sync() in the interrupt handler, the game just freezes. What can happen in Wifi_Sync() that makes the program freeze? It never returns from that while-loop? Why? It's hard to say what the code does... Out of memory error? Have to take a look at how libnds handles the interrupts, but here's mine: void irqHandler(void) { if (REG_IF & BIT_IE_T3) { // handle timer 3 Wifi_Timer(50); // end IRQ_CHECK |= BIT_IE_T3; REG_IF |= BIT_IE_T3; } if (REG_IF & BIT_IE_IPC_FIFO_NOT_EMPTY) { // handle IPC FIFO not empty u32 i = REG_IPCFIFORECV; if (i == 0x87654321) Wifi_Sync(); // end IRQ_CHECK |= BIT_IE_IPC_FIFO_NOT_EMPTY; REG_IF |= BIT_IE_IPC_FIFO_NOT_EMPTY; } if (REG_IF & BIT_IE_VBI) { // handle vblank // end IRQ_CHECK |= BIT_IE_VBI; REG_IF |= BIT_IE_VBI; } }

Hehee, I got it working! Plugged both my DS (via Wifi) and my PC to D-Link DI-524 (my wireless router), and addressed the server on my PC using its IP. Both are now under 192.168.0.*... So TetattDS has now network play with 0.3b in my local configuration. When I had my PC outside DI-524, but connected to my ADSL model (and DI-524 is connected to my ADSL modem as well), it didn't work. 0.3a didn't work no matter how I had configured the cables... Also wifi_example1 works with my UDP code, but unfortunately my own game freezes when it has sent its first UDP packet... Have to investigate it more, but now this is really progressing. Thanks for TetattDS, also, I got a bit addicted to it while testing dswifilib...

Got TetattDS to work with 0.3b! I guess this is a problem with my D-Link DI-524 as I plugged both my PC and DS into it (DS via wifi, ofcourse), and addressed my PC directly using its IP, and the game works. If my PC is outside DI-524, then it doesn't work. Also wifi_example1 works perfectly with my UDP code plugged into it, if PC and DS are both in 192.168.0.* under DI-524. With 0.3a this didn't work either. Now back to my own game, it sends one UDP and the PC recieves it, and at the very same moment the PC recieves the UDP packet my DS freezes. sendto() on the DS returns 1 (one byte payload there), so the freezing comes later. Perhaps the interrupts get fuxored? More investigations needed... But looks pretty good so far...

Just tested dswifilib 0.3b, but it doesn't seem to solve my problem. I managed to send one UDP packet to my server and my game would freeze. Also tried TetattDS, and plugged 0.3b into it, but it couldn't connect to the server either I had running in my local loop. Any ideas? I'll continue my investigations with 0.3b...

I just tested TetattDS (a nice game, BTW! ), and dswifilib 0.3b, but it didn't work. I mean, the game couldn't connect to the server. Everything compiled just fine under Linux... Damn. I hoped that 0.3b would solve my problems, but so far 0.3b has worked worse than 0.3a. With 0.3a I could send those 12 UDP packets using the supplied wifi_example1 as my basis. With 0.3b I managed to send one, but that would freeze my own application. Ugh... You wouldn't happen to have a TetattDS-server running somewhere?

Thanks! I'll check it out tomorrow... I can see from Stephen's Weblog that he's found some memory allocation related bugs. Could be that if I waited for 0.3b my wifi code might start working... Anyway, meanwhile I'll check out tetattds and do more testing.

I'd use it for testing. But I've added some UDP code to that wifilib_example, and can for some reason send only 12 UDP packets after which dswifilib just starts to return -1 from sendto()... A real working client-server combination would be nice, so I could really be 100% sure that it really works at least somewhere. If not at my home, then there would be something wrong in my local network, I guess.

Also plugged my Linux box to the D-Link DI-524 wireless router directly, so that both DS and the PC were under the same local network. Fiddled with the port settings in D-Link, and used the PC's IP address directly when sending the UDP packets instead of its human readable name, but still got the same behaviour. 12 packets go through, after that sendto() gives -1. Am I sending the packets too fast (one 2 byte packet every second frame)? Could my 64bit Athlon X2 4400+ be the culprit (i.e., DevKitARM has fully been tested with it)? Argh, anything?

Has anyone got sources for such combination? Just a simple UDP client that runs in DS, and a server that works on Linux or Windows... If you have sources for such a software (I don't care what it does as long as it really works, and sends packets from the client to the server, and possibly even back), please let me know, and email me the sources! I need to know if my local Wifi-network is plain broken... Or is my DevKitARM fuxored? Or is it just that I suck at coding.

I copied my network code (connectionless UDP sendto) to wifi_example1, but it doesn't work much better: I can send exactly 12 UDP packets (2 byte payloads each), and after that nothing comes through. After I restart wifi_example1 I can again send those 12 UDP packets... And this is with the latest sources, and just adding that UDP code to your wifi_example1. Augh... Tried both my old blue DS and the new white DS lite, but the result was the same. And TCP doesn't connect to my Linux machine at all. I have opened the ports I use in my router, and that shouldn't be the reason. When I look at the lights on the router I can see that the DS doesn't send anything after those 12 UDP packets that reach my server program. Any ideas? It's weird because in wifi_example1 you make a TCP connection to www.akkit.org and read and display some data, and it works perfectly fine (looped the thing 20 times in a row a couple of times). I don't think it's my UDP code, because it works 100% on my Linux machine, and the UDP client code is just a couple of lines. Sometimes the client doesn't start giving errors and succeeds sending lots of UDP packets, but none of them come through. The router lights blink, and looks like it is recieving the data, but nothing comes through to my server. I guess the packets might be broken somehow, and the router just drops them, as it's very quiet on my ADSL modem side. Anyway, because www.akkit.org works fine there might be a problem with dswifilib and my local configuration? I have a DI-524 wireless router connected to my ADSL modem, and my Linux box is also connected to that ADSL box. What could cause such behaviour? I wish I had a remote UDP server machine so I could do testing outside the local loop, but no... Mario Kart works just fine, but how come I can send just 12 UDP packets to my local server, and after that sendto() gives -1?

If I read my debug output correctly the ARM9 side doesn't fail sending the UDP packet (added some debug stuff to sendto()). But what happens next? I changed the ARM7 side of my program to your wifi_example1's ARM7 side (plus libnds7), but no help there. If I change the ARM9 init to that init in the example my app just gets stuck with a black screen... For some reason I cannot use my 3D stuff with libnds9. Might be the libnds's interrupt handling, don't know yet, but got to find out. I did some testing and couldn't make malloc() and free() to break (lots of malloc()s, free()s, and memory writes and reads, and verified that there was no data corruption). Also my own memory manager passed the tests...

I did some testing and couldn't make malloc() and free() to break (lots of malloc()s, free()s, and memory writes and reads). Also my own memory manager passed the tests...

It was too hot in Turkey (the worst day was +48C) for serious dev'ing, and we were busy getting cheated all the time by the locals (the Turkish sense of humor, or greed, I guess, never going back anyway). But I found out that if I compiled the same sources under Windows, I could always send one UDP packet from NDS to Windows, and then the NDS game got frozen. Weird. Same DevKitARM but different result. Next I'll check malloc() and free(), and do other testing (like add some debugging stuff to dswifi)...

Those are good things to know! [edited some crap away]... Somehow I managed to get it to work once, could send lots of UDP packets, but after a while the app got stuck. Now I'm not sending a single UDP packet once more... Hmm... I'll triple check everything. Did more testing, and updates using Timer3 should work 100%. It seems that IPC IRQs don't take place, or happen very rarely (tested by incrementing the background color, have both screen in use already). Perhaps because no UDP packets are transferred... No idea about caching the uncached memory mirror (yet), but at least I don't move the cache (don't even know how to do it, yet). All my vars are in bss. Tested also TCP, and no effect. It just gets stuck. About memory stuff, I guess I'll need to write a test app for libc's malloc() and free(), to see if they work well with my own stuff. Could be that they somehow break without libnds, etc. I'm taking my laptop and NDS with me to Turkey (one week holiday, scuba diving and other fun stuff ). I just installed DevKitARM in Windows, and will be using Windows to do the dev'ing there. Could be that this stuff compiles into something different under Windows than Linux, but most probably not. Anyway, I'll post more findings when I return.

I tested both, and didn't have any visible effect on anything. But I managed to send an UDP packet to my Linux server finally with DevKitARM r19b. I commented away #define SGIP_MEMBLOCK_DYNAMIC_MALLOC_ALL #define SGIP_USEDYNAMICMEMORY in sgIP_Config.h. This is the way it worked better with DevKitARM r18. The sources still want sgIP_malloc() and sgIP_free() so there is dynamic allocating going on (using libg), but at least it doesn't get stuck. Tested four times, could send an UDP packet only once. Seems like it is a memory related bug, but no idea why just one UDP packet. Somebody said in gbadev.org's forums that these malloc()s and free()s should be interrupt proof, which libg/libc's functions are not, or write a dswifilib specific free() and malloc(). I don't use free() or malloc() in my code, so they are only there for dswifilib. Is it still a problem?

I'm dev'ing under Linux, and I use M3-SD for testing (none of the emulators for Linux are any good. Any Windows emulators that support Wifi and 3D?). DevKitARM r19b, dswifilib 0.3a, and I have the latest libnds headers for dswifilib.

Hmm, it also seems that if I compile dswifilib with -O0 for both arm7 and arm9 Wifi_AutoConnect() gets stuck in ASSOCSTATUS_ACQUIRINGDHCP. With -O2 for both (and my project) I always get ASSOCSTATUS_ASSOCIATED. Doesn't matter if I put -O0 also for my project, as long as I compile dswifilib with -O0 Wifi_AutoConnect() gets stuck. Any ideas what could cause this? Also, should I use -mcpu=arm9tdmi -mtune=arm9tdmi or -march=armv5te -mtune=arm946e-s with DevKitARM r19b for ARM9? Does it matter as long as I compile my project and dswifilib using the same CPU model? I have another (a networkless 2D) project that can be compiled with both settings and it works just fine.

Yes I did test them on Linux before porting to DS. Also, it doesn't seem to matter wether I use my own malloc() & free() or those that come with libg/libc. What I've done is that I've written my own header files plus created my own small libs to do the things I need. Currently dswifilib is the only external lib that I use (on purpose, plus all those that DevKitARM forces). I know, I'm looking for trouble, and got some, but there's no better way to learn these machines than go through the registers bit by bit. Anyway, I'll double check free() and malloc(), but is there anything else that could cause behaviour like this? If I can connect to an AP, does it mean that the interrupts work 100%? I've checked them about twenty times, but still there could be something wrong (I've copied the inits from your examples, just converted them to use my header files). Thanks in advance, and huge thanks for making dswifilib!

Is it possible to get dswifilib to work without using libnds? I'm not using libnds, but would love to use dswifilib, but no matter what I do, dswifilib doesn't work properly. I can connect to an AP, but when I send UDP packets they usually vanish, and often my program just halts. With DevKitARM r18 things used to work better, but after switching to r19b I haven't been able to send a single packet. Mario Kart works 100%, and so do the test apps that use libnds. Any hints? Also, fiddling with dynamic memory settings doesn't help at all. I don't use malloc() / free() myself, but also wrote them myself, to see if that was the problem, but it wasn't. Is there something I should aware of when not using libnds?