Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!loft386!dpi From: dpi@loft386.UUCP (Doug Ingraham) Newsgroups: gnu.chess Subject: Re: gnuchess bad movement Summary: I found and fixed this. Message-ID: <516@loft386.UUCP> Date: 26 Sep 89 17:02:52 GMT References: <27401@shemp.CS.UCLA.EDU> Organization: Lofty Pursuits, Rapid City, SD USA Lines: 83 In article <27401@shemp.CS.UCLA.EDU>, rosa@maui.cs.ucla.edu (Berthier Ribeiro Araujo Neto) writes: > I got some problems with gnuchess. It is running, but plays strangely > sometimes. In the game below, it moves the pawn over the knight when > I play > > f1e1 (rook one square left). > > Could anyone try this movement to see it the mistake happens in other > environments? > > > Thank you in advance, > > --Berthier The problem is in the new module move.c in the function GenMoves. Here in its entirety is GenMoves with the blocked double pawn advance fixed and the missing test for enpassant pawn captures. --------------------------------- cut here --------------------------------- #if (NEWMOVE > 5) GenMoves(ply,sq,side,xside) short ply,sq,side,xside; /* Generate moves for a piece. The moves are taken from the precalulated array posdata. If the board is free, next move is choosen from nextpos else from nextdir. */ { register short u,piece; register struct sqdata *p; piece = board[sq]; p = posdata[side][piece][sq]; if (piece == pawn) { u = p[sq].nextdir; /* follow captures thread */ while (u != sq) { if (color[u] == xside || u == epsquare) LinkMove(ply,sq,u,xside); u = p[u].nextdir; } u = p[sq].nextpos; /* and follow no captures thread */ while (u != sq) { if (color[u] == neutral) { LinkMove(ply,sq,u,xside); u = p[u].nextpos; } else break; /* this will prevent a double move if blocked */ } } else { u = p[sq].nextpos; while (u != sq) { if (color[u] == neutral) { LinkMove(ply,sq,u,xside); u = p[u].nextpos; } else { if (color[u] == xside) LinkMove(ply,sq,u,xside); u = p[u].nextdir; } } } } #endif --------------------------------- cut again ---------------------------- I haven't found any other real bugs, but changing several for loops to memset and memcpy made a 30% difference in speed. I also changed an if then else sequence to a switch which speeded it up 5%. I cleaned up the board editor code. Also some trivial name changes for compatibility with SYSTEM V 3.2 curses. The variable beep conflicts with a curses beep function. I will be sending diffs to Stuart Cracraft for inclusion in the next release. I hope this helps. -- Doug Ingraham (SysAdmin) Lofty Pursuits (Public Access for Rapid City SD USA) uunet!loft386!dpi