cegui

Sistem GUI Crazy Eddie Mk-2

http://www.cegui.org.uk

Hak Cipta © 2004 - 2022 Paul D Turner, Tim Pengembangan Cegui dan Penulis yang Berkontribusi

Mayoritas file tambahan untuk CEGUI, yang dulunya teks biasa, sekarang disimpan dalam format "doxygenised" dalam direktori DOC/DOXYGEN - silakan lihat file -file tersebut, atau menghasilkan dokumentasi untuk format yang lebih ramah. Atau, kunjungi http://static.cegui.org.uk/docs untuk semua kebutuhan dokumentasi Anda!

Berikut ini hanyalah panduan awal yang cepat, pergi ke dokumen doxygen kami untuk dokumentasi yang lebih rinci.

Cabang dan versi yang tersedia

• Repositori CEGUI terdiri dari banyak cabang:
  • v0-8 memberikan versi CEGUI ABI yang kompatibel dengan ABI (hingga 0,8.x). Berdasarkan standar C ++ 03 dan kompatibel dengan kompiler yang paling umum, termasuk Visual Studio 2008-2015. Karena cabang ini kompatibel dengan ABI, dimungkinkan untuk menggantikan perpustakaan dinamis Cegui versi 0.8.x dengan versi 0.8.x yang lebih baru, atau sebaliknya, tanpa harus mengkompilasi ulang proyek. Cabang ini juga merupakan basis untuk rilis 0.8.x baru.
  • v0 menyediakan versi CEGUI yang kompatibel dengan API stabil terbaru dan berisi perubahan yang merusak ABI. Berdasarkan standar C ++ 03 dan kompatibel dengan kompiler yang paling umum, termasuk Visual Studio 2008-2015. Versi dari cabang ini akan digunakan untuk rilis versi minor berikutnya.
  • default berisi perubahan yang hanya akan digunakan dalam versi utama berikutnya. Berdasarkan standar C ++ 11 dan kompatibel dengan kompiler terkini yang paling umum, termasuk Visual Studio 2013 atau yang lebih baru. Cabang ini sangat tidak stabil, akan memperkenalkan perubahan mendasar dan merusak kompatibilitas ABI dan API . Kami tidak merekomendasikan Anda untuk menggunakan ini dalam produksi, kecuali Anda sangat bergantung pada fitur dan membahas ini dengan pengembang Cegui sebelumnya: ini disarankan sehingga Anda mengetahui semua risiko potensial. Dalam kasus umum Anda disarankan untuk menggunakan salah satu cabang yang stabil, untuk menyelamatkan Anda dari banyak sakit kepala.

Cabang v0-8 dan v0 dianggap stabil tetapi harus menjalani perbaikan serangga dan perubahan kecil, yang masing-masing tidak merusak ABI dan API. Perubahan ini tentu saja memperkenalkan risiko kecil bahwa mungkin ada masalah sementara untuk saat ini di cabang. Jika Anda melihat ada bug di cabang -cabang itu, silakan laporkan kepada kami sesegera mungkin - gunakan forum dan/atau saluran IRC kami #cegui dan #cegui-devel di irc.freenode.net untuk memberi tahu kami. Harap pertimbangkan bahwa kami tidak tersedia pada IRC 24 jam per hari, tetapi jangan ragu untuk menganggur di sana sampai kami merespons. Jika ragu cabang mana yang akan digunakan, jangan ragu untuk bertanya dengan cara ini. Untuk penggunaan produksi, kami biasanya merekomendasikan untuk menggunakan versi rilis yang stabil. Daftar rilis dapat ditemukan di situs web kami.

Berkontribusi

Kami paling bahagia dengan permintaan tarikan bersih yang berisi komitmen konskis dengan pesan komit yang tepat . Kami juga menerima tambalan biasa tetapi memudahkan kami untuk hanya menerima kontribusi Anda dengan satu klik dengan cepat mempercepat proses peninjauan.

Berikut adalah penjelasan tentang cara mendapatkan garpu dari repositori kami, melakukan perubahan pada garpu Anda, dan membuat permintaan tarik yang menargetkan cabang kanan: https://confluence.atlassian.com/display/bitbucket/fork+a+repo,+compare+code ,+ dan+create+Pull+request-request-request-request-request-request.

Harap juga perlu diingat untuk menargetkan repositori yang tepat. Kami lebih suka menargetkan cabang yang kompatibel dengan ABI jika memungkinkan. Kalau tidak, API yang kompatibel. Untuk informasi tentang kompatibilitas ABI/API, silakan baca halaman ini: https://community.kde.org/policies/binary_compatibility_issues_with_c%2b%2b

Jika ragu -ragu cabang mana yang akan ditargetkan, silakan hubungi kami!

Membangun Cegui

Script berikut lebih atau kurang universal untuk sistem dan Windows *nix. Perubahan kecil mungkin diperlukan.

 cd $cegui_folder
# you can call the folder differently but "build" is customary
mkdir build/
cd build/
# run the configure step
cmake-gui ../
# fix any issues pointed out by cmake
# not all dependencies are required so if some are not found, don't panic and carry on!
# alternative (if you are a command line pro)
# cmake ../

Pada titik ini, makefile, file proyek atau sesuatu yang lain akan dihasilkan. Langkah selanjutnya tergantung pada mana itu.

Untuk makefile, jalankan saja

 cd $cegui_folder
cd build/
make

Untuk solusi Visual Studio, klik ganda, ubah mode build sesuai (rilis, debug, ...) dan tekan build.

Menginstal Cegui

Bagian ini hanya masuk akal pada sistem seperti *Nix.

Pastikan Anda memiliki cmake_install_prefix yang benar diatur pada waktu konfigurasi. Alternativelly rerun cmake dan atur. Secara default seharusnya /usr/local/ tetapi Anda mungkin ingin /usr/ .

 cd $cegui_folder
cd build/
sudo make install

Menjalankan sampel cegui

Jika Anda menginstal CEGUI System-wide, hubungi:

CEGUISampleFramework-0

Jika lebih disukai untuk memanggilnya dari baris perintah karena akan meminta Anda untuk memilih penerima jika Anda memiliki lebih dari 1 yang tersedia.

Jika Anda tidak memiliki sistem yang terpasang di seluruh sistem, itu sedikit lebih terlibat dan rumit.

 cd $cegui_folder
cd build/bin/
CEGUI_SAMPLE_DATAPATH=../../datafiles ./CEGUISampleFramework-0

Kami ingin menjawab beberapa pertanyaan dan kesalahpahaman:

Mengapa ada begitu banyak ketergantungan?

CEGUI memiliki ketergantungan yang relatif sedikit (saat ini hanya GLM) dan banyak dependensi opsional . Fakta bahwa ia mendukung banyak perpustakaan dan mesin rendering yang berbeda, banyak pemuat/codec gambar yang berbeda (dengan opsi lewat) dan banyak parser XML yang berbeda adalah hal yang baik dan hanya orang yang tidak mendapat informasi yang akan memberi tahu Anda sebaliknya.

CMake memberitahuku ada sesuatu yang tidak ditemukan, apakah ini masalah?

Jika CMake memberi tahu Anda bahwa ada sesuatu yang tidak ditemukan, Anda tidak akan panik ;)! Kemungkinan besar itu pesan yang tidak berbahaya. Anda hanya harus khawatir jika ketergantungan yang Anda tahu tidak ditemukan atau jika tidak ada dependensi yang ditemukan sama sekali. Dalam kasus terakhir, pada Windows dan Mac OS X, Anda mungkin tidak meletakkan folder "dependensi" (termasuk dependensi yang dikompilasi dalam debug/rilis/apa pun yang Anda inginkan) ke dalam folder yang berisi semua file dan folder Cegui. Anda juga dapat menentukan folder lain di CMake menggunakan variabel cegui_dependencies_dir.

Untuk apa nomor versi dalam DLL dan dapat dieksekusi dengan baik? Bagaimana cara menghapusnya?

Sistem penomoran ini sebenarnya melayani tujuan yang sangat penting! Tolong biarkan kami menyimpannya. Ini memungkinkan distribusi Linux (dan lainnya) untuk menginstal beberapa versi API CEGUI di samping yang memudahkan migrasi dan mempercepat adopsi versi Cegui baru. Di Windows ini akan memungkinkan kami untuk memberi Anda dependensi Cegui yang dikompilasi menggunakan Nuget di masa depan.

Dalam aplikasi saya, kursor OS yang ditunjukkan di atas kursor Cegui jauh lebih cepat, mengapa?

Ini adalah perilaku yang diharapkan. Pertama -tama Anda harus selalu menguji kinerja dalam mode rilis, tetapi bahkan di sana kursor akan lebih lambat. Alasannya adalah bahwa sangat tidak mungkin aplikasi akan memiliki kursor secepat kursor OS. Juga ingat bahwa kecepatan terkait erat dengan frame rate Anda, jadi jika Anda menjalankan demo HelloWorld pada 5000 fps, perbedaannya akan kurang tetapi masih terlihat. Setiap game, simulasi, atau aplikasi lain di luar sana yang membuat kursor sendiri melalui fungsi OpenGL/Direct3D dengan cara yang sama. Namun, kecepatan kursor bukan masalah bagi pengguna jika aplikasi Anda berjalan pada laju bingkai yang dapat dihapus (> 60 fps) tanpa rangka rangka dan tidak akan dianggap seperti itu. Setelah Anda menyembunyikan kursor OS maka penundaan itu mungkin tidak akan terlihat lagi kepada Anda.

Begitu banyak dll, mengapa cegui menyebabkan "neraka dll"? Bagaimana dengan tautan statis?

Pertama, istilah "dll neraka" digunakan secara salah dalam konteks ini. Itu tidak berarti "Saya melihat banyak file DLL, ini pasti neraka!". Secara dinamis menghubungkan Perpustakaan Cegui adalah cara terbaik untuk memiliki hal -hal yang bekerja seperti yang seharusnya dan menjamin kompatibilitas yang baik dan peluang rendah masalah yang timbul dengan ketergantungan. Pada Windows kami merekomendasikan untuk menggunakan tautan dinamis dengan Cegui daripada tautan statis, karena pengalaman masa lalu (beberapa pengguna mengalami masalah teknis) telah menunjukkan kepada kami bahwa ini lebih aman. Namun, jika Anda tahu apa yang Anda lakukan, Anda pasti dapat menggunakan tautan statis. Walaupun waspadai bahwa kami hanya menguji tautan dinamis secara teratur, sehingga file cmake mungkin sudah ketinggalan zaman dan Anda mungkin harus menambahkan perpustakaan yang ditautkan ke IDE Anda sendiri dll. Pada catatan positif: dalam versi 1.0 mendatang kami akan mengurangi jumlah DLL yang dibuat Cegui dengan menggabungkan sebagian dari mereka ke dalam perpustakaan pangkalan. Ringkasan yang singkat tapi jelas tidak lengkap dari keuntungan dan kerugian dari tautan statis vs dinamis dapat ditemukan di sini: http://stackoverflow.com/questions/1993390/static-linking-vs-dynamic-linking

Apakah Cegui lebih lambat/lebih cepat dari perpustakaan lainnya? Mengapa lambat dalam kasus saya?

Sebagian besar ketika pengguna mengeluh di forum tentang kecepatan Cegui, ternyata mereka menjalankan aplikasi di debug config atau melakukan sesuatu yang salah: bisa lambat jika Anda memuat sumber daya tata letak/file setiap bingkai atau menyebabkan pembaruan dan acara yang tidak perlu. Atau bisa lambat jika Anda tidak perlu memperbarui CEGUI beberapa kali per frame dalam program Anda. Jika Anda tidak dapat menemukan masalah ini maka yang terbaik adalah melakukan pencarian forum/google dan - jika Anda tidak menemukan sesuatu yang bermanfaat - untuk menggambarkan pengaturan Anda secara detail dan masalah apa yang Anda miliki. Ketika Cegui menjadi lambat juga bisa disebabkan oleh penggunaan fitur spesifik yang sangat spesifik, yang tidak kami harapkan atau tes. Dalam hal ini kami ingin Anda menggambarkan kasus penggunaan Anda di forum sehingga kami dapat menemukan solusi atau, jika Anda mampu memecahkan masalah sendiri, buat permintaan tarik di Bitbucket.

Secara umum Cegui sangat cepat dan dapat dengan mudah bersaing dengan perpustakaan GUI lainnya dalam kecepatan (terutama yang berbasis flash, karena mereka tidak mengakses OpenGL atau Direct3D secara langsung). Meskipun tidak ada perpustakaan yang kompleks di luar sana yang akan dioptimalkan dengan sempurna, Cegui dapat dianggap sangat berkinerja. Ini berlaku untuk perhitungan yang dilakukan pada CPU serta yang ada di GPU. Itu masih berjalan secara optimal ketika ratusan jendela dibuka dan diterjemahkan pada saat yang sama.

Bukti terbaik bahwa Cegui cepat adalah bahwa permainan hak milik besar, yang menampilkan ratusan widget dan menggunakan hierarki yang kompleks, telah dibuat menggunakan Cegui (Torchlight 1, Torchlight 2, Venetica, dll.).

Sebagian besar sampel kami, jika dimulai dalam mode rilis, akan membuat dengan kecepatan di atas 3000 frame per detik pada CPU dan GPU modern. Sebagai catatan tambahan untuk beberapa orang yang suka mengutip tolok ukur yang meragukan mengenai perbandingan kecepatan seperti itu: tolok ukur bergantung pada situasi dan dapat dengan mudah menggambarkan kecepatan aktual perpustakaan dengan penggunaan yang salah, tidak efisien atau tidak biasa. Jika digunakan dengan benar dan di dalam batas penggunaan yang diharapkan, Cegui berkinerja sangat baik.