| Author |
Message |
Fergus Duniho (Fduniho)
| | Posted on Thursday, May 24, 2001 - 5:38 pm: | |
I have begun some experimenting with the new ability to use multiple grid statements, to find out what it is useful for.
In one test, I put one grid on top of another. They occupied the same board space but had different coordinates. I placed a Rook on the second board, where a Pawn was on the first. The pawn appeared on top of the Rook, which is good. But when I moved the Pawn, the Rook's image disappeared. It would be better if the Rook's image was refreshed after the Pawn moved.
In another test, I modified my Shogi script to use a separate grid for each section. This eliminated the need for (kill-positions), and I thought it would reduce the need for (unlink), but it did not. Although (directions) is part of the (grid) block, the (directions) block in the first (grid) block overrode all my other (directions) blocks. With the board first, and the off-board positions in the next two (grid) blocks, pieces had the same powers of movement off-board as they had on-board. Also, I defined next in left/right directions for the board and in up/down directions for off-board, but it used left/right directions for next even off-board. This is not what I wanted or expected to happen. Since the (directions) block is part of the (grid) block, each set of directions should be local to the grid it is defined in, not global to every grid. |
David GLAUDE (Glu)
| | Posted on Friday, May 25, 2001 - 2:39 am: | |
I don't believe multiple grid statement are supposed to be used to make board overlap each other. It should be used if your game is made of two or more totally separate board with few in between link. But I need to give it a try.
From my point of view grid statement should be treated and implemented as macro processing command (like macro and include).
As for your drawing problem, there is a problem with overlapping piece in a board. Currently, if you make multiple position that partially overlap (not one hiding each other) then the drawing of the board get confuse. And this including when the overlaping section of both piece picture are transparent (and thus the board should be visible properly).
I see multiple option for solving this "bug":
* Document the fact that overlapping position are not recomended (or not supported)
* Display a warning when ZRF file use that (use that buggy feature)
* Stop and display an error when in use (but those two last option will break many game that somehow use it)
* Implement overlapping correctly, define explicitly or implicitly a drawing order of the board then position.
One work arround I use in one of my test game is to type twice Ctrl-E for enlarge. This force a complete redraw and sometime give some result. Another trick that might work is displaying position (now F6).
The major problem in supporting properly overlaping is the potential flashing of the board when redrawing it, howerver with double buffering it should be possible to avoid that side effect.
David GLAUDE
Jeff: This is for you. ;-) |
Fergus Duniho (Fduniho)
| | Posted on Friday, May 25, 2001 - 8:17 am: | |
I believe that multiple grid statements should support overlapping boards, at least to some degree. Although it wouldn't be feasible to let the player pick up pieces from either one of two overlapping spaces, that is not what I want overlapping boards for. Rather, I want one board to serve as a background, containing pieces which show up behind the main pieces, even though they cannot be handled with the mouse. Being able to do this would let me reduce the code for Sisyphus, which currently has to do lots of extra work to keep the target spaces yellow. |
Jeff Mallett (Jeffm)
| | Posted on Friday, May 25, 2001 - 8:23 am: | |
David is correct: nothing was added for overlapping positions when support for multiple grids was added. The intention was simply to make it easier to program games with multiple simultaneous boards or games with a board made up of separate grid-like sections.
As for overlapping positions, these were not envisioned in the original design and I would recommend not doing this. I imagine the biggest problems to overlapping are drawing problems and the inability to click on positions (because one position is hiding another). I don't think these problems will be resolved until the concept of layoring/z-order is implemented in Zillions, including new syntax. |
Fergus Duniho (Fduniho)
| | Posted on Friday, May 25, 2001 - 6:47 pm: | |
Okay, I'll accept that, but in this discussion over overlapping positions, let's not lose sight of the more important issue, which is how (directions) works in the (grid) statement. I hope you can make it work the way the syntax suggests it should. |
Jeff Mallett (Jeffm)
| | Posted on Monday, May 28, 2001 - 10:22 pm: | |
The directions can't be entirely local to the grid, because the named directions defined there are used elsewhere, such as in the piece move code; however, I see your point, that it would make sense if the a grid were only linked up with directions it defines. That would require more ZRF code in the normal case where you want the grids to have the same directions (you'd have to repeat the direction definitions for each grid), but less code in your case, where you have to unlink unwanted directions. More important though, having "local" directions would be more powerful, assuming you could redefine the same direction differently in different grids. For example, if you wanted to make pawns go backwards on files e-h of a chessboard, you could simply make the chessboard composed of two grids that you'd link up. The first would define (n 0 -1) and the second would define (n 0 1). It would all be the same direction as far as a piece is concerned, though the links would be set up as if space was reversed...
Yes, I like this idea and will get this in the a quick 1.3.1 patch. So, let this be a warning to anybody using multiple grids in 1.3: you should put all directions you want a grid to have in its definition, rather than assuming inheritence from earlier defined grids. By doing this you'll be compatible with future versions as well as being compatible with 1.3. |
David GLAUDE (Glu)
| | Posted on Wednesday, May 30, 2001 - 6:17 am: | |
MULTI-GRID:
I think the new definition (1.3.1) is indeed more powerfull and should have been the one and only one ever used for multiple grid support.
Direction names are of course global but theire delta grid coordinate on a specific grid might be different (MUST be if grid don't have the same number of dimention 2D against 3D, how do you deal with that? Do you support that?).
So make sure grid statement really behave like a macro processing feature that translate into links and positions. Make sure direction are local information to a grid, and not global that overwrite previous definition if any.
OVERLAPPING POSITIONS:
The drawing problem is not really difficult, you just need to draw the background, then every visible (not dummy) piece and position into a "buffer" then display that buffer on the screen.
Notice that you may want to compare actual screen and futur screen to make delta update rather than full update (using dirty rectangle or so).
Inability to click on position must be known by the ZRF developper. One issue I see is that the computer AI is not "clicking" and don't know that the user is "clicking". So computer will see all legal move where user only see or reach practical move. This might be interesting thing in fact.
It is up to the ZRF writer to make sure this does not happend in the game. However, and unrelated to this it might be nice to let the user see in a window the list of all possible legal move (just like when ambiguous move are generate by the mouse). This will also help game developper see the mistake in ZRF and the representation in the saved game. Another related feature is to visualy choose from all the possible move (with a NEXT/PREVIOUS/PlayThis/Cancel set of buttons).
I don't think layoring/z-order concept need a new syntax. You just have to say that implicitly, position define first are on-top/at-the-bottom.
Also the translation order from grid to position need to be known and defined. This mean all current game already have implicit layoring information. The current syntax is "strong" enough to support this concept.
If you want more flexibility, then the position/grid statement can have a (on-top) or (at-the-bottom) option to precise where it should be z define.
David GLAUDE
PS: I know it require a bit of coding to implement, but Jeff, don't hide yourself behing theoritical/hypothetical consideration. It is eassy to think and do. ;-) |
Jeff Mallett (Jeffm)
| | Posted on Wednesday, May 30, 2001 - 9:02 am: | |
>(MUST be if grid don't have the same number
>of dimention 2D against 3D, how do
>you deal with that? Do you support that?).
In 1.3 each direction defined by a grid is inherited by all grids, so therefore the grids have the same dimensions. In 1.3.1 you'll be able to have different numbers of dimensions without unlinking. This is an implementation change as grid directions had been global in all earlier versions.
>OVERLAPPING POSITIONS:
>The drawing problem is not really difficult, you
>just need to draw the background, then every
>visible (not dummy) piece and position into a
>"buffer" then...
Hello, is this the room for Graphics 101?:-) Of course we do all this already -- the problems are a little more subtle -- and of course I know how to add support.
>PS: I know it require a bit of coding to
>implement, but Jeff, don't hide yourself
>behing theoritical/hypothetical consideration.
I'm hiding?? My point was not that Zillions would never support overlapping positions, but that Zillions does not currently support overlapping positions. |
Jeff Mallett (Jeffm)
| | Posted on Sunday, June 17, 2001 - 10:06 am: | |
Version 1.3.1 is out now. From the list of changes:
"If a variant contains multiple grids, they are now linked up only with the directions they define, not with directions defined in other grids." |
|