BAB V ANALISIS. V.1 Analisis Grafik

Transkripsi

1 BAB V ANALISIS 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

2 Berikut adalah tabel hasil pengukuran dan grafiknya: Skenario 1: Tabel 5. 1 Percobaan Skenario 1 Percobaan Skenario Rata-rata

3 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 ms. 83

4 Skenario 2: Tabel 5. 2 Percobaan Skenario 2 Percobaan Skenario Rata-rata

5 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 ms. 85

6 Skenario 3: Tabel 5. 3 Percobaan Skenario 3 Percobaan Skenario Rata-rata

7 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 ms. 87

8 Skenario 4: Tabel 5. 4 Percobaan Skenario 4 Percobaan Skenario Rata-rata

9 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

10 Skenario 5: Tabel 5. 5 Percobaan Skenario 5 Percobaan Skenario Rata-rata

11 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 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 ms. 91

12 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

13 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

14 Berikut adalah grafik hasil pengukuran performance networking game: Gambar 5. 8 Grafik Delay Pengiriman Data. 94

15 Berikut adalah tabel hasil pengujian performance networking game: Tabel 5. 6 Pengukuran Delay Networking Percobaan Lama Timer Delay Rata-rata 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

16 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. 96