- I can't use `wx-config --cppflags` in xcode for cpp flags. So I need to do it manually. Maybe xcode has a workaround instead of using execution quotes....
- wx-config returns a __WX_MAC__ define, a build then results in an #error No Target defined. It turns out now with the cocoa split, WX_MAC is no longer used, instead I need to manually set the target to be __WXOSX_COCOA__ (or _CARBON or _IPHONE etc). Maybe wx-config needs updating...
Sunday, 10 January 2010
wxWidgets on OS X...
Using the latest version from SVN... it doesn't work out of the box. Here are some notes (once I've got all this working I'll submit TRAC bugs or something similar to wxWidgets...)
Monday, 7 September 2009
Slack.
Well it didn't take long before the daily updates stopped. I'm busy packing up my house, throwing away my crap rather than working.
After wrestling with the iPhone http connection code I got it downloading files with stability. The cocoa framework code was threaded too, and I had only quickly put the code together for synchronous connections. I've expanded the system so after creating a connection you start a Download() or Upload() with an url (which obviously we can adapt for other protocols) which creates a task with a TBinaryTree which contains data being sent, URI information, error codes, and then on success will have the returned HTTP data -which will be exclusivly XML-. We poll the connection with our task ref to get the current status (False,Wait,True) and the data on the task and wait for the thread to finish.
Now that that was working on both formats (same fish test as before of course) I added uploading data via multi-part form posts. This wasn't too much trouble using Curl... I never realised how poorly thrown together some of the HTTP protocols are! The use of an arbrtitry string to seperate fields seems a little daft to me, and doesn't really impose any error checking for half-submitted forms IMO. But anyway, it's a 20 year old standard so I guess the world has coped.
Anyway, data gets uploaded as hex strings - a little ineffecient, but reliable, easily translatable back to binary, readable so good for debugging - as they're UTF8 compatbile and so good for XML and Form data. Each branch of the Upload data we supplied to Upload() gets put into a different form-part. The PHP code simply enumerates through the POST variables, and converts the form part name (Ref) and the form part data from Hex back into binary for whatever data we require; Ref, String, Data, integers etc. The whole system is essentially templated from setting up the upload data all the way through to the PHP code which now has the $_POST variable as an equivilent binary tree.
I'm now working on the database interaction code on the web side to store the match asset's data in the database and return some relevant data.
This can then all be re-used in the same way to get a list of matches applicable to one user name[ref] returned in an XML format which we can parse, or just to fetch the latest asset from the server of a particular match.
After wrestling with the iPhone http connection code I got it downloading files with stability. The cocoa framework code was threaded too, and I had only quickly put the code together for synchronous connections. I've expanded the system so after creating a connection you start a Download() or Upload() with an url (which obviously we can adapt for other protocols) which creates a task with a TBinaryTree which contains data being sent, URI information, error codes, and then on success will have the returned HTTP data -which will be exclusivly XML-. We poll the connection with our task ref to get the current status (False,Wait,True) and the data on the task and wait for the thread to finish.
Now that that was working on both formats (same fish test as before of course) I added uploading data via multi-part form posts. This wasn't too much trouble using Curl... I never realised how poorly thrown together some of the HTTP protocols are! The use of an arbrtitry string to seperate fields seems a little daft to me, and doesn't really impose any error checking for half-submitted forms IMO. But anyway, it's a 20 year old standard so I guess the world has coped.
Anyway, data gets uploaded as hex strings - a little ineffecient, but reliable, easily translatable back to binary, readable so good for debugging - as they're UTF8 compatbile and so good for XML and Form data. Each branch of the Upload data we supplied to Upload() gets put into a different form-part. The PHP code simply enumerates through the POST variables, and converts the form part name (Ref) and the form part data from Hex back into binary for whatever data we require; Ref, String, Data, integers etc. The whole system is essentially templated from setting up the upload data all the way through to the PHP code which now has the $_POST variable as an equivilent binary tree.
I'm now working on the database interaction code on the web side to store the match asset's data in the database and return some relevant data.
This can then all be re-used in the same way to get a list of matches applicable to one user name[ref] returned in an XML format which we can parse, or just to fetch the latest asset from the server of a particular match.
Wednesday, 2 September 2009
Embiggen day N
After wrestling mostly with NSConnection and an Objective-c learning curve, I've got the file-downloading code down to a wierd bad_access crash and stopped work on that to spend the rest of the afternoon on Embiggen features.
The next task was to do something with the words (and points) now that we've calculated them. To aid this I've setup player information; A list of players in the match, and arbritary data on the player. The data on the players contains a player ref (a global unique identifier) an avatar texture ref, a current score and a list of letters in the players rack.
I setup the gui to display the avatar, name and score. It also currently colours the active player red so we know who's playing. Upon pressing play, it calculates the words generated by the current player, verifies everything is okay (although I've not done spell checking yet), burns the players tiles into the board, adds the points to the players score.
It then saves the match asset which contains the board, (which contains tiles, letter pool), players and active player. Due to the way the engine works this is easily serialised into an asset. Now we have an asset we can/will send that asset up to the web, where some PHP will write it back to the database, do notifications etc and wait for the next player to make their move and submit the next board.
All simple data-orientated changes, but it does mean it turns into much more of a game now that we handle multiple players and save/load the board :)
Next task is back to sorting out the IPod web-connection, THEN I can do the PC and IPod web-sending code, then I'll sort out the server side PHP scripts and database to save our match and make it accessible world wide!
Target to finish by the end of the week may be reachable :) (Although I need to start packing for my move to Manchester next week)
The next task was to do something with the words (and points) now that we've calculated them. To aid this I've setup player information; A list of players in the match, and arbritary data on the player. The data on the players contains a player ref (a global unique identifier) an avatar texture ref, a current score and a list of letters in the players rack.
I setup the gui to display the avatar, name and score. It also currently colours the active player red so we know who's playing. Upon pressing play, it calculates the words generated by the current player, verifies everything is okay (although I've not done spell checking yet), burns the players tiles into the board, adds the points to the players score.
It then saves the match asset which contains the board, (which contains tiles, letter pool), players and active player. Due to the way the engine works this is easily serialised into an asset. Now we have an asset we can/will send that asset up to the web, where some PHP will write it back to the database, do notifications etc and wait for the next player to make their move and submit the next board.
All simple data-orientated changes, but it does mean it turns into much more of a game now that we handle multiple players and save/load the board :)
Next task is back to sorting out the IPod web-connection, THEN I can do the PC and IPod web-sending code, then I'll sort out the server side PHP scripts and database to save our match and make it accessible world wide!
Target to finish by the end of the week may be reachable :) (Although I need to start packing for my move to Manchester next week)
Embiggen day five
All day doing apple network code. 2am now. Quickly added word detection. Bed time.
Monday, 31 August 2009
Thank you curl, Thurl.
Today was a bit of engine work. (Not a bank holiday as some other people here in the UK seem think, too wet!)
For Embiggen we will need to fetch some data from the web. Namely, from a database which stores all our matches (and user profiles). A simple PHP script can convert the required match database row into some XML and pump it out - specifically into our asset XML format - and we can download it, convert it to binary asset data and load it in-game. Shimples!
Anyway, the UIKit in the iPhone SDK provides us with some functionality to do this for us (NSURLConnection) so we need a solution in windows to replicate this for easier testing. (and maybe for us on the Wii or Mac or whatever else we might port to)
I looked through a few open source projects, libs etc before settling on LibCurl which seems to do everything we require in a nice simple, supported, threadsafe, documented, active open source package. After some initial linking trouble with unresolved externals all starting with __imp__ I had a look through the example .vcproj for some pre-processor defines which sure enough I missed out on. Got it all going, setup a simple asynchronous base connection class (TLNetwork::TConnection), setup a new TestApp example which shows one texture asset on the left and another on the right. I uploaded a compiled .asset file to the web (Which is freely availible to download if you're curious, although it's binary data rather than XML representation, I'll show an example of that when it's ready)
Everything seemed to be setup nicely but when the internal thread was cleaned up I kept getting some corruption in the heap. I started looking into CRT issues and conflicts and found a full rebuild of an all debug build of the app didn't corrupt the heap. I setup all our projects to use Debug MT CRT but was still getting an occasional crash. I overloaded all the LibCurl memory allocation functions to use our own memory allocation functions which I can track much more easily. The remaining crash seemed more consistent (Instead of random crashes), looking further into it an asset kept being overwritten and corrupted... I stepped through the code and it turned out I was corrupting one of my assets myself, turning a c-pointer into a smart pointer and then releasing it, Oops.
Now I'm a little unsure if the change in the memory allocations, or the CRT changes were neccessary. Nevermind, it works!
The image is the file download test app. The image on the left is local, the image on the right is downloaded, converted and then set. Not the most exciting screenshot :)
I've put together an IPod/IPhone version, but untested. Now that this is stable I can see if it works on the iPhone and get back to game stuff :)
For Embiggen we will need to fetch some data from the web. Namely, from a database which stores all our matches (and user profiles). A simple PHP script can convert the required match database row into some XML and pump it out - specifically into our asset XML format - and we can download it, convert it to binary asset data and load it in-game. Shimples!
Anyway, the UIKit in the iPhone SDK provides us with some functionality to do this for us (NSURLConnection) so we need a solution in windows to replicate this for easier testing. (and maybe for us on the Wii or Mac or whatever else we might port to)
I looked through a few open source projects, libs etc before settling on LibCurl which seems to do everything we require in a nice simple, supported, threadsafe, documented, active open source package. After some initial linking trouble with unresolved externals all starting with __imp__ I had a look through the example .vcproj for some pre-processor defines which sure enough I missed out on. Got it all going, setup a simple asynchronous base connection class (TLNetwork::TConnection), setup a new TestApp example which shows one texture asset on the left and another on the right. I uploaded a compiled .asset file to the web (Which is freely availible to download if you're curious, although it's binary data rather than XML representation, I'll show an example of that when it's ready)
Everything seemed to be setup nicely but when the internal thread was cleaned up I kept getting some corruption in the heap. I started looking into CRT issues and conflicts and found a full rebuild of an all debug build of the app didn't corrupt the heap. I setup all our projects to use Debug MT CRT but was still getting an occasional crash. I overloaded all the LibCurl memory allocation functions to use our own memory allocation functions which I can track much more easily. The remaining crash seemed more consistent (Instead of random crashes), looking further into it an asset kept being overwritten and corrupted... I stepped through the code and it turned out I was corrupting one of my assets myself, turning a c-pointer into a smart pointer and then releasing it, Oops.
Now I'm a little unsure if the change in the memory allocations, or the CRT changes were neccessary. Nevermind, it works!
I've put together an IPod/IPhone version, but untested. Now that this is stable I can see if it works on the iPhone and get back to game stuff :)
Sunday, 30 August 2009
Embiggen day three
I'm half way through day three now and I can concentrate a bit further as I have all day to myself (bar cat-feeding).
I've added a rack to place tiles on now. The tiles on the rack come from the board's pool of letters (currently just 3 of every character). Tiles can be moved to the board and back and rearranged in the rack itself, all very nice and stable, and again, data driven. The rack places are datums inside my main GUI SVG. As are my buttons, these are extremley simple code wise, I have a datum specifying where the click should be detected and in the code I create a TWidgetButton assigned to that datum which just sends an command back to the game when it's clicked, thanks to the fantastic engine I don't need to worry about interface stuff much at all :)
The text on the buttons required a tiny bit more work, the GUI's scheme specifies text nodes which use smaller datums on the button to dictate the position of the "play"/"back"/"undo" text. Again, out of code and just means when we come to translate there are no texture or code changes.
My next task is a jump out of the Embiggen code for a while as I setup the all important (and important for Rocket) code to fetch and send files across http.
On first inspection libCurl seems like an adequate, stable, popular and open source library for me to use on win32 (and later the wii...) which mimicks apple's NSConnection classes which I'll be using on the iPod. Should be quite simple to write some platform indepedent interfaces to get/put files across HTTP which means I can send the current Match state asset as XML up to the server for PHP to process and stick in a database and reverse of that to download the current Match XML and turn back into an asset :)
All going well and nice and quick development so far! :)
I've added a rack to place tiles on now. The tiles on the rack come from the board's pool of letters (currently just 3 of every character). Tiles can be moved to the board and back and rearranged in the rack itself, all very nice and stable, and again, data driven. The rack places are datums inside my main GUI SVG. As are my buttons, these are extremley simple code wise, I have a datum specifying where the click should be detected and in the code I create a TWidgetButton assigned to that datum which just sends an command back to the game when it's clicked, thanks to the fantastic engine I don't need to worry about interface stuff much at all :)
The text on the buttons required a tiny bit more work, the GUI's scheme specifies text nodes which use smaller datums on the button to dictate the position of the "play"/"back"/"undo" text. Again, out of code and just means when we come to translate there are no texture or code changes.
On first inspection libCurl seems like an adequate, stable, popular and open source library for me to use on win32 (and later the wii...) which mimicks apple's NSConnection classes which I'll be using on the iPod. Should be quite simple to write some platform indepedent interfaces to get/put files across HTTP which means I can send the current Match state asset as XML up to the server for PHP to process and stick in a database and reverse of that to download the current Match XML and turn back into an asset :)
All going well and nice and quick development so far! :)
Embiggen day 2
Day two was about an hour of work while I had lunch on saturday :)
Just finished the tile-drag code which dropped the tiles onto the board and worked out a local position which translates to an integer grid x/y position. If the new grid xy is empty, the dragged tile is delete and the grid entry is reset and render node is recreated. Once a tile is dragged (from wherever) it becomes detatched and a bit disposable so we are relying on the widget code to get a Mouse-Up style message to drop the node somewhere.
Also changed the colour scheme a little. These are hard-coded colours at the moment and the tile is a simple transparent + white PNG. All ready for themes!
Just finished the tile-drag code which dropped the tiles onto the board and worked out a local position which translates to an integer grid x/y position. If the new grid xy is empty, the dragged tile is delete and the grid entry is reset and render node is recreated. Once a tile is dragged (from wherever) it becomes detatched and a bit disposable so we are relying on the widget code to get a Mouse-Up style message to drop the node somewhere.
Also changed the colour scheme a little. These are hard-coded colours at the moment and the tile is a simple transparent + white PNG. All ready for themes!
Subscribe to:
Posts (Atom)
Posts
