games/NXDoom: use default glob implementation

[linguini1]

Summary

Uses the DOOM glob implementation based on dirent. This removes the compile time
warning for no native glob implementation.

Impact

More featured DOOM port, and removed a compiler warning during build.

Testing

Tested using the sim:nxdoom config:

[cederom]

Thank you @linguini1 =)

[linguini1]

FYI @cederom, this patch is necessary to get the NXDoom port running on the RPi4B. It also appears I will need to fix the EMMC2 write/read size limit first as well, as the WAD lumps are big enough that they trigger the same error in apache/nuttx#17255

So I am now splitting my attention between the SDMMC issue and getting PCM audio working.

[cederom]

FYI @cederom, this patch is necessary to get the NXDoom port running on the RPi4B. It also appears I will need to fix the EMMC2 write/read size limit first as well, as the WAD lumps are big enough that they trigger the same error in apache/nuttx#17255

So I am now splitting my attention between the SDMMC issue and getting PCM audio working.

Ah I remember we were testing that during initial SD implementation hope it wont be too hard to fix! :-P

[cederom]

Btw @linguini1 I use apache/nuttx#17303 for flashing NuttX to rPI-4B without SD card just over the usb-bootloader and the rpiboot on the host side.. maybe that would help evade SD problems just for comparison or when needed? :-)

[linguini1]

Ah I remember we were testing that during initial SD implementation hope it wont be too hard to fix! :-P

I hope so too; I would think there should be some way to limit the size of the write chunks but I couldn't find one yet. If I spend more time on it I might get somewhere :)

Btw @linguini1 I use apache/nuttx#17303 for flashing NuttX to rPI-4B without SD card just over the usb-bootloader and the rpiboot on the host side.. maybe that would help evade SD problems just for comparison or when needed? :-)

That is useful, but I don't think it will work around this issue. The problem is because the EMMC2 hardware can only handle a maximum block size of 1023 at a time. So I will need to split larger chunks into smaller ones, no matter what is connected. I should maybe look into getting one of those eventually; it's tiring to swap the SD card every time haha!

[cederom]

Yeah, its very handy, just need some bootloader setup prior that to enable usb boot :-)

Unfortunately usb enumeration of lots of devices is non linear and hard to know which device is what when you have like 30 of them at one.. and uhubctl still is not fully functional.. so testing is still kind of manual.. but this is another story :D