 |
| Slartibartfast 2003-10-06 05:47:42 | As my notebook wasn't doing much at the moment I downloaded the *nix client as well, but even replacing the lattice file with 'up to 15cm' it keeps calculating 3 beam structures only. The Windows version more in the region of 55, 57 or 59, I aborted the client and ran the Windows version using Wine. Impressive, the graphical client even works, although I find it a waste of cycles if it can use those towards calculating, so I switched it to console (to have some idea how things are doing). Apart from a Wine error message (MSVCRT sopen, pmode ignored) during autosave (which does work), seems to be going strong. I've only had it running like this for about 10 minutes or so, took a couple of screenshots that I can post later if you all are interested in it. |
| Stephen Brooks 2003-10-06 12:38:05 | The screenshots might be interesting (we have some Linux machines here). I'd always assumed DirectX graphics via WinE was a lost cause! It doesn't make any sense: that's why they call it "virtual" |
| Slartibartfast 2003-10-06 12:49:00 | the screenshots I have of the Win client running under Wine are of the console, I'm not sure how to get the screencap to work while in graphical mode, as it works full screen just like it does on Win32. It looks the same to me in any case. If anyone knows how to take a screen cap while running a program in full screen on RH 9 Shrike, I'll give it a go. It's RH9 out of the box, same with Wine (latest stable build), in case you want to try it out yourself as well. Will the console screenshots be any good to post? (since that's what I meant earlier in my other post). |
| Slartibartfast 2003-10-06 13:22:50 | actually, on DirectX via Wine, there's quite a few games running that way. And as I installed Deus Ex on Wine that's most likely the reason the graphical client didn't complain about DirectX and ran. If you want to make the v5 release a cross platform release, perhaps looking at libsdl.org won't hurt. A lot of ports and intentional cross platform releases make use of it. In conjunction with OpenGL it's great. Another idea that I had. If during rechecking results one run comes out better than another, why not write it to the results file as well instead of the average (and total Mpts). e.g. sfinall=999;sfinalf=999; 9.081908 (x Mpts) [v4.32b] {6F1D91EA} sfinall=999;sfinalf=999; 9.081908 (x Mpts) [v4.32b] {6F1D91EA} sfinall=999;sfinalf=999; 9.081908 (x Mpts) [v4.32b] {6F1D91EA} sfinall=999;sfinalf=999; 9.081908 (x Mpts) [v4.32b] {6F1D91EA} sfinall=999;sfinalf=999; 9.081908 (x Mpts, total 1605.2) [v4.32b] {6F1D91EA} basically keep going until the 5 runs are done, remembering the results, then writing out all 5 using the same check code so it's apparent they're of the same batch. Meaning if any of the 5 has a better result than the average it has a better chance of ending up in the best100.txt, bettering the results after that. an idea anyway  |
| [DPC]Stephan202 2003-10-06 13:41:25 | Indeed the highest results need to be in best100.txt. But these results need to be accurate too. That's why it's better to filter high results on their average yield. This prevents an accidently high result from being added to best100.txt There have been abnormal results in the stats before. Only permitting rechecked results to best100.txt means that all configurations in there are (almost) guaranteed to be real good, not accidently good. --- Dutch Power Cow. MOOH! |
