So, trying wxHaskell. First, I want to try removing everything that might be left over from yesterday's experiments:
Pauls-Mac-Pro:~ paul$ brew list gettext libffi pkg-config xz Pauls-Mac-Pro:~ paul$ brew uninstall gettext libffi pkg-config xz Uninstalling /usr/local/Cellar/gettext/0.18.3... Uninstalling /usr/local/Cellar/libffi/3.0.13... Uninstalling /usr/local/Cellar/pkg-config/0.28... Uninstalling /usr/local/Cellar/xz/5.0.5... Pauls-Mac-Pro:~ paul$ port installed The following ports are currently installed: libiconv @1.14_0 (active) pkgconfig @0.28_0 (active) Pauls-Mac-Pro:~ paul$ sudo port uninstall pkgconfig libiconv ---> Deactivating pkgconfig @0.28_0 ---> Cleaning pkgconfig ---> Uninstalling pkgconfig @0.28_0 ---> Cleaning pkgconfig ---> Deactivating libiconv @1.14_0 ---> Cleaning libiconv ---> Uninstalling libiconv @1.14_0 ---> Cleaning libiconv
Then install wx: I'm attempting the directions here.
brew install wxmac --use-llvm --develbrew install wxmac --devel Warning: It appears you have MacPorts or Fink installed. Software installed with other package managers causes known problems for Homebrew. If a formula fails to build, uninstall MacPorts/Fink and try again.
(There shouldn't be any libraries or binaries in the various paths to interfere, so I'll ignore this). And it seemed to succeed. So, next step from the instructions above: Check your path to make sure you are using your wxWidgets and not the default Mac one. The command which wx-config should not return the file path /usr/bin/wx-config (On my system it returns /usr/local/bin/wx-config). Next, cabal install wx cabal-macosx. That chugs away for a while and I see an unnervingly large number of warnings, but it builds. And then, I saved this file as hello-ex.hs and ghc --make HelloWorld.hs and macosx-app hello-wx and ./hello-wx.app/Contents/MacOS/hello-wx and the result runs and I get a window, although it pops up off the bottom of my primary display, and the application's main menu does not seem to render its menu items quite right (they say "Hide H" and "Quit H" instead of the application name). But still -- promising!
So -- some code. To facilitate working with a GUI module in a separate .hs file I am now calling the core logic ArcticSlideCore.hs. and that file begins with module ArcticSlideCore where. I don't have very much working yet, but here's what is in my ArcticSlideGui.hs file so far. First I define my module and do my imports:
module Main where import Graphics.UI.WX import ArcticSlideCore
Then I define some bitmaps. For purposes of experimentation I made .png files out of the original Polar game's CICN resources. I want to redraw them -- first, to avoid blatant copyright infringement and second, to make them bigger. But temporarily:
bomb = bitmap "bomb.png" heart = bitmap "heart.png" house = bitmap "house.png" ice = bitmap "ice_block.png" tree = bitmap "tree.png"
While they are game tiles as such, there are icons for the penguin facing in the four cardinal directions and icons for a breaking ice block and exploding bomb that were used in original animations:
penguin_e = bitmap "penguin_east.png" penguin_s = bitmap "penguin_south.png" penguin_w = bitmap "penguin_west.png" penguin_n = bitmap "penguin_north.png" ice_break = bitmap "ice_block_breaking.png" bomb_explode = bitmap "bomb_exploding.png"
I noticed that wxHaskell's Point type operates in reverse. I'm accustomed to C arrays where the higher-rank indices come first (so y, x or row index, column index for tile positions), but points are backwards. My icons are 24x24 pixels, so I rearrange and scale them like so:
posToPoint :: Pos -> Point posToPoint pos = ( Point ( posX pos * 24 ) ( posY pos * 24 ) )
Now, some convenience function for drawing bitmaps based on Tile type or based on a wxHaskell bitmap. These are two more cases where I was not sure of the type signature, so I wrote the functions without them:
drawBmp dc bmp pos = drawBitmap dc bmp point True []
where point = posToPoint pos
drawTile dc tile pos = drawBmp dc bmp pos
where bmp = case tile of Bomb -> bomb
Heart -> heart
House -> house
Ice -> ice
Tree -> tree
GHCI says:
Prelude Main> :t drawBmp
drawBmp
:: Graphics.UI.WXCore.WxcClassTypes.DC a
-> Graphics.UI.WXCore.WxcClassTypes.Bitmap ()
-> ArcticSlideCore.Pos
-> IO ()
That boils down to drawBmp :: DC a -> Bitmap () -> Pos -> IO (), and the signature for DrawTile similarly boils down to drawTile :: DC a -> Tile -> Pos -> IO (). Thanks, GHCI!
Next, I need a view method. This is just a placeholder test to verify that I can draw all my icons in the bounds where I expect them:
draw dc view
= do
drawTile dc Bomb ( Pos 0 0 )
drawTile dc Heart ( Pos 0 1 )
drawTile dc House ( Pos 0 2 )
drawTile dc Ice ( Pos 0 3 )
drawTile dc Tree ( Pos 0 4 )
drawBmp dc penguin_e ( Pos 1 0 )
drawBmp dc penguin_s ( Pos 1 1 )
drawBmp dc penguin_w ( Pos 1 2 )
drawBmp dc penguin_n ( Pos 1 3 )
drawBmp dc ice_break ( Pos 0 23 )
drawBmp dc bomb_explode ( Pos 3 23 )
Now, my guy function is where things get interesting and wxHaskell shows off a little. I read this paper that talks about some of the layout options and other tricks of the wxHaskell implementation, and discovered that this maps really nicely to defining my window in terms of a grid of icons. space 24 24 returns a layout item of the appropriate size, and grid returns a layout item when given spacing values (I want the icons touching, so I use 0 0) and a list of lists for rows and columns. To generate the proper structure of 4 rows of 24 columns I just take what I need from infinite lists: take 4 $ repeat $ take 24 $ repeat $ space 24 24 Oh, that's nifty!
gui :: IO ()
gui
= do f <- frame [text := "Arctic Slide"]
t <- timer f [ interval := 250
]
set f [ layout := grid 0 0 $ take 4 $ repeat $
take 24 $ repeat $ space 24 24
,bgcolor := white
,on paint := draw
]
return ()
And finally, main:
main :: IO () main = start gui
To build this for use as a MacOS X GUI app I just do ghc --make ./arcticSlideGui.hs, and if it compiles properly then macosx-app arcticSlideGui; ./arcticSlideGui.app/Contents/MacOS/arcticSlideGui and I have a little GUI window:
Sweet! Now I've got some more thinking to do. There's some plumbing that needs to get hooked up between the core game logic and the GUI layer. The core game logic is mostly factored the way I want it to be -- it gets a world and a penguin move and returns an updated world -- but I need to do a little more than just map the tiles to a series of drawTile calls. I might want to support timed sequences of changes to the GUI representation of the board -- for example, smooth sliding of game pieces and smooth walking of the penguin. The draw method should draw the board pieces and the penguin all at once, with no redundancy if possible. Sound effects would be nice. Animation for crushing an ice block and blowing up a mountain would be nice. I've got some ideas along these lines based on event queues and a timer, and some other pieces of sample code I've been looking at.
Meanwhile, if any of you would like to take a crack at redrawing the graphics, please be my guest. It would be nice if the replacement icons would fit on an iPhone or iPod Touch. 48x84 is just a little bit too big -- 48 pixels by 24 icons is 1152 pixels, and the iPhone 4 and 5 screens are 640x960 and 640x1136. 40 pixels wide would fit perfectly on an iPhone 4. Note that the icons don't actually have to be square -- there is room to spare vertically. It might be nice, though, to leave room for a few extra rows, to support game boards that break out of the original 4-row height.
