Saturday, February 8, 2020
Lab 4 Update
Not much progress on the lab, we got the screen to change when up and down is pressed but it isn't exactly what the lab specified.
Monday, February 3, 2020
Lab 4 progress
Today we started lab 4. We started on the form entry selection, but later determined that the colour selection option was actually easier, and someone in our group started on that instead.
It was also sort of nice to see ROM routines, which meant that there was less work in a way.
It was also sort of nice to see ROM routines, which meant that there was less work in a way.
Saturday, February 1, 2020
Lab 3 Completed
1. Introduction
This lab is more complex compared to lab 2. We had 5 different choices, and our group choose option 3 which was pong. We only completed the first part, which was just pong, but we didn't complete the breakout game portion of the code.
2. Writing Code Results
You can check out the completed code here. This code basically has the same logic a cpp version of this program, keeping track of x and y axis, and randomly generating the angles and speed. An additional feature is a score counter which displays at game over.
One particular problem I found interesting was the logic to keep track of the score. The problem was that to keep track of the score, which was the number of times that the paddle hit the ball, you would think to just have a something to keep track of the paddle as it contacted the ball. The problem is, you can record it, but at something like 60 frames per second, which would mean that the score would be around 60 extra points each time the ball contacted the paddle.
Basically the solution to that was to keep track of 2 flags, one keeping track of the the time the ball was in contact with the paddle, and another flag keeping track of when it wasn't in contact with the paddle. When the variable touching the ball and the paddle was not 1, and the flag that kept track of the variable indicated that the paddle and ball were not together, that would mean you can add 1 to the score.
3. My Experiences
Getting the logic to make the pong even in a game like cpp was a bit of a chore for me. When I got the basic logic for a cpp program, the next step was to convert that logic into assembly. After referencing some code snippets, after a lot of work, our group made a working copy of pong. The main reference to make our code was the etch a sketch code (Check it out here!.) A big thing I noticed was that although we used that code as reference, our group didn't use much of it.
This lab is more complex compared to lab 2. We had 5 different choices, and our group choose option 3 which was pong. We only completed the first part, which was just pong, but we didn't complete the breakout game portion of the code.
2. Writing Code Results
You can check out the completed code here. This code basically has the same logic a cpp version of this program, keeping track of x and y axis, and randomly generating the angles and speed. An additional feature is a score counter which displays at game over.
One particular problem I found interesting was the logic to keep track of the score. The problem was that to keep track of the score, which was the number of times that the paddle hit the ball, you would think to just have a something to keep track of the paddle as it contacted the ball. The problem is, you can record it, but at something like 60 frames per second, which would mean that the score would be around 60 extra points each time the ball contacted the paddle.
Basically the solution to that was to keep track of 2 flags, one keeping track of the the time the ball was in contact with the paddle, and another flag keeping track of when it wasn't in contact with the paddle. When the variable touching the ball and the paddle was not 1, and the flag that kept track of the variable indicated that the paddle and ball were not together, that would mean you can add 1 to the score.
3. My Experiences
Getting the logic to make the pong even in a game like cpp was a bit of a chore for me. When I got the basic logic for a cpp program, the next step was to convert that logic into assembly. After referencing some code snippets, after a lot of work, our group made a working copy of pong. The main reference to make our code was the etch a sketch code (Check it out here!.) A big thing I noticed was that although we used that code as reference, our group didn't use much of it.
Friday, January 31, 2020
Lab 2 Completed
1. Introduction:
This lab is to blog the results of SPO600's lab 2 class. The aim of the bitmap portion of the lab was to observe the changes of the display each time. The aim of the coding portion of the lab was to take the bit display area of the emulator first colour the top of the screen with a green line and the bottom with a blue line. The next part of the lab is to write a yellow line on the left side of the screen and a purple line down the right.
2. Bitmap Code Results
Step 6: Sets 16 different colours vertically.
Step 7: made it shift by smaller blocks.
Step 7: less blocks.
Step 7: now the screen is divided by 2 each line.
Step 9: Different colours.
Step 9: Smaller colour bars.
Step 9: Less colours, only 2.
Step 9: Appears to have been in a different memory region.
Step 13: It's all yellow and black.
Step 13: It loaded it in a grid pattern.
Step 13: It loaded it with more black then yellow.
Step 13: It loaded it like when the 3rd time (grid).
3. Writing Code Portion Results
You can look at the completed code here. This code is pretty straightforward, 3 loops colouring the top, bottom and side.
4. My Experiences
This lab showed me how different this language is from higher level programming courses. The biggest difference I noticed was that each command usually referred to an address and I had to use 3 areas of memories which I can treat or think of as a type of variable. Writing the coding portion of the lab was also really difficult, as I had to adjust my way of thinking to assembly styled programming.
This lab is to blog the results of SPO600's lab 2 class. The aim of the bitmap portion of the lab was to observe the changes of the display each time. The aim of the coding portion of the lab was to take the bit display area of the emulator first colour the top of the screen with a green line and the bottom with a blue line. The next part of the lab is to write a yellow line on the left side of the screen and a purple line down the right.
2. Bitmap Code Results
Step 6: Sets 16 different colours vertically.
Step 7: made it shift by smaller blocks.
Step 7: less blocks.
Step 7: now the screen is divided by 2 each line.
Step 9: Different colours.
Step 9: Smaller colour bars.
Step 9: Less colours, only 2.
Step 9: Appears to have been in a different memory region.
Step 13: It's all yellow and black.
Step 13: It loaded it in a grid pattern.
Step 13: It loaded it with more black then yellow.
Step 13: It loaded it like when the 3rd time (grid).
3. Writing Code Portion Results
You can look at the completed code here. This code is pretty straightforward, 3 loops colouring the top, bottom and side.
4. My Experiences
This lab showed me how different this language is from higher level programming courses. The biggest difference I noticed was that each command usually referred to an address and I had to use 3 areas of memories which I can treat or think of as a type of variable. Writing the coding portion of the lab was also really difficult, as I had to adjust my way of thinking to assembly styled programming.
Wednesday, January 15, 2020
Lab 1
Mozilla Firefox
Firefox wants 2 main types of contributions to their codebase. Fixing pet peeve, and fixing a bug. After
you’ve written your contribution, you use Phabricator to submit your code to a reviewer you select. Once
it is reviewed, you would make the changes recommended by the reviewer, and tried on their ‘try server.’
If it passed all of their automated testing, it gets merged into their main branch
(https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction).
you’ve written your contribution, you use Phabricator to submit your code to a reviewer you select. Once
it is reviewed, you would make the changes recommended by the reviewer, and tried on their ‘try server.’
If it passed all of their automated testing, it gets merged into their main branch
(https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction).
React JS
Contribution on React happens on GitHub. All changes from team members and external contributors
can send pull requests, and they have the same review process according to React’s website
(https://reactjs.org/docs/how-to-contribute.html). React apparently uses Semantic versioning, which
according to https://semver.org/ is a versioning process designed to avoid ‘dependency hell.’ All code is
to be submitted on the master branch, where it will be reviewed. Experimental and breaking changes are
gated on the master branch on a feature flag, and patch fixes are released for critical bug fixes, minor
bug fixes, and major versions.
can send pull requests, and they have the same review process according to React’s website
(https://reactjs.org/docs/how-to-contribute.html). React apparently uses Semantic versioning, which
according to https://semver.org/ is a versioning process designed to avoid ‘dependency hell.’ All code is
to be submitted on the master branch, where it will be reviewed. Experimental and breaking changes are
gated on the master branch on a feature flag, and patch fixes are released for critical bug fixes, minor
bug fixes, and major versions.
Tuesday, January 14, 2020
Lab 2 in class
Yesterday in class we attempted to do lab 2 in class. We got as far as creating the top line in the display then we had to end the class. We then organized how to exchange information and went home.
Thursday, January 9, 2020
Subscribe to:
Posts (Atom)