Closed fredvs closed 6 years ago
Hello Fred! I got an error message when I launched Github Desktop and clicked on the "fetch origin" button. But after that I could "pull origin" and compile the program.
I believe we should continue to follow the rule of not touching anything while the other has the hand.
For me I have a private copy of Eschecs that I use to make some tests when I know that you are working on the project. :)
I like the 240 chessboard. The animation of the user move, the animation of the computer move, the sound, all is perfect. It's almost as beautiful as lichess.org. :) Maybe the 240 chessboard would need a border, so that the work "promotion"won't be cut. For now we could simply disable that style. In the future, we should rethink all the style management.
Hello Roland.
Wow for the mini-chessboard. Maybe for the menu-item, only keep item "Eschecs" and transfer "Moves", "Board", etc as sub-menu of "Eschecs" for mini-chessboard.
This to not cut the menu panel.
I believe we should continue to follow the rule of not touching anything while the other has the hand.
For me I have a private copy of Eschecs that I use to make some tests when I know that you are working on the project. :)
Huh, I will tell you a secret (dont repeat it please). I am still terrorized by Git. So, yes I prefer the rule "a vous la main".
Fre;D
Re-hello.
Or keep only "Eschecs" "Move" and "Promotion" as item in main-menu and transfer "Option" and "Board" as submenu of "Eschecs".
Or simply transfer "Board" as sub-menu of "Options", there should have place enough for "Eschecs" "Move" "Promotion" and "Option" menu-items.
Re-hello Fred! Yes, it's a good idea, to transfer some menu into another. Let's take some time to think to that. In the future, the "promotion" menu should disappear. It would be better to have something like a dialog box which is opened only when there is a promotion, to ask the user choice. If ever you have a ready to use solution, we could make that modification. Maybe a simple popup menu? When we have solved that problem, we could make a release, no? Regards. Roland
When we have solved that problem, we could make a release, no?
Yes, nearly!
I did compile/test Eschecs + Moustique on FreeBSD 64. Moustique + Eschecs + Audio works perfect.
;)
But I did not try to compile Fruit and I am no sure to have all the compile-tools to make it. I will try.
Anyway, what do you think to choose Moustique as default engine? If you prefer no, I can adapt Eschecs code for FreeBSD.(if I loose to compile Fruit).
For the release, maybe you can do a "alpha-pre-release" Windows 32 bit that I will use as layout for Unix release?
Have you decided how to deal with multi-arch ? Windows 64 is multi-arch so it can run engines 64 and 32 bit. Would you propose in the Windows 64 release the 2 types of engines (64 and 32 bit)?
Linux 64 bit is also multi-arch but not by default so Linux 64 release will have only 64 bit engine.
For audio libraries, maybe you prefer only root folder /audio/lib and not the sub-folders. No problem for this but Sound.pas code must be updated.
Note that for libraries, Eschecs 64 bit needs audio libraries 64 bit, Eschecs 32 needs audio libraries 32 bit. (this for Windows and Unix).
Also, before the release, maybe test all deeply.
Ha, yes, the most important, do not forget to add the feature:
if fredisplaying then lethimwinsometime;
;)
Fre;D
Re-hello.
For the Raspberry pi release, I have to fight first with fpGUI window-manager bug. I am not sure to find time asap for this.
Fre;D
Re-hello Fred ! Yes, we can choose Moustique as default engine. For the "lethimwinsometime" option, I will think of it. :) Will make a longer answer to your message tomorrow. I discovered a bug. When the computer promotes a pawn, the user's queen changes of color! I must fix that, and test seriously all the special situations (en passant, promotion, castling). Have a good night! Roland
Hello Roland.
OK I was able to compile (very tricky) Fruit for FreeBSD, so no need to make Maousique as default engine. FreD
Hello Roland.
I did some test with Fruit compiled with gcc vs clang. The result is surprising in speed and size with clang.
Maybe you may try to compile Fruit-Windows with clang too: http://releases.llvm.org/download.html#7.0.0
Fre;D
Hello Fred! Ok, I download LLVM.
You won't believe me, but I have almost no idea of what is FreeBSD and Raspberry. But I am very glad to know that Eschecs will work on all these systems. :)
For your previous questions (deal with multi-arch, audio libraries), I think we could have on our hard disks all the files in engines/ folder, and select automatically the good files when doing ZIP packages. The same for Eschecs binaries and why not for libraries.
We can make a different eschecs.eng for each package. We can also make only one, with different sections, as you suggested. Yes, the Win64 system supports Win32 applications, but as a user I see no interest in having Fruit32 AND Fruit64.
I will try to fix the bug relative to promotion. That part of the program is complicated. I would like to remake it more cleanly one day.
See you!
Roland
Hello Roland.
IMHO, different eschecs.eng will be simpler,each one for each package.
About the libraries and the engines, maybe after the first release, when all isok, we may delete all the binaries from Github-source.
People may find the binaries in the release.
About LLVM I would be very interested, if you was able to compile Fruit, to have your impressions about size + speed of programs compiled with LLVM on Windows 10.
Fre;D
but as a user I see no interest in having Fruit32 AND Fruit64.
Maybe the super-champions could find Fruit64 faster than Fruit32 (or the reverse)?
Re-hello Fred! Thank you for your messages.
Uploading the engines to Github? I used to believe that Github was only for source code. I used to believe that we would create ZIP file on hard disk and upload to Github. For me it would be easier, because I have tools to do that.
OK, I will give a try to LVMM ASAP.
I fixed the bug of the computer pawn promotion! See last commit.
Regards.
Roland
Uploading the engines to Github?
No, delete the engines and audio libraries from Github-source.
Uploading the engines to Github?
Yes, to "release" feature of Github (Click on "release" on your Github page, after "commit" and "branch").
OK Fred, I understand. So, who will start, you or me? What would you think of a "release candidate" version or something like that?
Or maybe for the first of the first, I will do one for Windows 32 bit, upload it to my Google site. Then you try it, change it and then do a first "release candidate" on Github-release?
Ok Fred, let's do that!
Moustique has a logo. :) http://www.peterrake.com/display_model.php?id=117
Wow for Moustique-logo.
https://sites.google.com/site/fredvsbinaries/eschecs_win32.zip
The executable is not the one from your last commit. Also check license.txt and credits.txt.
Fre;D
I have to leave, read you tomorrow..
Fre;D
Before I go, please do a check with -ghl for Moustique.
Here on Linux and Windows via wine there is no memory leak. But who knows with Windows 10.
;)
Fre;D
Thank you Fred. I test your package and come back to you. I will also check moustique with -ghl. Regards. Roland
No memory leak detected on Moustique. ;
Hello Fred!
A first report. All looks to be OK.
Some little observations.
The first time I executed Eschecs, it did freeze and take a very long time when I want to switch from Fruit to Moustique. After that I could switch without problem. I think it's because of Windows Defender. I have that problem with all my applications. So I believe there is nothing to do about that.
The sound for check event is not the latest one that I did choose. I will repush mine to Github.
DEBUG, FEN, INI and LOG files shouldn't be included. Only the ENG file.
I have already a "credits" section in readme and lisezmoi files, so if this is OK for you I will just append missing things in these files. Or is a separate credits file absolutely necessary?
My latest commit is important: it's a bug fix.
Regards.
Roland
An important point.
I would like that the source code of each engine be included, in a source/ folder or in a compressed file, in the same directory than the executable. I even believe that we must do that, to respect licenses of open source engines.
A question. Do you intend to insert the version number in the ZIP file name? As the project has made a big step (with your collaboration), I had in mind to give to the next release the number 4.0 (or 4.0.0). After that we could continue to 4.0.1, 4.0.2... The previous release was 3.1.5. Now the application is multiplatform, so it deserves a new major version number.
IMHO we should include also the readme files of the engines and all the TXT files. For example Fruit 2.1 has a readme.txt and a technical_10.txt. Moustique has a readme.txt and a lisezmoi.txt.
Very important.
You didn't include Fruit book! The file name is book_small.bin.
Re-hello Fred! I am playing with BGRABitmap and TrueType fonts. What do you think of this? I can apply the same effect for other fonts. For a future version...
Hello Roland.
Or is a separate credits file absolutely necessary?
It is more fair (IMHO).
About the files missing in my first pre-alpha release I agree with all. About source included in release, I dont know, I am not layer. In Audio/lib/windows/32 , please keep only LibPortaudio-32.dll and LibMpg123-32.dll. The 2 others were added by mistake.
You didn't include Fruit book!
Ha, ok, (strange it works without it here).
IMHO we should include also the readme files of the engines and all the TXT files.
If you give the sources in a zip files, IMHO you may included also he readme.txt in the zip file.
Ok for zip release-numbers.
I have to do a pull-request, when you have done all your commits, please prevent me.
Fre;D
Hello Fred! Yes the engine works without the book, but it isn't a reason to not include it. :) I have no commits to do, so you can go. Regards. Roland
Thank you Fred. I am at work. I will test the new code tonight.