WEBVTT 00:00.150 --> 00:00.660 Hello again! 00:01.020 --> 00:03.680 In this video, we are going to add bricks to our game. 00:04.620 --> 00:08.130 We are going to have a grid of bricks at the top of the screen. 00:08.880 --> 00:13.860 We are going to leave a gap at each side of the grid, and at the top, so the pool can get around here, 00:13.860 --> 00:15.780 which will make the game more interesting. 00:17.280 --> 00:24.600 The gap at the top is equal to the height of one brick. And the gap at the left is equal to the width 00:24.600 --> 00:26.880 of one brick, plus some offset. 00:27.840 --> 00:30.450 And this is just really something I found by experimenting. 00:30.810 --> 00:35.040 There is no deep calculation or scientific process behind this. 00:36.750 --> 00:40.530 We are going to implement this, using a vector of sprite objects. 00:41.220 --> 00:45.030 Normally games programmers avoid using the C++ Standard Library. 00:45.900 --> 00:51.100 The reason is that a lot of operations involve memory allocation and deallocation. 00:51.600 --> 00:56.190 So that means that you do not have a way of predicting how long an operation is going to take. 00:56.610 --> 00:59.910 And also you can lose control of how much memory the program is using. 01:01.050 --> 01:07.770 The other problem is that the debug implementation can be very slow compared to the release implementation 01:07.770 --> 01:09.030 of the standard library. 01:09.510 --> 01:11.580 Sometimes 10 or 20 times longer. 01:12.570 --> 01:17.220 If you have a bug in a game which only appears after you have been playing for 5 minutes and you are 01:17.220 --> 01:21.690 running it in the debugger, then it could easily take over an hour before the bug actually appears. 01:22.260 --> 01:23.820 And that is just not acceptable. 01:25.410 --> 01:29.790 However, in this project, we are not trying to come up with a production-quality game. 01:30.210 --> 01:36.660 We are trying to demonstrate some C++11 features. And using a vector is better for that, than using 01:36.900 --> 01:37.710 the built-in array. 01:38.130 --> 01:41.080 Although we could use the library array as a kind of compromise. 01:41.100 --> 01:41.640 I suppose. 01:44.170 --> 01:48.880 We need to work out how to find the coordinates of each brick. 01:49.630 --> 01:55.000 We are going to be using the origin, which is the top left hand corner of each of these bricks. For this 01:55.000 --> 01:55.300 brick, 01:55.930 --> 02:02.170 the "y" coordinate is going to be the height of the brick, because we are one height below the top 02:02.170 --> 02:02.680 of the screen. 02:03.400 --> 02:08.950 The "x" coordinate will be the offset plus the width, because that is how far we are from the left hand 02:08.950 --> 02:09.700 edge of the screen. 02:11.230 --> 02:16.140 When we go to the next brick on the right, that is going to be one width further away. 02:16.450 --> 02:19.360 So the "x" coordinate will be offset plus two times the width. 02:19.960 --> 02:25.450 And then as we go across this row, we keep adding the width to the "x" coordinate. 02:26.440 --> 02:31.450 And similarly, as we go down the column, we add the height to the "y" coordinate. 02:31.900 --> 02:38.050 So these have "y" equals height, these have "y" equals two times height, and then the next row has "y" 02:38.050 --> 02:40.030 equals three times height. And so on. 02:41.490 --> 02:46.380 We add some constants for the brick width and height, and the offset. 02:47.280 --> 02:51.390 We also need to know the number of columns, and the number of rows in our grid. 02:53.340 --> 02:59.640 We have a brick class which inherits from entity. Not a moving_entity, because the bricks do not move. 03:00.420 --> 03:02.160 And this should all look very familiar. 03:03.600 --> 03:04.860 And the source file. 03:05.370 --> 03:10.230 We load up the brick image, but the rest of is very similar to the background, actually. 03:10.650 --> 03:13.440 In the main coach we include the header. 03:15.170 --> 03:17.840 Then we have our vector of brick objects. 03:18.830 --> 03:24.990 We iterate over the columns and the rows of this grid, and then we calculate the coordinates. 03:25.610 --> 03:30.680 So the "x" coordinate is going to be the brick offset, plus the brick width, [times] the number of bricks 03:31.220 --> 03:37.550 and the "y" coordinates is going to be the brick height, plus the number of rose times the height of a brick. 03:38.810 --> 03:40.370 And then we use emplace_back(). 03:40.760 --> 03:47.000 So this is a C++11 feature which will create the object, directly in this vector, without any copying. 03:51.890 --> 03:52.730 In the game loop. 03:52.730 --> 03:57.950 We update the bricks. Which is not going to actually do anything, but we are being consistent with the 03:57.980 --> 03:58.520 background. 03:59.810 --> 04:06.680 We use a range-for loop, another C++11 feature, and we make the loop variable a reference, 04:06.680 --> 04:10.040 because in theory we could modify the brick objects. 04:11.740 --> 04:16.120 And then we use another range-for loop to display the bricks in the window. 04:16.870 --> 04:19.180 This time we do not need to use a reference. 04:19.480 --> 04:20.350 We can just copy them. 04:20.740 --> 04:24.220 Or we could perhaps use a reference to const, if you want to be more efficient. 04:27.780 --> 04:28.290 And there you are. 04:28.470 --> 04:33.540 So we can see that the pool can go above the bricks, and 04:35.340 --> 04:43.020 also to the side. So we can interact with the paddle, but not with with the bricks just yet, and we are going to 04:43.020 --> 04:44.100 do that in the next video. 04:44.610 --> 04:45.540 But that is all for this one. 04:45.720 --> 04:46.530 I will see you next time. 04:46.530 --> 04:48.990 But until next time, keep coding!