gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Help Wanted > Paid help wanted - mod and recompilation existing homebrew

#173580 - JonP01 - Sat Apr 17, 2010 2:01 pm

Hi,

I am looking for an individual with a demonstrated high level of expertise in C++, current versions devkitPRO and programming for the Nintendo DS in order to help me effect some (I believe relatively minor) modifications to an existing homebrew chess game for the Nintendo DS. I am also seeking to have a couple of minor bugs in the user interface of the same game rectified.

So long as you have the expertise required and can successfully effect the modifications I would like (subject of course to satisfactory testing), I am prepared to pay you a fee of 100 euro via Paypal.

The homebrew in question ceased development two years ago and I have not received any responses from the original author. In 2008, the author listed for download on his website both the nds binary and his own source code (which I understand would have been compiled using a contemporary version of devkitARM).

The homebrew game itself used an open source chess engine known as Fruit, which itself has ceased development. The particular version it is based upon was version 2.1 - a freeware version released several years ago with an open source licence.


What I am specifically looking to have done

1. Currently this homebrew game offers several types of playing levels. The first set of playing levels represent a fixed amount of time the program takes to calculate a response to it's opponent's move. At present the highest level offered is 40 seconds per move. I am looking to have the following additional fixed time levels added:

60 seconds per move
90 seconds per move
120 seconds per move


An additional set of playing levels are offered whereby the program will complete the entire game within a specified time. Currently, the longest playing time the user can select is 40 minutes per side per game. I am looking to have the following levels added:

60 minutes per side per game
90 minutes per side per game
120 minutes per side per game


The game also offers levels similar to those described above, however they are supposed to add a certain amount of incremented time for every move. For example, the player gets a 3 second bonus for every move they make. So far as I can tell, these incremental levels simply do not work, so I would like to have these levels removed from the program, rather than spending what would probably be even more time attempting to debug them.


2. There are a couple of minor bugs in the user interface when the user selects the playing level. The author admitted at the time of the last release that the game had had very little testing, so my belief is that these issues are simply a case of the program not having been debugged as regards the function of the level selection menu.

Please note I have identified the source C++ code that relates to the levels available and the level selection logic, etc.

3. I have attempted to compile the original source code using the current version of devkitARM within devkitPRO. I was unsuccessful in this endeavour, however since I lack any knowledge of C++ and devkitPRO, I do not know if this is a case of "user error", or a case of the source no longer being compatible with current versions of devkitPRO.

Obviously being able to compile the existing source and then successfully executing the resultant binary on the actual console is critical to this project. As I mentioned previously, my understanding is that the original source was successfully compiled using an earlier version of devkitARM (the source includes makefile files, etc).

The last part of this project then, would be to provide me with the source code correctly modified / amended in such a way that it successfully compiles using current versions of the devkitPRO development tools.


How I will contribute to this project.

Apart from offering a financial reward of 100 euro to anyone who can successfully address all the points I have raised, I will thoroughly test any changes you need to make to the program. If and when the items I have discussed above are addressed, I will test the resulting nds binary on my DSi console. Upon the completion of a satisfactory test, I will then effect payment via Paypal.

Although I have no experience whatsoever in C++, console game development or homebrew, before my retirement my main occupation was writing visual basic applications in Microsoft Office, therefore I probably have a very basic overall knowledge of fundamental programming concepts. This might make liason between us a little easier.

Additionally, I have 30 years experience in using chess playing programs and nearly 40 years chess experience. Again, this may be of some assistance, though I am hoping the enhancements required will be restricted to that part of the source code dealing with user input on the playing level selection screens. I can only hope anyway :)

About me

As mentioned previously, I am now retired but used to write financial programs in Office visual basic for a large corporation. I have long been looking for a strong chess program on the Nintendo DS / DSi / DSiXL console without success. Currently, all commercial programs are extremely weak (the strongest is roughly 1900 SSDF ELO). The current version of this homebrew program, however, is reasonably strong (~2250 ELO). It is, however, handicapped by it's current playing levels and could stand to increase it's playing strength by around 200 ELO with the modifications I have described.

I realise it is hard to establish my bona fides over the internet, however I can provide certain information to you (such as my 9 year eBay history). This may give you confidence that am person of my word, so long as you are too :)

If you feel you have the expertise and interest in assisting me, please do not hesitate to PM me.


Thank you

#173584 - JonP01 - Sun Apr 18, 2010 3:14 am

Hi,

I would like to thank people for their responses. I have obviously come to the right place. I have a dilligent respondent attending to this problem so at this stage there is no need to send me any further enquiries regarding this little project.

Thank you again

#173599 - wintermute - Sun Apr 18, 2010 5:49 pm

Recommend that whoever is doing it switch to using the default arm7 binary & use an arm9 only template as a basis. I had a brief look at this yesterday but I need to take a look at the sound functions, already moved to the arm9 template approach if it's any use.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#173600 - Pete_Lockwood - Sun Apr 18, 2010 5:55 pm

It's working, dropped the arm7 code entirely, sound works fine.

edit: That said, it runs out of memory in NO$ with the original hash table size. My DS is at work so I don't know if this is a NO$ weirdness or if the original code was already nearing the edge and the recent changes to libNds tipped it over. Downloaded a new package yesterday so I would've thought I had the stuff with optimization.
_________________
It's not an illusion, it just looks like one.

#173604 - JonP01 - Mon Apr 19, 2010 5:17 am

I'd just like to say that Pete has been doing an absolutely fantastic job - well beyond my hopes and expectations. I am so glad that he responded to my request for help, because I simply could have asked for anything more from anybody. My only regret is that the fee I am paying him is peanuts and not remotely reflective of the fee payable were this a commercial undertaking.

Within hours of agreeing to help me, he had already delivered a binary using the current tools and after two days he has already delivered several new builds with the features progessively being added and glitches / bugs being promptly resolved.

Right now, after only two days, all the original features I wanted are now incorporated in a binary on my emulator so I can now spend the week testing and get back to him next weekend. He has even done quite a few things beyond the call of duty - some of which I had simply put in the too hard basket - not because they were unsolvable, but simply because I am very conscious of not demanding more time than I feel I deserve and what time limits are realistic in view of the small remuneration.

Yes, it is clear that in working with the new tools the strength of the program at the comparable time controls has been hurt a little, however I do believe that even in it's current state this is the first program on a portable Nintendo console likely to break through the 2100 Swedish ELO barrier (and that is a genuine 2100 ELO that should be demonstrable through a long series of matches against rated opponents - not the ubiquitous, massively exaggerated "pretend" ELOs I keep coming across on internet discussion boards and in manufacturer's claims (as an example, the commercial Nintendo DS version of Fritz plays pathetically at the standard time controls - it would be lucky to play more than 1400 - 1500 ELO, yet the manufacturer claims an ELO of 2320. Even at it's maximum possible thinking time, I have already proven through a series of over 70 games played against rated opposition at slow torunament time controls that the program plays in the 1900 - 2000 ELO range - still far short of the claims made for it (and it plays an absolutely pathetic endgame at that).

Luckily, hash table issues are less of a problem when you are running on relatively modest hardware such as 67 Mhz ARM processors, as opposed to current generation PC processors. The slow CPU speeds simply do not enable chess programs to conduct searches anywhere near as exhaustive as even PC programs of today running at only a few seconds per move, and thus the amount of data useable in a hash table is much less. In any event, the program still benefits enormously from the hash tables in the endgame, where I have seen it reach 22 ply search depths in under a minute in King and a couple of pawn endgames.

But let's be realistic too - the bigger the better and the stronger the program will play, especially at the longer time controls.

I would even speculate that if the program were ever able to be modifed in such a way that it took full advantage of the DSi hardware capability (versus DS hardware capability), that we would come very close to the 2400 ELO barrier (FIDE male International Master strength) and it would at the very least play at the strength of a male FIDE Master title holder (2300 ELO).

(I should point out that the existing version of the program could not be tested for true playing strength because it did not provide the playing levels necessary for it to engage in rating matches that follow official FIDE or SSDF rules).

Anyway, again my sincere thanks to what Pete has achieved even thus far and I look forward to doing extensive testing over the working week.

#173605 - wintermute - Mon Apr 19, 2010 12:11 pm

Pete_Lockwood wrote:
It's working, dropped the arm7 code entirely, sound works fine.


Cool, I assume you changed the sound calls? I was thinking about adding back a function to take a struct rather than specifying all parameters in the function, still a bit undecided.

Quote:

edit: That said, it runs out of memory in NO$ with the original hash table size. My DS is at work so I don't know if this is a NO$ weirdness or if the original code was already nearing the edge and the recent changes to libNds tipped it over. Downloaded a new package yesterday so I would've thought I had the stuff with optimization.


There are still things in the latest gcc & newlib versions which take more memory than previous versions. It's certainly possible that it was close to the edge though. Might be worth looking at what C++ features it's using and seeing if they can be replaced with lower footprint code - new/delete are much larger than malloc/free & the former can be overridden to get rid of all the exception code that causes the bloat.

As for modifying the game to take advantage of the DSi hardware - you don't need to. Binaries built with the latest tools will already use the extra RAM & higher CPU speed when run in DSi mode.

Paying peanuts might be resolvable with a bit of crowdsourcing - run a chipin, see how many people are willing to donate for the improvements you're making to the game. Obviously you can't release binaries without the corresponding source code but you could make the release contingent on donations of a particular level.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#173607 - Pete_Lockwood - Mon Apr 19, 2010 1:12 pm

wintermute wrote:
Cool, I assume you changed the sound calls? I was thinking about adding back a function to take a struct rather than specifying all parameters in the function, still a bit undecided.


Yeah, simply wrote a wrapper to imitate the old approach and passed the correct value for the format enum.


Quote:
There are still things in the latest gcc & newlib versions which take more memory than previous versions. It's certainly possible that it was close to the edge though. Might be worth looking at what C++ features it's using and seeing if they can be replaced with lower footprint code - new/delete are much larger than malloc/free & the former can be overridden to get rid of all the exception code that causes the bloat.


I've done a little looking and it does look like it's just that it was already close to the edge. The original makefile had -Os (which I've still got set) and that seems to suggest (if I'm not mistaken) that he was more concerned with binary size than performance optimization, which considering the application is a curious choice unless he was running out of room.

I'll spend some time seeing if I can excise any bloat to get the hash size back up for regular DS.
_________________
It's not an illusion, it just looks like one.

#173608 - JonP01 - Mon Apr 19, 2010 1:33 pm

wintermute wrote:
As for modifying the game to take advantage of the DSi hardware - you don't need to. Binaries built with the latest tools will already use the extra RAM & higher CPU speed when run in DSi mode.


Am I correct in saying that the no$gba emulator cannot run in DSi mode, so effectively I would not be seeing the full playing strength of the program on the emulator as opposed to when I am finally able to run it on my DSi console?

#173609 - Sektor - Mon Apr 19, 2010 1:47 pm

no$gba doesn't emulate DSi mode and none of the current flash carts run in DSi mode. Current DSi compatible flash carts run in DS mode on DSi.
_________________
GTAMP.com/DS

#173610 - JonP01 - Mon Apr 19, 2010 1:50 pm

OK. Thanks. So I guess we are tied in any case unless a cart comes out that will run in DSi mode, but it is good to know the code itself would be DSi-ready.

#173612 - Sektor - Mon Apr 19, 2010 2:12 pm

It does depend how it was coded (not just how it was compiled). When Worms was ported from PSP to 360, the AI took just as long to take their turns as the PSP version. They eventually fixed it (it now performs better moves in much less time). Of course Worms isn't Chess but it is a turn based strategy game and the AI has to simulate many moves in a short amount of time to determine the best one.
_________________
GTAMP.com/DS

#173614 - headspin - Mon Apr 19, 2010 6:56 pm

When I read the title of this thread I thought to myself "oh no another one of those threads". Turns out to be one of the few well written, consise and polite ways to ask for help on here and to top it off an offer of something in return for services rendered. So kudos to the original poster and those who helped out.
_________________
Warhawk DS | Manic Miner: The Lost Levels | The Detective Game

#173624 - Pete_Lockwood - Tue Apr 20, 2010 2:27 am

I had an old 1.3.2 install lurking on my PC so went back and did a build with that.

Original binary ~399Kb
Binary with latest tools ~507Kb
Binary from 1.3.2 ~463Kb - and working with the larger hash table.

For fun I then replaced the 1.3.2 libNds with the latest (i.e. still older GCC) and produced a binary of ~485Kb that also works fine with the larger hash table. So I guess I need to shave off at most 22Kb to be able to compile and run at full power with the latest tools and libNds. I guess it really was just that close to the edge (I had independently estimated that it might be around 10Kb short based on how much more I thought it needed to allocate).


I think the answer is simply going to be to move a binary file that's currently compiled into the executable out to the SD card.
_________________
It's not an illusion, it just looks like one.

#173625 - elhobbs - Tue Apr 20, 2010 2:54 am

Make sure you are only looking at the arm9 binary when you are comparing the size. When wifi was added to the default arm7 it caused the nds file size to jump quite a bit if you are not using wifi.

#174069 - dheart88 - Sun May 16, 2010 11:15 pm

Well, this conversation isn't suitable for newbie like me.. I'm the worst when it's about compiling (about hash table and so on).. In my collage, I almost failed in compilation making (AHO as the reference to make a pascal compiler)... btw, is there a tutorial how to understand the process inside a commercial DS game?

And if it's possible to understand the .nds ASM so it's also possible to take the resources they use. Am I right?? sorry for my OOT talk.. because I'm really amazed with this thread.. since I'm really a newbie