Homebrew Updates about nesDS...

[huiminghao]

huiminghao uses R4SDHC, which requires hbmenu or x***file to set ARGV.

HB menu doesnot work on R4SDHC. It runs, but not able to load the 'nesDS.NDS'.

 

[YayMii]

Okay, I just tried 0.45a, and it doesn't show my whole ROM list. I have a (nearly) complete NES ROM collection, and it only loads games up to 'F'.

 

[huiminghao]

Okay, I just tried 0.45a, and it doesn't show my whole ROM list. I have a (nearly) complete NES ROM collection, and it only loads games up to 'F'.

Sorry, The MAX files on a list is 256.... You can change its value in romloader.c
231 #define MAXFILES 256
Better split them into different folders...

 

[avenir]

Hehe, you should know why the X***File used linkedlist rather than 2D array...

huiminghao uses R4SDHC, which requires hbmenu or x***file to set ARGV.

HB menu doesnot work on R4SDHC. It runs, but not able to load the 'nesDS.NDS'.

Fuck. You need to dldipatch r4tf_v2 to hbmenu.nds then dldilock it. default r4tf_v1 isn't compatible with ARM7(load.bin).
Also please test "cannot return to boot.nds after launching a NES" issue.

 

[huiminghao]

Fuck. You need to dldipatch r4tf_v2 to hbmenu.nds then dldilock it. default r4tf_v1 isn't compatible with ARM7(load.bin).
Also please test "cannot return to boot.nds after launching a NES" issue.

Still stuck at loading nesDS.NDS

 

[Sir_Voe]

Thanks for another great update! One new issue I've noticed that I'm wondering if anyone else is experiencing: every so often I'll hear a low steady sound, like "eeeeeeeeeeeee". The game I really noticed it in was Kung-Fu.

 

[spinal_cord]

Okay, I just tried 0.45a, and it doesn't show my whole ROM list. I have a (nearly) complete NES ROM collection, and it only loads games up to 'F'.

Why not put them in some sub folders?

0-9
a-e
f-j
k-o
p-t
u-z

or similar?

 

[huiminghao]

Thanks for another great update! One new issue I've noticed that I'm wondering if anyone else is experiencing: every so often I'll hear a low steady sound, like "eeeeeeeeeeeee". The game I really noticed it in was Kung-Fu.

I heard that too... I will fix it in a later version...

 

[Sir_Voe]

Thanks for another great update! One new issue I've noticed that I'm wondering if anyone else is experiencing: every so often I'll hear a low steady sound, like "eeeeeeeeeeeee". The game I really noticed it in was Kung-Fu.

I heard that too... I will fix it in a later version...

Cool. Another audio issue I'm not sure is related: I notice on Punch Out, a large portion of the bell sound from the intro is now missing.

 

[huiminghao]

Thanks for another great update! One new issue I've noticed that I'm wondering if anyone else is experiencing: every so often I'll hear a low steady sound, like "eeeeeeeeeeeee". The game I really noticed it in was Kung-Fu.

I heard that too... I will fix it in a later version...

Cool. Another audio issue I'm not sure is related: I notice on Punch Out, a large portion of the bell sound from the intro is now missing.

Sa.... I can not figure out why... The portion to devkitPro/HB really brought a lot of issues...

 

[AlanJohn]

When playing megaman 2 on Wily's 1st boss in the castle I had difficulties playing since the characters where flickering alot and the platforms where disappearing and appearing, fix this please.

 

[Sir_Voe]

When playing megaman 2 on Wily's 1st boss in the castle I had difficulties playing since the characters where flickering alot and the platforms where disappearing and appearing, fix this please.

That's just the way the game is: http://www.youtube.com/watch?v=y1L8OrVOh2g

 

[AlanJohn]

They still didn't fix Myke Tysons punchout, I really want to play it without having a pixelated mess instead of a rival.

 

[qwertymodo]

okay, this is very good.
The reason I ask about the location of the .ini is that on the DSTWO flashcart if you had to put it in the same directory as nesds.nds it would overwrite a DSTWO-specific .ini file that links a program with an image, and the nesds would have a ?, making it harder to see where it is.

A 'global' solution I think would be to change "/nesDS.ini" to "nesDS.cfg".
This will allow the file to 'follow' the NDS file and not conflict with the DSTwo's Plugin.
INI, CFG, DAT, TXT, doesn't matter, only the contents does.

I like TyRaNtM's idea better... /DATA/nesDS.ini

It's so annoying when apps create hardcoded folders regardless of where they are located. Also, from a programming perspective, it's usually the result of laziness. Sure, it's easier to implement just saving the config to the root of the card, but in the end the .ini should be located in the same folder as the .nds, if at all possible. No offense intended, but it's sloppy and it shouldn't take hardly any work at all to make this happen (at least now that you're using libnds... I'm not sure how it would have worked before, whether or not it could have handled relative paths...)

 

[Dann Woolf]

When playing megaman 2 on Wily's 1st boss in the castle I had difficulties playing since the characters where flickering alot and the platforms where disappearing and appearing, fix this please.

That's just the way the game is: http://www.youtube.com/watch?v=y1L8OrVOh2g

And that's why I play the Wily Wars version.

 

[nl255]

okay, this is very good.
The reason I ask about the location of the .ini is that on the DSTWO flashcart if you had to put it in the same directory as nesds.nds it would overwrite a DSTWO-specific .ini file that links a program with an image, and the nesds would have a ?, making it harder to see where it is.

A 'global' solution I think would be to change "/nesDS.ini" to "nesDS.cfg".
This will allow the file to 'follow' the NDS file and not conflict with the DSTwo's Plugin.
INI, CFG, DAT, TXT, doesn't matter, only the contents does.

I like TyRaNtM's idea better... /DATA/nesDS.ini

It's so annoying when apps create hardcoded folders regardless of where they are located. Also, from a programming perspective, it's usually the result of laziness. Sure, it's easier to implement just saving the config to the root of the card, but in the end the .ini should be located in the same folder as the .nds, if at all possible. No offense intended, but it's sloppy and it shouldn't take hardly any work at all to make this happen (at least now that you're using libnds... I'm not sure how it would have worked before, whether or not it could have handled relative paths...)

If the ini file is saved in the same directory as nesDS then you wouldn't be able to use it as a DSTwo plugin as the configuration .ini file would overwrite the ini file used by the DSTwo to store the plugin information. Also, not all cards support ARGV which is required for your idea to work which means lots of people will have to go to the trouble of running another loader like moonshell or they won't be able to run nesDS at all. A better idea would be to have it look for /data/nesds.ini first and then /nesds.ini if nothing is found in /data/. That is how dsx86 does it and it works fine.

 

[jurassicplayer]

If the ini file is saved in the same directory as nesDS then you wouldn't be able to use it as a DSTwo plugin as the configuration .ini file would overwrite the ini file used by the DSTwo to store the plugin information. Also, not all cards support ARGV which is required for your idea to work which means lots of people will have to go to the trouble of running another loader like moonshell or they won't be able to run nesDS at all. A better idea would be to have it look for /data/nesds.ini first and then /nesds.ini if nothing is found in /data/. That is how dsx86 does it and it works fine.

o.0 Ini files DO have different sections...It's not insanely hard that it can't read by section or name...I mean, have you TRIED combining the nesds.ini and changing the default path to the one in the dstwoplug folder o.0?

 

[nl255]

If the ini file is saved in the same directory as nesDS then you wouldn't be able to use it as a DSTwo plugin as the configuration .ini file would overwrite the ini file used by the DSTwo to store the plugin information. Also, not all cards support ARGV which is required for your idea to work which means lots of people will have to go to the trouble of running another loader like moonshell or they won't be able to run nesDS at all. A better idea would be to have it look for /data/nesds.ini first and then /nesds.ini if nothing is found in /data/. That is how dsx86 does it and it works fine.

o.0 Ini files DO have different sections...It's not insanely hard that it can't read by section or name...I mean, have you TRIED combining the nesds.ini and changing the default path to the one in the dstwoplug folder o.0?

It seems to work, but don't you think it would be a pain to have to merge the DSTwo .ini file with the one from nesDS every time a new version comes out? Much better to either use a different path or use nesDS.cfg instead of nesDS.ini to store the configuration data.

Also, what about carts that don't support ARGV for getting the current path?

 

[twiztidsinz]

If the ini file is saved in the same directory as nesDS then you wouldn't be able to use it as a DSTwo plugin as the configuration .ini file would overwrite the ini file used by the DSTwo to store the plugin information. Also, not all cards support ARGV which is required for your idea to work which means lots of people will have to go to the trouble of running another loader like moonshell or they won't be able to run nesDS at all. A better idea would be to have it look for /data/nesds.ini first and then /nesds.ini if nothing is found in /data/. That is how dsx86 does it and it works fine.
o.0 Ini files DO have different sections...It's not insanely hard that it can't read by section or name...I mean, have you TRIED combining the nesds.ini and changing the default path to the one in the dstwoplug folder o.0?


It seems to work, but don't you think it would be a pain to have to merge the DSTwo .ini file with the one from nesDS every time a new version comes out? Much better to either use a different path or use nesDS.cfg instead of nesDS.ini to store the configuration data.

Also, what about carts that don't support ARGV for getting the current path?

You wouldn't have to change the ini file unless the INI file structure was changed.
Features (should) always have a default, so if a new option not included in the INI file it would just be set to whatever is the default setting is.


But either way, I really like the /DATA/nesDS.ini idea as it solves all problems as far as I know, and is a simple fix (I see my post on the previous page for a compiled version that uses that folder).
Some "lesser" cards might have issues with accessing files in different folders while in homebrew, but those should be the exception not the rule, so for those users have it access /DATA/nesDS.ini first and if nothing there then /nesDS.ini like you said.



QUOTE(qwertymodo @ Mar 23 2011, 02:27 PM)

It's so annoying when apps create hardcoded folders regardless of where they are located. Also, from a programming perspective, it's usually the result of laziness. Sure, it's easier to implement just saving the config to the root of the card, but in the end the .ini should be located in the same folder as the .nds, if at all possible. No offense intended, but it's sloppy and it shouldn't take hardly any work at all to make this happen (at least now that you're using libnds... I'm not sure how it would have worked before, whether or not it could have handled relative paths...)

Sorry, but I have to disagree... Set folders are perfectly find and acceptable as they give STRUCTURE to files rather than leaving your card a mess.
I do see the merit of having nesDS.nds and nesDS.ini in the same folder, I just think that keeping settings and extra files in a /DATA// folder is a far cleaner solution.

For example, I have 3 applications that use 'extra' files: Bunjalloo, DSx86 and IKUReader.
Thankfully they all use the /DATA/ folder to store their files, because if they weren't (according to you) being "lazy", my Homebrew folder would be an ABSOLUTE MESS of files.

 

[Deleted-236924]

If the ini file is saved in the same directory as nesDS then you wouldn't be able to use it as a DSTwo plugin as the configuration .ini file would overwrite the ini file used by the DSTwo to store the plugin information.

Easy...
Change it so that it becomes nesDS.cfg

Besides, you aren't forced to keep the nesDS.nds file name, you can have the DSTwo plugin be nes.nds and nes.ini while the .ini for the emulator would be named nesDS.ini.
Shouldn't cause problems then.

I think having the configuration file kept in root is better.


ALL of these solutions work — I'm using a DSTwo right now.
What's the point of having a .ini file if it doesn't let you save the screen scaling?
It does let me disable every shortcut though. DIS I LIKE.