Sebagai seorang penggiat game engine dan belakang ini banyak yang membahas tentang bahasa safety dan tidak safety. Apakah sebaiknya kita bergerak megikuti arus, atau berenang melawan arus? Tentunya jawabannya ada pada diri kita masing-masing. Seperti sebuah percobaan yang dilakukan baru-baru ini, beliau mencoba menggunakan bumbu andalan yang acapkali dingunakan pada berbagai masakan, yaitu bumbu kuning. Tapi apakah hasilnya dapat diterima seperti biasa? Ternyata rasanya seperti gesper atau ikat pinggang, berikut video lengkap nya yang dapat anda saksikan:
Dapat kita lihat, tidak semunya cocok menggunakan bumbu kuning, terutama kulit buaya.
Berangkat dari situ, akhirnya saya coba-coba koding Windows API dan kemudian terciptalah sebuah aplikasi untuk mengunci volume, dan di samping itu, aplikasi ini juga terinspirasi dari https://github.com/troylar/quiet-on-the-set.
Setelah aplikasi ini "jadi" saya lihat-lihat memang secara tampilan aplikasi ini jauh lebih simpel, tapi ukuranya hanya 17kb jika di build ke versi 32bit dan 20kb jika di build ke versi 64bit. Dari aplikasi-aplikasi yang beredar di pasaran pun nampaknya ini yang paling kecil, tapi jika mengunakan icon maka ukuranya akan bertambah 5kb.
Kelebihannya jika kita menggunaakn icon seperti ini:
Nah jika ingin lebih menghemat memori, icon-nya bisa tidak kita gunakan dan nantinya akan menghemat 5kb, cuman paling minus nya karna gak ada icon-nya jadinya transparan dan agak ngawang-ngawang.
Aplikasi ini saya coba rekam dan memang sewaktu aplikasi OBS merekam audio-nya gak ada sangkut paut nya dengan level volume device saya, jadinya ya tidak berpengaruh kerena yang direkam bukan master volume dari device saya, jadi mau di mute juga masih ada suaranya, namun pastinya jika kita coba di device kita masing-masing ya level suara nya sesuai dengan level volume nya. Dan kalo icon-nya gak dipake hasilnya seperti ini:
Setelah beberapa minggu memikirkan nama dari blog ini sekaligus github-nya, akhirnya saya menemukan nama yang tepat, yaitu rendertree. Nama ini terinspirasi dari nama kanal youtube ini:
Oke sekian saja dari saya, jadi inti dari tulisan ini bertujuan untuk mengingatkan saya jika suatu hari nanti saya bertanya kenapa saya memberi nama rendertree, dan sepertinya ini sudah bagus dan gak usah ganti-ganti lagi.
Pada suatu ketika ada sebuah kejadian unik yang saya alami, jadi pada waktu itu saya ingin membuat objek yang di alokasikan ketika terdeteksi oleh kamera dan jika tidak terdeteksi objek itu dihapus.
Nah, jadi pada waktu itu objek nya saya buat jangan banyak-banyak dulu, maksimal 4 lah. Jadi ukuran array nya 4, jadi yang unik disini adalah: kan ada 4 objek, nah yang 2 aman, yang 2 lainya, bermasalah, padahal setiap objek diperlakukan dengan perlakuan yang sama. Seperti ini kejadianya:
Tapi sebenarnya solusinya simpel, cuman yang sedikit unik ya kenapa hal itu bisa terjadi, terlepas apapun penyebabnya, kok bisa kaya gitu. Setelah semuanya selesai diperbaiki maka aplikasinya bisa kita lihat seperti ini:
Jadi aplikasi di atas mendemostrasikan bagaimana skema pengalokasian memori ketika objek terdeteksi kamera, kita dapat melihat jumlah objek, ukuran heap, dan jumlah vertices. Dan physics body itu adalah member variable dari objek persegi tersebut, persegi kan vertex nya ada 4? Nah, jadi itu vertices total setotal-totalnya, jadi misal objeknya ada 4, berarti 4 x 4.
Saya juga baru-baru ini melihat seorang indie game developer asal swedia yang memiliki kesamaan dengan proyek ini, yaitu menggunakan raylib dalam membuat game sekaligus engine-nya. Dia membagikan konsep yang sangat menarik dalam menyelesaikan persoalan manajemen memori yang kompleks untuk mengatur objek yang jumlahnya sangat banyak seperti ini:
Sedangkan pada proyek open source yang saya buat, yaitu pada contoh repository ini:
Digunakan untuk mengatasi masalah FPS drop ketika objek yang memiliki physics body jumlahnya terlalu banyak. Jadi untuk saat ini masalah itu bisa di atasi sesimpel dengan mengalokasikan objek yang memiliki physics body hanya pada saat terlihat oleh kemera. Sedangkan untuk objek seperti koin, sejauh ini masih sangat hemat memory dan bahkan tidak berpengaruh terhadapat CPU komputer modern, seperti ini:
Tapi sayangnya untuk saat ini mekanisme pengalokasian memory itu masih perlu dikembangkan lagi, supaya objek dengan physics body yang tampil pada kamera nantinya dapat lebih banyak lagi.
