https://wiki.cdot.senecacollege.ca/w/api.php?action=feedcontributions&user=Ajcondinho&feedformat=atomCDOT Wiki - User contributions [en]2024-03-28T20:17:31ZUser contributionsMediaWiki 1.30.0https://wiki.cdot.senecacollege.ca/w/index.php?title=Netwerk&diff=55259Netwerk2011-01-18T16:42:12Z<p>Ajcondinho: /* Any other thing you find necessary */</p>
<hr />
<div>{{GAM670/DPS905 Index | 20111}}<br />
= Netwerk =<br />
<br />
= GAM670 section =<br />
<br />
Features to be implemented:<br />
<br />
- Networking<br />
<br />
=== Progress ===<br />
<br />
<br />
== Team ==<br />
# [mailto:dmmcgrath@learn.senecac.on.ca Andrew Condinho]<br />
<br />
== Proposal ==<br />
The main focus I have for this game / feature is the ability to have networking and to interact with other players within the game world. To start off I will attempt to implement a console based network system where multiple users can send and receive messages from the others. Once I have gotten this system working, I will try and merge this network system into the framework. Once I have the ability to transfer messages to and from one system to others, it shouldn't be too difficult to evolve those messages into player location and movements which can be updated on each user's local machine.<br />
<br />
As far as the game I plan to create goes, I see it as being similar to Home on the PS3. Obviously much less polished and "complete", the basic functionality of the game should be a room or rooms in which users log on to and appear as a coloured box or simple collada model. Once in they are free to move around and broadcast chat messages to other users in the same room.<br />
<br />
== Map of the World of the Game ==<br />
<br />
== Moderator's - Instructors Comments ==<br />
== Any other thing you find necessary ==<br />
# Tutorial on WinSocks<br />
## http://www.codeproject.com/KB/IP/beginningtcp_cpp.aspx<br />
# Chat Client Server Program<br />
## http://www.codeproject.com/KB/cpp/chat_client_server.aspx</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=Netwerk&diff=55252Netwerk2011-01-18T16:37:32Z<p>Ajcondinho: /* Any other thing you find necessary */</p>
<hr />
<div>{{GAM670/DPS905 Index | 20111}}<br />
= Netwerk =<br />
<br />
= GAM670 section =<br />
<br />
Features to be implemented:<br />
<br />
- Networking<br />
<br />
=== Progress ===<br />
<br />
<br />
== Team ==<br />
# [mailto:dmmcgrath@learn.senecac.on.ca Andrew Condinho]<br />
<br />
== Proposal ==<br />
The main focus I have for this game / feature is the ability to have networking and to interact with other players within the game world. To start off I will attempt to implement a console based network system where multiple users can send and receive messages from the others. Once I have gotten this system working, I will try and merge this network system into the framework. Once I have the ability to transfer messages to and from one system to others, it shouldn't be too difficult to evolve those messages into player location and movements which can be updated on each user's local machine.<br />
<br />
As far as the game I plan to create goes, I see it as being similar to Home on the PS3. Obviously much less polished and "complete", the basic functionality of the game should be a room or rooms in which users log on to and appear as a coloured box or simple collada model. Once in they are free to move around and broadcast chat messages to other users in the same room.<br />
<br />
== Map of the World of the Game ==<br />
<br />
== Moderator's - Instructors Comments ==<br />
== Any other thing you find necessary ==<br />
# http://www.codeproject.com/KB/IP/beginningtcp_cpp.aspx</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=GAM670/DPS905_Student_List_20111&diff=55247GAM670/DPS905 Student List 201112011-01-18T16:35:09Z<p>Ajcondinho: /* Student List for Winter of 2011 */</p>
<hr />
<div>{{GAM670/DPS905 Index | 20111}}<br />
== Student List for Winter of 2011 ==<br />
<br />
Please update or add your information to the student list table below (if you are a student in GAM670/DPS905, Winter of 2011).<br /><br />
If your information is incomplete, your assignments will not be marked.<br />
<br />
{| class="wikitable sortable" border="1" cellpadding="5"<br />
|+ GAM670/DPS905 - Winter of 2011 student list<br />
! First Name !! Last Name !! Team Name !! Subject !! Seneca Id !! wiki id !! IRC nick !! Blog URL !! Repository<br />
|-<br />
<br />
|-<br />
|[[User:dperit | David]]||Perit||[[DPS901_Hic_Sunt_Dracones|Hic Sunt Dracones]]||GAM670||[mailto:drperit@learn.senecac.on.ca drperit]||[[Special:Contributions/dperit| dperit]]||dperit||<br />
|-<br />
<br />
|-<br />
|[[User:ajcondinho | Andrew]]||Condinho||[[Netwerk|Netwerk]]||GAM670||[mailto:ajcondinho@learn.senecac.on.ca ajcondinho]||[[Special:Contributions/ajcondinho| ajcondinho]]||Dueraim||[http://ajcondinho.blogspot.com/ Andrew's Blog]<br />
|-<br />
<br />
|-<br />
|[[User:CloudScorpion | Joseph]]||Hughes||[[Team Mutalisk |Team Mutalisk]]||GAM670||[mailto:jphughes@learn.senecac.on.ca?sujbect=gam666 jphughes]||[[Special:Contributions/CloudScorpion | CloudScorpion]]||CloudScorpion||[http://cloudscorpion.blogspot.com/ Cloud's Blog]<br />
|-<br />
<br />
|-<br />
|[[User:dmmcgrath | Damien]]||Mcgrath||[[Team_Zombie|Team Zombie]]||GAM670||[mailto:dmmcgrath@learn.senecac.on.ca dmmcgrath]||[[Special:Contributions/dmmcgrath| dmmcgrath]]||Vandesdelca||N/A<br />
|-<br />
<br />
|-<br />
|[[User:qfeng5 | Qing]]||Feng||[[Team_Zombie|Team Zombie]]||GAM670||[mailto:qfeng5@learn.senecac.on.ca qfeng5]||[[Special:Contributions/qfeng5| qfeng5]]||Ryojin||N/A<br />
|-<br />
<br />
|-<br />
|[[User:Jbraffoul| Jordan]]||Raffoul||[[DPS901 Cerebral Thought |Cerebral Thought]]||DPS905||[mailto:jbraffoul@learn.senecac.on.ca jbraffoul]||[[Special:Contributions/jbraffoul| jbraffoul]]||phez||None<br />
|-<br />
<br />
|-<br />
|[[User:dsventura | Dan]]||Ventura||[[GAM670_Slap_Your_Grandma|Slap Your Grandma]]||GAM670||[mailto:dsventura@learn.senecac.on.ca dsventura]||[[Special:Contributions/dsventura| dsventura]]||danman||N/A||[svn://zenit.senecac.on.ca/dps901_103rep5/branches/dsventura 5]<br />
|-<br />
<br />
|-<br />
|[[User:dacallow | Kaitlyn]]||Callow||[[DPS901_Hic_Sunt_Dracones|Hic Sunt Dracones]]||DPS905||[mailto:dacallow@learn.senecac.on.ca dacallow]||[[Special:Contributions/dacallow| dacallow]]||Kait85||[http://blog.kaitlyncallow.com Kaitlyn's Rambling Ramblings]<br />
|-<br />
<br />
|-<br />
|[[User:dhhodgin | Daniel]]||Hodgin||[[DPS901_Hic_Sunt_Dracones|Hic Sunt Dracones]]||DPS905||[mailto:dhhodgin@learn.senecac.on.ca dhhodgin]||[[Special:Contributions/dhhodgin| dhhodgin]]||dhodgin||[http://www.hodgin.ca/ Blog/Website]<br />
|-<br />
<br />
|-<br />
|[[User:errichard| Richard]]||Eyre||[[DPS901 Cerebral Thought |Cerebral Thought]]||DPS905||[mailto:errichard@learn.senecac.on.ca Richard Eyre]||[[Special:Contributions/errichard|errichard]]||epsilon||None<br />
|-<br />
<br />
|-<br />
|[[User:akopytov | Andrei]]||Kopytov||||DPS905||[mailto:akopytov@learn.senecac.on.ca Andrei Kopytov]||[[Special:Contributions/akopytov |akopytov]]||akopytov||N/A<br />
|-<br />
<br />
|-<br />
|[[User:Satijas | Sasha]]||Atijas||[[GAM670_Slap_Your_Grandma|Slap Your Grandma]]||GAM670||[mailto:satijas@learn.senecac.on.ca Email]||[[Special:Contributions/Satijas| Satijas]]||Sash0400||N/A<br />
|-<br />
<br />
|-<br />
|[[User:BradMc| Brad]]||McKie||[[GG |GG]]||DPS905||[mailto:bmckie@learn.senecac.on.ca Brad McKie]||[[Special:Contributions/BradMc|BradMc]]||B-Rad||None<br />
|-<br />
<br />
|-<br />
|[[User:jrbuckley | Jon]]||Buckley||[[DPS901_Hic_Sunt_Dracones | Team Hic Sunt Dracones]]||DPS905||[mailto:jrbuckley@learn.senecac.on.ca Jon Buckley]||[[Special:Contributions/jrbuckley| jrbuckley]]||jrbuckley||N/A<br />
|-<br />
<br />
|-<br />
|[[User:rjmorales1| Randl]]||Morales||[[DPS901 Team Copycat |Team Copycat]]||DPS905||[mailto:rjmorales1@learn.senecac.on.ca Randl Morales]||[[Special:Contributions/rjmorales1| rjmorales1]]||rjmorales1||N/A<br />
|-<br />
<br />
|-<br />
|[[User:dpapagia | Denny]]||Papagiannidis||[[GAM670_Slap_Your_Grandma|Slap Your Grandma]]||GAM670||[mailto:dpapagia@learn.senecac.on.ca dpapagia]||[[Special:Contributions/dpapagia| dpapagia]]||dennyp|| [http://dennyp.wordpress.com Denny's Blog]<br />
|-<br />
<br />
|-<br />
|[[User:northWind87 | Hasan]]||Kamal-Al-Deen||[[Team Mutalisk|Team Mutalisk]] || GAM670||[mailto:hkamal-al-deen@learn.senecac.on.ca?subject=GAM666 hkamal-al-deen]||[[Special:Contributions/northWind87 | northWind87]]||northWind||[http://orbitalstation.wordpress.com The Orbital Station]<br />
|-</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=Netwerk&diff=55242Netwerk2011-01-18T16:31:26Z<p>Ajcondinho: /* Progress */</p>
<hr />
<div>{{GAM670/DPS905 Index | 20111}}<br />
= Netwerk =<br />
<br />
= GAM670 section =<br />
<br />
Features to be implemented:<br />
<br />
- Networking<br />
<br />
=== Progress ===<br />
<br />
<br />
== Team ==<br />
# [mailto:dmmcgrath@learn.senecac.on.ca Andrew Condinho]<br />
<br />
== Proposal ==<br />
The main focus I have for this game / feature is the ability to have networking and to interact with other players within the game world. To start off I will attempt to implement a console based network system where multiple users can send and receive messages from the others. Once I have gotten this system working, I will try and merge this network system into the framework. Once I have the ability to transfer messages to and from one system to others, it shouldn't be too difficult to evolve those messages into player location and movements which can be updated on each user's local machine.<br />
<br />
As far as the game I plan to create goes, I see it as being similar to Home on the PS3. Obviously much less polished and "complete", the basic functionality of the game should be a room or rooms in which users log on to and appear as a coloured box or simple collada model. Once in they are free to move around and broadcast chat messages to other users in the same room.<br />
<br />
== Map of the World of the Game ==<br />
<br />
== Moderator's - Instructors Comments ==<br />
== Any other thing you find necessary ==</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=Netwerk&diff=55240Netwerk2011-01-18T16:31:13Z<p>Ajcondinho: /* Netwerk */</p>
<hr />
<div>{{GAM670/DPS905 Index | 20111}}<br />
= Netwerk =<br />
<br />
= GAM670 section =<br />
<br />
Features to be implemented:<br />
<br />
- Networking<br />
<br />
=== Progress ===<br />
<br />
<br />
== Team == ajcondinho<br />
# [mailto:dmmcgrath@learn.senecac.on.ca Andrew Condinho]<br />
<br />
== Proposal ==<br />
The main focus I have for this game / feature is the ability to have networking and to interact with other players within the game world. To start off I will attempt to implement a console based network system where multiple users can send and receive messages from the others. Once I have gotten this system working, I will try and merge this network system into the framework. Once I have the ability to transfer messages to and from one system to others, it shouldn't be too difficult to evolve those messages into player location and movements which can be updated on each user's local machine.<br />
<br />
As far as the game I plan to create goes, I see it as being similar to Home on the PS3. Obviously much less polished and "complete", the basic functionality of the game should be a room or rooms in which users log on to and appear as a coloured box or simple collada model. Once in they are free to move around and broadcast chat messages to other users in the same room.<br />
<br />
== Map of the World of the Game ==<br />
<br />
== Moderator's - Instructors Comments ==<br />
== Any other thing you find necessary ==</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=Netwerk&diff=55239Netwerk2011-01-18T16:30:59Z<p>Ajcondinho: Created page with '{{GAM670/DPS905 Index | 20111}} = Netwerk = Braaaiiinns...... = GAM670 section = Features to be implemented: - Networking === Progress === == Team == ajcondinho # [mailto:d…'</p>
<hr />
<div>{{GAM670/DPS905 Index | 20111}}<br />
= Netwerk =<br />
Braaaiiinns......<br />
<br />
= GAM670 section =<br />
<br />
Features to be implemented:<br />
<br />
- Networking<br />
<br />
=== Progress ===<br />
<br />
<br />
== Team == ajcondinho<br />
# [mailto:dmmcgrath@learn.senecac.on.ca Andrew Condinho]<br />
<br />
== Proposal ==<br />
The main focus I have for this game / feature is the ability to have networking and to interact with other players within the game world. To start off I will attempt to implement a console based network system where multiple users can send and receive messages from the others. Once I have gotten this system working, I will try and merge this network system into the framework. Once I have the ability to transfer messages to and from one system to others, it shouldn't be too difficult to evolve those messages into player location and movements which can be updated on each user's local machine.<br />
<br />
As far as the game I plan to create goes, I see it as being similar to Home on the PS3. Obviously much less polished and "complete", the basic functionality of the game should be a room or rooms in which users log on to and appear as a coloured box or simple collada model. Once in they are free to move around and broadcast chat messages to other users in the same room.<br />
<br />
== Map of the World of the Game ==<br />
<br />
== Moderator's - Instructors Comments ==<br />
== Any other thing you find necessary ==</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=GAM670/DPS905_Teams_20111&diff=55232GAM670/DPS905 Teams 201112011-01-18T16:22:17Z<p>Ajcondinho: /* Team and Project Index */</p>
<hr />
<div><sup></sup>{{GAM670/DPS905 Index | 20111}}<br />
= Team and Project Index =<br />
<br />
== [[DPS901 Hic Sunt Dracones|Hic Sunt Dracones]] ==<br />
'''Razed by Fire'''<br />
# [mailto:dhhodgin@learn.senecac.on.ca?subject=dps905 Daniel Hodgin]<br />
# [mailto:jrbuckley@learn.senecac.on.ca?subject=dps905 Jon Buckley]<br />
# [mailto:sweerdenburg@learn.senecac.on.ca?subject=dps905 Steven Weerdenburg]<br />
# [mailto:dacallow@learn.senecac.on.ca?subject=dps905 Kaitlyn Callow]<br />
# [mailto:drperit@learn.senecac.on.ca?subject=gam670 David Perit]<br />
'''Wants'''<br />
# Skeletal Animation<br />
'''Needs'''<br />
# Collada - Daniel<br />
# Particle System - Kaitlyn<br />
# Audio - Jon<br />
# XInput<br />
# Visibility - David<br />
<br />
== [[Team Guardian|Team Guardian]] ==<br />
'''Guardian'''<br />
# [mailto:jphughes@learn.senecac.on.ca?subject=gam670 JP Hughes]<br />
# [mailto:hkamal-al-deen@learn.senecac.on.ca?subject=gam670 Hasan Kamal-Al-Deen]<br />
'''Wants'''<br />
# Lighting<br />
'''Needs'''<br />
# Physics - Hasan<br />
# Caching<br />
<br />
== [[GAM670 Slap Your Grandma| Slap Your Grandma]]==<br />
'''Game Name'''<br />
# [mailto:dpapagia@learn.senecac.on.ca?sujbect=gam670 Denny Papagiannidis]<br />
# [mailto:satijas@learn.senecac.on.ca?sujbect=gam670 Sasha Atijas]<br />
# [mailto:dsventura@learn.senecac.on.ca?sujbect=gam670 Dan Ventura]<br />
'''Wants'''<br />
# Collada Models <br />
'''Needs'''<br />
# Collision<br />
<br />
== [[Team_GG| Team GG]] ==<br />
'''Game Name'''<br />
# [mailto:bmckie@learn.senecac.on.ca?subject=dps905 Brad McKie]<br />
# [mailto:errichard@learn.senecac.on.ca?subject=DPS905 Richard Eyre]<br />
# [mailto:jbraffoul@learn.senecac.on.ca?subject=DPS905 Jordan Raffoul]<br />
# [mailto:rjmorales1@learn.senecac.on.ca?subject=dps905 Randl Morales]<br />
'''Wants'''<br />
#<br />
'''Needs'''<br />
# Collision Detection - Richard<br />
# Visibility - Brad<br />
# Third-Person Camera - Randl<br />
# Networking - Jordan, Andrew<br />
<br />
== [[Team_Zombie|Team Zombie]] ==<br />
'''Game Name'''<br />
# [mailto:dmmcgrath@learn.senecac.on.ca?subject=gam670 Damien McGrath]<br />
# [mailto:qfeng5@learn.senecac.on.ca?subject=gam670 Qing Feng]<br />
'''Wants'''<br />
# Collada<br />
'''Needs'''<br />
# OpenGL<br />
# Collision Detection<br />
# Lighting?<br />
<br />
== [[Netwerk | Netwerk]] ==<br />
#[mailto:ajcondinho@learn.senecac.on.ca?subject=gam670 Andrew Condinho]<br />
'''Wants'''<br />
# Collada<br />
'''Needs'''<br />
# Networking</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=GAM670/DPS905_Project_Requirements_20111&diff=55215GAM670/DPS905 Project Requirements 201112011-01-18T14:53:08Z<p>Ajcondinho: /* Appointment Schedules */</p>
<hr />
<div>{{GAM670/DPS905 Index | 20111}}<br />
<!--= Presentation Schedule =<br />
{| border="1"<br />
|-<br />
|Team Name<br />
|Date and Time<br />
|-<br />
|-<br />
|Team<br />
|Tuesday January 18 8:00AM<br />
|-<br />
|Slap Your Grandma<br />
|Tuesday December 7 8:15AM<br />
|-<br />
|Team Zombie<br />
|Tuesday December 7 8:30AM<br />
|-<br />
|Team GG<br />
|Tuesday December 7 8:45AM<br />
|-<br />
|Cerebral Thought<br />
|Tuesday December 7 9:00AM<br />
|-<br />
|Team Mutalisk<br />
|Tuesday December 7 9:15AM<br />
|-<br />
|Copy Cat<br />
|Thursday December 9 8:00AM<br />
|-<br />
|<br />
|Thursday December 9 8:15AM<br />
|-<br />
|Double Tap<br />
|Thursday December 9 8:30AM<br />
|-<br />
| Hic Sunt Dracones<br />
|Thursday December 9 8:45AM<br />
|-<br />
|SheetBrix Robotics<br />
|Thursday December 9 9:00AM<br />
|-<br />
|The 10th Floor<br />
|Thursday December 9 9:15AM<br />
|-<br />
|}<br />
<br />--><br />
<br />
= Appointment Schedules =<br />
Initial Proposal<br />
<br />
{| border="1"<br />
|-<br />
|Team Name<br />
|Date and Time<br />
|-<br />
|Zombie<br />
|Tuesday January 18 10:00AM<br />
|-<br />
|Team GG<br />
|Tuesday January 18 10:15AM<br />
|-<br />
|Team Guardian<br />
|Tuesday January 18 10:30AM<br />
|-<br />
|Andrew Condinho<br />
|Tuesday January 18 10:45AM<br />
|-<br />
|<br />
|Tuesday January 18 11:00AM<br />
|-<br />
|<br />
|Tuesday January 18 11:15AM<br />
|-<br />
|Slap Your Grandma<br />
|Tuesday January 18 1:30PM<br />
|-<br />
|}<br />
Proposal Acceptance<br />
{| border="1"<br />
|-<br />
|Team Name<br />
|Date and Time<br />
|-<br />
|Team GG<br />
|Tuesday February 1 10:00AM<br />
|-<br />
|Zombie<br />
|Tuesday February 1 10:15AM<br />
|-<br />
|<br />
|Tuesday February 1 10:30AM<br />
|-<br />
|<br />
|Tuesday February 1 10:45AM<br />
|-<br />
|<br />
|Tuesday February 1 11:00AM<br />
|-<br />
|<br />
|Tuesday February 1 11:15AM<br />
|-<br />
|Slap Your Grandma<br />
|Tuesday February 1 1:30PM<br />
|-<br />
|}<br />
Project Review<br />
{| border="1"<br />
|-<br />
|Team Name<br />
|Date and Time<br />
|-<br />
|Team GG<br />
|Tuesday February 22 10:00AM<br />
|-<br />
|Zombie<br />
|Tuesday February 22 10:15AM<br />
|-<br />
|<br />
|Tuesday February 22 10:30AM<br />
|-<br />
|<br />
|Tuesday February 22 10:45AM<br />
|-<br />
|<br />
|Tuesday February 22 11:00AM<br />
|-<br />
|<br />
|Tuesday February 22 11:15AM<br />
|-<br />
|Slap Your Grandma<br />
|Tuesday February 22 1:30PM<br />
|-<br />
|}<br />
<br /><br />
<br />
= Due Dates =<br />
{| border="1"<br />
|-<br />
|Proposed game and team members selected<br />
|January 18<br />
|-<br />
|Proposal completed and members' roles selected<br />
|February 1<br />
|-<br />
|Phase 2 draft and review<br />
|February 22<br />
|-<br />
|Phase 2 completed - Presentation<br />
|March 22<br />
|-<br />
|Phase 3 completed - Presentation<br />
|April 12-14<br />
|}<br />
<br /><br />
<br /><br />
<br />
= Project Requirements =<br />
<br />
Your game involves a real-time audio-visual-haptic experience in a 3-D world using advanced game programming techniques to improve the performance and the appeal of your game. The user should experience force feedback through some form of controller in response to certain common actions in your game.<br />
<br />
Each member must contribute their own feature to the game development in a selected area of specialization. Each member should also contribute to the integration of a separate, unrelated feature developed by another team.<br />
<br />
== Phase 1 ==<br />
<br />
The first phase is an informal, written proposal of the features that your team wishes to implement in its final game. Your description should identify the basic aspects of these features as well as the refinements to those features that are needed to implement your game design. Identifying the features and the required refinements will demand some research on your part. In the case of DPS905 students, the research should be deep and the description should identify the theory behind the required refinements. <br />
<br />
Your proposal should be documented on the team project page of the course wiki under '''Proposal'''. Your proposal should identify the parts of the framework that you expect to modify extensively in your implementation. A draft of your proposal should be on the wiki before your meeting with the instructor and you should update your proposal after consultation with your instructor.<br />
<br />
In developing your game, you may start with the code that you used in the previous course or you may start with the base code for this course. The base code for this course is an update version of the base code for the previous course. In any event, each member should use the updated base code to develop the feature that they have selected and present the results of their work using the updated base code. In other words, the update base code with the new features installed will serve as the source for other teams' access. <br />
<br />
Each team member should have their own successfully compiled version of the updated base code in their own workspace in the branch sub-directory of their team's repository.<br />
<br />
The source code for each team member's copy of the base code should include the following updates:<br />
* add your own name to the caption for the dialog box<br />
* change the window title to include the name of the team<br />
<br />
Merge all of the team members' workspaces back to trunk so that the caption of the dialog box shows all of the names of the team members. See [http://zenit.senecac.on.ca/wiki/index.php/Hints_for_Using_SVN_to_collaborate_on_school_projects#Merging_your_work_back_to_trunk Merging your work back to trunk] for details<br />
<br />
The purpose of this first phase of the project is twofold:<br />
* to identify the features that your final game will include<br />
* to identify the features that each member of your team will incorporate<br />
* to identify the features that your team is expecting to incorporate from the work of other teams.<br />
<br />
Your team should decide its own group to individual ratio for grading purposes and post the agreed ratio on its project page.<br />
<br />
== Phase 2 ==<br />
<br />
The second phase releases a version of the updated base code that includes the new features that your team members have incorporated. <br />
<br />
This phase includes a presentation that shows<br />
* how your new features work within<br />
** the updated base code<br />
** your own game<br />
* how to incorporate the new features in external code<br />
<br />
Your team will have one hour to make its presentation and each team member will have fifteen minutes to describe the feature that they implemented themselves<br />
<br />
== Phase 3 ==<br />
<br />
The third phase presents your completed game with your team's new features and two new features that members of other teams developed. <br />
<br />
Your presentation includes<br />
* a demonstration of how the game plays<br />
* an explanation of the innovative aspects that your team members have implemented<br />
* an evaluation of the features that your team incorporated, including criticisms and suggested enhancements<br />
<br />
Each team has 30 minutes to showcase its game.<br />
<br /><br />
<br /><br />
<br /><br />
<br />
= Features that you could add to the Updated Base Code =<br />
<br />
The base code serves as the common thread for sharing feature development amongst all members of the class. Our objective is to add as many of the features that students wish to see implemented in their own games as possible. We review this list at the start of the semester and you are welcome to expand detail or to add other features.<br />
<br />
* visibility determination<br />
** view frustum<br />
** bounding volume construction<br />
*** principal component analysis<br />
***: covariance matrix<br />
*** bounding box construction<br />
*** bounding sphere construction<br />
*** bounding ellipsoid construction<br />
** bounding volume tests<br />
**: bounding sphere test<br />
**: bounding ellipsoid test<br />
**: bounding cylinder test<br />
**: bounding box test<br />
** spatial partitioning<br />
*** octrees<br />
*** BSP trees<br />
** portal systems<br />
**: portal clipping<br />
**: reduced view frustums<br />
* collision detection<br />
** plane collisions<br />
**: sphere and plane<br />
**: box and plane<br />
**: spatial partitioning<br />
** general sphere collisions<br />
** oriented bounding boxes<br />
** sliding<br />
** collisions with physics<br />
*** moving spheres<br />
*** moving boxes<br />
* lighting techniques<br />
** isotropic<br />
*** Cook-Torrance<br />
*** Oren-Nayar<br />
** anisotropic<br />
*** Ward<br />
*** Ashikhmin-Shirley<br />
** bump mapping<br />
*** parallax<br />
*** self-shadowing<br />
** environment cube maps<br />
*** cube mapping<br />
*** high dynamic range cube maps<br />
** high dynamic range lighting<br />
*** simple<br />
*** faked<br />
*** tone mapping<br />
* texturing techniques<br />
** projective texturing<br />
** vertex texturing<br />
*** displacement mapping<br />
*** geometry images<br />
* audio techniques<br />
* comprehensive collada imports<br />
* third-person camera techniques<br />
* quaternions<br />
* networked gameplay<br />
* noise<br />
* fluids<br />
* non-photo-realistic rendering<br />
* particle systems<br />
* terrain<br />
** terrain following<br />
* opengl 3.0<br />
* open audio<br />
* Direct3D10<br />
** porting the framework to DirectX10<br />
* Direct3D11<br />
** porting the framework to DirectX11<br />
* Direct2D<br />
* advanced force feedback<br />
* input techniques<br />
** XInput<br />
** Raw input<br />
** picking<br />
* optimize coordinators for design unit creation and destruction<br />
** introduce standard template library<br />
** 0(1) removal of objects<br />
** provide external access to all objects in the scene coordinator<br />
* enable Streaming SIMD Extension 2 in Configuration Properties with optimized math calculations</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=User:Ajcondinho&diff=53128User:Ajcondinho2010-12-17T23:14:43Z<p>Ajcondinho: /* My OSD600 Project */</p>
<hr />
<div>== My Blog ==<br />
<br />
[http://ajcondinho.blogspot.com/ My Blog]<br />
<br />
== My OSD600 Project ==<br />
<br />
[http://zenit.senecac.on.ca/wiki/index.php/C3DL_Build_Bot C3DL Refactoring ]</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=C3DL_Build_Bot&diff=49961C3DL Build Bot2010-11-17T03:59:47Z<p>Ajcondinho: /* Releases */</p>
<hr />
<div>==Project Name==<br />
C3DL Build Bot - Build System for the C3DL Javascript library<br />
<br />
==Project Plan & Description==<br />
===Project Description===<br />
The build bot system for the C3DL library is a bash script that takes the numerous javascript files and combines them into one easy to download file. Future releases will allow users more customization options over what is/is not included in the library.<br />
<br />
===Project Plan===<br />
<br />
{| border="1"<br />
|-<br />
| '''Release'''<br />
| '''Download Release'''<br />
| '''Features/Points Addressed'''<br />
|-<br />
| 0.1<br />
| http://github.com/acondinho/C3DL-Build-System<br />
| Builds full library using a php web interface<br />
|-<br />
| 0.2<br />
| http://github.com/acondinho/C3DL-Build-System<br />
| This version now allows users to decide whether they want to include debugging tools when downloading the library<br />
|-<br />
| 0.3<br />
|<br />
|<br />
|-<br />
|}<br />
<br />
==Project Leader(s)==<br />
*Andrew Condinho<br />
*Andor Salga (Project Contact)<br />
*Cathy Leung (Project Contact)<br />
<br />
==Releases==<br />
*0.1 Release<br />
**Full library build<br />
**Minimized library build<br />
<br />
*0.2 Release<br />
**Debugging may now be turned on or off when downloading the library<br />
<br />
==Project News==<br />
<br />
==Project Contributor(s)==<br />
[http://sweerdenburg.wordpress.com/ Steven Weerdenburg] Contributed the web interface to interact with the bash script</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=C3DL_Build_Bot&diff=49960C3DL Build Bot2010-11-17T03:59:18Z<p>Ajcondinho: /* Project Plan */</p>
<hr />
<div>==Project Name==<br />
C3DL Build Bot - Build System for the C3DL Javascript library<br />
<br />
==Project Plan & Description==<br />
===Project Description===<br />
The build bot system for the C3DL library is a bash script that takes the numerous javascript files and combines them into one easy to download file. Future releases will allow users more customization options over what is/is not included in the library.<br />
<br />
===Project Plan===<br />
<br />
{| border="1"<br />
|-<br />
| '''Release'''<br />
| '''Download Release'''<br />
| '''Features/Points Addressed'''<br />
|-<br />
| 0.1<br />
| http://github.com/acondinho/C3DL-Build-System<br />
| Builds full library using a php web interface<br />
|-<br />
| 0.2<br />
| http://github.com/acondinho/C3DL-Build-System<br />
| This version now allows users to decide whether they want to include debugging tools when downloading the library<br />
|-<br />
| 0.3<br />
|<br />
|<br />
|-<br />
|}<br />
<br />
==Project Leader(s)==<br />
*Andrew Condinho<br />
*Andor Salga (Project Contact)<br />
*Cathy Leung (Project Contact)<br />
<br />
==Releases==<br />
*0.1 Release<br />
**Full library build<br />
**Minimized library build<br />
<br />
==Project News==<br />
<br />
==Project Contributor(s)==<br />
[http://sweerdenburg.wordpress.com/ Steven Weerdenburg] Contributed the web interface to interact with the bash script</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=Team_Blam&diff=49059Team Blam2010-11-04T14:39:54Z<p>Ajcondinho: /* To Do List */</p>
<hr />
<div>{{GAM666/DPS901 Index | 20103}}<br />
= Don't Crash Into Buildings! =<br />
== Project Marking Percentage ==<br />
<big><br />
Group work: xx% (25 <= xx <= 50)<br />
Individual work: xx% + (50 <= xx <= 75) <br />
-------------------------<br />
Total 100%<br />
</big><br />
== Team Website ==<br />
[http://blam.lighthouseapp.com/projects/61347-dont-crash-into-buildings/overview blam.lighthouseapp.com]<br />
== Repository ==<br />
=== Repo path ===<br />
<br />
svn://zenit.senecac.on.ca/dps901_103rep3<br />
<br />
=== Trunk Status ===<br />
<br />
committed by YuJin (04-Oct-2010)<br />
<br />
== Member List == <br />
<br />
*[mailto:blaw1@learn.senecac.on.ca,ajcondinho@learn.senecac.on.ca,drperit@learn.senecac.on.ca?subject=gam666 Email All]<br />
<br />
{| class="wikitable sortable" border="1" cellpadding="5"<br />
! First Name !! Last Name !! Seneca Id !! wiki id !! IRC nick !! Blog URL !! MSN !! Phone<br />
|-<br />
|[[User:dperit | David]]||Perit||[mailto:drperit@learn.senecac.on.ca?sujbect=gam666 drperit]||[[Special:Contributions/dperit| dperit]]||dperit|| || wowbagger5@hotmail.com || 647 - 520 - 3039<br />
|-<br />
<br />
|-<br />
|[[User:ajcondinho | Andrew]]||Condinho||[mailto:ajcondinho@learn.senecac.on.ca?sujbect=gam666 ajcondinho]||[[Special:Contributions/ajcondinho| ajcondinho]]||Dueraim||[http://ajcondinho.blogspot.com/ Andrew's Blog] || || 416 - 997 - 1589<br />
|-<br />
<br />
|-<br />
|[[User:blaw1 | Brian]]||Law||[mailto:blaw1@learn.senecac.on.ca?sujbect=gam666 blaw1]||[[Special:Contributions/blaw1|blaw1 ]] || || || || 416 - 254 - 3457<br />
|-<br />
<br />
|}<br />
<br />
== Member Roles ==<br />
{| class="wikitable" border="1" width="300"<br />
! Member !! Role<br />
|- align="left"<br />
| [[User:dperit | David ]] || Collision Detection<br />
|- align="left"<br />
| [[User:ajcondinho | Andrew ]] || Path Guaranteeing<br />
|- align="left"<br />
| [[User:blaw1 | Brian ]] || Ship Movement<br />
<br />
|}<br />
<br />
== Proposal ==<br />
<br />
<br />
'''Game Name:''' Don't Crash Into Buildings !<br/><br/><br />
'''Game Description:'''<br/><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;In our game, you will be the captain of a ship. The main engine of this ship is stuck on full blast, so it cannot ever stop. The ship is travelling through an increasingly dense urban landscape, and it is your goal to avoid crashing into anything for as long as possible! To accomplish this goal you have a view of your ship from high above it, allowing you to see buildings as they race towards you. You also have a set of maneuvering thrusters, which can push your ship back, forwards, left, and right on a two-dimensional plane. This will hopefully allow you to avoid crashing into buildings!<br /><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The top down view of your ship is provided by a camera moving at a constant speed. This camera provides a limited view of the area around your ship, and your ship cannot move out of this area, or it will crash into an unseen building. This results in you having a mostly static view of your ship as it flies forward through the city.<br />
Crashing into a building will kill you. Try to avoid this. The maneuvering thrusters on your ship are unlimited use, and can move you at a constant speed around the viewable area.<br/><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Due to overzealous construction, all of the entrances and exits to the city's planning department were blocked with buildings while the department was meeting to create a layout and zoning plan for the city. As a result, the placement of buildings in the city is random! There is, however, guaranteed to be a navigable path for your ship through the city, due to the actions of the Emergency Runaway Spacecraft Advance Demolition Crew, who are busy carving a path of destruction offscreen, just so that the game isn't impossible. All of the buildings in the city are rectangular in shape, making the collision detection code much easier to write.<br />
<br />
<br />
'''Enhanced Don't Crash Into Buildings !'''<br />
this is a list of things we can do if we're done everything else, and looking for more<br />
<br />
(Some or all of these features may be added to/replace features in the base game, depending on time constraints)<br />
<br />
* Rather than move you at a constant speed, your thrusters can accelerate you (up to certain maximum speeds). This can provide additional challenge.<br />
<br />
* Rather than being instantly killed by a collision, you could have shields on your ship which regenerate over time. This would be damaged by collisions in direct proportion to the speed with which you collided with the building, and you will die if it's reduced to 0<br />
<br />
* Could transition between levels, or have moments of blank space giving a chance to rest, followed by a change in environment/city textures<br />
* Have three dimensional movement (up + down, along with forward + back + left + right), combined with shorter buildings that can be flown over or buildings that have gaps in them<br />
* Because it is important to be at the correct altitude to fly through the gaps/over them, we could have an altitude meter with different colours. The gaps in the buildings could be marked with those colours, and then you can match up those colours with the altitude meter to know that you're at the correct height to pass through the gaps<br />
* Vertical movement should be between a set of discrete values, due to the difficulty in telling exact height from a top down perspective, even with an altitude meter<br />
<br />
== Initial version ==<br />
<br />
The initial version of the game will be on the command line, turn based, with positional accuracy to the character level. This will allow us to write the full grid-aligned bounding box based collision detection, a simplified version of the ship movement code, and the maze generation and path guaranteeing code.<br />
<br />
Basic algorithms:<br />
Collision detection: All of the buildings are aligned to a grid, so they have a maximum and minimum x position, and a maximum and minimum y position. To determine if we have collided with a building, we check (either for all nearby buildings or all buildings onscreen) out ship's collision co-ordinates to see if maxBuildingX < shipX < minBuildingX AND maxBuildingY < shipY < minBuildingY. If so, then we've collided with that building. We should be keeping track of the ship's position in the previous frame, so that after we collide with something we can reset the position to that of the previous frame.<br />
<br />
Ship movement: Press arrows, ship position changes at a constant rate. In the console, we will simply change the ships position by one when an arrow key is pressed.<br />
<br />
Maze generation: We will have a difficulty number, possibly from 0 to 100, that increases over time. For each building square, we create a random number from 0 to 100. If that number is less than the difficulty number, then we place a building in that square.<br />
<br />
Path guaranteeing:<br />
If we have a building grid, like so, where x is a building and o is not a building:<br />
<pre><br />
XOOXX<br />
XXOOX<br />
XXOXX<br />
XOXXX<br />
</pre><br />
<br />
Then we'll have an exit point defined in the topmost row, either at column 2 or 3. Our next row will look like one of these possibilities (I'll assume the exit point is 3). The ? marks are pseudo-randomly determined to be a building or not a building depending on our maze generation algorithm.<br />
<pre><br />
??O?? new endpoint is 3<br />
?OO?? new endpoint is 2<br />
OOO?? new endpoint is 1<br />
??OO? new endpoint is 4<br />
??OOO new endpoint is 5<br />
</pre><br />
The most likely endpoint here would be 3, with endpoints of 2 and 4 less likely, and 1 and 5 even less likely, although the chance of getting 2,4,1, or 5 would increase with the difficulty level. If it's not possible for the ship to move fast enough to navigate X squares over in a row, then we'll remove that as a possibility, so that the maximum difference between end points in adjacent rows would be x - 1<br />
<br />
New maze generation code!<br />
<pre><br />
char buildings[40][5];<br />
//initialize that<br />
Path ourPaths[3];<br />
//initialize that<br />
<br />
for (int curRow = 0; curRow < 40; curRow++)<br />
{<br />
foreach(Path curPath in ourPaths)<br />
{<br />
curPath.buildPath(buildings[curRow]);<br />
}<br />
}<br />
<br />
<br />
Path<br />
{<br />
int startCol;<br />
int endCol;<br />
<br />
public:<br />
void buildPath(char currentRow[5])<br />
{<br />
currentRow[endCol] = notabuilding;<br />
startCol = endCol;<br />
endCol = endCol + or - a random number, probably influenced by difficulty level;<br />
//Fill in all columns between startCol and endCol with notabuildings<br />
}<br />
}<br />
</pre><br />
<br />
We are going to have several objects:<br />
A path object, which takes a row of buildings and generates a path in them.<br />
[optional, can just be a list] A pathset object, which contains a set of paths<br />
A building object, representing one building<br />
A maze object, containing a two dimensional array of buildings<br />
A ship object, representing the player's ship.<br />
<br />
Our main method will flow as follows, at least in the text version:<br />
The maze will use the set of path objects to generate a path through the maze<br />
Then, loop until exit, doing the following:<br />
Call the maze's draw function.<br />
<br />
Call the maze's collision detection function, passing in our ship. (Maze's collision detection will check all of the buildings for collisions, using the ship's co-ordinates)(If a collision is detected, the Maze's collision detection will call the ship's collision function, which will move the ship back in such a way that it's no longer colliding (this could involve storing the previous move and undoing it, adding in any additional movement downwards because the screen has just scrolled down) and reduce your shields)<br />
<br />
Call the ship's draw function<br />
<br />
Wait for input from the player.<br />
<br />
Give input to ship object, which will update position.<br />
<br />
Call the maze's scroll function, which will scroll at the pre-set rate.<br />
<br />
<br />
<br />
[http://zenit.senecac.on.ca/wiki/index.php/GAM666/DPS901_Project_requirements_20103#Phase_1 *How to write game proposal]<br />
== To Do List ==<br />
*Background City<br />
*Ship Implementation<br />
**Hook Ship Up To Arrow Keys<br />
*<s>Camera Fix</s><br />
*Building Texture Fix<br />
*Additional Maze Features<br />
*Add test grid to bottom of maze<br />
*Ambient Lighting<br />
*Scrolling Implementation<br />
*Ship Lights<br />
*Building + Ship Models<br />
*Full Screen Mode<br />
*Opening Configuration Box<br />
*HUD Implementation<br />
*Clean Up Framework Artifacts<br />
<br />
== Map of the World of the Game ==<br />
== Moderator's - Instructors Comments ==<br />
== Important Project Due Dates ==<br />
{| border="1"<br />
! Tasks !! Due Date<br />
|-<br />
|<s>1. Proposal outline and team members selected</s><br />
|<s>September 21</s><br />
|-<br />
|<s>2. Proposal completed and members roles selected</s><br />
|<s>September 28</s><br />
|-<br />
|<s>3. Research into game requirements begins</s><br />
|<s>September 29</s><br />
|-<br />
|<s>4. Approval meeting with instructor</s><br />
|<s>Weeks of October 3 and October 10</s><br />
|-<br />
|5. Draft game submission and project review<br />
|November 16<br />
|-<br />
|6. Final game presentation<br />
|December 7<br />
|}<br />
<br />
== Meeting Schedule ==<br />
{| border="1"<br />
! Date and Time !! Place<br />
|-<br />
|<s>Sept 16, 09:50 AM</s><br />
|<s>Seneca Library Room 1131</s><br />
|-<br />
|<s>Sept 23, 09:50 AM</s><br />
|<s>Seneca Library Room 1131</s><br />
|-<br />
|<s>Sept 30, 09:50 AM</s><br />
|<s>Seneca Library Room 1132</s><br />
|-<br />
|Oct 7, 09:50 AM<br />
|Seneca Library Room 1132<br />
|-<br />
<br />
|}<br />
<br />
== Meeting Log ==<br />
=== Sept 16th Meeting ===<br />
Meeting place : Room 1131, Seneca Library <br />
==== Agenda ====<br />
# Look for the last member <br />
# Brainstorming on our game - share any ideas in mind<br />
# Decide member roles<br />
# How this group will work<br />
# Set regular meeting schedule<br />
## at least once a week<br />
## share each other's timetable<br />
==== Result ====<br />
# Brian joined our group !<br />
# Agreed on David's idea - he will put up more details on wiki page<br />
# Will be decided later<br />
# Work under one trunk<br />
# Regular Meeting Schedule<br />
## in-person meeting<br />
## at Seneca Library - YuJin will book the room every week<br />
## on every Thursday between 9:50am and 11:40am<br />
<br />
<hr/><br />
=== Sept 23th Meeting ===<br />
Meeting place : Room 1132, Seneca Library<br/><br />
Meeting time : 9:50am ~ 11:40am<br />
==== Agenda ====<br />
# Finalize our game proposal<br />
# Divide roles & responsibilities<br />
# Keep updated <br/><br />
## subscribe to team page and course pages<br/><br />
## subscribe by clicking 'watch' of each page menu<br />
# Creating our own private team page ???<br />
##to disclose certain information of our group project ???<br />
<br />
==== Result ====<br />
# Uploaded game proposal - there might be changes in the future<br />
# Will divide roles after having meeting with Chris<br />
# (was just notification)<br />
# (wasn't discussed) <br />
# New meeting schedule<br />
## We will have meetings every Thursday AND Friday<br />
## Will have to figure the exact meeting time soon (for Fridays)<br />
<hr/><br />
=== Sept 30th Meeting ===<br />
Meeting place : Room 1132, Seneca Library<br/><br />
Meeting time : 9:50am ~ 11:40am<br />
==== Agenda ====<br />
# Discuss details on our game proposal<br />
# Divide up roles<br />
==== Result ====<br />
# Updated game proposal<br />
# Initial roles decided<br />
## David - Collision detection<br />
## YuJin - Maze Generator<br />
## Brian - Ship Movement<br />
## Andrew - Path guaranteeing<br />
<br />
<hr/><br />
=== Oct 7th Meeting ===<br />
Meeting place : Room 1132, Seneca Library<br/><br />
Meeting time : 9:50am ~ 11:40am<br />
==== Agenda ====<br />
<br />
==== Result ====<br />
<br />
== Resources ==<br />
[http://zenit.senecac.on.ca/wiki/index.php/Team_Blam-GridCode Simple Grid Code]<br />
<br />
== Useful Links ==<br />
[http://theory.stanford.edu/~amitp/GameProgramming/ Pathfinding Guide]</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=Team_Blam&diff=49058Team Blam2010-11-04T14:39:26Z<p>Ajcondinho: /* To Do List */</p>
<hr />
<div>{{GAM666/DPS901 Index | 20103}}<br />
= Don't Crash Into Buildings! =<br />
== Project Marking Percentage ==<br />
<big><br />
Group work: xx% (25 <= xx <= 50)<br />
Individual work: xx% + (50 <= xx <= 75) <br />
-------------------------<br />
Total 100%<br />
</big><br />
== Team Website ==<br />
[http://blam.lighthouseapp.com/projects/61347-dont-crash-into-buildings/overview blam.lighthouseapp.com]<br />
== Repository ==<br />
=== Repo path ===<br />
<br />
svn://zenit.senecac.on.ca/dps901_103rep3<br />
<br />
=== Trunk Status ===<br />
<br />
committed by YuJin (04-Oct-2010)<br />
<br />
== Member List == <br />
<br />
*[mailto:blaw1@learn.senecac.on.ca,ajcondinho@learn.senecac.on.ca,drperit@learn.senecac.on.ca?subject=gam666 Email All]<br />
<br />
{| class="wikitable sortable" border="1" cellpadding="5"<br />
! First Name !! Last Name !! Seneca Id !! wiki id !! IRC nick !! Blog URL !! MSN !! Phone<br />
|-<br />
|[[User:dperit | David]]||Perit||[mailto:drperit@learn.senecac.on.ca?sujbect=gam666 drperit]||[[Special:Contributions/dperit| dperit]]||dperit|| || wowbagger5@hotmail.com || 647 - 520 - 3039<br />
|-<br />
<br />
|-<br />
|[[User:ajcondinho | Andrew]]||Condinho||[mailto:ajcondinho@learn.senecac.on.ca?sujbect=gam666 ajcondinho]||[[Special:Contributions/ajcondinho| ajcondinho]]||Dueraim||[http://ajcondinho.blogspot.com/ Andrew's Blog] || || 416 - 997 - 1589<br />
|-<br />
<br />
|-<br />
|[[User:blaw1 | Brian]]||Law||[mailto:blaw1@learn.senecac.on.ca?sujbect=gam666 blaw1]||[[Special:Contributions/blaw1|blaw1 ]] || || || || 416 - 254 - 3457<br />
|-<br />
<br />
|}<br />
<br />
== Member Roles ==<br />
{| class="wikitable" border="1" width="300"<br />
! Member !! Role<br />
|- align="left"<br />
| [[User:dperit | David ]] || Collision Detection<br />
|- align="left"<br />
| [[User:ajcondinho | Andrew ]] || Path Guaranteeing<br />
|- align="left"<br />
| [[User:blaw1 | Brian ]] || Ship Movement<br />
<br />
|}<br />
<br />
== Proposal ==<br />
<br />
<br />
'''Game Name:''' Don't Crash Into Buildings !<br/><br/><br />
'''Game Description:'''<br/><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;In our game, you will be the captain of a ship. The main engine of this ship is stuck on full blast, so it cannot ever stop. The ship is travelling through an increasingly dense urban landscape, and it is your goal to avoid crashing into anything for as long as possible! To accomplish this goal you have a view of your ship from high above it, allowing you to see buildings as they race towards you. You also have a set of maneuvering thrusters, which can push your ship back, forwards, left, and right on a two-dimensional plane. This will hopefully allow you to avoid crashing into buildings!<br /><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The top down view of your ship is provided by a camera moving at a constant speed. This camera provides a limited view of the area around your ship, and your ship cannot move out of this area, or it will crash into an unseen building. This results in you having a mostly static view of your ship as it flies forward through the city.<br />
Crashing into a building will kill you. Try to avoid this. The maneuvering thrusters on your ship are unlimited use, and can move you at a constant speed around the viewable area.<br/><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Due to overzealous construction, all of the entrances and exits to the city's planning department were blocked with buildings while the department was meeting to create a layout and zoning plan for the city. As a result, the placement of buildings in the city is random! There is, however, guaranteed to be a navigable path for your ship through the city, due to the actions of the Emergency Runaway Spacecraft Advance Demolition Crew, who are busy carving a path of destruction offscreen, just so that the game isn't impossible. All of the buildings in the city are rectangular in shape, making the collision detection code much easier to write.<br />
<br />
<br />
'''Enhanced Don't Crash Into Buildings !'''<br />
this is a list of things we can do if we're done everything else, and looking for more<br />
<br />
(Some or all of these features may be added to/replace features in the base game, depending on time constraints)<br />
<br />
* Rather than move you at a constant speed, your thrusters can accelerate you (up to certain maximum speeds). This can provide additional challenge.<br />
<br />
* Rather than being instantly killed by a collision, you could have shields on your ship which regenerate over time. This would be damaged by collisions in direct proportion to the speed with which you collided with the building, and you will die if it's reduced to 0<br />
<br />
* Could transition between levels, or have moments of blank space giving a chance to rest, followed by a change in environment/city textures<br />
* Have three dimensional movement (up + down, along with forward + back + left + right), combined with shorter buildings that can be flown over or buildings that have gaps in them<br />
* Because it is important to be at the correct altitude to fly through the gaps/over them, we could have an altitude meter with different colours. The gaps in the buildings could be marked with those colours, and then you can match up those colours with the altitude meter to know that you're at the correct height to pass through the gaps<br />
* Vertical movement should be between a set of discrete values, due to the difficulty in telling exact height from a top down perspective, even with an altitude meter<br />
<br />
== Initial version ==<br />
<br />
The initial version of the game will be on the command line, turn based, with positional accuracy to the character level. This will allow us to write the full grid-aligned bounding box based collision detection, a simplified version of the ship movement code, and the maze generation and path guaranteeing code.<br />
<br />
Basic algorithms:<br />
Collision detection: All of the buildings are aligned to a grid, so they have a maximum and minimum x position, and a maximum and minimum y position. To determine if we have collided with a building, we check (either for all nearby buildings or all buildings onscreen) out ship's collision co-ordinates to see if maxBuildingX < shipX < minBuildingX AND maxBuildingY < shipY < minBuildingY. If so, then we've collided with that building. We should be keeping track of the ship's position in the previous frame, so that after we collide with something we can reset the position to that of the previous frame.<br />
<br />
Ship movement: Press arrows, ship position changes at a constant rate. In the console, we will simply change the ships position by one when an arrow key is pressed.<br />
<br />
Maze generation: We will have a difficulty number, possibly from 0 to 100, that increases over time. For each building square, we create a random number from 0 to 100. If that number is less than the difficulty number, then we place a building in that square.<br />
<br />
Path guaranteeing:<br />
If we have a building grid, like so, where x is a building and o is not a building:<br />
<pre><br />
XOOXX<br />
XXOOX<br />
XXOXX<br />
XOXXX<br />
</pre><br />
<br />
Then we'll have an exit point defined in the topmost row, either at column 2 or 3. Our next row will look like one of these possibilities (I'll assume the exit point is 3). The ? marks are pseudo-randomly determined to be a building or not a building depending on our maze generation algorithm.<br />
<pre><br />
??O?? new endpoint is 3<br />
?OO?? new endpoint is 2<br />
OOO?? new endpoint is 1<br />
??OO? new endpoint is 4<br />
??OOO new endpoint is 5<br />
</pre><br />
The most likely endpoint here would be 3, with endpoints of 2 and 4 less likely, and 1 and 5 even less likely, although the chance of getting 2,4,1, or 5 would increase with the difficulty level. If it's not possible for the ship to move fast enough to navigate X squares over in a row, then we'll remove that as a possibility, so that the maximum difference between end points in adjacent rows would be x - 1<br />
<br />
New maze generation code!<br />
<pre><br />
char buildings[40][5];<br />
//initialize that<br />
Path ourPaths[3];<br />
//initialize that<br />
<br />
for (int curRow = 0; curRow < 40; curRow++)<br />
{<br />
foreach(Path curPath in ourPaths)<br />
{<br />
curPath.buildPath(buildings[curRow]);<br />
}<br />
}<br />
<br />
<br />
Path<br />
{<br />
int startCol;<br />
int endCol;<br />
<br />
public:<br />
void buildPath(char currentRow[5])<br />
{<br />
currentRow[endCol] = notabuilding;<br />
startCol = endCol;<br />
endCol = endCol + or - a random number, probably influenced by difficulty level;<br />
//Fill in all columns between startCol and endCol with notabuildings<br />
}<br />
}<br />
</pre><br />
<br />
We are going to have several objects:<br />
A path object, which takes a row of buildings and generates a path in them.<br />
[optional, can just be a list] A pathset object, which contains a set of paths<br />
A building object, representing one building<br />
A maze object, containing a two dimensional array of buildings<br />
A ship object, representing the player's ship.<br />
<br />
Our main method will flow as follows, at least in the text version:<br />
The maze will use the set of path objects to generate a path through the maze<br />
Then, loop until exit, doing the following:<br />
Call the maze's draw function.<br />
<br />
Call the maze's collision detection function, passing in our ship. (Maze's collision detection will check all of the buildings for collisions, using the ship's co-ordinates)(If a collision is detected, the Maze's collision detection will call the ship's collision function, which will move the ship back in such a way that it's no longer colliding (this could involve storing the previous move and undoing it, adding in any additional movement downwards because the screen has just scrolled down) and reduce your shields)<br />
<br />
Call the ship's draw function<br />
<br />
Wait for input from the player.<br />
<br />
Give input to ship object, which will update position.<br />
<br />
Call the maze's scroll function, which will scroll at the pre-set rate.<br />
<br />
<br />
<br />
[http://zenit.senecac.on.ca/wiki/index.php/GAM666/DPS901_Project_requirements_20103#Phase_1 *How to write game proposal]<br />
== To Do List ==<br />
*Background City*<br />
*Ship Implementation*<br />
**Hook Ship Up To Arrow Keys**<br />
*<s>Camera Fix</s>*<br />
*Building Texture Fix*<br />
*Additional Maze Features*<br />
*Add test grid to bottom of maze*<br />
*Ambient Lighting*<br />
*Scrolling Implementation*<br />
*Ship Lights*<br />
*Building + Ship Models*<br />
*Full Screen Mode*<br />
*Opening Configuration Box*<br />
*HUD Implementation*<br />
*Clean Up Framework Artifacts*<br />
<br />
== Map of the World of the Game ==<br />
== Moderator's - Instructors Comments ==<br />
== Important Project Due Dates ==<br />
{| border="1"<br />
! Tasks !! Due Date<br />
|-<br />
|<s>1. Proposal outline and team members selected</s><br />
|<s>September 21</s><br />
|-<br />
|<s>2. Proposal completed and members roles selected</s><br />
|<s>September 28</s><br />
|-<br />
|<s>3. Research into game requirements begins</s><br />
|<s>September 29</s><br />
|-<br />
|<s>4. Approval meeting with instructor</s><br />
|<s>Weeks of October 3 and October 10</s><br />
|-<br />
|5. Draft game submission and project review<br />
|November 16<br />
|-<br />
|6. Final game presentation<br />
|December 7<br />
|}<br />
<br />
== Meeting Schedule ==<br />
{| border="1"<br />
! Date and Time !! Place<br />
|-<br />
|<s>Sept 16, 09:50 AM</s><br />
|<s>Seneca Library Room 1131</s><br />
|-<br />
|<s>Sept 23, 09:50 AM</s><br />
|<s>Seneca Library Room 1131</s><br />
|-<br />
|<s>Sept 30, 09:50 AM</s><br />
|<s>Seneca Library Room 1132</s><br />
|-<br />
|Oct 7, 09:50 AM<br />
|Seneca Library Room 1132<br />
|-<br />
<br />
|}<br />
<br />
== Meeting Log ==<br />
=== Sept 16th Meeting ===<br />
Meeting place : Room 1131, Seneca Library <br />
==== Agenda ====<br />
# Look for the last member <br />
# Brainstorming on our game - share any ideas in mind<br />
# Decide member roles<br />
# How this group will work<br />
# Set regular meeting schedule<br />
## at least once a week<br />
## share each other's timetable<br />
==== Result ====<br />
# Brian joined our group !<br />
# Agreed on David's idea - he will put up more details on wiki page<br />
# Will be decided later<br />
# Work under one trunk<br />
# Regular Meeting Schedule<br />
## in-person meeting<br />
## at Seneca Library - YuJin will book the room every week<br />
## on every Thursday between 9:50am and 11:40am<br />
<br />
<hr/><br />
=== Sept 23th Meeting ===<br />
Meeting place : Room 1132, Seneca Library<br/><br />
Meeting time : 9:50am ~ 11:40am<br />
==== Agenda ====<br />
# Finalize our game proposal<br />
# Divide roles & responsibilities<br />
# Keep updated <br/><br />
## subscribe to team page and course pages<br/><br />
## subscribe by clicking 'watch' of each page menu<br />
# Creating our own private team page ???<br />
##to disclose certain information of our group project ???<br />
<br />
==== Result ====<br />
# Uploaded game proposal - there might be changes in the future<br />
# Will divide roles after having meeting with Chris<br />
# (was just notification)<br />
# (wasn't discussed) <br />
# New meeting schedule<br />
## We will have meetings every Thursday AND Friday<br />
## Will have to figure the exact meeting time soon (for Fridays)<br />
<hr/><br />
=== Sept 30th Meeting ===<br />
Meeting place : Room 1132, Seneca Library<br/><br />
Meeting time : 9:50am ~ 11:40am<br />
==== Agenda ====<br />
# Discuss details on our game proposal<br />
# Divide up roles<br />
==== Result ====<br />
# Updated game proposal<br />
# Initial roles decided<br />
## David - Collision detection<br />
## YuJin - Maze Generator<br />
## Brian - Ship Movement<br />
## Andrew - Path guaranteeing<br />
<br />
<hr/><br />
=== Oct 7th Meeting ===<br />
Meeting place : Room 1132, Seneca Library<br/><br />
Meeting time : 9:50am ~ 11:40am<br />
==== Agenda ====<br />
<br />
==== Result ====<br />
<br />
== Resources ==<br />
[http://zenit.senecac.on.ca/wiki/index.php/Team_Blam-GridCode Simple Grid Code]<br />
<br />
== Useful Links ==<br />
[http://theory.stanford.edu/~amitp/GameProgramming/ Pathfinding Guide]</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=Team_Blam&diff=49057Team Blam2010-11-04T14:32:18Z<p>Ajcondinho: /* To Do List */</p>
<hr />
<div>{{GAM666/DPS901 Index | 20103}}<br />
= Don't Crash Into Buildings! =<br />
== Project Marking Percentage ==<br />
<big><br />
Group work: xx% (25 <= xx <= 50)<br />
Individual work: xx% + (50 <= xx <= 75) <br />
-------------------------<br />
Total 100%<br />
</big><br />
== Team Website ==<br />
[http://blam.lighthouseapp.com/projects/61347-dont-crash-into-buildings/overview blam.lighthouseapp.com]<br />
== Repository ==<br />
=== Repo path ===<br />
<br />
svn://zenit.senecac.on.ca/dps901_103rep3<br />
<br />
=== Trunk Status ===<br />
<br />
committed by YuJin (04-Oct-2010)<br />
<br />
== Member List == <br />
<br />
*[mailto:blaw1@learn.senecac.on.ca,ajcondinho@learn.senecac.on.ca,drperit@learn.senecac.on.ca?subject=gam666 Email All]<br />
<br />
{| class="wikitable sortable" border="1" cellpadding="5"<br />
! First Name !! Last Name !! Seneca Id !! wiki id !! IRC nick !! Blog URL !! MSN !! Phone<br />
|-<br />
|[[User:dperit | David]]||Perit||[mailto:drperit@learn.senecac.on.ca?sujbect=gam666 drperit]||[[Special:Contributions/dperit| dperit]]||dperit|| || wowbagger5@hotmail.com || 647 - 520 - 3039<br />
|-<br />
<br />
|-<br />
|[[User:ajcondinho | Andrew]]||Condinho||[mailto:ajcondinho@learn.senecac.on.ca?sujbect=gam666 ajcondinho]||[[Special:Contributions/ajcondinho| ajcondinho]]||Dueraim||[http://ajcondinho.blogspot.com/ Andrew's Blog] || || 416 - 997 - 1589<br />
|-<br />
<br />
|-<br />
|[[User:blaw1 | Brian]]||Law||[mailto:blaw1@learn.senecac.on.ca?sujbect=gam666 blaw1]||[[Special:Contributions/blaw1|blaw1 ]] || || || || 416 - 254 - 3457<br />
|-<br />
<br />
|}<br />
<br />
== Member Roles ==<br />
{| class="wikitable" border="1" width="300"<br />
! Member !! Role<br />
|- align="left"<br />
| [[User:dperit | David ]] || Collision Detection<br />
|- align="left"<br />
| [[User:ajcondinho | Andrew ]] || Path Guaranteeing<br />
|- align="left"<br />
| [[User:blaw1 | Brian ]] || Ship Movement<br />
<br />
|}<br />
<br />
== Proposal ==<br />
<br />
<br />
'''Game Name:''' Don't Crash Into Buildings !<br/><br/><br />
'''Game Description:'''<br/><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;In our game, you will be the captain of a ship. The main engine of this ship is stuck on full blast, so it cannot ever stop. The ship is travelling through an increasingly dense urban landscape, and it is your goal to avoid crashing into anything for as long as possible! To accomplish this goal you have a view of your ship from high above it, allowing you to see buildings as they race towards you. You also have a set of maneuvering thrusters, which can push your ship back, forwards, left, and right on a two-dimensional plane. This will hopefully allow you to avoid crashing into buildings!<br /><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The top down view of your ship is provided by a camera moving at a constant speed. This camera provides a limited view of the area around your ship, and your ship cannot move out of this area, or it will crash into an unseen building. This results in you having a mostly static view of your ship as it flies forward through the city.<br />
Crashing into a building will kill you. Try to avoid this. The maneuvering thrusters on your ship are unlimited use, and can move you at a constant speed around the viewable area.<br/><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Due to overzealous construction, all of the entrances and exits to the city's planning department were blocked with buildings while the department was meeting to create a layout and zoning plan for the city. As a result, the placement of buildings in the city is random! There is, however, guaranteed to be a navigable path for your ship through the city, due to the actions of the Emergency Runaway Spacecraft Advance Demolition Crew, who are busy carving a path of destruction offscreen, just so that the game isn't impossible. All of the buildings in the city are rectangular in shape, making the collision detection code much easier to write.<br />
<br />
<br />
'''Enhanced Don't Crash Into Buildings !'''<br />
this is a list of things we can do if we're done everything else, and looking for more<br />
<br />
(Some or all of these features may be added to/replace features in the base game, depending on time constraints)<br />
<br />
* Rather than move you at a constant speed, your thrusters can accelerate you (up to certain maximum speeds). This can provide additional challenge.<br />
<br />
* Rather than being instantly killed by a collision, you could have shields on your ship which regenerate over time. This would be damaged by collisions in direct proportion to the speed with which you collided with the building, and you will die if it's reduced to 0<br />
<br />
* Could transition between levels, or have moments of blank space giving a chance to rest, followed by a change in environment/city textures<br />
* Have three dimensional movement (up + down, along with forward + back + left + right), combined with shorter buildings that can be flown over or buildings that have gaps in them<br />
* Because it is important to be at the correct altitude to fly through the gaps/over them, we could have an altitude meter with different colours. The gaps in the buildings could be marked with those colours, and then you can match up those colours with the altitude meter to know that you're at the correct height to pass through the gaps<br />
* Vertical movement should be between a set of discrete values, due to the difficulty in telling exact height from a top down perspective, even with an altitude meter<br />
<br />
== Initial version ==<br />
<br />
The initial version of the game will be on the command line, turn based, with positional accuracy to the character level. This will allow us to write the full grid-aligned bounding box based collision detection, a simplified version of the ship movement code, and the maze generation and path guaranteeing code.<br />
<br />
Basic algorithms:<br />
Collision detection: All of the buildings are aligned to a grid, so they have a maximum and minimum x position, and a maximum and minimum y position. To determine if we have collided with a building, we check (either for all nearby buildings or all buildings onscreen) out ship's collision co-ordinates to see if maxBuildingX < shipX < minBuildingX AND maxBuildingY < shipY < minBuildingY. If so, then we've collided with that building. We should be keeping track of the ship's position in the previous frame, so that after we collide with something we can reset the position to that of the previous frame.<br />
<br />
Ship movement: Press arrows, ship position changes at a constant rate. In the console, we will simply change the ships position by one when an arrow key is pressed.<br />
<br />
Maze generation: We will have a difficulty number, possibly from 0 to 100, that increases over time. For each building square, we create a random number from 0 to 100. If that number is less than the difficulty number, then we place a building in that square.<br />
<br />
Path guaranteeing:<br />
If we have a building grid, like so, where x is a building and o is not a building:<br />
<pre><br />
XOOXX<br />
XXOOX<br />
XXOXX<br />
XOXXX<br />
</pre><br />
<br />
Then we'll have an exit point defined in the topmost row, either at column 2 or 3. Our next row will look like one of these possibilities (I'll assume the exit point is 3). The ? marks are pseudo-randomly determined to be a building or not a building depending on our maze generation algorithm.<br />
<pre><br />
??O?? new endpoint is 3<br />
?OO?? new endpoint is 2<br />
OOO?? new endpoint is 1<br />
??OO? new endpoint is 4<br />
??OOO new endpoint is 5<br />
</pre><br />
The most likely endpoint here would be 3, with endpoints of 2 and 4 less likely, and 1 and 5 even less likely, although the chance of getting 2,4,1, or 5 would increase with the difficulty level. If it's not possible for the ship to move fast enough to navigate X squares over in a row, then we'll remove that as a possibility, so that the maximum difference between end points in adjacent rows would be x - 1<br />
<br />
New maze generation code!<br />
<pre><br />
char buildings[40][5];<br />
//initialize that<br />
Path ourPaths[3];<br />
//initialize that<br />
<br />
for (int curRow = 0; curRow < 40; curRow++)<br />
{<br />
foreach(Path curPath in ourPaths)<br />
{<br />
curPath.buildPath(buildings[curRow]);<br />
}<br />
}<br />
<br />
<br />
Path<br />
{<br />
int startCol;<br />
int endCol;<br />
<br />
public:<br />
void buildPath(char currentRow[5])<br />
{<br />
currentRow[endCol] = notabuilding;<br />
startCol = endCol;<br />
endCol = endCol + or - a random number, probably influenced by difficulty level;<br />
//Fill in all columns between startCol and endCol with notabuildings<br />
}<br />
}<br />
</pre><br />
<br />
We are going to have several objects:<br />
A path object, which takes a row of buildings and generates a path in them.<br />
[optional, can just be a list] A pathset object, which contains a set of paths<br />
A building object, representing one building<br />
A maze object, containing a two dimensional array of buildings<br />
A ship object, representing the player's ship.<br />
<br />
Our main method will flow as follows, at least in the text version:<br />
The maze will use the set of path objects to generate a path through the maze<br />
Then, loop until exit, doing the following:<br />
Call the maze's draw function.<br />
<br />
Call the maze's collision detection function, passing in our ship. (Maze's collision detection will check all of the buildings for collisions, using the ship's co-ordinates)(If a collision is detected, the Maze's collision detection will call the ship's collision function, which will move the ship back in such a way that it's no longer colliding (this could involve storing the previous move and undoing it, adding in any additional movement downwards because the screen has just scrolled down) and reduce your shields)<br />
<br />
Call the ship's draw function<br />
<br />
Wait for input from the player.<br />
<br />
Give input to ship object, which will update position.<br />
<br />
Call the maze's scroll function, which will scroll at the pre-set rate.<br />
<br />
<br />
<br />
[http://zenit.senecac.on.ca/wiki/index.php/GAM666/DPS901_Project_requirements_20103#Phase_1 *How to write game proposal]<br />
== To Do List ==<br />
*Background City*<br />
*Ship Implementation*<br />
<s>*Camera Fix*</s><br />
*Building Texture Fix*<br />
*Additional Maze Features*<br />
*Add test grid to bottom of maze*<br />
<br />
== Map of the World of the Game ==<br />
== Moderator's - Instructors Comments ==<br />
== Important Project Due Dates ==<br />
{| border="1"<br />
! Tasks !! Due Date<br />
|-<br />
|<s>1. Proposal outline and team members selected</s><br />
|<s>September 21</s><br />
|-<br />
|<s>2. Proposal completed and members roles selected</s><br />
|<s>September 28</s><br />
|-<br />
|<s>3. Research into game requirements begins</s><br />
|<s>September 29</s><br />
|-<br />
|<s>4. Approval meeting with instructor</s><br />
|<s>Weeks of October 3 and October 10</s><br />
|-<br />
|5. Draft game submission and project review<br />
|November 16<br />
|-<br />
|6. Final game presentation<br />
|December 7<br />
|}<br />
<br />
== Meeting Schedule ==<br />
{| border="1"<br />
! Date and Time !! Place<br />
|-<br />
|<s>Sept 16, 09:50 AM</s><br />
|<s>Seneca Library Room 1131</s><br />
|-<br />
|<s>Sept 23, 09:50 AM</s><br />
|<s>Seneca Library Room 1131</s><br />
|-<br />
|<s>Sept 30, 09:50 AM</s><br />
|<s>Seneca Library Room 1132</s><br />
|-<br />
|Oct 7, 09:50 AM<br />
|Seneca Library Room 1132<br />
|-<br />
<br />
|}<br />
<br />
== Meeting Log ==<br />
=== Sept 16th Meeting ===<br />
Meeting place : Room 1131, Seneca Library <br />
==== Agenda ====<br />
# Look for the last member <br />
# Brainstorming on our game - share any ideas in mind<br />
# Decide member roles<br />
# How this group will work<br />
# Set regular meeting schedule<br />
## at least once a week<br />
## share each other's timetable<br />
==== Result ====<br />
# Brian joined our group !<br />
# Agreed on David's idea - he will put up more details on wiki page<br />
# Will be decided later<br />
# Work under one trunk<br />
# Regular Meeting Schedule<br />
## in-person meeting<br />
## at Seneca Library - YuJin will book the room every week<br />
## on every Thursday between 9:50am and 11:40am<br />
<br />
<hr/><br />
=== Sept 23th Meeting ===<br />
Meeting place : Room 1132, Seneca Library<br/><br />
Meeting time : 9:50am ~ 11:40am<br />
==== Agenda ====<br />
# Finalize our game proposal<br />
# Divide roles & responsibilities<br />
# Keep updated <br/><br />
## subscribe to team page and course pages<br/><br />
## subscribe by clicking 'watch' of each page menu<br />
# Creating our own private team page ???<br />
##to disclose certain information of our group project ???<br />
<br />
==== Result ====<br />
# Uploaded game proposal - there might be changes in the future<br />
# Will divide roles after having meeting with Chris<br />
# (was just notification)<br />
# (wasn't discussed) <br />
# New meeting schedule<br />
## We will have meetings every Thursday AND Friday<br />
## Will have to figure the exact meeting time soon (for Fridays)<br />
<hr/><br />
=== Sept 30th Meeting ===<br />
Meeting place : Room 1132, Seneca Library<br/><br />
Meeting time : 9:50am ~ 11:40am<br />
==== Agenda ====<br />
# Discuss details on our game proposal<br />
# Divide up roles<br />
==== Result ====<br />
# Updated game proposal<br />
# Initial roles decided<br />
## David - Collision detection<br />
## YuJin - Maze Generator<br />
## Brian - Ship Movement<br />
## Andrew - Path guaranteeing<br />
<br />
<hr/><br />
=== Oct 7th Meeting ===<br />
Meeting place : Room 1132, Seneca Library<br/><br />
Meeting time : 9:50am ~ 11:40am<br />
==== Agenda ====<br />
<br />
==== Result ====<br />
<br />
== Resources ==<br />
[http://zenit.senecac.on.ca/wiki/index.php/Team_Blam-GridCode Simple Grid Code]<br />
<br />
== Useful Links ==<br />
[http://theory.stanford.edu/~amitp/GameProgramming/ Pathfinding Guide]</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=Team_Blam&diff=49055Team Blam2010-11-04T14:21:28Z<p>Ajcondinho: </p>
<hr />
<div>{{GAM666/DPS901 Index | 20103}}<br />
= Don't Crash Into Buildings! =<br />
== Project Marking Percentage ==<br />
<big><br />
Group work: xx% (25 <= xx <= 50)<br />
Individual work: xx% + (50 <= xx <= 75) <br />
-------------------------<br />
Total 100%<br />
</big><br />
== Team Website ==<br />
[http://blam.lighthouseapp.com/projects/61347-dont-crash-into-buildings/overview blam.lighthouseapp.com]<br />
== Repository ==<br />
=== Repo path ===<br />
<br />
svn://zenit.senecac.on.ca/dps901_103rep3<br />
<br />
=== Trunk Status ===<br />
<br />
committed by YuJin (04-Oct-2010)<br />
<br />
== Member List == <br />
<br />
*[mailto:blaw1@learn.senecac.on.ca,ajcondinho@learn.senecac.on.ca,drperit@learn.senecac.on.ca?subject=gam666 Email All]<br />
<br />
{| class="wikitable sortable" border="1" cellpadding="5"<br />
! First Name !! Last Name !! Seneca Id !! wiki id !! IRC nick !! Blog URL !! MSN !! Phone<br />
|-<br />
|[[User:dperit | David]]||Perit||[mailto:drperit@learn.senecac.on.ca?sujbect=gam666 drperit]||[[Special:Contributions/dperit| dperit]]||dperit|| || wowbagger5@hotmail.com || 647 - 520 - 3039<br />
|-<br />
<br />
|-<br />
|[[User:ajcondinho | Andrew]]||Condinho||[mailto:ajcondinho@learn.senecac.on.ca?sujbect=gam666 ajcondinho]||[[Special:Contributions/ajcondinho| ajcondinho]]||Dueraim||[http://ajcondinho.blogspot.com/ Andrew's Blog] || || 416 - 997 - 1589<br />
|-<br />
<br />
|-<br />
|[[User:blaw1 | Brian]]||Law||[mailto:blaw1@learn.senecac.on.ca?sujbect=gam666 blaw1]||[[Special:Contributions/blaw1|blaw1 ]] || || || || 416 - 254 - 3457<br />
|-<br />
<br />
|}<br />
<br />
== Member Roles ==<br />
{| class="wikitable" border="1" width="300"<br />
! Member !! Role<br />
|- align="left"<br />
| [[User:dperit | David ]] || Collision Detection<br />
|- align="left"<br />
| [[User:ajcondinho | Andrew ]] || Path Guaranteeing<br />
|- align="left"<br />
| [[User:blaw1 | Brian ]] || Ship Movement<br />
<br />
|}<br />
<br />
== Proposal ==<br />
<br />
<br />
'''Game Name:''' Don't Crash Into Buildings !<br/><br/><br />
'''Game Description:'''<br/><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;In our game, you will be the captain of a ship. The main engine of this ship is stuck on full blast, so it cannot ever stop. The ship is travelling through an increasingly dense urban landscape, and it is your goal to avoid crashing into anything for as long as possible! To accomplish this goal you have a view of your ship from high above it, allowing you to see buildings as they race towards you. You also have a set of maneuvering thrusters, which can push your ship back, forwards, left, and right on a two-dimensional plane. This will hopefully allow you to avoid crashing into buildings!<br /><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The top down view of your ship is provided by a camera moving at a constant speed. This camera provides a limited view of the area around your ship, and your ship cannot move out of this area, or it will crash into an unseen building. This results in you having a mostly static view of your ship as it flies forward through the city.<br />
Crashing into a building will kill you. Try to avoid this. The maneuvering thrusters on your ship are unlimited use, and can move you at a constant speed around the viewable area.<br/><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Due to overzealous construction, all of the entrances and exits to the city's planning department were blocked with buildings while the department was meeting to create a layout and zoning plan for the city. As a result, the placement of buildings in the city is random! There is, however, guaranteed to be a navigable path for your ship through the city, due to the actions of the Emergency Runaway Spacecraft Advance Demolition Crew, who are busy carving a path of destruction offscreen, just so that the game isn't impossible. All of the buildings in the city are rectangular in shape, making the collision detection code much easier to write.<br />
<br />
<br />
'''Enhanced Don't Crash Into Buildings !'''<br />
this is a list of things we can do if we're done everything else, and looking for more<br />
<br />
(Some or all of these features may be added to/replace features in the base game, depending on time constraints)<br />
<br />
* Rather than move you at a constant speed, your thrusters can accelerate you (up to certain maximum speeds). This can provide additional challenge.<br />
<br />
* Rather than being instantly killed by a collision, you could have shields on your ship which regenerate over time. This would be damaged by collisions in direct proportion to the speed with which you collided with the building, and you will die if it's reduced to 0<br />
<br />
* Could transition between levels, or have moments of blank space giving a chance to rest, followed by a change in environment/city textures<br />
* Have three dimensional movement (up + down, along with forward + back + left + right), combined with shorter buildings that can be flown over or buildings that have gaps in them<br />
* Because it is important to be at the correct altitude to fly through the gaps/over them, we could have an altitude meter with different colours. The gaps in the buildings could be marked with those colours, and then you can match up those colours with the altitude meter to know that you're at the correct height to pass through the gaps<br />
* Vertical movement should be between a set of discrete values, due to the difficulty in telling exact height from a top down perspective, even with an altitude meter<br />
<br />
== Initial version ==<br />
<br />
The initial version of the game will be on the command line, turn based, with positional accuracy to the character level. This will allow us to write the full grid-aligned bounding box based collision detection, a simplified version of the ship movement code, and the maze generation and path guaranteeing code.<br />
<br />
Basic algorithms:<br />
Collision detection: All of the buildings are aligned to a grid, so they have a maximum and minimum x position, and a maximum and minimum y position. To determine if we have collided with a building, we check (either for all nearby buildings or all buildings onscreen) out ship's collision co-ordinates to see if maxBuildingX < shipX < minBuildingX AND maxBuildingY < shipY < minBuildingY. If so, then we've collided with that building. We should be keeping track of the ship's position in the previous frame, so that after we collide with something we can reset the position to that of the previous frame.<br />
<br />
Ship movement: Press arrows, ship position changes at a constant rate. In the console, we will simply change the ships position by one when an arrow key is pressed.<br />
<br />
Maze generation: We will have a difficulty number, possibly from 0 to 100, that increases over time. For each building square, we create a random number from 0 to 100. If that number is less than the difficulty number, then we place a building in that square.<br />
<br />
Path guaranteeing:<br />
If we have a building grid, like so, where x is a building and o is not a building:<br />
<pre><br />
XOOXX<br />
XXOOX<br />
XXOXX<br />
XOXXX<br />
</pre><br />
<br />
Then we'll have an exit point defined in the topmost row, either at column 2 or 3. Our next row will look like one of these possibilities (I'll assume the exit point is 3). The ? marks are pseudo-randomly determined to be a building or not a building depending on our maze generation algorithm.<br />
<pre><br />
??O?? new endpoint is 3<br />
?OO?? new endpoint is 2<br />
OOO?? new endpoint is 1<br />
??OO? new endpoint is 4<br />
??OOO new endpoint is 5<br />
</pre><br />
The most likely endpoint here would be 3, with endpoints of 2 and 4 less likely, and 1 and 5 even less likely, although the chance of getting 2,4,1, or 5 would increase with the difficulty level. If it's not possible for the ship to move fast enough to navigate X squares over in a row, then we'll remove that as a possibility, so that the maximum difference between end points in adjacent rows would be x - 1<br />
<br />
New maze generation code!<br />
<pre><br />
char buildings[40][5];<br />
//initialize that<br />
Path ourPaths[3];<br />
//initialize that<br />
<br />
for (int curRow = 0; curRow < 40; curRow++)<br />
{<br />
foreach(Path curPath in ourPaths)<br />
{<br />
curPath.buildPath(buildings[curRow]);<br />
}<br />
}<br />
<br />
<br />
Path<br />
{<br />
int startCol;<br />
int endCol;<br />
<br />
public:<br />
void buildPath(char currentRow[5])<br />
{<br />
currentRow[endCol] = notabuilding;<br />
startCol = endCol;<br />
endCol = endCol + or - a random number, probably influenced by difficulty level;<br />
//Fill in all columns between startCol and endCol with notabuildings<br />
}<br />
}<br />
</pre><br />
<br />
We are going to have several objects:<br />
A path object, which takes a row of buildings and generates a path in them.<br />
[optional, can just be a list] A pathset object, which contains a set of paths<br />
A building object, representing one building<br />
A maze object, containing a two dimensional array of buildings<br />
A ship object, representing the player's ship.<br />
<br />
Our main method will flow as follows, at least in the text version:<br />
The maze will use the set of path objects to generate a path through the maze<br />
Then, loop until exit, doing the following:<br />
Call the maze's draw function.<br />
<br />
Call the maze's collision detection function, passing in our ship. (Maze's collision detection will check all of the buildings for collisions, using the ship's co-ordinates)(If a collision is detected, the Maze's collision detection will call the ship's collision function, which will move the ship back in such a way that it's no longer colliding (this could involve storing the previous move and undoing it, adding in any additional movement downwards because the screen has just scrolled down) and reduce your shields)<br />
<br />
Call the ship's draw function<br />
<br />
Wait for input from the player.<br />
<br />
Give input to ship object, which will update position.<br />
<br />
Call the maze's scroll function, which will scroll at the pre-set rate.<br />
<br />
<br />
<br />
[http://zenit.senecac.on.ca/wiki/index.php/GAM666/DPS901_Project_requirements_20103#Phase_1 *How to write game proposal]<br />
== To Do List ==<br />
== Map of the World of the Game ==<br />
== Moderator's - Instructors Comments ==<br />
== Important Project Due Dates ==<br />
{| border="1"<br />
! Tasks !! Due Date<br />
|-<br />
|<s>1. Proposal outline and team members selected</s><br />
|<s>September 21</s><br />
|-<br />
|<s>2. Proposal completed and members roles selected</s><br />
|<s>September 28</s><br />
|-<br />
|<s>3. Research into game requirements begins</s><br />
|<s>September 29</s><br />
|-<br />
|<s>4. Approval meeting with instructor</s><br />
|<s>Weeks of October 3 and October 10</s><br />
|-<br />
|5. Draft game submission and project review<br />
|November 16<br />
|-<br />
|6. Final game presentation<br />
|December 7<br />
|}<br />
<br />
== Meeting Schedule ==<br />
{| border="1"<br />
! Date and Time !! Place<br />
|-<br />
|<s>Sept 16, 09:50 AM</s><br />
|<s>Seneca Library Room 1131</s><br />
|-<br />
|<s>Sept 23, 09:50 AM</s><br />
|<s>Seneca Library Room 1131</s><br />
|-<br />
|<s>Sept 30, 09:50 AM</s><br />
|<s>Seneca Library Room 1132</s><br />
|-<br />
|Oct 7, 09:50 AM<br />
|Seneca Library Room 1132<br />
|-<br />
<br />
|}<br />
<br />
== Meeting Log ==<br />
=== Sept 16th Meeting ===<br />
Meeting place : Room 1131, Seneca Library <br />
==== Agenda ====<br />
# Look for the last member <br />
# Brainstorming on our game - share any ideas in mind<br />
# Decide member roles<br />
# How this group will work<br />
# Set regular meeting schedule<br />
## at least once a week<br />
## share each other's timetable<br />
==== Result ====<br />
# Brian joined our group !<br />
# Agreed on David's idea - he will put up more details on wiki page<br />
# Will be decided later<br />
# Work under one trunk<br />
# Regular Meeting Schedule<br />
## in-person meeting<br />
## at Seneca Library - YuJin will book the room every week<br />
## on every Thursday between 9:50am and 11:40am<br />
<br />
<hr/><br />
=== Sept 23th Meeting ===<br />
Meeting place : Room 1132, Seneca Library<br/><br />
Meeting time : 9:50am ~ 11:40am<br />
==== Agenda ====<br />
# Finalize our game proposal<br />
# Divide roles & responsibilities<br />
# Keep updated <br/><br />
## subscribe to team page and course pages<br/><br />
## subscribe by clicking 'watch' of each page menu<br />
# Creating our own private team page ???<br />
##to disclose certain information of our group project ???<br />
<br />
==== Result ====<br />
# Uploaded game proposal - there might be changes in the future<br />
# Will divide roles after having meeting with Chris<br />
# (was just notification)<br />
# (wasn't discussed) <br />
# New meeting schedule<br />
## We will have meetings every Thursday AND Friday<br />
## Will have to figure the exact meeting time soon (for Fridays)<br />
<hr/><br />
=== Sept 30th Meeting ===<br />
Meeting place : Room 1132, Seneca Library<br/><br />
Meeting time : 9:50am ~ 11:40am<br />
==== Agenda ====<br />
# Discuss details on our game proposal<br />
# Divide up roles<br />
==== Result ====<br />
# Updated game proposal<br />
# Initial roles decided<br />
## David - Collision detection<br />
## YuJin - Maze Generator<br />
## Brian - Ship Movement<br />
## Andrew - Path guaranteeing<br />
<br />
<hr/><br />
=== Oct 7th Meeting ===<br />
Meeting place : Room 1132, Seneca Library<br/><br />
Meeting time : 9:50am ~ 11:40am<br />
==== Agenda ====<br />
<br />
==== Result ====<br />
<br />
== Resources ==<br />
[http://zenit.senecac.on.ca/wiki/index.php/Team_Blam-GridCode Simple Grid Code]<br />
<br />
== Useful Links ==<br />
[http://theory.stanford.edu/~amitp/GameProgramming/ Pathfinding Guide]</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=DPS909_and_OSD600_Fall_2010_0.1_Release&diff=48534DPS909 and OSD600 Fall 2010 0.1 Release2010-10-22T05:27:40Z<p>Ajcondinho: /* Submission Instructions */</p>
<hr />
<div>==Introduction==<br />
<br />
Your 0.1 release is the first point at which you have a working release of your project. It often represents as much research as it does coding, but ''always'' includes a working first-version. Through the coming weeks and months, you will iterate on your 0.1 code and refine it, fix bugs, add new features, etc. The 0.2, 0.3, ... releases will see this first step grow into something more polished and full-featured.<br />
<br />
==Submission Instructions==<br />
<br />
In order to submit your release, you need to complete a number of steps:<br />
<br />
# Release your code, either as a patch or commit on an existing project's repo, or start a new one<br />
# Create and/or update a wiki page with technical details about your release. This will be your project's homepage, and should have links and info relevant to anyone wishing to use it or contribute<br />
# Write a blog post announcing the release of your project's first milestone. If your code does something that can be demoed, make sure you include a live demo, screenshots, and perhaps a video on youtube if it is hard to setup and run. You should also include info about what is coming in 0.2.<br />
<br />
After you have done the above steps, please add an entry below with relevant links. Here is a template you can use:<br />
<br />
* '''Name:''' ''<your name>''<br />
* '''Project:''' ''<project name>''<br />
* '''Project URL:''' ''<project url or wiki page>''<br />
* '''0.1 Blog Post''': ''<link to your 0.1 release blog post>''<br />
* '''Source Code''': ''<link to a git repo, bug with patch, etc.>''<br />
<br />
==Submissions==<br />
<br />
* '''Name:''' ''Andrew Condinho''<br />
* '''Project:''' ''C3DL Build System''<br />
* '''Project URL:''' ''[[C3DL_Build_Bot]]''<br />
* '''0.1 Blog Post''': ''[http://ajcondinho.blogspot.com/2010/10/c3dl-build-system-01-released.html 0.1 Release]''<br />
* '''Source Code''': ''[http://github.com/acondinho/C3DL-Build-System Github repo]''</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=DPS909_and_OSD600_Fall_2010_0.1_Release&diff=48533DPS909 and OSD600 Fall 2010 0.1 Release2010-10-22T05:27:22Z<p>Ajcondinho: /* Submissions */</p>
<hr />
<div>==Introduction==<br />
<br />
Your 0.1 release is the first point at which you have a working release of your project. It often represents as much research as it does coding, but ''always'' includes a working first-version. Through the coming weeks and months, you will iterate on your 0.1 code and refine it, fix bugs, add new features, etc. The 0.2, 0.3, ... releases will see this first step grow into something more polished and full-featured.<br />
<br />
==Submission Instructions==<br />
<br />
In order to submit your release, you need to complete a number of steps:<br />
<br />
# Release your code, either as a patch or commit on an existing project's repo, or start a new one<br />
# Create and/or update a wiki page with technical details about your release. This will be your project's homepage, and should have links and info relevant to anyone wishing to use it or contribute<br />
# Write a blog post announcing the release of your project's first milestone. If your code does something that can be demoed, make sure you include a live demo, screenshots, and perhaps a video on youtube if it is hard to setup and run. You should also include info about what is coming in 0.2.<br />
<br />
After you have done the above steps, please add an entry below with relevant links. Here is a template you can use:<br />
<br />
* '''Name:''' ''<your name>''<br />
* '''Project:''' ''<project name>''<br />
* '''Project URL:''' ''<project url or wiki page>''<br />
* '''0.1 Blog Post''': ''<link to your 0.1 release blog post>''<br />
* '''Source Code''': ''<link to a git repo, bug with patch, etc.>''<br />
<br />
[[[==Submissions==<br />
<br />
* '''Name:''' ''Andrew Condinho''<br />
* '''Project:''' ''C3DL Build System''<br />
* '''Project URL:''' ''[[C3DL_Build_Bot]]''<br />
* '''0.1 Blog Post''': ''[http://ajcondinho.blogspot.com/2010/10/c3dl-build-system-01-released.html 0.1 Release]''<br />
* '''Source Code''': ''[http://github.com/acondinho/C3DL-Build-System Github repo]''</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=C3DL_Build_Bot&diff=48529C3DL Build Bot2010-10-22T05:11:26Z<p>Ajcondinho: /* Project Plan */</p>
<hr />
<div>==Project Name==<br />
C3DL Build Bot - Build System for the C3DL Javascript library<br />
<br />
==Project Plan & Description==<br />
===Project Description===<br />
The build bot system for the C3DL library is a bash script that takes the numerous javascript files and combines them into one easy to download file. Future releases will allow users more customization options over what is/is not included in the library.<br />
<br />
===Project Plan===<br />
<br />
{| border="1"<br />
|-<br />
| '''Release'''<br />
| '''Download Release'''<br />
| '''Features/Points Addressed'''<br />
|-<br />
| 0.1<br />
| http://github.com/acondinho/C3DL-Build-System<br />
| Builds full library using a php web interface<br />
|-<br />
| 0.2<br />
|<br />
|<br />
|-<br />
| 0.3<br />
|<br />
|<br />
|-<br />
|}<br />
<br />
==Project Leader(s)==<br />
*Andrew Condinho<br />
*Andor Salga (Project Contact)<br />
*Cathy Leung (Project Contact)<br />
<br />
==Releases==<br />
*0.1 Release<br />
**Full library build<br />
**Minimized library build<br />
<br />
==Project News==<br />
<br />
==Project Contributor(s)==<br />
[http://sweerdenburg.wordpress.com/ Steven Weerdenburg] Contributed the web interface to interact with the bash script</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=C3DL_Build_Bot&diff=48506C3DL Build Bot2010-10-21T19:55:39Z<p>Ajcondinho: /* Project Leader(s) */</p>
<hr />
<div>==Project Name==<br />
C3DL Build Bot - Build System for the C3DL Javascript library<br />
<br />
==Project Plan & Description==<br />
===Project Description===<br />
The build bot system for the C3DL library is a bash script that takes the numerous javascript files and combines them into one easy to download file. Future releases will allow users more customization options over what is/is not included in the library.<br />
<br />
===Project Plan===<br />
<br />
{| border="1"<br />
|-<br />
| '''Release'''<br />
| '''Download Release'''<br />
| '''Features/Points Addressed'''<br />
|-<br />
| 0.1<br />
|<br />
|<br />
|-<br />
| 0.2<br />
|<br />
|<br />
|-<br />
| 0.3<br />
|<br />
|<br />
|-<br />
|}<br />
<br />
==Project Leader(s)==<br />
*Andrew Condinho<br />
*Andor Salga (Project Contact)<br />
*Cathy Leung (Project Contact)<br />
<br />
==Releases==<br />
*0.1 Release<br />
**Full library build<br />
**Minimized library build<br />
<br />
==Project News==<br />
<br />
==Project Contributor(s)==<br />
[http://sweerdenburg.wordpress.com/ Steven Weerdenburg] Contributed the web interface to interact with the bash script</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=C3DL_Build_Bot&diff=48505C3DL Build Bot2010-10-21T19:55:28Z<p>Ajcondinho: /* Project Contributor(s) */</p>
<hr />
<div>==Project Name==<br />
C3DL Build Bot - Build System for the C3DL Javascript library<br />
<br />
==Project Plan & Description==<br />
===Project Description===<br />
The build bot system for the C3DL library is a bash script that takes the numerous javascript files and combines them into one easy to download file. Future releases will allow users more customization options over what is/is not included in the library.<br />
<br />
===Project Plan===<br />
<br />
{| border="1"<br />
|-<br />
| '''Release'''<br />
| '''Download Release'''<br />
| '''Features/Points Addressed'''<br />
|-<br />
| 0.1<br />
|<br />
|<br />
|-<br />
| 0.2<br />
|<br />
|<br />
|-<br />
| 0.3<br />
|<br />
|<br />
|-<br />
|}<br />
<br />
==Project Leader(s)==<br />
Andrew Condinho<br />
Andor Salga (Project Contact)<br />
Cathy Leung (Project Contact)<br />
<br />
==Releases==<br />
*0.1 Release<br />
**Full library build<br />
**Minimized library build<br />
<br />
==Project News==<br />
<br />
==Project Contributor(s)==<br />
[http://sweerdenburg.wordpress.com/ Steven Weerdenburg] Contributed the web interface to interact with the bash script</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=C3DL_Build_Bot&diff=48504C3DL Build Bot2010-10-21T19:54:11Z<p>Ajcondinho: </p>
<hr />
<div>==Project Name==<br />
C3DL Build Bot - Build System for the C3DL Javascript library<br />
<br />
==Project Plan & Description==<br />
===Project Description===<br />
The build bot system for the C3DL library is a bash script that takes the numerous javascript files and combines them into one easy to download file. Future releases will allow users more customization options over what is/is not included in the library.<br />
<br />
===Project Plan===<br />
<br />
{| border="1"<br />
|-<br />
| '''Release'''<br />
| '''Download Release'''<br />
| '''Features/Points Addressed'''<br />
|-<br />
| 0.1<br />
|<br />
|<br />
|-<br />
| 0.2<br />
|<br />
|<br />
|-<br />
| 0.3<br />
|<br />
|<br />
|-<br />
|}<br />
<br />
==Project Leader(s)==<br />
Andrew Condinho<br />
Andor Salga (Project Contact)<br />
Cathy Leung (Project Contact)<br />
<br />
==Releases==<br />
*0.1 Release<br />
**Full library build<br />
**Minimized library build<br />
<br />
==Project News==<br />
<br />
==Project Contributor(s)==</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=C3DL_Build_Bot&diff=48503C3DL Build Bot2010-10-21T19:53:28Z<p>Ajcondinho: /* Releases */</p>
<hr />
<div>==Project Name==<br />
C3DL Build Bot - Build System for the C3DL Javascript library<br />
<br />
==Project Plan & Description==<br />
===Project Description===<br />
The build bot system for the C3DL library is a bash script that takes the numerous javascript files and combines them into one easy to download file. Future releases will allow users more customization options over what is/is not included in the library.<br />
<br />
===Project Plan===<br />
<br />
{| border="1"<br />
|-<br />
| '''Release'''<br />
| '''Download Release'''<br />
| '''Features/Points Addressed'''<br />
|-<br />
| 0.1<br />
|<br />
|<br />
|-<br />
| 0.2<br />
|<br />
|<br />
|-<br />
| 0.3<br />
|<br />
|<br />
|-<br />
|}<br />
<br />
==Project Leader(s)==<br />
Andrew Condinho<br />
Andor Salga (Project Contact)<br />
Cathy Leung (Project Contact)<br />
<br />
==Releases==<br />
*0.1 Release<br />
**Full library build<br />
**Minimized library build<br />
<br />
==Project Contributor(s)==</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=C3DL_Build_Bot&diff=48502C3DL Build Bot2010-10-21T19:52:42Z<p>Ajcondinho: /* Project Leader(s) */</p>
<hr />
<div>==Project Name==<br />
C3DL Build Bot - Build System for the C3DL Javascript library<br />
<br />
==Project Plan & Description==<br />
===Project Description===<br />
The build bot system for the C3DL library is a bash script that takes the numerous javascript files and combines them into one easy to download file. Future releases will allow users more customization options over what is/is not included in the library.<br />
<br />
===Project Plan===<br />
<br />
{| border="1"<br />
|-<br />
| '''Release'''<br />
| '''Download Release'''<br />
| '''Features/Points Addressed'''<br />
|-<br />
| 0.1<br />
|<br />
|<br />
|-<br />
| 0.2<br />
|<br />
|<br />
|-<br />
| 0.3<br />
|<br />
|<br />
|-<br />
|}<br />
<br />
==Project Leader(s)==<br />
Andrew Condinho<br />
Andor Salga (Project Contact)<br />
Cathy Leung (Project Contact)<br />
<br />
==Releases==<br />
==Project Contributor(s)==</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=C3DL_Build_Bot&diff=48501C3DL Build Bot2010-10-21T19:51:47Z<p>Ajcondinho: /* Project Plan */</p>
<hr />
<div>==Project Name==<br />
C3DL Build Bot - Build System for the C3DL Javascript library<br />
<br />
==Project Plan & Description==<br />
===Project Description===<br />
The build bot system for the C3DL library is a bash script that takes the numerous javascript files and combines them into one easy to download file. Future releases will allow users more customization options over what is/is not included in the library.<br />
<br />
===Project Plan===<br />
<br />
{| border="1"<br />
|-<br />
| '''Release'''<br />
| '''Download Release'''<br />
| '''Features/Points Addressed'''<br />
|-<br />
| 0.1<br />
|<br />
|<br />
|-<br />
| 0.2<br />
|<br />
|<br />
|-<br />
| 0.3<br />
|<br />
|<br />
|-<br />
|}<br />
<br />
==Project Leader(s)==<br />
==Releases==<br />
==Project Contributor(s)==</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=C3DL_Build_Bot&diff=48500C3DL Build Bot2010-10-21T19:46:34Z<p>Ajcondinho: /* Project Description */</p>
<hr />
<div>==Project Name==<br />
C3DL Build Bot - Build System for the C3DL Javascript library<br />
<br />
==Project Plan & Description==<br />
===Project Description===<br />
The build bot system for the C3DL library is a bash script that takes the numerous javascript files and combines them into one easy to download file. Future releases will allow users more customization options over what is/is not included in the library.<br />
<br />
===Project Plan===<br />
<br />
==Project Leader(s)==<br />
==Releases==<br />
==Project Contributor(s)==</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=C3DL_Build_Bot&diff=48499C3DL Build Bot2010-10-21T19:41:21Z<p>Ajcondinho: /* Project Plan & Description */</p>
<hr />
<div>==Project Name==<br />
C3DL Build Bot - Build System for the C3DL Javascript library<br />
<br />
==Project Plan & Description==<br />
===Project Description===<br />
===Project Plan===<br />
<br />
==Project Leader(s)==<br />
==Releases==<br />
==Project Contributor(s)==</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=C3DL_Build_Bot&diff=48498C3DL Build Bot2010-10-21T19:39:55Z<p>Ajcondinho: /* Project Name */</p>
<hr />
<div>==Project Name==<br />
C3DL Build Bot - Build System for the C3DL Javascript library<br />
<br />
==Project Plan & Description==<br />
==Project Leader(s)==<br />
==Releases==<br />
==Project Contributor(s)==</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=C3DL_Build_Bot&diff=48497C3DL Build Bot2010-10-21T19:39:22Z<p>Ajcondinho: Created page with '==Project Name== ==Project Plan & Description== ==Project Leader(s)== ==Releases== ==Project Contributor(s)=='</p>
<hr />
<div>==Project Name==<br />
==Project Plan & Description==<br />
==Project Leader(s)==<br />
==Releases==<br />
==Project Contributor(s)==</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=Team_Blam&diff=47029Team Blam2010-10-07T14:44:04Z<p>Ajcondinho: /* Useful Links */</p>
<hr />
<div>{{GAM666/DPS901 Index | 20103}}<br />
= Don't Crash Into Buildings! =<br />
== Project Marking Percentage ==<br />
<big><br />
Group work: xx% (25 <= xx <= 50)<br />
Individual work: xx% + (50 <= xx <= 75) <br />
-------------------------<br />
Total 100%<br />
</big><br />
== Team Website ==<br />
[http://blam.lighthouseapp.com/projects/61347-dont-crash-into-buildings/overview blam.lighthouseapp.com]<br />
== Repository ==<br />
=== Repo path ===<br />
<br />
svn://zenit.senecac.on.ca/dps901_103rep3<br />
<br />
=== Trunk Status ===<br />
<br />
committed by YuJin (04-Oct-2010)<br />
<br />
== Member List == <br />
<br />
*[mailto:blaw1@learn.senecac.on.ca,ajcondinho@learn.senecac.on.ca,yjeong@learn.senecac.on.ca,drperit@learn.senecac.on.ca?subject=gam666 Email All]<br />
<br />
{| class="wikitable sortable" border="1" cellpadding="5"<br />
! First Name !! Last Name !! Seneca Id !! wiki id !! IRC nick !! Blog URL !! MSN !! Phone<br />
|-<br />
|[[User:Yujin.jeong | YuJin]]||Jeong||[mailto:yjeong@learn.senecac.on.ca?sujbect=gam666 yjeong]||[[Special:Contributions/yujin.jeong | yujin.jeong]]||_YJ||[http://yujinjeong.wordpress.com Spirit & Soul] || be-warmhearted@hotmail.com || 647 - 832 - 6771<br />
|-<br />
<br />
|-<br />
|[[User:dperit | David]]||Perit||[mailto:drperit@learn.senecac.on.ca?sujbect=gam666 drperit]||[[Special:Contributions/dperit| dperit]]||dperit|| || wowbagger5@hotmail.com || 647 - 520 - 3039<br />
|-<br />
<br />
|-<br />
|[[User:ajcondinho | Andrew]]||Condinho||[mailto:ajcondinho@learn.senecac.on.ca?sujbect=gam666 ajcondinho]||[[Special:Contributions/ajcondinho| ajcondinho]]||Dueraim||[http://ajcondinho.blogspot.com/ Andrew's Blog] || || 416 - 997 - 1589<br />
|-<br />
<br />
|-<br />
|[[User:blaw1 | Brian]]||Law||[mailto:blaw1@learn.senecac.on.ca?sujbect=gam666 blaw1]||[[Special:Contributions/blaw1|blaw1 ]] || || || || 416 - 254 - 3457<br />
|-<br />
<br />
|}<br />
<br />
== Member Roles ==<br />
{| class="wikitable" border="1" width="300"<br />
! Member !! Role<br />
|- align="left"<br />
| [[User:yujin.jeong | YuJin ]] || 1. Maze Generator <br/> 2. Book Meeting Room Every Week<br/> 3. Meeting Log<br />
|- align="left"<br />
| [[User:dperit | David ]] || Collision Detection<br />
|- align="left"<br />
| [[User:ajcondinho | Andrew ]] || Path Guaranteeing<br />
|- align="left"<br />
| [[User:blaw1 | Brian ]] || Ship Movement<br />
<br />
|}<br />
<br />
== Proposal ==<br />
<br />
<br />
'''Game Name:''' Don't Crash Into Buildings !<br/><br/><br />
'''Game Description:'''<br/><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;In our game, you will be the captain of a ship. The main engine of this ship is stuck on full blast, so it cannot ever stop. The ship is travelling through an increasingly dense urban landscape, and it is your goal to avoid crashing into anything for as long as possible! To accomplish this goal you have a view of your ship from high above it, allowing you to see buildings as they race towards you. You also have a set of maneuvering thrusters, which can push your ship back, forwards, left, and right on a two-dimensional plane. This will hopefully allow you to avoid crashing into buildings!<br /><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The top down view of your ship is provided by a camera moving at a constant speed. This camera provides a limited view of the area around your ship, and your ship cannot move out of this area, or it will crash into an unseen building. This results in you having a mostly static view of your ship as it flies forward through the city.<br />
Crashing into a building will kill you. Try to avoid this. The maneuvering thrusters on your ship are unlimited use, and can move you at a constant speed around the viewable area.<br/><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Due to overzealous construction, all of the entrances and exits to the city's planning department were blocked with buildings while the department was meeting to create a layout and zoning plan for the city. As a result, the placement of buildings in the city is random! There is, however, guaranteed to be a navigable path for your ship through the city, due to the actions of the Emergency Runaway Spacecraft Advance Demolition Crew, who are busy carving a path of destruction offscreen, just so that the game isn't impossible. All of the buildings in the city are rectangular in shape, making the collision detection code much easier to write.<br />
<br />
<br />
'''Enhanced Don't Crash Into Buildings !'''<br />
this is a list of things we can do if we're done everything else, and looking for more<br />
<br />
(Some or all of these features may be added to/replace features in the base game, depending on time constraints)<br />
<br />
* Rather than move you at a constant speed, your thrusters can accelerate you (up to certain maximum speeds). This can provide additional challenge.<br />
<br />
* Rather than being instantly killed by a collision, you could have shields on your ship which regenerate over time. This would be damaged by collisions in direct proportion to the speed with which you collided with the building, and you will die if it's reduced to 0<br />
<br />
* Could transition between levels, or have moments of blank space giving a chance to rest, followed by a change in environment/city textures<br />
* Have three dimensional movement (up + down, along with forward + back + left + right), combined with shorter buildings that can be flown over or buildings that have gaps in them<br />
* Because it is important to be at the correct altitude to fly through the gaps/over them, we could have an altitude meter with different colours. The gaps in the buildings could be marked with those colours, and then you can match up those colours with the altitude meter to know that you're at the correct height to pass through the gaps<br />
* Vertical movement should be between a set of discrete values, due to the difficulty in telling exact height from a top down perspective, even with an altitude meter<br />
<br />
== Initial version ==<br />
<br />
The initial version of the game will be on the command line, turn based, with positional accuracy to the character level. This will allow us to write the full grid-aligned bounding box based collision detection, a simplified version of the ship movement code, and the maze generation and path guaranteeing code.<br />
<br />
Basic algorithms:<br />
Collision detection: All of the buildings are aligned to a grid, so they have a maximum and minimum x position, and a maximum and minimum y position. To determine if we have collided with a building, we check (either for all nearby buildings or all buildings onscreen) out ship's collision co-ordinates to see if maxBuildingX < shipX < minBuildingX AND maxBuildingY < shipY < minBuildingY. If so, then we've collided with that building. We should be keeping track of the ship's position in the previous frame, so that after we collide with something we can reset the position to that of the previous frame.<br />
<br />
Ship movement: Press arrows, ship position changes at a constant rate. In the console, we will simply change the ships position by one when an arrow key is pressed.<br />
<br />
Maze generation: We will have a difficulty number, possibly from 0 to 100, that increases over time. For each building square, we create a random number from 0 to 100. If that number is less than the difficulty number, then we place a building in that square.<br />
<br />
Path guaranteeing:<br />
If we have a building grid, like so, where x is a building and o is not a building:<br />
<pre><br />
XOOXX<br />
XXOOX<br />
XXOXX<br />
XOXXX<br />
</pre><br />
<br />
Then we'll have an exit point defined in the topmost row, either at column 2 or 3. Our next row will look like one of these possibilities (I'll assume the exit point is 3). The ? marks are pseudo-randomly determined to be a building or not a building depending on our maze generation algorithm.<br />
<pre><br />
??O?? new endpoint is 3<br />
?OO?? new endpoint is 2<br />
OOO?? new endpoint is 1<br />
??OO? new endpoint is 4<br />
??OOO new endpoint is 5<br />
</pre><br />
The most likely endpoint here would be 3, with endpoints of 2 and 4 less likely, and 1 and 5 even less likely, although the chance of getting 2,4,1, or 5 would increase with the difficulty level. If it's not possible for the ship to move fast enough to navigate X squares over in a row, then we'll remove that as a possibility, so that the maximum difference between end points in adjacent rows would be x - 1<br />
<br />
New maze generation code!<br />
<pre><br />
char buildings[40][5];<br />
//initialize that<br />
Path ourPaths[3];<br />
//initialize that<br />
<br />
for (int curRow = 0; curRow < 40; curRow++)<br />
{<br />
foreach(Path curPath in ourPaths)<br />
{<br />
curPath.buildPath(buildings[curRow]);<br />
}<br />
}<br />
<br />
<br />
Path<br />
{<br />
int startCol;<br />
int endCol;<br />
<br />
public:<br />
void buildPath(char currentRow[5])<br />
{<br />
currentRow[endCol] = notabuilding;<br />
startCol = endCol;<br />
endCol = endCol + or - a random number, probably influenced by difficulty level;<br />
//Fill in all columns between startCol and endCol with notabuildings<br />
}<br />
}<br />
</pre><br />
<br />
[http://zenit.senecac.on.ca/wiki/index.php/GAM666/DPS901_Project_requirements_20103#Phase_1 *How to write game proposal]<br />
<br />
== Map of the World of the Game ==<br />
== Moderator's - Instructors Comments ==<br />
== Important Project Due Dates ==<br />
{| border="1"<br />
! Tasks !! Due Date<br />
|-<br />
|<s>1. Proposal outline and team members selected</s><br />
|<s>September 21</s><br />
|-<br />
|<s>2. Proposal completed and members roles selected</s><br />
|<s>September 28</s><br />
|-<br />
|<s>3. Research into game requirements begins</s><br />
|<s>September 29</s><br />
|-<br />
|<s>4. Approval meeting with instructor</s><br />
|<s>Weeks of October 3 and October 10</s><br />
|-<br />
|5. Draft game submission and project review<br />
|November 16<br />
|-<br />
|6. Final game presentation<br />
|December 7<br />
|}<br />
<br />
== Meeting Schedule ==<br />
{| border="1"<br />
! Date and Time !! Place<br />
|-<br />
|<s>Sept 16, 09:50 AM</s><br />
|<s>Seneca Library Room 1131</s><br />
|-<br />
|<s>Sept 23, 09:50 AM</s><br />
|<s>Seneca Library Room 1131</s><br />
|-<br />
|<s>Sept 30, 09:50 AM</s><br />
|<s>Seneca Library Room 1132</s><br />
|-<br />
|Oct 7, 09:50 AM<br />
|Seneca Library Room 1132<br />
|-<br />
<br />
|}<br />
<br />
== Meeting Log ==<br />
=== Sept 16th Meeting ===<br />
Meeting place : Room 1131, Seneca Library <br />
==== Agenda ====<br />
# Look for the last member <br />
# Brainstorming on our game - share any ideas in mind<br />
# Decide member roles<br />
# How this group will work<br />
# Set regular meeting schedule<br />
## at least once a week<br />
## share each other's timetable<br />
==== Result ====<br />
# Brian joined our group !<br />
# Agreed on David's idea - he will put up more details on wiki page<br />
# Will be decided later<br />
# Work under one trunk<br />
# Regular Meeting Schedule<br />
## in-person meeting<br />
## at Seneca Library - YuJin will book the room every week<br />
## on every Thursday between 9:50am and 11:40am<br />
<br />
<hr/><br />
=== Sept 23th Meeting ===<br />
Meeting place : Room 1132, Seneca Library<br/><br />
Meeting time : 9:50am ~ 11:40am<br />
==== Agenda ====<br />
# Finalize our game proposal<br />
# Divide roles & responsibilities<br />
# Keep updated <br/><br />
## subscribe to team page and course pages<br/><br />
## subscribe by clicking 'watch' of each page menu<br />
# Creating our own private team page ???<br />
##to disclose certain information of our group project ???<br />
<br />
==== Result ====<br />
# Uploaded game proposal - there might be changes in the future<br />
# Will divide roles after having meeting with Chris<br />
# (was just notification)<br />
# (wasn't discussed) <br />
# New meeting schedule<br />
## We will have meetings every Thursday AND Friday<br />
## Will have to figure the exact meeting time soon (for Fridays)<br />
<hr/><br />
=== Sept 30th Meeting ===<br />
Meeting place : Room 1132, Seneca Library<br/><br />
Meeting time : 9:50am ~ 11:40am<br />
==== Agenda ====<br />
# Discuss details on our game proposal<br />
# Divide up roles<br />
==== Result ====<br />
# Updated game proposal<br />
# Initial roles decided<br />
## David - Collision detection<br />
## YuJin - Maze Generator<br />
## Brian - Ship Movement<br />
## Andrew - Path guaranteeing<br />
<br />
<hr/><br />
=== Oct 7th Meeting ===<br />
Meeting place : Room 1132, Seneca Library<br/><br />
Meeting time : 9:50am ~ 11:40am<br />
==== Agenda ====<br />
<br />
==== Result ====<br />
<br />
== Resources ==<br />
[http://zenit.senecac.on.ca/wiki/index.php/Team_Blam-GridCode Simple Grid Code]<br />
<br />
== Useful Links ==<br />
[http://theory.stanford.edu/~amitp/GameProgramming/ Pathfinding Guide]</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=OSD600Project-C3DLRefactoring&diff=46685OSD600Project-C3DLRefactoring2010-10-01T18:40:50Z<p>Ajcondinho: </p>
<hr />
<div>=== C3DL Library Core Refactoring ===<br />
<br />
<br />
== Project Description ==<br />
<br />
c3dl is a js library that provides higher level functionality for web developers wishing to develop 3D web applications. Currently the library always includes all features c3dl provides, even though they won't be needed in all cases. This adds download size, code complexity, etc. This project will refactor c3dl so that we have a core component, and then all the features can be added to this core and become unbound.<br />
<br />
== Project Leader(s) ==<br />
<br />
Andrew Condinho<br />
<br />
== Project Contributor(s) ==<br />
<br />
* Contacts: Cathy Leung, Andor Salga<br />
<br />
== Project Details ==<br />
* Technologies: JavaScript, WebGL, HTML5<br />
<br />
<br />
== Project News ==<br />
Things to research:<br />
* Current javascript dependency methods<br />
* Identify what is core to C3DL<br />
* Explore JQuery</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=Team_Blam-GridCode&diff=46463Team Blam-GridCode2010-09-30T17:20:55Z<p>Ajcondinho: </p>
<hr />
<div>Paste this into a Visual C# project and it will draw a bounding box for a grid of X's<br />
<br />
*If you have any changes / upgrades to this code, post here for the benefit of others*<br />
**Edit: Updated it to use an array for grid storage<br />
<br />
<pre><br />
/*<br />
* Basic char array grid creator<br />
* Created by: Andrew Condinho<br />
* 9/30/2010<br />
*/<br />
<br />
using System;<br />
using System.Collections.Generic;<br />
using System.Linq;<br />
using System.Text;<br />
<br />
namespace Console_Move<br />
{<br />
class Program<br />
{<br />
static void Main(string[] args)<br />
{<br />
//create array to hold grid coordinates<br />
char[,] gridArray = new char[20, 20];<br />
<br />
//populate grid -- !!!replace this with a grid generator!!!<br />
for (int i = 0; i < 20; i++)<br />
{<br />
gridArray[0, i] = 'x';<br />
gridArray[19, i] = 'x';<br />
}<br />
<br />
for (int i = 1; i < 19; i++)<br />
{<br />
gridArray[i, 0] = 'x';<br />
gridArray[i, 19] = 'x';<br />
}<br />
<br />
drawGrid(gridArray);<br />
<br />
//Grid is useable starting at 1,1<br />
//corner co-ords are<br />
//TL: 1,1<br />
//TR: 19,1<br />
//BL: 1,18<br />
//BR: 19,18<br />
<br />
Console.SetCursorPosition(0, 21);<br />
Console.WriteLine("All done");<br />
<br />
}<br />
<br />
static void drawGrid(char [,] gArray)<br />
{<br />
int hop = 1;<br />
for (int i = 0; i < 20; i++)<br />
{<br />
for (int x = 0; x < 20; x++)<br />
{<br />
Console.Write(gArray[i, x]);<br />
}<br />
Console.SetCursorPosition(0, hop++);<br />
}<br />
}<br />
<br />
}<br />
}<br />
</pre></div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=Team_Blam-GridCode&diff=46462Team Blam-GridCode2010-09-30T17:20:45Z<p>Ajcondinho: </p>
<hr />
<div>Paste this into a Visual C# project and it will draw a bounding box for a grid of X's<br />
<br />
*If you have any changes / upgrades to this code, post here for the benefit of others*<br />
**Edit: Updated it to use an array for grid storage**<br />
<br />
<pre><br />
/*<br />
* Basic char array grid creator<br />
* Created by: Andrew Condinho<br />
* 9/30/2010<br />
*/<br />
<br />
using System;<br />
using System.Collections.Generic;<br />
using System.Linq;<br />
using System.Text;<br />
<br />
namespace Console_Move<br />
{<br />
class Program<br />
{<br />
static void Main(string[] args)<br />
{<br />
//create array to hold grid coordinates<br />
char[,] gridArray = new char[20, 20];<br />
<br />
//populate grid -- !!!replace this with a grid generator!!!<br />
for (int i = 0; i < 20; i++)<br />
{<br />
gridArray[0, i] = 'x';<br />
gridArray[19, i] = 'x';<br />
}<br />
<br />
for (int i = 1; i < 19; i++)<br />
{<br />
gridArray[i, 0] = 'x';<br />
gridArray[i, 19] = 'x';<br />
}<br />
<br />
drawGrid(gridArray);<br />
<br />
//Grid is useable starting at 1,1<br />
//corner co-ords are<br />
//TL: 1,1<br />
//TR: 19,1<br />
//BL: 1,18<br />
//BR: 19,18<br />
<br />
Console.SetCursorPosition(0, 21);<br />
Console.WriteLine("All done");<br />
<br />
}<br />
<br />
static void drawGrid(char [,] gArray)<br />
{<br />
int hop = 1;<br />
for (int i = 0; i < 20; i++)<br />
{<br />
for (int x = 0; x < 20; x++)<br />
{<br />
Console.Write(gArray[i, x]);<br />
}<br />
Console.SetCursorPosition(0, hop++);<br />
}<br />
}<br />
<br />
}<br />
}<br />
</pre></div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=Team_Blam&diff=46440Team Blam2010-09-30T15:25:19Z<p>Ajcondinho: /* Useful Links */</p>
<hr />
<div>{{GAM666/DPS901 Index | 20103}}<br />
= Don't Crash Into Buildings! =<br />
== Repository ==<br />
=== Repo path ===<br />
<br />
svn://zenit.senecac.on.ca/dps901_103rep3<br />
<br />
=== Trunk Status ===<br />
<br />
committed by [NAME] / being committed by [NAME]<br />
<br />
<br />
== Member List == <br />
<br />
*[mailto:blaw1@learn.senecac.on.ca,ajcondinho@learn.senecac.on.ca,yjeong@learn.senecac.on.ca,drperit@learn.senecac.on.ca?subject=gam666 Email All]<br />
<br />
{| class="wikitable sortable" border="1" cellpadding="5"<br />
! First Name !! Last Name !! Seneca Id !! wiki id !! IRC nick !! Blog URL !! MSN<br />
|-<br />
|[[User:Yujin.jeong | YuJin]]||Jeong||[mailto:yjeong@learn.senecac.on.ca?sujbect=gam666 yjeong]||[[Special:Contributions/yujin.jeong | yujin.jeong]]||_YJ||[http://yujinjeong.wordpress.com Spirit & Soul] || be-warmhearted@hotmail.com<br />
|-<br />
<br />
|-<br />
|[[User:dperit | David]]||Perit||[mailto:drperit@learn.senecac.on.ca?sujbect=gam666 drperit]||[[Special:Contributions/dperit| dperit]]||dperit|| || wowbagger5@hotmail.com<br />
|-<br />
<br />
|-<br />
|[[User:ajcondinho | Andrew]]||Condinho||[mailto:ajcondinho@learn.senecac.on.ca?sujbect=gam666 ajcondinho]||[[Special:Contributions/ajcondinho| ajcondinho]]||Dueraim||[http://ajcondinho.blogspot.com/ Andrew's Blog] ||<br />
|-<br />
<br />
|-<br />
|[[User:blaw1 | Brian]]||Law||[mailto:blaw1@learn.senecac.on.ca?sujbect=gam666 blaw1]||[[Special:Contributions/blaw1|blaw1 ]] || || ||<br />
|-<br />
<br />
|}<br />
<br />
== Member Roles ==<br />
{| class="wikitable" border="1" width="300"<br />
! Member !! Role<br />
|- align="left"<br />
| [[User:yujin.jeong | YuJin ]] || 1. Book Meeting Room Every Week<br/> 2. Meeting Log<br />
|- align="left"<br />
| [[User:dperit | David ]] || TBA<br />
|- align="left"<br />
| [[User:ajcondinho | Andrew ]] || TBA<br />
|- align="left"<br />
| [[User:blaw1 | Brian ]] || TBA<br />
<br />
|}<br />
<br />
== Proposal ==<br />
<br />
<br />
'''Game Name:''' Don't Crash Into Buildings !<br/><br/><br />
'''Game Description:'''<br/><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;In our game, you will be the captain of a ship. The main engine of this ship is stuck on full blast, so it cannot ever stop. The ship is travelling through an increasingly dense urban landscape, and it is your goal to avoid crashing into anything for as long as possible! To accomplish this goal you have a view of your ship from high above it, allowing you to see buildings as they race towards you. You also have a set of maneuvering thrusters, which can push your ship back, forwards, left, and right on a two-dimensional plane. This will hopefully allow you to avoid crashing into buildings!<br /><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The top down view of your ship is provided by a camera moving at a constant speed. This camera provides a limited view of the area around your ship, and your ship cannot move out of this area, or it will crash into an unseen building. This results in you having a mostly static view of your ship as it flies forward through the city.<br />
Crashing into a building will kill you. Try to avoid this. The maneuvering thrusters on your ship are unlimited use, and can move you at a constant speed around the viewable area.<br/><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Due to overzealous construction, all of the entrances and exits to the city's planning department were blocked with buildings while the department was meeting to create a layout and zoning plan for the city. As a result, the placement of buildings in the city is random! There is, however, guaranteed to be a navigable path for your ship through the city, due to the actions of the Emergency Runaway Spacecraft Advance Demolition Crew, who are busy carving a path of destruction offscreen, just so that the game isn't impossible. All of the buildings in the city are rectangular in shape, making the collision detection code much easier to write.<br />
<br />
<br />
'''Enhanced Don't Crash Into Buildings !'''<br />
this is a list of things we can do if we're done everything else, and looking for more<br />
<br />
(Some or all of these features may be added to/replace features in the base game, depending on time constraints)<br />
<br />
* Rather than move you at a constant speed, your thrusters can accelerate you (up to certain maximum speeds). This can provide additional challenge.<br />
<br />
* Rather than being instantly killed by a collision, you could have shields on your ship which regenerate over time. This would be damaged by collisions in direct proportion to the speed with which you collided with the building, and you will die if it's reduced to 0<br />
<br />
* Could transition between levels, or have moments of blank space giving a chance to rest, followed by a change in environment/city textures<br />
* Have three dimensional movement (up + down, along with forward + back + left + right), combined with shorter buildings that can be flown over or buildings that have gaps in them<br />
* Because it is important to be at the correct altitude to fly through the gaps/over them, we could have an altitude meter with different colours. The gaps in the buildings could be marked with those colours, and then you can match up those colours with the altitude meter to know that you're at the correct height to pass through the gaps<br />
* Vertical movement should be between a set of discrete values, due to the difficulty in telling exact height from a top down perspective, even with an altitude meter<br />
<br />
== Initial version ==<br />
<br />
The initial version of the game will be on the command line, turn based, with positional accuracy to the character level. This will allow us to write the full grid-aligned bounding box based collision detection, a simplified version of the ship movement code, and the maze generation and path guaranteeing code.<br />
<br />
Basic algorithms:<br />
Collision detection: All of the buildings are aligned to a grid, so they have a maximum and minimum x position, and a maximum and minimum y position. To determine if we have collided with a building, we check (either for all nearby buildings or all buildings onscreen) out ship's collision co-ordinates to see if maxBuildingX < shipX < minBuildingX AND maxBuildingY < shipY < minBuildingY. If so, then we've collided with that building. We should be keeping track of the ship's position in the previous frame, so that after we collide with something we can reset the position to that of the previous frame.<br />
<br />
Ship movement: Press arrows, ship position changes at a constant rate. In the console, we will simply change the ships position by one when an arrow key is pressed.<br />
<br />
Maze generation: We will have a difficulty number, possibly from 0 to 100, that increases over time. For each building square, we create a random number from 0 to 100. If that number is less than the difficulty number, then we place a building in that square.<br />
<br />
Path guaranteeing:<br />
If we have a building grid, like so, where x is a building and o is not a building:<br />
<pre><br />
XOOXX<br />
XXOOX<br />
XXOXX<br />
XOXXX<br />
</pre><br />
<br />
Then we'll have an exit point defined in the topmost row, either at column 2 or 3. Our next row will look like one of these possibilities (I'll assume the exit point is 3). The ? marks are pseudo-randomly determined to be a building or not a building depending on our maze generation algorithm.<br />
<pre><br />
??O?? new endpoint is 3<br />
?OO?? new endpoint is 2<br />
OOO?? new endpoint is 1<br />
??OO? new endpoint is 4<br />
??OOO new endpoint is 5<br />
</pre><br />
The most likely endpoint here would be 3, with endpoints of 2 and 4 less likely, and 1 and 5 even less likely, although the chance of getting 2,4,1, or 5 would increase with the difficulty level. If it's not possible for the ship to move fast enough to navigate X squares over in a row, then we'll remove that as a possibility, so that the maximum difference between end points in adjacent rows would be x - 1<br />
<br />
[http://zenit.senecac.on.ca/wiki/index.php/GAM666/DPS901_Project_requirements_20103#Phase_1 *How to write game proposal]<br />
<br />
== Map of the World of the Game ==<br />
== Moderator's - Instructors Comments ==<br />
== Important Project Due Dates ==<br />
{| border="1"<br />
! Tasks !! Due Date<br />
|-<br />
|<s>1. Proposal outline and team members selected</s><br />
|<s>September 21</s><br />
|-<br />
|2. Proposal completed and members roles selected<br />
|September 28<br />
|-<br />
|3. Research into game requirements begins<br />
|September 29<br />
|-<br />
|4. Approval meeting with instructor<br />
|Weeks of October 3 and October 10<br />
|-<br />
|5. Draft game submission and project review<br />
|November 16<br />
|-<br />
|6. Final game presentation<br />
|December 7<br />
|}<br />
<br />
== Meeting Schedule ==<br />
{| border="1"<br />
! Date and Time !! Place<br />
|-<br />
|<s>Sept 16, 09:50 AM</s><br />
|<s>Seneca Library Room 1131</s><br />
|-<br />
|<s>Sept 23, 09:50 AM</s><br />
|<s>Seneca Library Room 1131</s><br />
|-<br />
|Sept 30, 09:50 AM<br />
|Seneca Library Room 1132<br />
|-<br />
|}<br />
<br />
== Meeting Log ==<br />
=== Sept 16th Meeting ===<br />
Meeting place : Room 1131, Seneca Library <br />
==== Agenda ====<br />
# Look for the last member <br />
# Brainstorming on our game - share any ideas in mind<br />
# Decide member roles<br />
# How this group will work<br />
# Set regular meeting schedule<br />
## at least once a week<br />
## share each other's timetable<br />
==== Result ====<br />
# Brian joined our group !<br />
# Agreed on David's idea - he will put up more details on wiki page<br />
# Will be decided later<br />
# Work under one trunk<br />
# Regular Meeting Schedule<br />
## in-person meeting<br />
## at Seneca Library - YuJin will book the room every week<br />
## on every Thursday between 9:50am and 11:40am<br />
<br />
<hr/><br />
=== Sept 23th Meeting ===<br />
Meeting place : Room 1132, Seneca Library<br/><br />
Meeting time : 9:50am ~ 11:40am<br />
==== Agenda ====<br />
# Finalize our game proposal<br />
# Divide roles & responsibilities<br />
# Keep updated <br/><br />
## subscribe to team page and course pages<br/><br />
## subscribe by clicking 'watch' of each page menu<br />
# Creating our own private team page ???<br />
##to disclose certain information of our group project ???<br />
<br />
==== Result ====<br />
# Uploaded game proposal - there might be changes in the future<br />
# Will divide roles after having meeting with Chris<br />
# (was just notification)<br />
# (wasn't discussed) <br />
# New meeting schedule<br />
## We will have meetings every Thursday AND Friday<br />
## Will have to figure the exact meeting time soon (for Fridays)<br />
<br />
=== Sept 30th Meeting ===<br />
Meeting place : Room 1132, Seneca Library<br/><br />
Meeting time : 9:50am ~ 11:40am<br />
==== Agenda ====<br />
# <br />
==== Result ====<br />
#<br />
<br />
== Useful Links ==<br />
<br />
[http://zenit.senecac.on.ca/wiki/index.php/Team_Blam-GridCode Simple Grid Code]</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=Team_Blam-GridCode&diff=46439Team Blam-GridCode2010-09-30T15:24:39Z<p>Ajcondinho: </p>
<hr />
<div>Paste this into a Visual C# project and it will draw a bounding box for a grid of X's<br />
<br />
*If you have any changes / upgrades to this code, post here for the benefit of others*<br />
<br />
<pre><br />
using System;<br />
using System.Collections.Generic;<br />
using System.Linq;<br />
using System.Text;<br />
<br />
namespace Console_Move<br />
{<br />
class Program<br />
{<br />
static void Main(string[] args)<br />
{<br />
drawGrid();<br />
<br />
//Grid is useable starting at 1,1<br />
//corner co-ords are<br />
//TL: 1,1<br />
//TR: 19,1<br />
//BL: 1,18<br />
//BR: 19,18<br />
<br />
Console.SetCursorPosition(0, 21);<br />
Console.WriteLine("All done");<br />
<br />
}<br />
<br />
static void drawGrid()<br />
{<br />
int i = 0;<br />
int x = 0;<br />
<br />
for (i = 1; i < 19; i++)<br />
{<br />
Console.SetCursorPosition(0, i);<br />
Console.Write("x");<br />
}<br />
<br />
for (x = 0; x < 20; x++)<br />
{<br />
Console.SetCursorPosition(x, i);<br />
Console.Write("x");<br />
}<br />
<br />
for (i = 0; i < 20; i++)<br />
{<br />
Console.SetCursorPosition(i, 0);<br />
Console.Write("x");<br />
}<br />
<br />
for (x = 0; x < 20; x++)<br />
{<br />
Console.SetCursorPosition(i, x);<br />
Console.Write("x");<br />
}<br />
}<br />
}<br />
}<br />
</pre></div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=Team_Blam-GridCode&diff=46438Team Blam-GridCode2010-09-30T15:24:17Z<p>Ajcondinho: </p>
<hr />
<div>Paste this into a Visual C# project and it will draw a bounding box for a grid of X's<br />
<br />
*If you have any changes / upgrades to this code, post here for the benefit of others*<br />
<br />
<code><br />
using System;<br />
using System.Collections.Generic;<br />
using System.Linq;<br />
using System.Text;<br />
<br />
namespace Console_Move<br />
{<br />
class Program<br />
{<br />
static void Main(string[] args)<br />
{<br />
drawGrid();<br />
<br />
//Grid is useable starting at 1,1<br />
//corner co-ords are<br />
//TL: 1,1<br />
//TR: 19,1<br />
//BL: 1,18<br />
//BR: 19,18<br />
<br />
Console.SetCursorPosition(0, 21);<br />
Console.WriteLine("All done");<br />
<br />
}<br />
<br />
static void drawGrid()<br />
{<br />
int i = 0;<br />
int x = 0;<br />
<br />
for (i = 1; i < 19; i++)<br />
{<br />
Console.SetCursorPosition(0, i);<br />
Console.Write("x");<br />
}<br />
<br />
for (x = 0; x < 20; x++)<br />
{<br />
Console.SetCursorPosition(x, i);<br />
Console.Write("x");<br />
}<br />
<br />
for (i = 0; i < 20; i++)<br />
{<br />
Console.SetCursorPosition(i, 0);<br />
Console.Write("x");<br />
}<br />
<br />
for (x = 0; x < 20; x++)<br />
{<br />
Console.SetCursorPosition(i, x);<br />
Console.Write("x");<br />
}<br />
}<br />
}<br />
}<br />
</code></div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=Team_Blam-GridCode&diff=46437Team Blam-GridCode2010-09-30T15:23:03Z<p>Ajcondinho: Created page with 'Paste this into a Visual C# project and it will draw a bounding box for a grid of X's *If you have any changes / upgrades to this code, post here for the benefit of others* us…'</p>
<hr />
<div>Paste this into a Visual C# project and it will draw a bounding box for a grid of X's<br />
<br />
*If you have any changes / upgrades to this code, post here for the benefit of others*<br />
<br />
<br />
using System;<br />
using System.Collections.Generic;<br />
using System.Linq;<br />
using System.Text;<br />
<br />
namespace Console_Move<br />
{<br />
class Program<br />
{<br />
static void Main(string[] args)<br />
{<br />
drawGrid();<br />
<br />
//Grid is useable starting at 1,1<br />
//corner co-ords are<br />
//TL: 1,1<br />
//TR: 19,1<br />
//BL: 1,18<br />
//BR: 19,18<br />
<br />
Console.SetCursorPosition(0, 21);<br />
Console.WriteLine("All done");<br />
<br />
}<br />
<br />
static void drawGrid()<br />
{<br />
int i = 0;<br />
int x = 0;<br />
<br />
for (i = 1; i < 19; i++)<br />
{<br />
Console.SetCursorPosition(0, i);<br />
Console.Write("x");<br />
}<br />
<br />
for (x = 0; x < 20; x++)<br />
{<br />
Console.SetCursorPosition(x, i);<br />
Console.Write("x");<br />
}<br />
<br />
for (i = 0; i < 20; i++)<br />
{<br />
Console.SetCursorPosition(i, 0);<br />
Console.Write("x");<br />
}<br />
<br />
for (x = 0; x < 20; x++)<br />
{<br />
Console.SetCursorPosition(i, x);<br />
Console.Write("x");<br />
}<br />
}<br />
}<br />
}</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=User:Ajcondinho&diff=46340User:Ajcondinho2010-09-30T03:18:37Z<p>Ajcondinho: </p>
<hr />
<div>== My Blog ==<br />
<br />
[http://ajcondinho.blogspot.com/ My Blog]<br />
<br />
== My OSD600 Project ==<br />
<br />
[http://zenit.senecac.on.ca/wiki/index.php/OSD600Project-C3DLRefactoring C3DL Refactoring ]</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=OSD600Project-C3DLRefactoring&diff=46339OSD600Project-C3DLRefactoring2010-09-30T03:17:00Z<p>Ajcondinho: </p>
<hr />
<div>=== C3DL Library Core Refactoring ===<br />
<br />
<br />
== Project Description ==<br />
<br />
c3dl is a js library that provides higher level functionality for web developers wishing to develop 3D web applications. Currently the library always includes all features c3dl provides, even though they won't be needed in all cases. This adds download size, code complexity, etc. This project will refactor c3dl so that we have a core component, and then all the features can be added to this core and become unbound.<br />
<br />
== Project Leader(s) ==<br />
<br />
Andrew Condinho<br />
<br />
== Project Contributor(s) ==<br />
<br />
* Contacts: Cathy Leung, Andor Salga<br />
<br />
== Project Details ==<br />
* Technologies: JavaScript, WebGL, HTML5<br />
<br />
<br />
== Project News ==<br />
So far I've just chosen this project as the one I'm going to work on for OSD600, more news to come as it progresses.</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=OSD600Project-C3DLRefactoring&diff=46338OSD600Project-C3DLRefactoring2010-09-30T03:13:37Z<p>Ajcondinho: Created page with '== Project Name == Sample Project -- This is a template only! == Project Description == Description should be no longer than a paragraph. Include links to any relevant on-lin…'</p>
<hr />
<div>== Project Name ==<br />
<br />
Sample Project -- This is a template only!<br />
<br />
== Project Description ==<br />
<br />
Description should be no longer than a paragraph. Include links to any relevant on-line resources. For example, http://google.com or [http://developer.mozilla.org MDC].<br />
<br />
== Project Leader(s) ==<br />
<br />
Name(s) of primary people working on the project. If you want to join a project as leader, discuss with other leaders first. Include links to personal pages within wiki<br />
<br />
== Project Contributor(s) ==<br />
<br />
Name(s) of people casually working on the project, or who have contributed significant help. Include links to personal pages within wiki<br />
<br />
NOTE: only Project Leader(s) should add names here. You '''can’t''' add your own name to the Contributor list.<br />
<br />
== Project Details ==<br />
<br />
Provides more depth than the Project Description. This is the place for technical discussions, project specs, or other details. If this gets very long, you might consider breaking this part into multiple pages and linking to them.<br />
<br />
== Project News ==<br />
<br />
This is where your regular updates will go. In these you should discuss the status or your work, your interactions with other members of the community (e.g., Seneca and Mozilla), problems you have encountered, etc.<br />
<br />
Put detailed technical information into the Project Details page (i.e., update it as you go), and save this section for news about participation in the project.</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=Fall_2010_Mozilla_Open_Source_Project_List&diff=46337Fall 2010 Mozilla Open Source Project List2010-09-30T03:10:41Z<p>Ajcondinho: /* C3DL Library Core Refactoring */</p>
<hr />
<div>==Introduction==<br />
<br />
The open source course is a project based course, which puts students in direct contact with the open source community and real-world open source code. Students are encouraged to jump inot something big and unknown, and to do so with the full support of their colleagues, professor, and the open community.<br />
<br />
All projects will be done individually, but with collaboration between students and the open source community. Some of the projects below are complicated enough that they can be broken into parts for multiple people. If more than one person is interested in the same project, speak to your professor to figure out if it can be broken into sub-components.<br />
<br />
==Potential Projects==<br />
<br />
===C3DL Library Core Refactoring===<br />
<br />
c3dl is a [http://c3dl.org js library] that provides higher level functionality for web developers wishing to develop 3D web applications. Currently the library always includes all features c3dl provides, even though they won't be needed in all cases. This adds download size, code complexity, etc. This project will refactor c3dl so that we have a core component, and then all the features can be added to this core and become unbound.<br />
<br />
* Technologies: JavaScript, WebGL, HTML5<br />
* Contacts: Cathy Leung, Andor Salga<br />
* Primary: Andrew Condinho<br />
* Secondary: Pete Leaning, Carl Desautels<br />
<br />
===C3DL Build, Package, and Test Automation=== <br />
<br />
The c3dl library is currently manually packaged and deployed, and does not have a proper automated test suite. This project will create an automated build system that takes care of such tasks as: combining the multiple source files into one, minified file (better for download); port the automated test system from Processing.js to c3dl; and create a way to package various sub-components of c3dl into a single custom version of the library.<br />
<br />
* Technologies: JavaScript, light scripting (python, bash), Makefile, canvas and HTML5<br />
* Contacts: Cathy Leung, Andor Salga, Dave Humphrey<br />
* Secondary: Konstantin Novichikhin, Steven Weerdenburg<br />
<br />
===CSS Checker JetPack Extension===<br />
<br />
CSS as a standard evolves more slowly than browser vendor implementations, and as such, browser extensions are created. For example: -moz-box-shadow (Mozilla only), -webkit-box-shadow (Chrome/Safari), box-shadow (CSS standard). This extension will allow the user to tell when a a -webkit-* extension is being used for which there is also a -moz-* version. This will help with finding compatibility issues on websites that appear to work in one browser and not another.<br />
<br />
* Technologies: JavaScript, JetPack Extension API, CSS<br />
* Contacts: Dave Humphrey<br />
* Primary: Konstantin Novichikhin<br />
<br />
===Popcorn.js Visual Debug Mode=== <br />
<br />
The Popcorn.js library is a JavaScript library that allows semantic and timeline data to be added to a web video. Currently, it is text-based (xml and json) with no way of visually seeing what is in a Popcorn timeline file. This project will create a 2D canvas based visualization tool, allowing developers to easily turn on debug mode, and have a visual timeline appear at the bottom of the web page, showing various commands and their times. See the [http://github.com/blog/621-bye-bye-flash-network-graph-is-now-canvas recent Github redesign], which added a timeline canvas view for network activity.<br />
<br />
* Technologies: JavaScript, Popcorn.js, canvas and HTML5<br />
* Contacts: Scott Downe, Brett Gaylor, Dave Humphrey<br />
<br />
===Video Wrapper for Popcorn.js===<br />
<br />
The video element provides basic functionality for playing, pausing, seeking video in a web page, and for doing things like changing the volume. However, it is quite limited, and could be enhanced to support multiple overlapping videos, controlling more than 1 video in a page, fetching and displaying thumbnails, better seeking, buffering, etc. This project will create a new programming interface and API for the video element.<br />
<br />
* Technologies: JavaScript, Popcorn.js, video<br />
* Contacts: Anna Sobiepanek, Joel Young<br />
*Primary Choice: Chris DeCairos<br />
<br />
===Create Soda.js: an interface extension to Popcorn.js===<br />
<br />
Various projects using video on the web need to create innovative and non-standard user interfaces to control things like visual timelines, play, pause, changing the volume, etc. This project will create a library that provides some commonly needed interfaces, specifically aimed at the Global Lives project<br />
<br />
* Technologies: JavaScript, video, canvas, HTML5<br />
* Contacts: Brett Gaylor, Anna Sobiepanek, Joel Young<br />
* Primary Choice: Crystal de Nobrega<br />
<br />
===Create Candy.js: an effects extension to Popcorn.js===<br />
<br />
Various projects using video on the web need to create innovative and non-standard effects to transform the video, for example, applying filters, altering the video, using 2D and 3D effects, etc. This project will create a library that provides some commonly needed effects (e.g., colour filters, tilt shifting, etc.). This project will overlap and support the HTML5/Video Comic Book project.<br />
<br />
* Technologies: JavaScript, video, canvas, WebGL, HTML5<br />
* Contacts: Brett Gaylor, Scott Downe, Anna Sobiepanek, Dave Humphrey<br />
* Primary Choice: Kevin Lasconia, Kenneth Pangilinan<br />
* Secondary Choice: Crystal de Nobrega<br />
<br />
===HTML5/Video Comic Book===<br />
<br />
For the release of Firefox 4, Mozilla is creating a web-based comic book application, which uses video, canvas, and other HTML5 features. This project will help create the back-end JavaScript necessary to make things work with the video and canvas in the page. A professional designer will work on the HTML/CSS with you. This project will overlap and support the Candy.js library project.<br />
<br />
* Technologies: JavaScript, video, canvas, HTML5<br />
* Documentation: https://wiki.mozilla.org/Documentary<br />
* Contacts: Brett Gaylor<br />
* Secondary Choice: Kevin Lasconia, Kenneth Pangilinan<br />
* Primary Choice: Brian Law<br />
<br />
===NFB Open Video Player===<br />
<br />
The NFB wishes to start experimenting with the possibilities of HTML5 video. They want to implement and deploy an HTML5 video player on NFB.ca that meets the high quality feature set that we have currently in place with our flash video player. In order to demonstrate how this player would extend the ability of the NFB to create dynamic interactions with page content, this project will also produce several "demos" of the possibilities for educational distribution.<br />
<br />
''NOTE:'' This project is large enough for a few people to work on it.<br />
<br />
* Technologies: JavaScript, video, canvas, HTML5<br />
* Documentation: http://developer.nfb.ca/trac/web/wiki/NFBHTML5videoplayer<br />
* Contacts: Brett Gaylor, Anna Sobiepanek, Dave Humphrey<br />
* Primary: Steven Weerdenburg<br />
<br />
===Get Microsoft's WiX MSI toolchain working with Mono===<br />
<br />
Microsoft has an open source tool written in .NET that can create MSI installable packages. Currently this toolchain runs on Windows using the Microsoft .NET Framework. This project will get this tool to run using Mono (the open source, cross platform .NET runtime) and working on Linux.<br />
<br />
* Technologies: .NET, Windows, Linux, XML<br />
* Contacts: Mike Hoye<br />
<br />
===Create Music.js: an API for dynamic music generation in JavaScript===<br />
<br />
The music.js library is meant to provide a high-level API for music generation, with functions and data sets for things like notes, scales, arpeggios, chords, phrases and rhythms. Music.js will be highly abstracted, but primarily developed to work with dsp.js<br />
<br />
* Technologies: JavaScript, Mozilla Audio Data API, dsp.js<br />
* Contacts: Al MacDonald, Corban Brook, David Humphrey<br />
* Resources: https://wiki.mozilla.org/Audio_Data_API<br />
<br />
* Primary: Pete Leaning<br />
<br />
===Create a WebGL Performance Test Suite===<br />
<br />
Compare the speed of Mozilla's WebGL implementation with other implementations, and build an automated test suite to allow Mozilla to track that it's implementation doesn't get slower over time.<br />
<br />
* Technologies: JavaScript, C++, OpenGL, WebGL<br />
* Contacts: Vlad, #gfx, Cathy Leung<br />
* Primary: Carl Desautels</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=Fall_2010_Open_Source_Students&diff=45869Fall 2010 Open Source Students2010-09-25T03:17:44Z<p>Ajcondinho: /* The following is a list of students taking open source courses this fall */</p>
<hr />
<div>== The following is a list of students taking open source courses this fall ==<br />
<br />
* '''[[User:sbologna|Bologna, Stephen]]''', ''[http://stevebologna.wordpress.com/ Blog]''<br />
* '''[[User:dacallow|Callow, Kaitlyn]]''', ''[http://blog.kaitlyncallow.com/ Blog]''<br />
* '''[[User:ajcondinho|Condinho, Andrew]]''', ''[http://ajcondinho.blogspot.com Blog]''<br />
* '''[[User:cldenobrega|de Nobrega, Crystal]]''', ''[http://cldenobrega.wordpress.com/category Blog]''<br />
* '''[[User:cadecairos|DeCairos, Christopher]]''', ''[http://cadecairos.blogspot.com/ Blog]''<br />
* '''[[User:cwdesautels|Desautels, Carl]]''', ''[http://cwd89.blogspot.com Blog]''<br />
* '''[[User:jevangel|Evangelista, James]]''', ''[http://jevangelos.wordpress.com/ Blog]''<br />
* '''[[User:peleaning|Leaning, Pete]]''', ''[http://blockrockinpete.blogspot.com/ Blog]''<br />
* '''[[User:kclascon|Lasconia, Kevin]]''', ''[http://klasconia.wordpress.com/ Blog]''<br />
* '''Law, Brian''', ''[http://brianlaw20.blogspot.com/ Blog]''<br />
* '''Pangilinan, Kenneth''', ''[http://kpangilinan.wordpress.com/ Blog]''<br />
* '''[[User:Sweerdenburg|Weerdenburg, Steven]]''', ''[http://sweerdenburg.wordpress.com/ Blog]''<br />
* '''[[User:knovichikhi|Novichikhin, Konstantin]]''', ''[http://manoutoftime.wordpress.com/ Blog]''</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=Firefox_Performance_Testing_Lab_Fall_2010&diff=45868Firefox Performance Testing Lab Fall 20102010-09-25T03:16:03Z<p>Ajcondinho: /* Bug Reports */</p>
<hr />
<div>== Goal ==<br />
<br />
The goal of this lab is twofold. First, to provide students with a real-world experience of working collaboratively in an open community; and second, to work on a cutting-edge, but manageable project within the Mozilla community.<br />
<br />
== Objective ==<br />
<br />
To conduct A/B performance tests of the Chrome Experiments using nightly builds of both Firefox and Chrome, in order to identify performance bottlenecks in Firefox. Also, to profile and file bugs in order to fix these issues.<br />
<br />
== Method ==<br />
<br />
* As a group determine a method for dividing the Chrome Experiments so they all get tested<br />
* Install both the Firefox and Chrome nightly builds<br />
* Test each experiment in the two browsers, looking for various issues:<br />
** Speed - is Firefox as fast as Chrome at rendering the graphics?<br />
** Smoothness - are the graphics as smooth as in Chrome? Do you notice a lot of pauses, jerkiness, etc.?<br />
** Responsiveness - does Firefox remain responsive while you run the demo? Is it pegging your CPU(s)? <br />
* Record your findings, as well as browser and computer info ([about:support], [about:]) in the Results Spreadsheet.<br />
<br />
== Resources ==<br />
<br />
===Links===<br />
<br />
* [http://chromeexperiments.com Chrome Experiments]<br />
* [http://nightly.mozilla.org/ Firefox (i.e., Minefield) nightly builds]<br />
* [http://build.chromium.org/buildbot/snapshots/ Chrome (i.e., Chromium) nightly builds]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=594920 Example performance bug]<br />
<br />
===Misc Info===<br />
<br />
One of the questions that comes up a lot when filing these bugs, especially on Windows, is whether or not you have Direct2D (i.e., D2D) or Direct3D (D3D) enabled. The graphics system in Firefox has 3 states related to hardware acceleration:<br />
<br />
# no hardware acceleration<br />
# D3D but not D2D<br />
# All hardware acceleration<br />
<br />
You can control this using various preferences, which you can change by going to '''about:config''' (type this into your address bar and press enter):<br />
<br />
* D3D Layers Preferences<br />
** layers.accelerate-all<br />
** layers.accelerate-none<br />
* Font Rendering<br />
** gfx.font_rendering.directwrite.enabled<br />
* Direct2D<br />
** gfx.direct2d.force-enabled<br />
<br />
You can also use built-in Firefox options to toggle hardware acceleration between the "None" and "All" states by (un)checking “Use hardware acceleration when available” in the Advanced section of the Preferences/Options dialog. Alternately, you can run Firefox in safe mode to disable hardware acceleration [http://blog.mozilla.com/joe/2010/09/15/testing-hardware-acceleration/]. When filing a bug related to hardware acceleration, please include the Graphics card information from '''about:support''' in your browser.<br />
<br />
== Tests: Initial First Round ==<br />
<br />
(humph) Let's refine this a bit more, such that we track:<br />
<br />
Name of Experiment | URL of Experiment | Your Name | Date of Test | Hardware Info | Browser Info | Firefox Performance - Speed | Firefox Performance - Smoothness | Firefox Performance - Responsiveness | Notes and other Details |<br />
<br />
{| border="1" cellpadding="5"<br />
! Test No. !! Name <br /> !! Results<br />
|-<br />
| 1-10 || [[User:cwdesautels|Carl]] || [[Firefox_Performance_Testing_Lab_Fall_2010_cwdesautels | Results]] <br />
|-<br />
| 11-20 || [[User:kclascon|Kevin Lasconia]] || [[Firefox_Performance_Testing_Lab_Fall_2010_kclascon | Results]] <br />
|-<br />
| 21-30 || [[User:ajcondinho | Andrew Condinho]] || [[Firefox_Performance_Testing_Lab_Fall_2010_ajcondinho | Results]] <br />
|-<br />
| 31-40 || [[User:sbologna|Stephen Bologna]] || [[Firefox_Performance_Testing_Lab_Fall_2010_sbologna | Results]]<br />
|-<br />
| 41-50 || [[User:kpangilinan|Kenneth Pangilinan]] || [[Firefox_Performance_Testing_Lab_Fall_2010_kpangilinan | Results]] <br />
|-<br />
| 51-60 || [[User:peleaning|Pete Leaning]] || [[Firefox_Performance_Testing_Lab_Fall_2010_peleaning | Results]] <br />
|-<br />
| 61-70 || [[User:blaw1|Brian Law]] || [[Firefox_Performance_Testing_Lab_Fall_2010_blaw1 | Results]] <br />
|-<br />
| 71-80 || [[User:sweerdenburg|Steven Weerdenburg]] || [[Firefox_Performance_Testing_Lab_Fall_2010_sweerdenburg | Results]] <br />
|-<br />
| 81-90 || [[User:jevangel|James Evangelista]] || [[Firefox_Performance_Testing_Lab_Fall_2010_jevangel | Results]] <br />
|-<br />
| 91-100 || [[User:dacallow|Kaitlyn Callow]] || [[Firefox_Performance_Testing_Lab_Fall_2010_dacallow| Results]] <br />
|-<br />
| 101-110 || [[User:cldenobrega|Crystal de Nobrega]] || [[Firefox_Performance_Testing_Lab_Fall_2010_cldenobrega | Results]]<br />
|-<br />
| 111-120 || [[User:cadecairos|Chris DeCairos]] || [[Firefox_Performance_Testing_Lab_Fall_2010_cadecairos | Results]] <br />
|-<br />
| 1-26 (Linux) || [[User:knovichikhi|Konstantin Novichikhin]] || [[Firefox_Performance_Testing_Lab_Fall_2010_knov | Results]] <br />
|}<br />
<br />
== Tests: Second Round ==<br />
<br />
For each experiment you tested as part of the first-round of testing that was not as fast or faster than Chrome, please create an entry in the table below. Include details about what you are seeing, what is failing, etc. Also, if you need to file a bug, include the link to the bug you filed.<br />
<br />
[https://developer.mozilla.org/En/Profiling_with_Xperf Link to Xperf Profiler]<br /><br />
[http://blogs.msdn.com/b/pigscanfly/archive/2009/08/06/stack-walking-in-xperf.aspx MSDN blog detailing how to use xperf results]<br />
<br />
{| border="1" cellpadding="5"<br />
! Test !! Tester !! Problem !! Additional Info <br /><br />
|-<br />
| [http://www.chromeexperiments.com/detail/lorenz-84/ Lorenz 84]<br />
|| [[User:sbologna|Stephen Bologna]]<br />
|| In the 32bit version of Minefield on Vista the browser froze for several seconds when the page loaded, and any attempt to interact with the test caused it to freeze again. In the 64bit version of Minefield on Window 7, the page took several minutes to load, and the image was not drawn properly.<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/google-sphere/ Google Sphere]<br />
|| [[User:sbologna|Stephen Bologna]]<br />
|| Overall look in Minefield is very sloppy compared to Chromium. When the 2d text gets close to the screen, it becomes less legible. It also runs slower on Minefield.<br />
|| Runs fine in Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/cheloniidae-live/ Cheloniidae Live] <br />
|| [[User:dacallow|Kaitlyn Callow]] <br />
|| Not running. <br />
|| Returning error:<br />
Error: console is not defined<br />
Source File: http://spencertipping.com/beta/cheloniidae-live-b1/script.js<br />
Line: 2<br />
|-<br />
<br />
<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/water-type/ Water Type] <br />
|| [[User:dacallow|Kaitlyn Callow]] <br />
|| MUCH SLOWER in Minefield on school computers. Speeds seems compairable to Chrome on my home computer. At school browser significantly slowed down while viewing this experiment.<br />
|| Not sure which is better, but Chrome looks more blurry or anti-aliased maybe then Mindfield.<br />
|-<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/plane-deformations/ Plane Deformations] <br />
|| [[User:dacallow|Kaitlyn Callow]] <br />
|| At school Mindfield is slower, 12fps vs Chrome at 20fps. At home running must faster in Mindfield, 50 fps (25 in Chrome).<br />
||<br />
|-<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/balldroppings/ BallDroppings]<br />
|| [[User:cwdesautels|Carl D]]<br />
|| far more audio clipping and visual chop when at a 'max' ball drop speed when compared to chrome<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/video-picture-puzzle/ VP Puzzle]<br />
|| [[User:cwdesautels|Carl D]]<br />
|| far greater delay generating picture puzzle windows<br />
|| Firefox was much faster and smoother then Chrome when creating the one video puzzle and its windows<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/liquid-particles/ Liquid Particles]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Minefield particle dot redraw very slow, manages approx 10 frames/sec. Chromium has no delay when rendering particle dot movement. Both have difficulty in letter rendering<br />
|| Investigation yields a [https://bugzilla.mozilla.org/show_bug.cgi?id=564643 duplicate]<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/animated-harmonograph/ Animated Harmonograph]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Image rendering much slower than on Chromium. Drawing of complex patterns on Minefield would sometimes cause centre to "wobble". CPU utilization seems (near) identical on both.<br />
|| Hardware acceleration makes no difference<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/browser-pong/ Browser Pong]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Minefield calculates the "ball" window height as twice that of Chromium<br />
|| <br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/realtime-video-ascii-conversion/ Realtime Video->ASCII Conversion]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Seems to have very difficult time at higher "resolutions" (smaller fonts). Scales up in canvas size ok, but becomes unresponsive over prolonged periods (5+ minutes) of use. Handles larger canvas with same resolution better than chrome at default settings.<br />
|| <br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/colorscube/ Colorscube]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| When the cube is rotated in any direction the animation is very choppy. There is also a delay between moving the mouse in one direction and the actual cube moving in that direction.<br />
|| Chrome was very smooth, and responsive. Filed a bug [https://bugzilla.mozilla.org/show_bug.cgi?id=599351 here].<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/monster/ Monster]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| In Firefox, when more complex objects are generated the spinning animation of the object becomes increasingly more choppy. During transformations the animation would freeze for a few seconds then continue.<br />
|| Found a bug about the same experiment [https://bugzilla.mozilla.org/show_bug.cgi?id=503470 here].<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/browser-ball/ Browser Ball]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| There is an issue when multiple windows are spawned in Firefox for this experiment. When moving the ball from the main window to another the ball will get stuck. Even when trying to "throw" the ball to another window it will still get stuck.<br />
|| In Chrome, the ball can actually be moved to and from new windows.<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/gravity/ Gravity]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| This experiment does not work in the Firefox/4.0b7pre nightly build.<br />
|| It works fine in Chrome. It also works in Firefox 3.6.10, however the objects cannot be dragged around like in Chrome. A bug filed [https://bugzilla.mozilla.org/show_bug.cgi?id=570922 here] outlines the dragging issues. Did some regression testing to determine the builds where the experiment worked and stopped working. Added some additional info to this bug [https://bugzilla.mozilla.org/show_bug.cgi?id=595541 here].<br />
|-<br />
<br />
<br />
| [http://www.thewildernessdowntown.com Wilderness Downtown]<br />
|| [[User:cadecairos |Chris DeCairos]]<br />
|| '''NEW''' Minefield crashes on my computer at the same point in the song every time! I have had it happen 3 times in a row, my first crash reprot was not sent but two others were. It happens after the first verse.<br />
|| see my first [http://crash-stats.mozilla.com/report/index/bp-e5ff5685-4816-4787-b8f0-25de02100921 crash report] and second [http://crash-stats.mozilla.com/report/index/bp-4c74c6af-2bd4-4e52-b8ac-65a402100921 crash report] '''Update''': I've reproduced it again got a [http://crash-stats.mozilla.com/report/index/49bba790-767f-4662-b83f-1ad092100921 third crash report] will file bug report once I know exactly what component this is crashing in.<br />
also, I would test it on Chrome nightly, but their current build still cannot play the video at all.<br />
Filed a [https://bugzilla.mozilla.org/show_bug.cgi?id=598498 Bug]<br />
|-<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/depth-of-field/ Depth of Field]<br />
|| [[User:kpangilinan |Kenneth Pangilinan]]<br />
|| Minefield freezes up PC for a few seconds before running. When attempting to move the window around, PC freezes up again.<br />
|| Experiment works fine in Chromium, moving the window around is fine as well.<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/3d-javascript-with-sandy-hx/ 3D JS w/ Sandy DX]<br />
|| [[User:kpangilinan |Kenneth Pangilinan]]<br />
|| Experiment did not load in Minefield or Chromium.<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/javascript-voxel-spacing/ JS Voxel Spacing]<br />
|| [[User:kpangilinan |Kenneth Pangilinan]]<br />
|| In Minefield it runs at 2-4FPS, in Chromium it runs at 22-24FPS, about 10 times faster!<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/gear/ Gear]<br />
|| [[User:blaw1 |Brian Law]]<br />
|| This experiment is very choppy in Minefield, whereas Chromium runs smoothly. In Minefield you can see arrows in the boxes which shouldn't be visible.<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/waterfall/ Waterfall]<br />
|| [[User:blaw1 |Brian Law]]<br />
|| Minefield quickly begins to lag as more balls enter the screen. Chromium will run smoothly for much longer.<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/pocket-full-of-canvas/ Pocket Full of Canvas]<br />
|| [[User:peleaning |Pete Leaning]]<br />
|| Minefield draws black triangles in the following effects in 'pocket full of canvas':<br />
Elipse, Colorrects, Mario, Colormunch, imagewaves, fire, wave(de)form and imagemagnifier. These artifacts are not present in Chromium<br />
||The two functions that seem to be responsible for this are renderTriangle() and drawImage<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/kaleidscope/ Kaleidscope]<br />
|| [[User:ajcondinho |Andrew Condinho]]<br />
|| Physical window becomes jerky and laggy whenever you re-size the window.<br />
|| Tested this out on my desktop and lag disappeared, looks like it might be an issue with lesser hardware<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/physicsketch/ physicSketch]<br />
|| [[User:ajcondinho |Andrew Condinho]]<br />
|| Objects don't draw, and after a few failed attempts experiment stops responding to any attempts to draw.<br />
|| Chrome has no problems running this experiment.<br />
|-<br />
<br />
|}<br />
<br />
==Bug Reports==<br />
<br />
'''NOTE:''' All bugs related to what we find should have '''[chromeexperiments]''' in the bug's Whiteboard field, so we can track them. The following Bugzilla search will list them all: <nowiki>https://bugzilla.mozilla.org/buglist.cgi?quicksearch=[chromeexperiments]</nowiki><br />
<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=596677 Sand Trap bug(dupe)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=595963 Open Sand Trap bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=596707 Sand Trap graphics bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=596746 Sand Trap painting perf bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=597186 Wilderness Downtown Canvas bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=598498 Wilderness Downtown Crash bug (xull.dll)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=598831 Liquid Particles perf bug (dupe)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=598834 Animated Harmonograph perf bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=598361 Pocket Full of Canvas triangle bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599210 Ball Dropping bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599236 Video->ASCII Conversion perf bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599318 Javascript Voxel Spacing bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599350 Gear bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599351 Colorscube bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=595541 Google Gravity bug (added additional info)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599568 physicSketch bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599569 Kaleidscope Re-size Bug]</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=Firefox_Performance_Testing_Lab_Fall_2010&diff=45867Firefox Performance Testing Lab Fall 20102010-09-25T03:08:47Z<p>Ajcondinho: /* Bug Reports */</p>
<hr />
<div>== Goal ==<br />
<br />
The goal of this lab is twofold. First, to provide students with a real-world experience of working collaboratively in an open community; and second, to work on a cutting-edge, but manageable project within the Mozilla community.<br />
<br />
== Objective ==<br />
<br />
To conduct A/B performance tests of the Chrome Experiments using nightly builds of both Firefox and Chrome, in order to identify performance bottlenecks in Firefox. Also, to profile and file bugs in order to fix these issues.<br />
<br />
== Method ==<br />
<br />
* As a group determine a method for dividing the Chrome Experiments so they all get tested<br />
* Install both the Firefox and Chrome nightly builds<br />
* Test each experiment in the two browsers, looking for various issues:<br />
** Speed - is Firefox as fast as Chrome at rendering the graphics?<br />
** Smoothness - are the graphics as smooth as in Chrome? Do you notice a lot of pauses, jerkiness, etc.?<br />
** Responsiveness - does Firefox remain responsive while you run the demo? Is it pegging your CPU(s)? <br />
* Record your findings, as well as browser and computer info ([about:support], [about:]) in the Results Spreadsheet.<br />
<br />
== Resources ==<br />
<br />
===Links===<br />
<br />
* [http://chromeexperiments.com Chrome Experiments]<br />
* [http://nightly.mozilla.org/ Firefox (i.e., Minefield) nightly builds]<br />
* [http://build.chromium.org/buildbot/snapshots/ Chrome (i.e., Chromium) nightly builds]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=594920 Example performance bug]<br />
<br />
===Misc Info===<br />
<br />
One of the questions that comes up a lot when filing these bugs, especially on Windows, is whether or not you have Direct2D (i.e., D2D) or Direct3D (D3D) enabled. The graphics system in Firefox has 3 states related to hardware acceleration:<br />
<br />
# no hardware acceleration<br />
# D3D but not D2D<br />
# All hardware acceleration<br />
<br />
You can control this using various preferences, which you can change by going to '''about:config''' (type this into your address bar and press enter):<br />
<br />
* D3D Layers Preferences<br />
** layers.accelerate-all<br />
** layers.accelerate-none<br />
* Font Rendering<br />
** gfx.font_rendering.directwrite.enabled<br />
* Direct2D<br />
** gfx.direct2d.force-enabled<br />
<br />
You can also use built-in Firefox options to toggle hardware acceleration between the "None" and "All" states by (un)checking “Use hardware acceleration when available” in the Advanced section of the Preferences/Options dialog. Alternately, you can run Firefox in safe mode to disable hardware acceleration [http://blog.mozilla.com/joe/2010/09/15/testing-hardware-acceleration/]. When filing a bug related to hardware acceleration, please include the Graphics card information from '''about:support''' in your browser.<br />
<br />
== Tests: Initial First Round ==<br />
<br />
(humph) Let's refine this a bit more, such that we track:<br />
<br />
Name of Experiment | URL of Experiment | Your Name | Date of Test | Hardware Info | Browser Info | Firefox Performance - Speed | Firefox Performance - Smoothness | Firefox Performance - Responsiveness | Notes and other Details |<br />
<br />
{| border="1" cellpadding="5"<br />
! Test No. !! Name <br /> !! Results<br />
|-<br />
| 1-10 || [[User:cwdesautels|Carl]] || [[Firefox_Performance_Testing_Lab_Fall_2010_cwdesautels | Results]] <br />
|-<br />
| 11-20 || [[User:kclascon|Kevin Lasconia]] || [[Firefox_Performance_Testing_Lab_Fall_2010_kclascon | Results]] <br />
|-<br />
| 21-30 || [[User:ajcondinho | Andrew Condinho]] || [[Firefox_Performance_Testing_Lab_Fall_2010_ajcondinho | Results]] <br />
|-<br />
| 31-40 || [[User:sbologna|Stephen Bologna]] || [[Firefox_Performance_Testing_Lab_Fall_2010_sbologna | Results]]<br />
|-<br />
| 41-50 || [[User:kpangilinan|Kenneth Pangilinan]] || [[Firefox_Performance_Testing_Lab_Fall_2010_kpangilinan | Results]] <br />
|-<br />
| 51-60 || [[User:peleaning|Pete Leaning]] || [[Firefox_Performance_Testing_Lab_Fall_2010_peleaning | Results]] <br />
|-<br />
| 61-70 || [[User:blaw1|Brian Law]] || [[Firefox_Performance_Testing_Lab_Fall_2010_blaw1 | Results]] <br />
|-<br />
| 71-80 || [[User:sweerdenburg|Steven Weerdenburg]] || [[Firefox_Performance_Testing_Lab_Fall_2010_sweerdenburg | Results]] <br />
|-<br />
| 81-90 || [[User:jevangel|James Evangelista]] || [[Firefox_Performance_Testing_Lab_Fall_2010_jevangel | Results]] <br />
|-<br />
| 91-100 || [[User:dacallow|Kaitlyn Callow]] || [[Firefox_Performance_Testing_Lab_Fall_2010_dacallow| Results]] <br />
|-<br />
| 101-110 || [[User:cldenobrega|Crystal de Nobrega]] || [[Firefox_Performance_Testing_Lab_Fall_2010_cldenobrega | Results]]<br />
|-<br />
| 111-120 || [[User:cadecairos|Chris DeCairos]] || [[Firefox_Performance_Testing_Lab_Fall_2010_cadecairos | Results]] <br />
|-<br />
| 1-26 (Linux) || [[User:knovichikhi|Konstantin Novichikhin]] || [[Firefox_Performance_Testing_Lab_Fall_2010_knov | Results]] <br />
|}<br />
<br />
== Tests: Second Round ==<br />
<br />
For each experiment you tested as part of the first-round of testing that was not as fast or faster than Chrome, please create an entry in the table below. Include details about what you are seeing, what is failing, etc. Also, if you need to file a bug, include the link to the bug you filed.<br />
<br />
[https://developer.mozilla.org/En/Profiling_with_Xperf Link to Xperf Profiler]<br /><br />
[http://blogs.msdn.com/b/pigscanfly/archive/2009/08/06/stack-walking-in-xperf.aspx MSDN blog detailing how to use xperf results]<br />
<br />
{| border="1" cellpadding="5"<br />
! Test !! Tester !! Problem !! Additional Info <br /><br />
|-<br />
| [http://www.chromeexperiments.com/detail/lorenz-84/ Lorenz 84]<br />
|| [[User:sbologna|Stephen Bologna]]<br />
|| In the 32bit version of Minefield on Vista the browser froze for several seconds when the page loaded, and any attempt to interact with the test caused it to freeze again. In the 64bit version of Minefield on Window 7, the page took several minutes to load, and the image was not drawn properly.<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/google-sphere/ Google Sphere]<br />
|| [[User:sbologna|Stephen Bologna]]<br />
|| Overall look in Minefield is very sloppy compared to Chromium. When the 2d text gets close to the screen, it becomes less legible. It also runs slower on Minefield.<br />
|| Runs fine in Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/cheloniidae-live/ Cheloniidae Live] <br />
|| [[User:dacallow|Kaitlyn Callow]] <br />
|| Not running. <br />
|| Returning error:<br />
Error: console is not defined<br />
Source File: http://spencertipping.com/beta/cheloniidae-live-b1/script.js<br />
Line: 2<br />
|-<br />
<br />
<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/water-type/ Water Type] <br />
|| [[User:dacallow|Kaitlyn Callow]] <br />
|| MUCH SLOWER in Minefield on school computers. Speeds seems compairable to Chrome on my home computer. At school browser significantly slowed down while viewing this experiment.<br />
|| Not sure which is better, but Chrome looks more blurry or anti-aliased maybe then Mindfield.<br />
|-<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/plane-deformations/ Plane Deformations] <br />
|| [[User:dacallow|Kaitlyn Callow]] <br />
|| At school Mindfield is slower, 12fps vs Chrome at 20fps. At home running must faster in Mindfield, 50 fps (25 in Chrome).<br />
||<br />
|-<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/balldroppings/ BallDroppings]<br />
|| [[User:cwdesautels|Carl D]]<br />
|| far more audio clipping and visual chop when at a 'max' ball drop speed when compared to chrome<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/video-picture-puzzle/ VP Puzzle]<br />
|| [[User:cwdesautels|Carl D]]<br />
|| far greater delay generating picture puzzle windows<br />
|| Firefox was much faster and smoother then Chrome when creating the one video puzzle and its windows<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/liquid-particles/ Liquid Particles]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Minefield particle dot redraw very slow, manages approx 10 frames/sec. Chromium has no delay when rendering particle dot movement. Both have difficulty in letter rendering<br />
|| Investigation yields a [https://bugzilla.mozilla.org/show_bug.cgi?id=564643 duplicate]<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/animated-harmonograph/ Animated Harmonograph]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Image rendering much slower than on Chromium. Drawing of complex patterns on Minefield would sometimes cause centre to "wobble". CPU utilization seems (near) identical on both.<br />
|| Hardware acceleration makes no difference<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/browser-pong/ Browser Pong]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Minefield calculates the "ball" window height as twice that of Chromium<br />
|| <br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/realtime-video-ascii-conversion/ Realtime Video->ASCII Conversion]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Seems to have very difficult time at higher "resolutions" (smaller fonts). Scales up in canvas size ok, but becomes unresponsive over prolonged periods (5+ minutes) of use. Handles larger canvas with same resolution better than chrome at default settings.<br />
|| <br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/colorscube/ Colorscube]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| When the cube is rotated in any direction the animation is very choppy. There is also a delay between moving the mouse in one direction and the actual cube moving in that direction.<br />
|| Chrome was very smooth, and responsive. Filed a bug [https://bugzilla.mozilla.org/show_bug.cgi?id=599351 here].<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/monster/ Monster]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| In Firefox, when more complex objects are generated the spinning animation of the object becomes increasingly more choppy. During transformations the animation would freeze for a few seconds then continue.<br />
|| Found a bug about the same experiment [https://bugzilla.mozilla.org/show_bug.cgi?id=503470 here].<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/browser-ball/ Browser Ball]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| There is an issue when multiple windows are spawned in Firefox for this experiment. When moving the ball from the main window to another the ball will get stuck. Even when trying to "throw" the ball to another window it will still get stuck.<br />
|| In Chrome, the ball can actually be moved to and from new windows.<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/gravity/ Gravity]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| This experiment does not work in the Firefox/4.0b7pre nightly build.<br />
|| It works fine in Chrome. It also works in Firefox 3.6.10, however the objects cannot be dragged around like in Chrome. A bug filed [https://bugzilla.mozilla.org/show_bug.cgi?id=570922 here] outlines the dragging issues. Did some regression testing to determine the builds where the experiment worked and stopped working. Added some additional info to this bug [https://bugzilla.mozilla.org/show_bug.cgi?id=595541 here].<br />
|-<br />
<br />
<br />
| [http://www.thewildernessdowntown.com Wilderness Downtown]<br />
|| [[User:cadecairos |Chris DeCairos]]<br />
|| '''NEW''' Minefield crashes on my computer at the same point in the song every time! I have had it happen 3 times in a row, my first crash reprot was not sent but two others were. It happens after the first verse.<br />
|| see my first [http://crash-stats.mozilla.com/report/index/bp-e5ff5685-4816-4787-b8f0-25de02100921 crash report] and second [http://crash-stats.mozilla.com/report/index/bp-4c74c6af-2bd4-4e52-b8ac-65a402100921 crash report] '''Update''': I've reproduced it again got a [http://crash-stats.mozilla.com/report/index/49bba790-767f-4662-b83f-1ad092100921 third crash report] will file bug report once I know exactly what component this is crashing in.<br />
also, I would test it on Chrome nightly, but their current build still cannot play the video at all.<br />
Filed a [https://bugzilla.mozilla.org/show_bug.cgi?id=598498 Bug]<br />
|-<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/depth-of-field/ Depth of Field]<br />
|| [[User:kpangilinan |Kenneth Pangilinan]]<br />
|| Minefield freezes up PC for a few seconds before running. When attempting to move the window around, PC freezes up again.<br />
|| Experiment works fine in Chromium, moving the window around is fine as well.<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/3d-javascript-with-sandy-hx/ 3D JS w/ Sandy DX]<br />
|| [[User:kpangilinan |Kenneth Pangilinan]]<br />
|| Experiment did not load in Minefield or Chromium.<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/javascript-voxel-spacing/ JS Voxel Spacing]<br />
|| [[User:kpangilinan |Kenneth Pangilinan]]<br />
|| In Minefield it runs at 2-4FPS, in Chromium it runs at 22-24FPS, about 10 times faster!<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/gear/ Gear]<br />
|| [[User:blaw1 |Brian Law]]<br />
|| This experiment is very choppy in Minefield, whereas Chromium runs smoothly. In Minefield you can see arrows in the boxes which shouldn't be visible.<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/waterfall/ Waterfall]<br />
|| [[User:blaw1 |Brian Law]]<br />
|| Minefield quickly begins to lag as more balls enter the screen. Chromium will run smoothly for much longer.<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/pocket-full-of-canvas/ Pocket Full of Canvas]<br />
|| [[User:peleaning |Pete Leaning]]<br />
|| Minefield draws black triangles in the following effects in 'pocket full of canvas':<br />
Elipse, Colorrects, Mario, Colormunch, imagewaves, fire, wave(de)form and imagemagnifier. These artifacts are not present in Chromium<br />
||The two functions that seem to be responsible for this are renderTriangle() and drawImage<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/kaleidscope/ Kaleidscope]<br />
|| [[User:ajcondinho |Andrew Condinho]]<br />
|| Physical window becomes jerky and laggy whenever you re-size the window.<br />
|| Tested this out on my desktop and lag disappeared, looks like it might be an issue with lesser hardware<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/physicsketch/ physicSketch]<br />
|| [[User:ajcondinho |Andrew Condinho]]<br />
|| Objects don't draw, and after a few failed attempts experiment stops responding to any attempts to draw.<br />
|| Chrome has no problems running this experiment.<br />
|-<br />
<br />
|}<br />
<br />
==Bug Reports==<br />
<br />
'''NOTE:''' All bugs related to what we find should have '''[chromeexperiments]''' in the bug's Whiteboard field, so we can track them. The following Bugzilla search will list them all: <nowiki>https://bugzilla.mozilla.org/buglist.cgi?quicksearch=[chromeexperiments]</nowiki><br />
<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=596677 Sand Trap bug(dupe)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=595963 Open Sand Trap bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=596707 Sand Trap graphics bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=596746 Sand Trap painting perf bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=597186 Wilderness Downtown Canvas bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=598498 Wilderness Downtown Crash bug (xull.dll)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=598831 Liquid Particles perf bug (dupe)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=598834 Animated Harmonograph perf bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=598361 Pocket Full of Canvas triangle bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599210 Ball Dropping bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599236 Video->ASCII Conversion perf bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599318 Javascript Voxel Spacing bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599350 Gear bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599351 Colorscube bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=595541 Google Gravity bug (added additional info)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599568 physicSketch bug]</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=Firefox_Performance_Testing_Lab_Fall_2010&diff=45866Firefox Performance Testing Lab Fall 20102010-09-25T03:02:53Z<p>Ajcondinho: /* Tests: Second Round */</p>
<hr />
<div>== Goal ==<br />
<br />
The goal of this lab is twofold. First, to provide students with a real-world experience of working collaboratively in an open community; and second, to work on a cutting-edge, but manageable project within the Mozilla community.<br />
<br />
== Objective ==<br />
<br />
To conduct A/B performance tests of the Chrome Experiments using nightly builds of both Firefox and Chrome, in order to identify performance bottlenecks in Firefox. Also, to profile and file bugs in order to fix these issues.<br />
<br />
== Method ==<br />
<br />
* As a group determine a method for dividing the Chrome Experiments so they all get tested<br />
* Install both the Firefox and Chrome nightly builds<br />
* Test each experiment in the two browsers, looking for various issues:<br />
** Speed - is Firefox as fast as Chrome at rendering the graphics?<br />
** Smoothness - are the graphics as smooth as in Chrome? Do you notice a lot of pauses, jerkiness, etc.?<br />
** Responsiveness - does Firefox remain responsive while you run the demo? Is it pegging your CPU(s)? <br />
* Record your findings, as well as browser and computer info ([about:support], [about:]) in the Results Spreadsheet.<br />
<br />
== Resources ==<br />
<br />
===Links===<br />
<br />
* [http://chromeexperiments.com Chrome Experiments]<br />
* [http://nightly.mozilla.org/ Firefox (i.e., Minefield) nightly builds]<br />
* [http://build.chromium.org/buildbot/snapshots/ Chrome (i.e., Chromium) nightly builds]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=594920 Example performance bug]<br />
<br />
===Misc Info===<br />
<br />
One of the questions that comes up a lot when filing these bugs, especially on Windows, is whether or not you have Direct2D (i.e., D2D) or Direct3D (D3D) enabled. The graphics system in Firefox has 3 states related to hardware acceleration:<br />
<br />
# no hardware acceleration<br />
# D3D but not D2D<br />
# All hardware acceleration<br />
<br />
You can control this using various preferences, which you can change by going to '''about:config''' (type this into your address bar and press enter):<br />
<br />
* D3D Layers Preferences<br />
** layers.accelerate-all<br />
** layers.accelerate-none<br />
* Font Rendering<br />
** gfx.font_rendering.directwrite.enabled<br />
* Direct2D<br />
** gfx.direct2d.force-enabled<br />
<br />
You can also use built-in Firefox options to toggle hardware acceleration between the "None" and "All" states by (un)checking “Use hardware acceleration when available” in the Advanced section of the Preferences/Options dialog. Alternately, you can run Firefox in safe mode to disable hardware acceleration [http://blog.mozilla.com/joe/2010/09/15/testing-hardware-acceleration/]. When filing a bug related to hardware acceleration, please include the Graphics card information from '''about:support''' in your browser.<br />
<br />
== Tests: Initial First Round ==<br />
<br />
(humph) Let's refine this a bit more, such that we track:<br />
<br />
Name of Experiment | URL of Experiment | Your Name | Date of Test | Hardware Info | Browser Info | Firefox Performance - Speed | Firefox Performance - Smoothness | Firefox Performance - Responsiveness | Notes and other Details |<br />
<br />
{| border="1" cellpadding="5"<br />
! Test No. !! Name <br /> !! Results<br />
|-<br />
| 1-10 || [[User:cwdesautels|Carl]] || [[Firefox_Performance_Testing_Lab_Fall_2010_cwdesautels | Results]] <br />
|-<br />
| 11-20 || [[User:kclascon|Kevin Lasconia]] || [[Firefox_Performance_Testing_Lab_Fall_2010_kclascon | Results]] <br />
|-<br />
| 21-30 || [[User:ajcondinho | Andrew Condinho]] || [[Firefox_Performance_Testing_Lab_Fall_2010_ajcondinho | Results]] <br />
|-<br />
| 31-40 || [[User:sbologna|Stephen Bologna]] || [[Firefox_Performance_Testing_Lab_Fall_2010_sbologna | Results]]<br />
|-<br />
| 41-50 || [[User:kpangilinan|Kenneth Pangilinan]] || [[Firefox_Performance_Testing_Lab_Fall_2010_kpangilinan | Results]] <br />
|-<br />
| 51-60 || [[User:peleaning|Pete Leaning]] || [[Firefox_Performance_Testing_Lab_Fall_2010_peleaning | Results]] <br />
|-<br />
| 61-70 || [[User:blaw1|Brian Law]] || [[Firefox_Performance_Testing_Lab_Fall_2010_blaw1 | Results]] <br />
|-<br />
| 71-80 || [[User:sweerdenburg|Steven Weerdenburg]] || [[Firefox_Performance_Testing_Lab_Fall_2010_sweerdenburg | Results]] <br />
|-<br />
| 81-90 || [[User:jevangel|James Evangelista]] || [[Firefox_Performance_Testing_Lab_Fall_2010_jevangel | Results]] <br />
|-<br />
| 91-100 || [[User:dacallow|Kaitlyn Callow]] || [[Firefox_Performance_Testing_Lab_Fall_2010_dacallow| Results]] <br />
|-<br />
| 101-110 || [[User:cldenobrega|Crystal de Nobrega]] || [[Firefox_Performance_Testing_Lab_Fall_2010_cldenobrega | Results]]<br />
|-<br />
| 111-120 || [[User:cadecairos|Chris DeCairos]] || [[Firefox_Performance_Testing_Lab_Fall_2010_cadecairos | Results]] <br />
|-<br />
| 1-26 (Linux) || [[User:knovichikhi|Konstantin Novichikhin]] || [[Firefox_Performance_Testing_Lab_Fall_2010_knov | Results]] <br />
|}<br />
<br />
== Tests: Second Round ==<br />
<br />
For each experiment you tested as part of the first-round of testing that was not as fast or faster than Chrome, please create an entry in the table below. Include details about what you are seeing, what is failing, etc. Also, if you need to file a bug, include the link to the bug you filed.<br />
<br />
[https://developer.mozilla.org/En/Profiling_with_Xperf Link to Xperf Profiler]<br /><br />
[http://blogs.msdn.com/b/pigscanfly/archive/2009/08/06/stack-walking-in-xperf.aspx MSDN blog detailing how to use xperf results]<br />
<br />
{| border="1" cellpadding="5"<br />
! Test !! Tester !! Problem !! Additional Info <br /><br />
|-<br />
| [http://www.chromeexperiments.com/detail/lorenz-84/ Lorenz 84]<br />
|| [[User:sbologna|Stephen Bologna]]<br />
|| In the 32bit version of Minefield on Vista the browser froze for several seconds when the page loaded, and any attempt to interact with the test caused it to freeze again. In the 64bit version of Minefield on Window 7, the page took several minutes to load, and the image was not drawn properly.<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/google-sphere/ Google Sphere]<br />
|| [[User:sbologna|Stephen Bologna]]<br />
|| Overall look in Minefield is very sloppy compared to Chromium. When the 2d text gets close to the screen, it becomes less legible. It also runs slower on Minefield.<br />
|| Runs fine in Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/cheloniidae-live/ Cheloniidae Live] <br />
|| [[User:dacallow|Kaitlyn Callow]] <br />
|| Not running. <br />
|| Returning error:<br />
Error: console is not defined<br />
Source File: http://spencertipping.com/beta/cheloniidae-live-b1/script.js<br />
Line: 2<br />
|-<br />
<br />
<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/water-type/ Water Type] <br />
|| [[User:dacallow|Kaitlyn Callow]] <br />
|| MUCH SLOWER in Minefield on school computers. Speeds seems compairable to Chrome on my home computer. At school browser significantly slowed down while viewing this experiment.<br />
|| Not sure which is better, but Chrome looks more blurry or anti-aliased maybe then Mindfield.<br />
|-<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/plane-deformations/ Plane Deformations] <br />
|| [[User:dacallow|Kaitlyn Callow]] <br />
|| At school Mindfield is slower, 12fps vs Chrome at 20fps. At home running must faster in Mindfield, 50 fps (25 in Chrome).<br />
||<br />
|-<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/balldroppings/ BallDroppings]<br />
|| [[User:cwdesautels|Carl D]]<br />
|| far more audio clipping and visual chop when at a 'max' ball drop speed when compared to chrome<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/video-picture-puzzle/ VP Puzzle]<br />
|| [[User:cwdesautels|Carl D]]<br />
|| far greater delay generating picture puzzle windows<br />
|| Firefox was much faster and smoother then Chrome when creating the one video puzzle and its windows<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/liquid-particles/ Liquid Particles]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Minefield particle dot redraw very slow, manages approx 10 frames/sec. Chromium has no delay when rendering particle dot movement. Both have difficulty in letter rendering<br />
|| Investigation yields a [https://bugzilla.mozilla.org/show_bug.cgi?id=564643 duplicate]<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/animated-harmonograph/ Animated Harmonograph]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Image rendering much slower than on Chromium. Drawing of complex patterns on Minefield would sometimes cause centre to "wobble". CPU utilization seems (near) identical on both.<br />
|| Hardware acceleration makes no difference<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/browser-pong/ Browser Pong]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Minefield calculates the "ball" window height as twice that of Chromium<br />
|| <br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/realtime-video-ascii-conversion/ Realtime Video->ASCII Conversion]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Seems to have very difficult time at higher "resolutions" (smaller fonts). Scales up in canvas size ok, but becomes unresponsive over prolonged periods (5+ minutes) of use. Handles larger canvas with same resolution better than chrome at default settings.<br />
|| <br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/colorscube/ Colorscube]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| When the cube is rotated in any direction the animation is very choppy. There is also a delay between moving the mouse in one direction and the actual cube moving in that direction.<br />
|| Chrome was very smooth, and responsive. Filed a bug [https://bugzilla.mozilla.org/show_bug.cgi?id=599351 here].<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/monster/ Monster]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| In Firefox, when more complex objects are generated the spinning animation of the object becomes increasingly more choppy. During transformations the animation would freeze for a few seconds then continue.<br />
|| Found a bug about the same experiment [https://bugzilla.mozilla.org/show_bug.cgi?id=503470 here].<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/browser-ball/ Browser Ball]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| There is an issue when multiple windows are spawned in Firefox for this experiment. When moving the ball from the main window to another the ball will get stuck. Even when trying to "throw" the ball to another window it will still get stuck.<br />
|| In Chrome, the ball can actually be moved to and from new windows.<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/gravity/ Gravity]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| This experiment does not work in the Firefox/4.0b7pre nightly build.<br />
|| It works fine in Chrome. It also works in Firefox 3.6.10, however the objects cannot be dragged around like in Chrome. A bug filed [https://bugzilla.mozilla.org/show_bug.cgi?id=570922 here] outlines the dragging issues. Did some regression testing to determine the builds where the experiment worked and stopped working. Added some additional info to this bug [https://bugzilla.mozilla.org/show_bug.cgi?id=595541 here].<br />
|-<br />
<br />
<br />
| [http://www.thewildernessdowntown.com Wilderness Downtown]<br />
|| [[User:cadecairos |Chris DeCairos]]<br />
|| '''NEW''' Minefield crashes on my computer at the same point in the song every time! I have had it happen 3 times in a row, my first crash reprot was not sent but two others were. It happens after the first verse.<br />
|| see my first [http://crash-stats.mozilla.com/report/index/bp-e5ff5685-4816-4787-b8f0-25de02100921 crash report] and second [http://crash-stats.mozilla.com/report/index/bp-4c74c6af-2bd4-4e52-b8ac-65a402100921 crash report] '''Update''': I've reproduced it again got a [http://crash-stats.mozilla.com/report/index/49bba790-767f-4662-b83f-1ad092100921 third crash report] will file bug report once I know exactly what component this is crashing in.<br />
also, I would test it on Chrome nightly, but their current build still cannot play the video at all.<br />
Filed a [https://bugzilla.mozilla.org/show_bug.cgi?id=598498 Bug]<br />
|-<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/depth-of-field/ Depth of Field]<br />
|| [[User:kpangilinan |Kenneth Pangilinan]]<br />
|| Minefield freezes up PC for a few seconds before running. When attempting to move the window around, PC freezes up again.<br />
|| Experiment works fine in Chromium, moving the window around is fine as well.<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/3d-javascript-with-sandy-hx/ 3D JS w/ Sandy DX]<br />
|| [[User:kpangilinan |Kenneth Pangilinan]]<br />
|| Experiment did not load in Minefield or Chromium.<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/javascript-voxel-spacing/ JS Voxel Spacing]<br />
|| [[User:kpangilinan |Kenneth Pangilinan]]<br />
|| In Minefield it runs at 2-4FPS, in Chromium it runs at 22-24FPS, about 10 times faster!<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/gear/ Gear]<br />
|| [[User:blaw1 |Brian Law]]<br />
|| This experiment is very choppy in Minefield, whereas Chromium runs smoothly. In Minefield you can see arrows in the boxes which shouldn't be visible.<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/waterfall/ Waterfall]<br />
|| [[User:blaw1 |Brian Law]]<br />
|| Minefield quickly begins to lag as more balls enter the screen. Chromium will run smoothly for much longer.<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/pocket-full-of-canvas/ Pocket Full of Canvas]<br />
|| [[User:peleaning |Pete Leaning]]<br />
|| Minefield draws black triangles in the following effects in 'pocket full of canvas':<br />
Elipse, Colorrects, Mario, Colormunch, imagewaves, fire, wave(de)form and imagemagnifier. These artifacts are not present in Chromium<br />
||The two functions that seem to be responsible for this are renderTriangle() and drawImage<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/kaleidscope/ Kaleidscope]<br />
|| [[User:ajcondinho |Andrew Condinho]]<br />
|| Physical window becomes jerky and laggy whenever you re-size the window.<br />
|| Tested this out on my desktop and lag disappeared, looks like it might be an issue with lesser hardware<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/physicsketch/ physicSketch]<br />
|| [[User:ajcondinho |Andrew Condinho]]<br />
|| Objects don't draw, and after a few failed attempts experiment stops responding to any attempts to draw.<br />
|| Chrome has no problems running this experiment.<br />
|-<br />
<br />
|}<br />
<br />
==Bug Reports==<br />
<br />
'''NOTE:''' All bugs related to what we find should have '''[chromeexperiments]''' in the bug's Whiteboard field, so we can track them. The following Bugzilla search will list them all: <nowiki>https://bugzilla.mozilla.org/buglist.cgi?quicksearch=[chromeexperiments]</nowiki><br />
<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=596677 Sand Trap bug(dupe)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=595963 Open Sand Trap bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=596707 Sand Trap graphics bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=596746 Sand Trap painting perf bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=597186 Wilderness Downtown Canvas bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=598498 Wilderness Downtown Crash bug (xull.dll)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=598831 Liquid Particles perf bug (dupe)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=598834 Animated Harmonograph perf bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=598361 Pocket Full of Canvas triangle bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599210 Ball Dropping bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599236 Video->ASCII Conversion perf bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599318 Javascript Voxel Spacing bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599350 Gear bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599351 Colorscube bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=595541 Google Gravity bug (added additional info)]</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=Firefox_Performance_Testing_Lab_Fall_2010&diff=45828Firefox Performance Testing Lab Fall 20102010-09-24T17:47:30Z<p>Ajcondinho: /* Tests: Second Round */</p>
<hr />
<div>== Goal ==<br />
<br />
The goal of this lab is twofold. First, to provide students with a real-world experience of working collaboratively in an open community; and second, to work on a cutting-edge, but manageable project within the Mozilla community.<br />
<br />
== Objective ==<br />
<br />
To conduct A/B performance tests of the Chrome Experiments using nightly builds of both Firefox and Chrome, in order to identify performance bottlenecks in Firefox. Also, to profile and file bugs in order to fix these issues.<br />
<br />
== Method ==<br />
<br />
* As a group determine a method for dividing the Chrome Experiments so they all get tested<br />
* Install both the Firefox and Chrome nightly builds<br />
* Test each experiment in the two browsers, looking for various issues:<br />
** Speed - is Firefox as fast as Chrome at rendering the graphics?<br />
** Smoothness - are the graphics as smooth as in Chrome? Do you notice a lot of pauses, jerkiness, etc.?<br />
** Responsiveness - does Firefox remain responsive while you run the demo? Is it pegging your CPU(s)? <br />
* Record your findings, as well as browser and computer info ([about:support], [about:]) in the Results Spreadsheet.<br />
<br />
== Resources ==<br />
<br />
===Links===<br />
<br />
* [http://chromeexperiments.com Chrome Experiments]<br />
* [http://nightly.mozilla.org/ Firefox (i.e., Minefield) nightly builds]<br />
* [http://build.chromium.org/buildbot/snapshots/ Chrome (i.e., Chromium) nightly builds]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=594920 Example performance bug]<br />
<br />
===Misc Info===<br />
<br />
One of the questions that comes up a lot when filing these bugs, especially on Windows, is whether or not you have Direct2D (i.e., D2D) or Direct3D (D3D) enabled. The graphics system in Firefox has 3 states related to hardware acceleration:<br />
<br />
# no hardware acceleration<br />
# D3D but not D2D<br />
# All hardware acceleration<br />
<br />
You can control this using various preferences, which you can change by going to '''about:config''' (type this into your address bar and press enter):<br />
<br />
* D3D Layers Preferences<br />
** layers.accelerate-all<br />
** layers.accelerate-none<br />
* Font Rendering<br />
** gfx.font_rendering.directwrite.enabled<br />
* Direct2D<br />
** gfx.direct2d.force-enabled<br />
<br />
You can also use built-in Firefox options to toggle hardware acceleration between the "None" and "All" states by (un)checking “Use hardware acceleration when available” in the Advanced section of the Preferences/Options dialog. Alternately, you can run Firefox in safe mode to disable hardware acceleration [http://blog.mozilla.com/joe/2010/09/15/testing-hardware-acceleration/]. When filing a bug related to hardware acceleration, please include the Graphics card information from '''about:support''' in your browser.<br />
<br />
== Tests: Initial First Round ==<br />
<br />
(humph) Let's refine this a bit more, such that we track:<br />
<br />
Name of Experiment | URL of Experiment | Your Name | Date of Test | Hardware Info | Browser Info | Firefox Performance - Speed | Firefox Performance - Smoothness | Firefox Performance - Responsiveness | Notes and other Details |<br />
<br />
{| border="1" cellpadding="5"<br />
! Test No. !! Name <br /> !! Results<br />
|-<br />
| 1-10 || [[User:cwdesautels|Carl]] || [[Firefox_Performance_Testing_Lab_Fall_2010_cwdesautels | Results]] <br />
|-<br />
| 11-20 || [[User:kclascon|Kevin Lasconia]] || [[Firefox_Performance_Testing_Lab_Fall_2010_kclascon | Results]] <br />
|-<br />
| 21-30 || [[User:ajcondinho | Andrew Condinho]] || [[Firefox_Performance_Testing_Lab_Fall_2010_ajcondinho | Results]] <br />
|-<br />
| 31-40 || [[User:sbologna|Stephen Bologna]] || [[Firefox_Performance_Testing_Lab_Fall_2010_sbologna | Results]]<br />
|-<br />
| 41-50 || [[User:kpangilinan|Kenneth Pangilinan]] || [[Firefox_Performance_Testing_Lab_Fall_2010_kpangilinan | Results]] <br />
|-<br />
| 51-60 || [[User:peleaning|Pete Leaning]] || [[Firefox_Performance_Testing_Lab_Fall_2010_peleaning | Results]] <br />
|-<br />
| 61-70 || [[User:blaw1|Brian Law]] || [[Firefox_Performance_Testing_Lab_Fall_2010_blaw1 | Results]] <br />
|-<br />
| 71-80 || [[User:sweerdenburg|Steven Weerdenburg]] || [[Firefox_Performance_Testing_Lab_Fall_2010_sweerdenburg | Results]] <br />
|-<br />
| 81-90 || [[User:jevangel|James Evangelista]] || [[Firefox_Performance_Testing_Lab_Fall_2010_jevangel | Results]] <br />
|-<br />
| 91-100 || [[User:dacallow|Kaitlyn Callow]] || [[Firefox_Performance_Testing_Lab_Fall_2010_dacallow| Results]] <br />
|-<br />
| 101-110 || [[User:cldenobrega|Crystal de Nobrega]] || [[Firefox_Performance_Testing_Lab_Fall_2010_cldenobrega | Results]]<br />
|-<br />
| 111-120 || [[User:cadecairos|Chris DeCairos]] || [[Firefox_Performance_Testing_Lab_Fall_2010_cadecairos | Results]] <br />
|-<br />
| 1-26 (Linux) || [[User:knovichikhi|Konstantin Novichikhin]] || [[Firefox_Performance_Testing_Lab_Fall_2010_knov | Results]] <br />
|}<br />
<br />
== Tests: Second Round ==<br />
<br />
For each experiment you tested as part of the first-round of testing that was not as fast or faster than Chrome, please create an entry in the table below. Include details about what you are seeing, what is failing, etc. Also, if you need to file a bug, include the link to the bug you filed.<br />
<br />
[https://developer.mozilla.org/En/Profiling_with_Xperf Link to Xperf Profiler]<br /><br />
[http://blogs.msdn.com/b/pigscanfly/archive/2009/08/06/stack-walking-in-xperf.aspx MSDN blog detailing how to use xperf results]<br />
<br />
{| border="1" cellpadding="5"<br />
! Test !! Tester !! Problem !! Additional Info <br /><br />
|-<br />
| [http://www.chromeexperiments.com/detail/lorenz-84/ Lorenz 84]<br />
|| [[User:sbologna|Stephen Bologna]]<br />
|| In the 32bit version of Minefield on Vista the browser froze for several seconds when the page loaded, and any attempt to interact with the test caused it to freeze again. In the 64bit version of Minefield on Window 7, the page took several minutes to load, and the image was not drawn properly.<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/google-sphere/ Google Sphere]<br />
|| [[User:sbologna|Stephen Bologna]]<br />
|| Overall look in Minefield is very sloppy compared to Chromium. When the 2d text gets close to the screen, it becomes less legible. It also runs slower on Minefield.<br />
|| Runs fine in Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/cheloniidae-live/ Cheloniidae Live] <br />
|| [[User:dacallow|Kaitlyn Callow]] <br />
|| Not running. <br />
|| Returning error:<br />
Error: console is not defined<br />
Source File: http://spencertipping.com/beta/cheloniidae-live-b1/script.js<br />
Line: 2<br />
|-<br />
<br />
<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/water-type/ Water Type] <br />
|| [[User:dacallow|Kaitlyn Callow]] <br />
|| MUCH SLOWER in Minefield on school computers. Speeds seems compairable to Chrome on my home computer. At school browser significantly slowed down while viewing this experiment.<br />
|| Not sure which is better, but Chrome looks more blurry or anti-aliased maybe then Mindfield.<br />
|-<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/plane-deformations/ Plane Deformations] <br />
|| [[User:dacallow|Kaitlyn Callow]] <br />
|| At school Mindfield is slower, 12fps vs Chrome at 20fps. At home running must faster in Mindfield, 50 fps (25 in Chrome).<br />
||<br />
|-<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/balldroppings/ BallDroppings]<br />
|| [[User:cwdesautels|Carl D]]<br />
|| far more audio clipping and visual chop when at a 'max' ball drop speed when compared to chrome<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/video-picture-puzzle/ VP Puzzle]<br />
|| [[User:cwdesautels|Carl D]]<br />
|| far greater delay generating picture puzzle windows<br />
|| Firefox was much faster and smoother then Chrome when creating the one video puzzle and its windows<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/liquid-particles/ Liquid Particles]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Minefield particle dot redraw very slow, manages approx 10 frames/sec. Chromium has no delay when rendering particle dot movement. Both have difficulty in letter rendering<br />
|| Investigation yields a [https://bugzilla.mozilla.org/show_bug.cgi?id=564643 duplicate]<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/animated-harmonograph/ Animated Harmonograph]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Image rendering much slower than on Chromium. Drawing of complex patterns on Minefield would sometimes cause centre to "wobble". CPU utilization seems (near) identical on both.<br />
|| Hardware acceleration makes no difference<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/browser-pong/ Browser Pong]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Minefield calculates the "ball" window height as twice that of Chromium<br />
|| <br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/realtime-video-ascii-conversion/ Realtime Video->ASCII Conversion]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Seems to have very difficult time at higher "resolutions" (smaller fonts). Scales up in canvas size ok, but becomes unresponsive over prolonged periods (5+ minutes) of use. Handles larger canvas with same resolution better than chrome at default settings.<br />
|| <br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/colorscube/ Colorscube]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| When the cube is rotated in any direction the animation is very choppy. There is also a delay between moving the mouse in one direction and the actual cube moving in that direction.<br />
|| Chrome was very smooth, and responsive. Filed a bug [https://bugzilla.mozilla.org/show_bug.cgi?id=599351 here].<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/monster/ Monster]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| In Firefox, when more complex objects are generated the spinning animation of the object becomes increasingly more choppy. During transformations the animation would freeze for a few seconds then continue.<br />
|| Found a bug about the same experiment [https://bugzilla.mozilla.org/show_bug.cgi?id=503470 here].<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/browser-ball/ Browser Ball]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| There is an issue when multiple windows are spawned in Firefox for this experiment. When moving the ball from the main window to another the ball will get stuck. Even when trying to "throw" the ball to another window it will still get stuck.<br />
|| In Chrome, the ball can actually be moved to and from new windows.<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/gravity/ Gravity]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| This experiment does not work in the Firefox/4.0b7pre nightly build.<br />
|| It works fine in Chrome. It also works in Firefox 3.6.10, however the objects cannot be dragged around like in Chrome. A bug filed [https://bugzilla.mozilla.org/show_bug.cgi?id=570922 here] outlines the dragging issues. Did some regression testing to determine the builds where the experiment worked and stopped working. Added some additional info to this bug [https://bugzilla.mozilla.org/show_bug.cgi?id=595541 here].<br />
|-<br />
<br />
<br />
| [http://www.thewildernessdowntown.com Wilderness Downtown]<br />
|| [[User:cadecairos |Chris DeCairos]]<br />
|| '''NEW''' Minefield crashes on my computer at the same point in the song every time! I have had it happen 3 times in a row, my first crash reprot was not sent but two others were. It happens after the first verse.<br />
|| see my first [http://crash-stats.mozilla.com/report/index/bp-e5ff5685-4816-4787-b8f0-25de02100921 crash report] and second [http://crash-stats.mozilla.com/report/index/bp-4c74c6af-2bd4-4e52-b8ac-65a402100921 crash report] '''Update''': I've reproduced it again got a [http://crash-stats.mozilla.com/report/index/49bba790-767f-4662-b83f-1ad092100921 third crash report] will file bug report once I know exactly what component this is crashing in.<br />
also, I would test it on Chrome nightly, but their current build still cannot play the video at all.<br />
Filed a [https://bugzilla.mozilla.org/show_bug.cgi?id=598498 Bug]<br />
|-<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/depth-of-field/ Depth of Field]<br />
|| [[User:kpangilinan |Kenneth Pangilinan]]<br />
|| Minefield freezes up PC for a few seconds before running. When attempting to move the window around, PC freezes up again.<br />
|| Experiment works fine in Chromium, moving the window around is fine as well.<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/3d-javascript-with-sandy-hx/ 3D JS w/ Sandy DX]<br />
|| [[User:kpangilinan |Kenneth Pangilinan]]<br />
|| Experiment did not load in Minefield or Chromium.<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/javascript-voxel-spacing/ JS Voxel Spacing]<br />
|| [[User:kpangilinan |Kenneth Pangilinan]]<br />
|| In Minefield it runs at 2-4FPS, in Chromium it runs at 22-24FPS, about 10 times faster!<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/gear/ Gear]<br />
|| [[User:blaw1 |Brian Law]]<br />
|| This experiment is very choppy in Minefield, whereas Chromium runs smoothly. In Minefield you can see arrows in the boxes which shouldn't be visible.<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/waterfall/ Waterfall]<br />
|| [[User:blaw1 |Brian Law]]<br />
|| Minefield quickly begins to lag as more balls enter the screen. Chromium will run smoothly for much longer.<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/pocket-full-of-canvas/ Pocket Full of Canvas]<br />
|| [[User:peleaning |Pete Leaning]]<br />
|| Minefield draws black triangles in the following effects in 'pocket full of canvas':<br />
Elipse, Colorrects, Mario, Colormunch, imagewaves, fire, wave(de)form and imagemagnifier. These artifacts are not present in Chromium<br />
||The two functions that seem to be responsible for this are renderTriangle() and drawImage<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/kaleidscope/ Kaleidscope]<br />
|| [[User:ajcondinho |Andrew Condinho]]<br />
|| Physical window becomes jerky and laggy whenever you re-size the window.<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/physicsketch/ physicSketch]<br />
|| [[User:ajcondinho |Andrew Condinho]]<br />
|| Objects don't draw, and after a few failed attempts experiment stops responding to any attempts to draw.<br />
|| Chrome has no problems running this experiment.<br />
|-<br />
<br />
|}<br />
<br />
==Bug Reports==<br />
<br />
'''NOTE:''' All bugs related to what we find should have '''[chromeexperiments]''' in the bug's Whiteboard field, so we can track them. The following Bugzilla search will list them all: <nowiki>https://bugzilla.mozilla.org/buglist.cgi?quicksearch=[chromeexperiments]</nowiki><br />
<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=596677 Sand Trap bug(dupe)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=595963 Open Sand Trap bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=596707 Sand Trap graphics bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=596746 Sand Trap painting perf bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=597186 Wilderness Downtown Canvas bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=598498 Wilderness Downtown Crash bug (xull.dll)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=598831 Liquid Particles perf bug (dupe)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=598834 Animated Harmonograph perf bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=598361 Pocket Full of Canvas triangle bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599210 Ball Dropping bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599236 Video->ASCII Conversion perf bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599318 Javascript Voxel Spacing bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599350 Gear bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599351 Colorscube bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=595541 Google Gravity bug (added additional info)]</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=Firefox_Performance_Testing_Lab_Fall_2010&diff=45827Firefox Performance Testing Lab Fall 20102010-09-24T17:45:34Z<p>Ajcondinho: /* Tests: Second Round */</p>
<hr />
<div>== Goal ==<br />
<br />
The goal of this lab is twofold. First, to provide students with a real-world experience of working collaboratively in an open community; and second, to work on a cutting-edge, but manageable project within the Mozilla community.<br />
<br />
== Objective ==<br />
<br />
To conduct A/B performance tests of the Chrome Experiments using nightly builds of both Firefox and Chrome, in order to identify performance bottlenecks in Firefox. Also, to profile and file bugs in order to fix these issues.<br />
<br />
== Method ==<br />
<br />
* As a group determine a method for dividing the Chrome Experiments so they all get tested<br />
* Install both the Firefox and Chrome nightly builds<br />
* Test each experiment in the two browsers, looking for various issues:<br />
** Speed - is Firefox as fast as Chrome at rendering the graphics?<br />
** Smoothness - are the graphics as smooth as in Chrome? Do you notice a lot of pauses, jerkiness, etc.?<br />
** Responsiveness - does Firefox remain responsive while you run the demo? Is it pegging your CPU(s)? <br />
* Record your findings, as well as browser and computer info ([about:support], [about:]) in the Results Spreadsheet.<br />
<br />
== Resources ==<br />
<br />
===Links===<br />
<br />
* [http://chromeexperiments.com Chrome Experiments]<br />
* [http://nightly.mozilla.org/ Firefox (i.e., Minefield) nightly builds]<br />
* [http://build.chromium.org/buildbot/snapshots/ Chrome (i.e., Chromium) nightly builds]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=594920 Example performance bug]<br />
<br />
===Misc Info===<br />
<br />
One of the questions that comes up a lot when filing these bugs, especially on Windows, is whether or not you have Direct2D (i.e., D2D) or Direct3D (D3D) enabled. The graphics system in Firefox has 3 states related to hardware acceleration:<br />
<br />
# no hardware acceleration<br />
# D3D but not D2D<br />
# All hardware acceleration<br />
<br />
You can control this using various preferences, which you can change by going to '''about:config''' (type this into your address bar and press enter):<br />
<br />
* D3D Layers Preferences<br />
** layers.accelerate-all<br />
** layers.accelerate-none<br />
* Font Rendering<br />
** gfx.font_rendering.directwrite.enabled<br />
* Direct2D<br />
** gfx.direct2d.force-enabled<br />
<br />
You can also use built-in Firefox options to toggle hardware acceleration between the "None" and "All" states by (un)checking “Use hardware acceleration when available” in the Advanced section of the Preferences/Options dialog. Alternately, you can run Firefox in safe mode to disable hardware acceleration [http://blog.mozilla.com/joe/2010/09/15/testing-hardware-acceleration/]. When filing a bug related to hardware acceleration, please include the Graphics card information from '''about:support''' in your browser.<br />
<br />
== Tests: Initial First Round ==<br />
<br />
(humph) Let's refine this a bit more, such that we track:<br />
<br />
Name of Experiment | URL of Experiment | Your Name | Date of Test | Hardware Info | Browser Info | Firefox Performance - Speed | Firefox Performance - Smoothness | Firefox Performance - Responsiveness | Notes and other Details |<br />
<br />
{| border="1" cellpadding="5"<br />
! Test No. !! Name <br /> !! Results<br />
|-<br />
| 1-10 || [[User:cwdesautels|Carl]] || [[Firefox_Performance_Testing_Lab_Fall_2010_cwdesautels | Results]] <br />
|-<br />
| 11-20 || [[User:kclascon|Kevin Lasconia]] || [[Firefox_Performance_Testing_Lab_Fall_2010_kclascon | Results]] <br />
|-<br />
| 21-30 || [[User:ajcondinho | Andrew Condinho]] || [[Firefox_Performance_Testing_Lab_Fall_2010_ajcondinho | Results]] <br />
|-<br />
| 31-40 || [[User:sbologna|Stephen Bologna]] || [[Firefox_Performance_Testing_Lab_Fall_2010_sbologna | Results]]<br />
|-<br />
| 41-50 || [[User:kpangilinan|Kenneth Pangilinan]] || [[Firefox_Performance_Testing_Lab_Fall_2010_kpangilinan | Results]] <br />
|-<br />
| 51-60 || [[User:peleaning|Pete Leaning]] || [[Firefox_Performance_Testing_Lab_Fall_2010_peleaning | Results]] <br />
|-<br />
| 61-70 || [[User:blaw1|Brian Law]] || [[Firefox_Performance_Testing_Lab_Fall_2010_blaw1 | Results]] <br />
|-<br />
| 71-80 || [[User:sweerdenburg|Steven Weerdenburg]] || [[Firefox_Performance_Testing_Lab_Fall_2010_sweerdenburg | Results]] <br />
|-<br />
| 81-90 || [[User:jevangel|James Evangelista]] || [[Firefox_Performance_Testing_Lab_Fall_2010_jevangel | Results]] <br />
|-<br />
| 91-100 || [[User:dacallow|Kaitlyn Callow]] || [[Firefox_Performance_Testing_Lab_Fall_2010_dacallow| Results]] <br />
|-<br />
| 101-110 || [[User:cldenobrega|Crystal de Nobrega]] || [[Firefox_Performance_Testing_Lab_Fall_2010_cldenobrega | Results]]<br />
|-<br />
| 111-120 || [[User:cadecairos|Chris DeCairos]] || [[Firefox_Performance_Testing_Lab_Fall_2010_cadecairos | Results]] <br />
|-<br />
| 1-26 (Linux) || [[User:knovichikhi|Konstantin Novichikhin]] || [[Firefox_Performance_Testing_Lab_Fall_2010_knov | Results]] <br />
|}<br />
<br />
== Tests: Second Round ==<br />
<br />
For each experiment you tested as part of the first-round of testing that was not as fast or faster than Chrome, please create an entry in the table below. Include details about what you are seeing, what is failing, etc. Also, if you need to file a bug, include the link to the bug you filed.<br />
<br />
[https://developer.mozilla.org/En/Profiling_with_Xperf Link to Xperf Profiler]<br /><br />
[http://blogs.msdn.com/b/pigscanfly/archive/2009/08/06/stack-walking-in-xperf.aspx MSDN blog detailing how to use xperf results]<br />
<br />
{| border="1" cellpadding="5"<br />
! Test !! Tester !! Problem !! Additional Info <br /><br />
|-<br />
| [http://www.chromeexperiments.com/detail/lorenz-84/ Lorenz 84]<br />
|| [[User:sbologna|Stephen Bologna]]<br />
|| In the 32bit version of Minefield on Vista the browser froze for several seconds when the page loaded, and any attempt to interact with the test caused it to freeze again. In the 64bit version of Minefield on Window 7, the page took several minutes to load, and the image was not drawn properly.<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/google-sphere/ Google Sphere]<br />
|| [[User:sbologna|Stephen Bologna]]<br />
|| Overall look in Minefield is very sloppy compared to Chromium. When the 2d text gets close to the screen, it becomes less legible. It also runs slower on Minefield.<br />
|| Runs fine in Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/cheloniidae-live/ Cheloniidae Live] <br />
|| [[User:dacallow|Kaitlyn Callow]] <br />
|| Not running. <br />
|| Returning error:<br />
Error: console is not defined<br />
Source File: http://spencertipping.com/beta/cheloniidae-live-b1/script.js<br />
Line: 2<br />
|-<br />
<br />
<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/water-type/ Water Type] <br />
|| [[User:dacallow|Kaitlyn Callow]] <br />
|| MUCH SLOWER in Minefield on school computers. Speeds seems compairable to Chrome on my home computer. At school browser significantly slowed down while viewing this experiment.<br />
|| Not sure which is better, but Chrome looks more blurry or anti-aliased maybe then Mindfield.<br />
|-<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/plane-deformations/ Plane Deformations] <br />
|| [[User:dacallow|Kaitlyn Callow]] <br />
|| At school Mindfield is slower, 12fps vs Chrome at 20fps. At home running must faster in Mindfield, 50 fps (25 in Chrome).<br />
||<br />
|-<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/balldroppings/ BallDroppings]<br />
|| [[User:cwdesautels|Carl D]]<br />
|| far more audio clipping and visual chop when at a 'max' ball drop speed when compared to chrome<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/video-picture-puzzle/ VP Puzzle]<br />
|| [[User:cwdesautels|Carl D]]<br />
|| far greater delay generating picture puzzle windows<br />
|| Firefox was much faster and smoother then Chrome when creating the one video puzzle and its windows<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/liquid-particles/ Liquid Particles]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Minefield particle dot redraw very slow, manages approx 10 frames/sec. Chromium has no delay when rendering particle dot movement. Both have difficulty in letter rendering<br />
|| Investigation yields a [https://bugzilla.mozilla.org/show_bug.cgi?id=564643 duplicate]<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/animated-harmonograph/ Animated Harmonograph]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Image rendering much slower than on Chromium. Drawing of complex patterns on Minefield would sometimes cause centre to "wobble". CPU utilization seems (near) identical on both.<br />
|| Hardware acceleration makes no difference<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/browser-pong/ Browser Pong]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Minefield calculates the "ball" window height as twice that of Chromium<br />
|| <br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/realtime-video-ascii-conversion/ Realtime Video->ASCII Conversion]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Seems to have very difficult time at higher "resolutions" (smaller fonts). Scales up in canvas size ok, but becomes unresponsive over prolonged periods (5+ minutes) of use. Handles larger canvas with same resolution better than chrome at default settings.<br />
|| <br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/colorscube/ Colorscube]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| When the cube is rotated in any direction the animation is very choppy. There is also a delay between moving the mouse in one direction and the actual cube moving in that direction.<br />
|| Chrome was very smooth, and responsive. Filed a bug [https://bugzilla.mozilla.org/show_bug.cgi?id=599351 here].<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/monster/ Monster]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| In Firefox, when more complex objects are generated the spinning animation of the object becomes increasingly more choppy. During transformations the animation would freeze for a few seconds then continue.<br />
|| Found a bug about the same experiment [https://bugzilla.mozilla.org/show_bug.cgi?id=503470 here].<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/browser-ball/ Browser Ball]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| There is an issue when multiple windows are spawned in Firefox for this experiment. When moving the ball from the main window to another the ball will get stuck. Even when trying to "throw" the ball to another window it will still get stuck.<br />
|| In Chrome, the ball can actually be moved to and from new windows.<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/gravity/ Gravity]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| This experiment does not work in the Firefox/4.0b7pre nightly build.<br />
|| It works fine in Chrome. It also works in Firefox 3.6.10, however the objects cannot be dragged around like in Chrome. A bug filed [https://bugzilla.mozilla.org/show_bug.cgi?id=570922 here] outlines the dragging issues. Did some regression testing to determine the builds where the experiment worked and stopped working. Added some additional info to this bug [https://bugzilla.mozilla.org/show_bug.cgi?id=595541 here].<br />
|-<br />
<br />
<br />
| [http://www.thewildernessdowntown.com Wilderness Downtown]<br />
|| [[User:cadecairos |Chris DeCairos]]<br />
|| '''NEW''' Minefield crashes on my computer at the same point in the song every time! I have had it happen 3 times in a row, my first crash reprot was not sent but two others were. It happens after the first verse.<br />
|| see my first [http://crash-stats.mozilla.com/report/index/bp-e5ff5685-4816-4787-b8f0-25de02100921 crash report] and second [http://crash-stats.mozilla.com/report/index/bp-4c74c6af-2bd4-4e52-b8ac-65a402100921 crash report] '''Update''': I've reproduced it again got a [http://crash-stats.mozilla.com/report/index/49bba790-767f-4662-b83f-1ad092100921 third crash report] will file bug report once I know exactly what component this is crashing in.<br />
also, I would test it on Chrome nightly, but their current build still cannot play the video at all.<br />
Filed a [https://bugzilla.mozilla.org/show_bug.cgi?id=598498 Bug]<br />
|-<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/depth-of-field/ Depth of Field]<br />
|| [[User:kpangilinan |Kenneth Pangilinan]]<br />
|| Minefield freezes up PC for a few seconds before running. When attempting to move the window around, PC freezes up again.<br />
|| Experiment works fine in Chromium, moving the window around is fine as well.<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/3d-javascript-with-sandy-hx/ 3D JS w/ Sandy DX]<br />
|| [[User:kpangilinan |Kenneth Pangilinan]]<br />
|| Experiment did not load in Minefield or Chromium.<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/javascript-voxel-spacing/ JS Voxel Spacing]<br />
|| [[User:kpangilinan |Kenneth Pangilinan]]<br />
|| In Minefield it runs at 2-4FPS, in Chromium it runs at 22-24FPS, about 10 times faster!<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/gear/ Gear]<br />
|| [[User:blaw1 |Brian Law]]<br />
|| This experiment is very choppy in Minefield, whereas Chromium runs smoothly. In Minefield you can see arrows in the boxes which shouldn't be visible.<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/waterfall/ Waterfall]<br />
|| [[User:blaw1 |Brian Law]]<br />
|| Minefield quickly begins to lag as more balls enter the screen. Chromium will run smoothly for much longer.<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/pocket-full-of-canvas/ Pocket Full of Canvas]<br />
|| [[User:peleaning |Pete Leaning]]<br />
|| Minefield draws black triangles in the following effects in 'pocket full of canvas':<br />
Elipse, Colorrects, Mario, Colormunch, imagewaves, fire, wave(de)form and imagemagnifier. These artifacts are not present in Chromium<br />
||The two functions that seem to be responsible for this are renderTriangle() and drawImage<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/kaleidscope/ Kaleidscope]<br />
|| [[User:ajcondinho |Andrew Condinho]]<br />
|| Physical window becomes jerky and laggy whenever you re-size the window.<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/physicsketch/ physicSketch]<br />
|| [[User:ajcondinho |Andrew Condinho]]<br />
|| Objects don't draw, and after a few failed attempts experiment stops responding to any attempts to draw.<br />
||<br />
|-<br />
<br />
|}<br />
<br />
==Bug Reports==<br />
<br />
'''NOTE:''' All bugs related to what we find should have '''[chromeexperiments]''' in the bug's Whiteboard field, so we can track them. The following Bugzilla search will list them all: <nowiki>https://bugzilla.mozilla.org/buglist.cgi?quicksearch=[chromeexperiments]</nowiki><br />
<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=596677 Sand Trap bug(dupe)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=595963 Open Sand Trap bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=596707 Sand Trap graphics bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=596746 Sand Trap painting perf bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=597186 Wilderness Downtown Canvas bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=598498 Wilderness Downtown Crash bug (xull.dll)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=598831 Liquid Particles perf bug (dupe)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=598834 Animated Harmonograph perf bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=598361 Pocket Full of Canvas triangle bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599210 Ball Dropping bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599236 Video->ASCII Conversion perf bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599318 Javascript Voxel Spacing bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599350 Gear bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599351 Colorscube bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=595541 Google Gravity bug (added additional info)]</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=Firefox_Performance_Testing_Lab_Fall_2010&diff=45826Firefox Performance Testing Lab Fall 20102010-09-24T17:42:58Z<p>Ajcondinho: /* Tests: Second Round */</p>
<hr />
<div>== Goal ==<br />
<br />
The goal of this lab is twofold. First, to provide students with a real-world experience of working collaboratively in an open community; and second, to work on a cutting-edge, but manageable project within the Mozilla community.<br />
<br />
== Objective ==<br />
<br />
To conduct A/B performance tests of the Chrome Experiments using nightly builds of both Firefox and Chrome, in order to identify performance bottlenecks in Firefox. Also, to profile and file bugs in order to fix these issues.<br />
<br />
== Method ==<br />
<br />
* As a group determine a method for dividing the Chrome Experiments so they all get tested<br />
* Install both the Firefox and Chrome nightly builds<br />
* Test each experiment in the two browsers, looking for various issues:<br />
** Speed - is Firefox as fast as Chrome at rendering the graphics?<br />
** Smoothness - are the graphics as smooth as in Chrome? Do you notice a lot of pauses, jerkiness, etc.?<br />
** Responsiveness - does Firefox remain responsive while you run the demo? Is it pegging your CPU(s)? <br />
* Record your findings, as well as browser and computer info ([about:support], [about:]) in the Results Spreadsheet.<br />
<br />
== Resources ==<br />
<br />
===Links===<br />
<br />
* [http://chromeexperiments.com Chrome Experiments]<br />
* [http://nightly.mozilla.org/ Firefox (i.e., Minefield) nightly builds]<br />
* [http://build.chromium.org/buildbot/snapshots/ Chrome (i.e., Chromium) nightly builds]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=594920 Example performance bug]<br />
<br />
===Misc Info===<br />
<br />
One of the questions that comes up a lot when filing these bugs, especially on Windows, is whether or not you have Direct2D (i.e., D2D) or Direct3D (D3D) enabled. The graphics system in Firefox has 3 states related to hardware acceleration:<br />
<br />
# no hardware acceleration<br />
# D3D but not D2D<br />
# All hardware acceleration<br />
<br />
You can control this using various preferences, which you can change by going to '''about:config''' (type this into your address bar and press enter):<br />
<br />
* D3D Layers Preferences<br />
** layers.accelerate-all<br />
** layers.accelerate-none<br />
* Font Rendering<br />
** gfx.font_rendering.directwrite.enabled<br />
* Direct2D<br />
** gfx.direct2d.force-enabled<br />
<br />
You can also use built-in Firefox options to toggle hardware acceleration between the "None" and "All" states by (un)checking “Use hardware acceleration when available” in the Advanced section of the Preferences/Options dialog. Alternately, you can run Firefox in safe mode to disable hardware acceleration [http://blog.mozilla.com/joe/2010/09/15/testing-hardware-acceleration/]. When filing a bug related to hardware acceleration, please include the Graphics card information from '''about:support''' in your browser.<br />
<br />
== Tests: Initial First Round ==<br />
<br />
(humph) Let's refine this a bit more, such that we track:<br />
<br />
Name of Experiment | URL of Experiment | Your Name | Date of Test | Hardware Info | Browser Info | Firefox Performance - Speed | Firefox Performance - Smoothness | Firefox Performance - Responsiveness | Notes and other Details |<br />
<br />
{| border="1" cellpadding="5"<br />
! Test No. !! Name <br /> !! Results<br />
|-<br />
| 1-10 || [[User:cwdesautels|Carl]] || [[Firefox_Performance_Testing_Lab_Fall_2010_cwdesautels | Results]] <br />
|-<br />
| 11-20 || [[User:kclascon|Kevin Lasconia]] || [[Firefox_Performance_Testing_Lab_Fall_2010_kclascon | Results]] <br />
|-<br />
| 21-30 || [[User:ajcondinho | Andrew Condinho]] || [[Firefox_Performance_Testing_Lab_Fall_2010_ajcondinho | Results]] <br />
|-<br />
| 31-40 || [[User:sbologna|Stephen Bologna]] || [[Firefox_Performance_Testing_Lab_Fall_2010_sbologna | Results]]<br />
|-<br />
| 41-50 || [[User:kpangilinan|Kenneth Pangilinan]] || [[Firefox_Performance_Testing_Lab_Fall_2010_kpangilinan | Results]] <br />
|-<br />
| 51-60 || [[User:peleaning|Pete Leaning]] || [[Firefox_Performance_Testing_Lab_Fall_2010_peleaning | Results]] <br />
|-<br />
| 61-70 || [[User:blaw1|Brian Law]] || [[Firefox_Performance_Testing_Lab_Fall_2010_blaw1 | Results]] <br />
|-<br />
| 71-80 || [[User:sweerdenburg|Steven Weerdenburg]] || [[Firefox_Performance_Testing_Lab_Fall_2010_sweerdenburg | Results]] <br />
|-<br />
| 81-90 || [[User:jevangel|James Evangelista]] || [[Firefox_Performance_Testing_Lab_Fall_2010_jevangel | Results]] <br />
|-<br />
| 91-100 || [[User:dacallow|Kaitlyn Callow]] || [[Firefox_Performance_Testing_Lab_Fall_2010_dacallow| Results]] <br />
|-<br />
| 101-110 || [[User:cldenobrega|Crystal de Nobrega]] || [[Firefox_Performance_Testing_Lab_Fall_2010_cldenobrega | Results]]<br />
|-<br />
| 111-120 || [[User:cadecairos|Chris DeCairos]] || [[Firefox_Performance_Testing_Lab_Fall_2010_cadecairos | Results]] <br />
|-<br />
| 1-26 (Linux) || [[User:knovichikhi|Konstantin Novichikhin]] || [[Firefox_Performance_Testing_Lab_Fall_2010_knov | Results]] <br />
|}<br />
<br />
== Tests: Second Round ==<br />
<br />
For each experiment you tested as part of the first-round of testing that was not as fast or faster than Chrome, please create an entry in the table below. Include details about what you are seeing, what is failing, etc. Also, if you need to file a bug, include the link to the bug you filed.<br />
<br />
[https://developer.mozilla.org/En/Profiling_with_Xperf Link to Xperf Profiler]<br /><br />
[http://blogs.msdn.com/b/pigscanfly/archive/2009/08/06/stack-walking-in-xperf.aspx MSDN blog detailing how to use xperf results]<br />
<br />
{| border="1" cellpadding="5"<br />
! Test !! Tester !! Problem !! Additional Info <br /><br />
|-<br />
| [http://www.chromeexperiments.com/detail/lorenz-84/ Lorenz 84]<br />
|| [[User:sbologna|Stephen Bologna]]<br />
|| In the 32bit version of Minefield on Vista the browser froze for several seconds when the page loaded, and any attempt to interact with the test caused it to freeze again. In the 64bit version of Minefield on Window 7, the page took several minutes to load, and the image was not drawn properly.<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/google-sphere/ Google Sphere]<br />
|| [[User:sbologna|Stephen Bologna]]<br />
|| Overall look in Minefield is very sloppy compared to Chromium. When the 2d text gets close to the screen, it becomes less legible. It also runs slower on Minefield.<br />
|| Runs fine in Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/cheloniidae-live/ Cheloniidae Live] <br />
|| [[User:dacallow|Kaitlyn Callow]] <br />
|| Not running. <br />
|| Returning error:<br />
Error: console is not defined<br />
Source File: http://spencertipping.com/beta/cheloniidae-live-b1/script.js<br />
Line: 2<br />
|-<br />
<br />
<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/water-type/ Water Type] <br />
|| [[User:dacallow|Kaitlyn Callow]] <br />
|| MUCH SLOWER in Minefield on school computers. Speeds seems compairable to Chrome on my home computer. At school browser significantly slowed down while viewing this experiment.<br />
|| Not sure which is better, but Chrome looks more blurry or anti-aliased maybe then Mindfield.<br />
|-<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/plane-deformations/ Plane Deformations] <br />
|| [[User:dacallow|Kaitlyn Callow]] <br />
|| At school Mindfield is slower, 12fps vs Chrome at 20fps. At home running must faster in Mindfield, 50 fps (25 in Chrome).<br />
||<br />
|-<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/balldroppings/ BallDroppings]<br />
|| [[User:cwdesautels|Carl D]]<br />
|| far more audio clipping and visual chop when at a 'max' ball drop speed when compared to chrome<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/video-picture-puzzle/ VP Puzzle]<br />
|| [[User:cwdesautels|Carl D]]<br />
|| far greater delay generating picture puzzle windows<br />
|| Firefox was much faster and smoother then Chrome when creating the one video puzzle and its windows<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/liquid-particles/ Liquid Particles]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Minefield particle dot redraw very slow, manages approx 10 frames/sec. Chromium has no delay when rendering particle dot movement. Both have difficulty in letter rendering<br />
|| Investigation yields a [https://bugzilla.mozilla.org/show_bug.cgi?id=564643 duplicate]<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/animated-harmonograph/ Animated Harmonograph]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Image rendering much slower than on Chromium. Drawing of complex patterns on Minefield would sometimes cause centre to "wobble". CPU utilization seems (near) identical on both.<br />
|| Hardware acceleration makes no difference<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/browser-pong/ Browser Pong]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Minefield calculates the "ball" window height as twice that of Chromium<br />
|| <br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/realtime-video-ascii-conversion/ Realtime Video->ASCII Conversion]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Seems to have very difficult time at higher "resolutions" (smaller fonts). Scales up in canvas size ok, but becomes unresponsive over prolonged periods (5+ minutes) of use. Handles larger canvas with same resolution better than chrome at default settings.<br />
|| <br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/colorscube/ Colorscube]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| When the cube is rotated in any direction the animation is very choppy. There is also a delay between moving the mouse in one direction and the actual cube moving in that direction.<br />
|| Chrome was very smooth, and responsive. Filed a bug [https://bugzilla.mozilla.org/show_bug.cgi?id=599351 here].<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/monster/ Monster]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| In Firefox, when more complex objects are generated the spinning animation of the object becomes increasingly more choppy. During transformations the animation would freeze for a few seconds then continue.<br />
|| Found a bug about the same experiment [https://bugzilla.mozilla.org/show_bug.cgi?id=503470 here].<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/browser-ball/ Browser Ball]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| There is an issue when multiple windows are spawned in Firefox for this experiment. When moving the ball from the main window to another the ball will get stuck. Even when trying to "throw" the ball to another window it will still get stuck.<br />
|| In Chrome, the ball can actually be moved to and from new windows.<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/gravity/ Gravity]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| This experiment does not work in the Firefox/4.0b7pre nightly build.<br />
|| It works fine in Chrome. It also works in Firefox 3.6.10, however the objects cannot be dragged around like in Chrome. A bug filed [https://bugzilla.mozilla.org/show_bug.cgi?id=570922 here] outlines the dragging issues. Did some regression testing to determine the builds where the experiment worked and stopped working. Added some additional info to this bug [https://bugzilla.mozilla.org/show_bug.cgi?id=595541 here].<br />
|-<br />
<br />
<br />
| [http://www.thewildernessdowntown.com Wilderness Downtown]<br />
|| [[User:cadecairos |Chris DeCairos]]<br />
|| '''NEW''' Minefield crashes on my computer at the same point in the song every time! I have had it happen 3 times in a row, my first crash reprot was not sent but two others were. It happens after the first verse.<br />
|| see my first [http://crash-stats.mozilla.com/report/index/bp-e5ff5685-4816-4787-b8f0-25de02100921 crash report] and second [http://crash-stats.mozilla.com/report/index/bp-4c74c6af-2bd4-4e52-b8ac-65a402100921 crash report] '''Update''': I've reproduced it again got a [http://crash-stats.mozilla.com/report/index/49bba790-767f-4662-b83f-1ad092100921 third crash report] will file bug report once I know exactly what component this is crashing in.<br />
also, I would test it on Chrome nightly, but their current build still cannot play the video at all.<br />
Filed a [https://bugzilla.mozilla.org/show_bug.cgi?id=598498 Bug]<br />
|-<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/depth-of-field/ Depth of Field]<br />
|| [[User:kpangilinan |Kenneth Pangilinan]]<br />
|| Minefield freezes up PC for a few seconds before running. When attempting to move the window around, PC freezes up again.<br />
|| Experiment works fine in Chromium, moving the window around is fine as well.<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/3d-javascript-with-sandy-hx/ 3D JS w/ Sandy DX]<br />
|| [[User:kpangilinan |Kenneth Pangilinan]]<br />
|| Experiment did not load in Minefield or Chromium.<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/javascript-voxel-spacing/ JS Voxel Spacing]<br />
|| [[User:kpangilinan |Kenneth Pangilinan]]<br />
|| In Minefield it runs at 2-4FPS, in Chromium it runs at 22-24FPS, about 10 times faster!<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/gear/ Gear]<br />
|| [[User:blaw1 |Brian Law]]<br />
|| This experiment is very choppy in Minefield, whereas Chromium runs smoothly. In Minefield you can see arrows in the boxes which shouldn't be visible.<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/waterfall/ Waterfall]<br />
|| [[User:blaw1 |Brian Law]]<br />
|| Minefield quickly begins to lag as more balls enter the screen. Chromium will run smoothly for much longer.<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/pocket-full-of-canvas/ Pocket Full of Canvas]<br />
|| [[User:peleaning |Pete Leaning]]<br />
|| Minefield draws black triangles in the following effects in 'pocket full of canvas':<br />
Elipse, Colorrects, Mario, Colormunch, imagewaves, fire, wave(de)form and imagemagnifier. These artifacts are not present in Chromium<br />
||The two functions that seem to be responsible for this are renderTriangle() and drawImage<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/kaleidscope/ Kaleidscope]<br />
|| [[User:ajcondinho |Andrew Condinho]]<br />
|| Physical window becomes jerky and laggy whenever you re-size the window.<br />
||<br />
|-<br />
|}<br />
<br />
==Bug Reports==<br />
<br />
'''NOTE:''' All bugs related to what we find should have '''[chromeexperiments]''' in the bug's Whiteboard field, so we can track them. The following Bugzilla search will list them all: <nowiki>https://bugzilla.mozilla.org/buglist.cgi?quicksearch=[chromeexperiments]</nowiki><br />
<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=596677 Sand Trap bug(dupe)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=595963 Open Sand Trap bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=596707 Sand Trap graphics bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=596746 Sand Trap painting perf bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=597186 Wilderness Downtown Canvas bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=598498 Wilderness Downtown Crash bug (xull.dll)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=598831 Liquid Particles perf bug (dupe)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=598834 Animated Harmonograph perf bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=598361 Pocket Full of Canvas triangle bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599210 Ball Dropping bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599236 Video->ASCII Conversion perf bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599318 Javascript Voxel Spacing bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599350 Gear bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=599351 Colorscube bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=595541 Google Gravity bug (added additional info)]</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=Firefox_Performance_Testing_Lab_Fall_2010&diff=45320Firefox Performance Testing Lab Fall 20102010-09-21T17:18:35Z<p>Ajcondinho: /* Tests: Second Round */</p>
<hr />
<div>== Goal ==<br />
<br />
The goal of this lab is twofold. First, to provide students with a real-world experience of working collaboratively in an open community; and second, to work on a cutting-edge, but manageable project within the Mozilla community.<br />
<br />
== Objective ==<br />
<br />
To conduct A/B performance tests of the Chrome Experiments using nightly builds of both Firefox and Chrome, in order to identify performance bottlenecks in Firefox. Also, to profile and file bugs in order to fix these issues.<br />
<br />
== Method ==<br />
<br />
* As a group determine a method for dividing the Chrome Experiments so they all get tested<br />
* Install both the Firefox and Chrome nightly builds<br />
* Test each experiment in the two browsers, looking for various issues:<br />
** Speed - is Firefox as fast as Chrome at rendering the graphics?<br />
** Smoothness - are the graphics as smooth as in Chrome? Do you notice a lot of pauses, jerkiness, etc.?<br />
** Responsiveness - does Firefox remain responsive while you run the demo? Is it pegging your CPU(s)? <br />
* Record your findings, as well as browser and computer info ([about:support], [about:]) in the Results Spreadsheet.<br />
<br />
== Resources ==<br />
<br />
* [http://chromeexperiments.com Chrome Experiments]<br />
* [https://spreadsheets.google.com/ccc?key=0AgzO6h8d9PSsdHE0a2JmeEZWUHFOQm00ZTJLNElIZ2c&hl=en&pli=1#gid=0 Results Spreadsheet]. Talk to Dave to get permissions in order to edit.<br />
* [http://nightly.mozilla.org/ Firefox (i.e., Minefield) nightly builds]<br />
* [http://build.chromium.org/buildbot/snapshots/ Chrome (i.e., Chromium) nightly builds]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=594920 Example performance bug]<br />
<br />
<br />
== Tests: Initial First Round ==<br />
<br />
(humph) Let's refine this a bit more, such that we track:<br />
<br />
Name of Experiment | URL of Experiment | Your Name | Date of Test | Hardware Info | Browser Info | Firefox Performance - Speed | Firefox Performance - Smoothness | Firefox Performance - Responsiveness | Notes and other Details |<br />
<br />
{| border="1" cellpadding="5"<br />
! Test No. !! Name <br /> !! Results<br />
|-<br />
| 1-10 || [[User:cwdesautels|Carl]] || [[Firefox_Performance_Testing_Lab_Fall_2010_cwdesautels | Results]] <br />
|-<br />
| 11-20 || [[User:kclascon|Kevin Lasconia]] || [[Firefox_Performance_Testing_Lab_Fall_2010_kclascon | Results]] <br />
|-<br />
| 21-30 || [[User:ajcondinho | Andrew Condinho]] || [[Firefox_Performance_Testing_Lab_Fall_2010_ajcondinho | Results]] <br />
|-<br />
| 31-40 || [[User:sbologna|Stephen Bologna]] || [[Firefox_Performance_Testing_Lab_Fall_2010_sbologna | Results]]<br />
|-<br />
| 41-50 || [[User:kpangilinan|Kenneth Pangilinan]] || [[Firefox_Performance_Testing_Lab_Fall_2010_kpangilinan | Results]] <br />
|-<br />
| 51-60 || [[User:peleaning|Pete Leaning]] || [[Firefox_Performance_Testing_Lab_Fall_2010_peleaning | Results]] <br />
|-<br />
| 61-70 || [[User:blaw1|Brian Law]] || [[Firefox_Performance_Testing_Lab_Fall_2010_blaw1 | Results]] <br />
|-<br />
| 71-80 || [[User:sweerdenburg|Steven Weerdenburg]] || [[Firefox_Performance_Testing_Lab_Fall_2010_sweerdenburg | Results]] <br />
|-<br />
| 81-90 || [[User:jevangel|James Evangelista]] || [[Firefox_Performance_Testing_Lab_Fall_2010_jevangel | Results]] <br />
|-<br />
| 91-100 || [[User:dacallow|Kaitlyn Callow]] || [[Firefox_Performance_Testing_Lab_Fall_2010_dacallow| Results]] <br />
|-<br />
| 101-110 || [[User:cldenobrega|Crystal de Nobrega]] || [[Firefox_Performance_Testing_Lab_Fall_2010_cldenobrega | Results]]<br />
|-<br />
| 111-120 || [[User:cadecairos|Chris DeCairos]] || [[Firefox_Performance_Testing_Lab_Fall_2010_cadecairos | Results]] <br />
|-<br />
| 1-26 (Linux) || [[User:knovichikhi|Konstantin Novichikhin]] || [[Firefox_Performance_Testing_Lab_Fall_2010_knov | Results]] <br />
|}<br />
<br />
== Tests: Second Round ==<br />
<br />
For each experiment you tested as part of the first-round of testing that was not as fast or faster than Chrome, please create an entry in the table below. Include details about what you are seeing, what is failing, etc. Also, if you need to file a bug, include the link to the bug you filed.<br />
<br />
[https://developer.mozilla.org/En/Profiling_with_Xperf Link to Xperf Profiler]<br />
<br />
{| border="1" cellpadding="5"<br />
! Test !! Tester !! Problem !! Additional Info <br /><br />
|-<br />
| [http://www.chromeexperiments.com/detail/lorenz-84/ Lorenz 84] || [[User:sbologna|Stephen Bologna]] || In the 32bit version of Minefield on Vista the browser froze for several seconds when the page loaded, and any attempt to interact with the test caused it to freeze again. In the 64bit version of Minefield on Window 7, the page took several minutes to load, and the image was not drawn properly.||<br />
<br />
<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/cheloniidae-live/ Cheloniidae Live] <br />
|| [[User:dacallow|Kaitlyn Callow]] <br />
|| Not running. <br />
|| Returning error:<br />
Error: console is not defined<br />
Source File: http://spencertipping.com/beta/cheloniidae-live-b1/script.js<br />
Line: 2<br />
|-<br />
<br />
<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/water-type/ Water Type] <br />
|| [[User:dacallow|Kaitlyn Callow]] <br />
|| MUCH SLOWER in Minefield on school computers. Speeds seems compairable to Chrome on my home computer. At school browser significantly slowed down while viewing this experiment.<br />
|| Not sure which is better, but Chrome looks more blurry or anti-aliased maybe then Mindfield.<br />
|-<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/plane-deformations/ Plane Deformations] <br />
|| [[User:dacallow|Kaitlyn Callow]] <br />
|| At school Mindfield is slower, 12fps vs Chrome at 20fps. At home running must faster in Mindfield, 50 fps (25 in Chrome).<br />
||<br />
|-<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/balldroppings/ BallDroppings]<br />
|| [[User:cwdesautels|Carl D]]<br />
|| far more audio clipping and visual chop when at a 'max' ball drop speed when compared to chrome<br />
||<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/video-picture-puzzle/ VP Puzzle]<br />
|| [[User:cwdesautels|Carl D]]<br />
|| far greater delay generating picture puzzle windows<br />
|| Firefox was much faster and smoother then Chrome when creating the one video puzzle and its windows<br />
|-<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/ball-pool/ Ball Pool]<br />
|| [[User:cwdesautels|Carl D]]<br />
|| Choppy at 50+% ball saturation when moving the window <br />
|| Chromes breakpoint was far later<br />
|-<br />
<br />
<br />
| [http://www.chromeexperiments.com/detail/chromedrones/ ChromeDrones]<br />
|| [[User:cwdesautels|Carl D]]<br />
|| Video and Audio chop when 8+ notes were introduced<br />
|| <br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/liquid-particles/ Liquid Particles]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Minefield particle dot redraw very slow, manages approx 10 frames/sec<br />
|| Chromium has no delay when rendering particle dot movement. Both have difficulty in letter rendering<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/browser-pong/ Browser Pong]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Minefield calculates the "ball" window height as twice that of Chromium<br />
|| <br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/realtime-video-ascii-conversion/ Realtime Video->ASCII Conversion]<br />
|| [[User:Sweerdenburg |Steven Weerdenburg]]<br />
|| Seems to have very difficult time at higher "resolutions" (smaller fonts). Scales up in canvas size ok, but becomes unresponsive over prolonged periods (5+ minutes) of use.<br />
|| <br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/colorscube/ Colorscube]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| When the cube is rotated in any direction the animation is very choppy. There is also a delay between moving the mouse in one direction and the actual cube moving in that direction.<br />
|| Chrome was very smooth, and responsive.<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/monster/ Monster]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| In Firefox, when more complex objects are generated the spinning animation of the object becomes increasingly more choppy. During transformations the animation would freeze for a few seconds then continue.<br />
|| Chrome did not experience any of the outlined problems above.<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/browser-ball/ Browser Ball]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| There is an issue when multiple windows are spawned in Firefox for this experiment. When moving the ball from the main window to another the ball will get stuck. Even when trying to "throw" the ball to another window it will still get stuck.<br />
|| In Chrome, the ball can actually be moved to and from new windows.<br />
|-<br />
<br />
| [http://www.chromeexperiments.com/detail/gravity/ Gravity]<br />
|| [[User:Kclascon |Kevin Lasconia]]<br />
|| This experiment does not work in the Mozilla/5.0 (Windows NT 6.0; WOW64; rv:2.0b7pre) Gecko/20100916 Firefox/4.0b7pre nightly build.<br />
|| It works fine in Chrome. It also works in Firefox 3.6.10.<br />
|-<br />
|}<br />
<br />
==Bug Reports==<br />
<br />
'''NOTE:''' All bugs related to what we find should have '''[chromeexperiments]''' in the bug's Whiteboard field, so we can track them. The following Bugzilla search will list them all: <nowiki>https://bugzilla.mozilla.org/buglist.cgi?quicksearch=[chromeexperiments]</nowiki><br />
<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=596677 Sand Trap bug(dupe)]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=595963 Open Sand Trap bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=596707 Sand Trap graphics bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=596746 Sand Trap painting perf bug]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=597186 Wilderness Downtown Canvas bug]</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=Firefox_Performance_Testing_Lab_Fall_2010_ajcondinho&diff=44791Firefox Performance Testing Lab Fall 2010 ajcondinho2010-09-16T18:04:27Z<p>Ajcondinho: /* Test Notes */</p>
<hr />
<div>==Test Results (ajcondinho)==<br />
<br />
[[Firefox_Performance_Testing_Lab_Fall_2010 | '''Go back to lab page''']]<br />
<br />
==Hardware Info==<br />
*Adapter Description: ATI Mobility Radeon HD 4570 <br />
*Vendor ID: 1002<br />
*Device ID: 9553<br />
*Adapter RAM: 512MB<br />
*Adapter Drivers: ATI Technologies Inc.<br />
*Driver Version: 8.673.0.0<br />
*Driver Date: 11/10/2009<br />
*Direct2D Enabled: Enabled<br />
*DirectWrite Enabled: Enabled<br />
*GPU Accelerated Windows: Yes<br />
<br />
==Firefox Build Info==<br />
<br />
Mozilla/5.0 (Windows NT 6.1; rv:2.0b7pre) Gecko/20100916 Firefox/4.0b7pre<br />
<br />
==Chromium Build Info==<br />
Chromium<br />
7.0.527.0 (Developer Build 59649)<br />
<br />
==Test Notes==<br />
{| border="1" cellpadding="5"<br />
!Name & URL !! Tester !! Date !! Firefox Performance - Speed !! Firefox Performance - Smoothness !! Firefox Performance - Responsiveness !! Notes and other Details<br />
|-<br />
| [http://www.chromeexperiments.com/detail/bomomo/ Bomomo] || Andrew || 9/16/2010 || CPU was sitting at approximately 50%, and showed no signs of lag. || Visual components all seem to flow seamlessly. || Using the first drawing tool the balls seem to be a bit behind on mouse movements. || When tried out on Chrome, CPU use rose to 70% at idle, and a lot of lag occurred, Firefox seems to outperform Chrome on this experiment.<br />
|-<br />
| [http://www.chromeexperiments.com/detail/kaleidscope/ Kaleidscope] || Andrew || 9/16/2010 || CPU usage varied from 30-50% constantly. || Ran smoothly, no jittery jumps. || Might be a bug, the actual window seems to jerk around while trying to re-size. || Chrome performed almost identically minus the re-sizing issue. <br />
|-<br />
| [http://www.chromeexperiments.com/detail/vizeddit/ Vizeddit] || Andrew || 9/16/2010 || CPU sat at around 50%. || The Reddit alien seemed to stutter a bit on the way down. || As far as I could tell this experiment doesn't actually allow you to do anything. || Chrome seemed to use 10-20% less CPU.<br />
|-<br />
| [http://www.chromeexperiments.com/detail/chiptunecom-gui/ Amiga Workbench Emulator] || Andrew || 9/16/2010 || See Responsiveness. || See Responsiveness. || This experiment re-creates an old operating system, but upon "loading" it internally crashes, so I cannot actually test this one. || Chrome loaded it and ran the experiment fine.<br />
|-<br />
| [http://www.chromeexperiments.com/detail/wavy-scrollbars/ Wavy Scrollbars] || Andrew || 9/16/2010 || Experiment not available for Firefox. || Experiment not available for Firefox. || Experiment not available for Firefox. || Runs smoothly in Chrome.<br />
|-<br />
| [http://www.chromeexperiments.com/detail/javascript-canvas-raytracer/ Javascript Canvas Raytracer] || Andrew || 9/16/2010 || CPU was stable at 50%. || This is a rendering experiment, so it took time to render it, so the image appeared slowly. || Experiment responded quickly. || Chrome ran just as fast.<br />
|-<br />
| [http://www.chromeexperiments.com/detail/notcanvas/ NotCanvas] || Andrew || 9/16/2010 || Doesn't seem to be an actual experiment just shows results from pre-rendered drawings. || Doesn't seem to be an actual experiment just shows results from pre-rendered drawings. || Doesn't seem to be an actual experiment just shows results from pre-rendered drawings. || Same in Chrome<br />
|-<br />
| [http://www.chromeexperiments.com/detail/internetris/ Internetris] || Andrew || 9/16/2010 || Low CPU usage (20%) || Very smooth for Tetris. || All controls were very responsive. || Chrome ran exactly the same.<br />
|-<br />
| [http://www.chromeexperiments.com/detail/starfield/ Starfield] || Andrew || 9/16/2010 || CPU sat at 50% || Very smooth. || Very responsive to mouse clicks. || Chrome used up 20% more CPU.<br />
|-<br />
| [http://www.chromeexperiments.com/detail/physicsketch/ physicSketch] || Andrew || 9/16/2010 || CPU sat at 50% || Animations were very smooth. || I encountered a problem when some of my drawings stopped showing up and I could not longer draw on the screen. It also seems to carry not allow me to draw anymore even if I reload the window, not sure if this is a problem on just my system. || Did not get this error in Chrome.<br />
|}</div>Ajcondinhohttps://wiki.cdot.senecacollege.ca/w/index.php?title=Firefox_Performance_Testing_Lab_Fall_2010_ajcondinho&diff=44790Firefox Performance Testing Lab Fall 2010 ajcondinho2010-09-16T17:59:01Z<p>Ajcondinho: /* Test Notes */</p>
<hr />
<div>==Test Results (ajcondinho)==<br />
<br />
[[Firefox_Performance_Testing_Lab_Fall_2010 | '''Go back to lab page''']]<br />
<br />
==Hardware Info==<br />
*Adapter Description: ATI Mobility Radeon HD 4570 <br />
*Vendor ID: 1002<br />
*Device ID: 9553<br />
*Adapter RAM: 512MB<br />
*Adapter Drivers: ATI Technologies Inc.<br />
*Driver Version: 8.673.0.0<br />
*Driver Date: 11/10/2009<br />
*Direct2D Enabled: Enabled<br />
*DirectWrite Enabled: Enabled<br />
*GPU Accelerated Windows: Yes<br />
<br />
==Firefox Build Info==<br />
<br />
Mozilla/5.0 (Windows NT 6.1; rv:2.0b7pre) Gecko/20100916 Firefox/4.0b7pre<br />
<br />
==Chromium Build Info==<br />
Chromium<br />
7.0.527.0 (Developer Build 59649)<br />
<br />
==Test Notes==<br />
{| border="1" cellpadding="5"<br />
!Name & URL !! Tester !! Date !! Firefox Performance - Speed !! Firefox Performance - Smoothness !! Firefox Performance - Responsiveness !! Notes and other Details<br />
|-<br />
| [http://www.chromeexperiments.com/detail/bomomo/ Bomomo] || Andrew || 9/16/2010 || CPU was sitting at approximately 50%, and showed no signs of lag. || Visual components all seem to flow seamlessly. || Using the first drawing tool the balls seem to be a bit behind on mouse movements. || When tried out on Chrome, CPU use rose to 70% at idle, and a lot of lag occurred, Firefox seems to outperform Chrome on this experiment.<br />
|-<br />
| [http://www.chromeexperiments.com/detail/kaleidscope/ Kaleidscope] || Andrew || 9/16/2010 || CPU usage varied from 30-50% constantly. || Ran smoothly, no jittery jumps. || Might be a bug, the actual window seems to jerk around while trying to re-size. || Chrome performed almost identically minus the re-sizing issue. <br />
|-<br />
| [http://www.chromeexperiments.com/detail/vizeddit/ Vizeddit] || Andrew || 9/16/2010 || CPU sat at around 50%. || The Reddit alien seemed to stutter a bit on the way down. || As far as I could tell this experiment doesn't actually allow you to do anything. || Chrome seemed to use 10-20% less CPU.<br />
|-<br />
| [http://www.chromeexperiments.com/detail/chiptunecom-gui/ Amiga Workbench Emulator] || Andrew || 9/16/2010 || See Responsiveness. || See Responsiveness. || This experiment re-creates an old operating system, but upon "loading" it internally crashes, so I cannot actually test this one. || Chrome loaded it and ran the experiment fine.<br />
|-<br />
| [http://www.chromeexperiments.com/detail/wavy-scrollbars/ Wavy Scrollbars] || Andrew || 9/16/2010 || Experiment not available for Firefox. || Experiment not available for Firefox. || Experiment not available for Firefox. || Runs smoothly in Chrome.<br />
|-<br />
| [http://www.chromeexperiments.com/detail/javascript-canvas-raytracer/ Javascript Canvas Raytracer] || Andrew || 9/16/2010 || CPU was stable at 50%. || This is a rendering experiment, so it took time to render it, so the image appeared slowly. || Experiment responded quickly. || Chrome ran just as fast.<br />
|-<br />
| [http://www.chromeexperiments.com/detail/notcanvas/ NotCanvas] || Andrew || 9/16/2010 || Doesn't seem to be an actual experiment just shows results from pre-rendered drawings. || Doesn't seem to be an actual experiment just shows results from pre-rendered drawings. || Doesn't seem to be an actual experiment just shows results from pre-rendered drawings. || Same in Chrome<br />
|-<br />
| [http://www.chromeexperiments.com/detail/internetris/ Internetris] || Andrew || 9/16/2010 || Low CPU usage (20%) || Very smooth for Tetris. || All controls were very responsive. || Chrome ran exactly the same.<br />
|-<br />
| [http://www.chromeexperiments.com/detail/starfield/ Starfield] || Andrew || 9/16/2010 || CPU sat at 50% || Very smooth. || Very responsive to mouse clicks. || Chrome used up 20% more CPU.<br />
|-<br />
| [http://www.chromeexperiments.com/detail/physicsketch/ physicSketch] || Andrew || - || - || - || - || -<br />
|}</div>Ajcondinho