1 BAB V ANALISIS V.1 Analisis Grafik Analisis Grafik dilakukan dalam upaya membandingkan delay dari kelima buah skenario grafik yang telah dibuat sebe...
V.1 Analisis Grafik Analisis Grafik dilakukan dalam upaya membandingkan delay dari kelima buah skenario grafik yang telah dibuat sebelumnya. Analisis performance grafik dilakukan untuk mencari berapa delay rata-rata dari setiap skenario penggunaan resource grafik yang dibuat. Tujuannya adalah untuk mencari skenario terbaik untuk menggunakan interface grafik BREW. Skenario yang digunakan adalah: 1. penggambaran di seluruh bagian layar dengan file jpg; 2. penggambaran tile-per-tile di seluruh bagian layar; 3. penggambaran file jpg ditambah tile-per-tile; 4. penggambaran satu tile tiap kesempatan; 5. penggambaran
empat
tile
sekaligus
dalam
satu
kesempatan.
81
Berikut adalah tabel hasil pengukuran dan grafiknya: Skenario 1: Tabel 5. 1 Percobaan Skenario 1
Percobaan
Skenario 1
1
16
2
16
3
16
4
16
5
16
6
15
7
16
8
16
9
15
10
15
11
16
12
16
13
16
14
15
15
15
Rata-rata
15.67
82
Gambar 5. 1 Grafik Pengukuran Skenario 1.
Skenario pertama adalah mengukur berapa lama delay untuk menggambar satu buah gambar format jpg secara full screen. Terlihat bahwa rata-rata waktu yang dibutuhkan adalah sebesar 15.67 ms.
83
Skenario 2: Tabel 5. 2 Percobaan Skenario 2
Percobaan
Skenario 2
1
31
2
31
3
32
4
31
5
31
6
31
7
31
8
32
9
31
10
31
11
32
12
31
13
32
14
31
15
31
Rata-rata
31.27
84
Gambar 5. 2 Grafik Pengukuran Skenario 2.
Skenario kedua dilakukan untuk mengukur berapa lama delay penggambaran tile satu per satu sehingga memenuhi layar. Terlihat bahwa rata-rata delay penggambaran adalah sebesar 31.27 ms.
85
Skenario 3: Tabel 5. 3 Percobaan Skenario 3
Percobaan
Skenario 3
1
47
2
47
3
47
4
46
5
46
6
47
7
47
8
47
9
47
10
47
11
47
12
47
13
47
14
47
15
47
Rata-rata
46.87
86
Gambar 5. 3 Grafik Pengukuran Skenario 2.
Skenario ketiga adalah dengan menggabungkan skenario pertama dan kedua. Awalnya program menggambar satu buah image jpg secara full screen. Lalu program menggambar lagi tile satu per satu di atasnya. Hasil rata-rata adalah sebesar 46.87 ms.
87
Skenario 4: Tabel 5. 4 Percobaan Skenario 4
Percobaan
Skenario 4
1
0
2
0
3
0
4
0
5
0
6
16
7
0
8
0
9
0
10
0
11
0
12
0
13
0
14
16
15
0
Rata-rata
2.13
88
Gambar 5. 4 Grafik Pengukuran Skenario 4.
Skenario keempat adalah dengan menggambar hanya pada bagian yang perlu di-update dalam permainan. Dalam percobaan ini, ukuran tile adalah 11x11 piksel. Terlihat bahwa rata-rata delay penggambaran adalah 2.13 ms. Dalam 15 kali percobaan, terdapat dua kali hasil menunjukkan perhitungan sebesar 16 ms. Hal ini disebabkan karena perhitungan dilakukan sebelum menggambar single tile tersebut. Perhitungan yang dilakukan adalah untuk mencari posisi baru sprite. Dalam waktu-waktu tertentu perhitungan dapat mengalami stagnasi sementara karena program hanya akan melanjutkan ke proses berikutnya jika telah mendapatkan posisi yang baik (free tile). Ketika perhitungan yang didapatkan tidak memberikan posisi free tile, maka program akan menghitung ulang. Itulah yang mengakibatkan terjadinya delay 16 ms dalam skenario keempat ini.
89
Skenario 5: Tabel 5. 5 Percobaan Skenario 5
Percobaan
Skenario 5
1
0
2
0
3
0
4
16
5
0
6
0
7
0
8
16
9
0
10
0
11
0
12
15
13
0
14
0
15
0
Rata-rata
3.13
90
Gambar 5. 5 Grafik Pengukuran Skenario 5.
Skenario
terakhir
pada
dasarnya
sama
dengan
skenario
keempat.
Perbedaannya adalah bahwa percobaan dilakukan pada algoritma pergerakan enemy, di mana ada empat buah tile yang harus di-update. Pengukuran menunjukkan rata-rata delay
sebesar 3.13 ms. Dalam percobaan terlihat
bahwa delay 15-16 ms terlhat juga seperti pada skenario keempat. Hal ini terjadi karena skenario kelima pada dasarnya adalah skenario keempat yang dilakukan berulang selama empat kali. Di dalamnya disisipkan proses untuk menghitung posisi random dari musuh. Ketika mengalami stagnasi maka delay akan menjadi 15-16 ms.
91
Gambar 5. 6 Perbandingan Kelima Skenario.
Gambar 5. 7 Perbandingan Rata-rata Skenario.
Dari gambar di atas terlihat bahwa delay terbesar ada pada skenario ketiga yang menggabungkan penggambaran full-screen dan satu per satu tile. Delay terkecil adalah pada skenario keempat di mana penggambaran hanya dilakukan ketika ada tile yang ingin di-update. Hasil analisis adalah bahwa cara terbaik untuk meng-update gambar dalam BREW adalah dengan memprosesnya per tile saja. Hanya gambar yang ingin di-update yang diproses. Untuk meng-update tile tersebut, program harus 92
menginisiasi window layar yang ingin di-update (default adalah seluruh layar), menghapus gambar, menggambar ulang lalu melakukan update layar hanya pada window tersebut.
V.2 Analisis Networking Analisis Networking dilakukan terhadap performance mode permainan network jika timer callback-nya diubah-ubah. Performance yang dicari adalah seberapa besar pengaruh perubahan timer callback terhadap delay pengiriman data melalui socket, dan juga sampai seberapa kecil timer callback dapat ditangani oleh engine game tersebut. Analisis performance jaringan dilakukan untuk mencari tahu berapa milisekon timercallback minimum yang dapat ditangani game BREW agar tidak mengalami error dalam pengiriman. Metoda dilakukan dengan cara mencoba beberapa nilai timercallback (1000, 800, 600, 500, 400, 300, 200, 100, 80, 60 dan 40 ms). Hasil yang dicari adalah berapa nilai delay (pengiriman sampai penerimaan) untuk setiap timercallback.
93
Berikut adalah grafik hasil pengukuran performance networking game:
Gambar 5. 8 Grafik Delay Pengiriman Data.
94
Berikut adalah tabel hasil pengujian performance networking game: Tabel 5. 6 Pengukuran Delay Networking
Percobaan
Lama Timer
Delay Rata-rata
1
1000
94.00
2
800
98.83
3
600
124.80
4
500
124.86
5
400
143.00
6
300
156.29
7
200
146.80
8
100
200.80
9
80
194.18
10
60
0
11
40
0
Grafik menunjukkan bahwa penurunan lama timer callback tidak terlalu mempengaruhi lama delay pengiriman data. Namun penurunan lama timer callback cenderung sedikit menaikkan delay pengiriman. Kecenderungan ini diakibatkan karena lama timer callback yang lebih kecil memaksa socket untuk bekerja lebih keras (hampir terjadi congestion karena semakin banyak data yang terkumpul di buffer, maka pengiriman akan semakin lambat). Pada percobaan ke-10 dan ke-11 simulator mengalami error. Hal ini disebabkan karena terlalu singkatnya timercallback yang diberikan. Socket belum siap mengirimkan data lagi namun ketika dipaksakan untuk dikirim maka program akan mengalami crash. Data dapat terkumpul dalam socket sebelum sempat dikirim. Akibatnya, data yang terkumpul melebihi buffer yang disediakan. Meluapnya data ini akan membuat server menutup koneksi dan client akan mengenalinya sebagai kesalahan.
95
Hasil pecobaan terakhir ini menunjukkan bahwa timer callback minimum yang dapat dibebankan kepada program adalah sebesar 60 ms. Ketika program dipaksakan untuk melakukan callback di bawah itu maka ia akan mengalami crash.
