Rugs
I have been working on a virtual lounge room for www.rugsonline.com.au - an online rug shop. The owner (David), also has a real shop a few blocks from me, and is a young guy who's got good ideas about websites.
This is a flashy website where you can select a rug, some furniture, and some paintings by a local artist. So you can kind of see how the rug might look in a room of your own. I guess kind of like an Ikea catalogue where you can change the items in the photo.
You can also change the colour of the walls, the shadows of the room, and the type of floor under the rug.
The front part was made with flash - with a lot of action script.
One of the hard parts was doing a 3D transform of the photo of the rug. So it sat in the room with the correct perspective. All of the photos were taken over head, so the transform needed to be done to make the rugs look ok in the scene. Since all of the photos were already taken, retaking the photos from a different angle wasn't practical.
I had to also code some functions to get rid of white parts around the edges of some images. I first coded it in php, which worked ok after caching the results - even if a little slow. Unfortunately I couldn't get the texture mapping code to use the alpha transparency part of the image. So I had to recode it in action script - which also was initially slow. So I had to use a built in function which was much faster (probably written in C) - but with not quite as good quality. You have to make trade offs sometimes right?
The bitmap functions in flash 8 are pretty good. Before flash 8 they were very limited. You can do many things which are too slow for actionscript by itself - by using the built in functions. However sometimes the documentation is lacking. I don't know if adobe-flash actively seeks feedback from people using their APIs. The quality of the documentation is quite good - and consistent. However common problems people had with the APIs are not addressed. It's like a release and forget style of documentation. Or maybe they're just busy! Since many of their APIs do get better with every release.
A better method for documentation is to look at problems people are having, and then either fix the API, or improve the documentation until people stop asking those questions. It's a good method we try and use with the pygame mailing list, and website documentation. If there are common problems - we try and document them, or fix the api so people don't have those problems or questions. It's better to fix it so people don't have to look at the documentation in the first place - but some times that's not possible. There's still some recurring questions/problems people have with pygame of course! There's also over 100 doc comments which need to be addressed, and folded back into the documentation.
Adobe do have user comments on their website though. However not many people use them, since people use the inbuilt flash documentation - which doesn't download the user comments from the website. Also you can't make user comments from inside flash. So it's no where near as helpful as the php documentation, or the pygame documentation doc comments. For the amount of people using flash, there should be FAR more doc comments than there is. So I think it's a user interface and work flow issue. Also maybe adobe not embracing contributions from people using their software - as best they could.
Not that pygame, or php allow you to make doc comments from within php, or pygame. But mostly people look at the documentation on the web. Maybe we could build a doc comment function into pygame itself? Since people use help(pygame.something) a lot, or see the doc strings in their editor. Maybe a pygame.add_doc_comment(pygame.somefunction) function, which uploads comments to the website ;)
Doc comments on websites are like bug reports - or patches. They are a very valuable source of information when trying to improve something.
Oops... I started ranting about documentation. Back to the virtual lounge room...
The flash front end integrates with a database which is shared with the shop part of the website. So the same rug descriptions, and photos are all used - and controlled from a management interface. David (the owner of rugs online) can change which couches, floors, and paintings are displayed. I made the database for the rest of the shop first, but it wasn't hard getting flash to use the same database. Flash has a number of different ways it can request information from websites - so that part wasn't very hard. Flash has been doing AJAXy style communication with websites since flash 4. I used php to communicate with flash, but it's really easy to integrate with other languages too. You can talk to flash a number of ways, but the simplest methods are to use urlencoding, or xml encoding. Almost every language used for making websites can do either urlencoding or xml encoding - often both. You can also use json, xmlrpc etc - or even sockets.
It would have been possible to do this virtual lounge room with javascript using the Canvas tag using modern browsers, but that's not what was chosen.
Have a play - it’s kinda fun making the images zoom across the screen: virtual lounge room.
Written by a Melbourne freelance web developer. Available for your projects - php, mysql, e commerce, javascript, CMS, css, flash, actionscript, python, games, postgresql, xml.
This is a flashy website where you can select a rug, some furniture, and some paintings by a local artist. So you can kind of see how the rug might look in a room of your own. I guess kind of like an Ikea catalogue where you can change the items in the photo.
You can also change the colour of the walls, the shadows of the room, and the type of floor under the rug.
The front part was made with flash - with a lot of action script.
One of the hard parts was doing a 3D transform of the photo of the rug. So it sat in the room with the correct perspective. All of the photos were taken over head, so the transform needed to be done to make the rugs look ok in the scene. Since all of the photos were already taken, retaking the photos from a different angle wasn't practical.
I had to also code some functions to get rid of white parts around the edges of some images. I first coded it in php, which worked ok after caching the results - even if a little slow. Unfortunately I couldn't get the texture mapping code to use the alpha transparency part of the image. So I had to recode it in action script - which also was initially slow. So I had to use a built in function which was much faster (probably written in C) - but with not quite as good quality. You have to make trade offs sometimes right?
The bitmap functions in flash 8 are pretty good. Before flash 8 they were very limited. You can do many things which are too slow for actionscript by itself - by using the built in functions. However sometimes the documentation is lacking. I don't know if adobe-flash actively seeks feedback from people using their APIs. The quality of the documentation is quite good - and consistent. However common problems people had with the APIs are not addressed. It's like a release and forget style of documentation. Or maybe they're just busy! Since many of their APIs do get better with every release.
A better method for documentation is to look at problems people are having, and then either fix the API, or improve the documentation until people stop asking those questions. It's a good method we try and use with the pygame mailing list, and website documentation. If there are common problems - we try and document them, or fix the api so people don't have those problems or questions. It's better to fix it so people don't have to look at the documentation in the first place - but some times that's not possible. There's still some recurring questions/problems people have with pygame of course! There's also over 100 doc comments which need to be addressed, and folded back into the documentation.
Adobe do have user comments on their website though. However not many people use them, since people use the inbuilt flash documentation - which doesn't download the user comments from the website. Also you can't make user comments from inside flash. So it's no where near as helpful as the php documentation, or the pygame documentation doc comments. For the amount of people using flash, there should be FAR more doc comments than there is. So I think it's a user interface and work flow issue. Also maybe adobe not embracing contributions from people using their software - as best they could.
Not that pygame, or php allow you to make doc comments from within php, or pygame. But mostly people look at the documentation on the web. Maybe we could build a doc comment function into pygame itself? Since people use help(pygame.something) a lot, or see the doc strings in their editor. Maybe a pygame.add_doc_comment(pygame.somefunction) function, which uploads comments to the website ;)
Doc comments on websites are like bug reports - or patches. They are a very valuable source of information when trying to improve something.
Oops... I started ranting about documentation. Back to the virtual lounge room...
The flash front end integrates with a database which is shared with the shop part of the website. So the same rug descriptions, and photos are all used - and controlled from a management interface. David (the owner of rugs online) can change which couches, floors, and paintings are displayed. I made the database for the rest of the shop first, but it wasn't hard getting flash to use the same database. Flash has a number of different ways it can request information from websites - so that part wasn't very hard. Flash has been doing AJAXy style communication with websites since flash 4. I used php to communicate with flash, but it's really easy to integrate with other languages too. You can talk to flash a number of ways, but the simplest methods are to use urlencoding, or xml encoding. Almost every language used for making websites can do either urlencoding or xml encoding - often both. You can also use json, xmlrpc etc - or even sockets.
It would have been possible to do this virtual lounge room with javascript using the Canvas tag using modern browsers, but that's not what was chosen.
Have a play - it’s kinda fun making the images zoom across the screen: virtual lounge room.
Written by a Melbourne freelance web developer. Available for your projects - php, mysql, e commerce, javascript, CMS, css, flash, actionscript, python, games, postgresql, xml.
Comments