Saf WASM üzerinde çalışan Unity tarzı oyun editörü

 (raverie-us.github.io)
2 puan yazan GN⁺ 2023-09-27 | 1 yorum | WhatsApp'ta paylaş
  • Geçmişteki Macromedia/Adobe Flash deneyimini yeniden canlandırmayı hedefleyen hafif bir oyun motoru
  • Tüm platformlarda çalışacak şekilde tasarlandı ve tek çıktı hedefi saf WASM
  • Çıktıya çalıştırılabilir dosya veya glue code dahil edilmiyor ve Emscripten kullanılmıyor
  • import ve export listeleri PlatformCommunication.hpp içinde açık biçimde tanımlanmış
  • Tarayıcı dahil herhangi bir platformda kolayca uygulanabilecek bir yapı

Genel bakış

  • Geçmişteki Macromedia/Adobe Flash deneyimini yeniden üretmeyi amaçlayan hafif (light-weight) bir oyun motoru

Mimari

  • Herhangi bir platformda çalışacak şekilde geliştirildi ve tek çıktı hedefi olarak saf WASM benimsendi
  • Çıktıya çalıştırılabilir dosyalar, glue code vb. dahil edilmiyor ve Emscripten kullanılmıyor
  • import ve export listeleri PlatformCommunication.hpp içinde düzenli biçimde tanımlandığı için, tarayıcı dahil her platformda kolayca uygulanabiliyor

İlgili okumalar

1 yorum

 
GN⁺ 2023-09-27
Hacker News yorumları

  • Vay, Zero Engine'i yapan kişiler bunlar mı? Uzun zaman önce DigiPen yaz kampında kullanmıştım ve Zilch ile programlamak gerçekten çok keyifliydi.
    Galaga klonunu oynayan bir yapay zeka da yapmıştım. Bu Unity olayları yüzünden Zero'ya ne oldu diye merak ediyordum; yeniden canlanacak gibi görünmesi beni gerçekten heyecanlandırıyor.

    • Harika! Zilch benim gözüm gibi baktığım bir şeydi; böyle söylemenize gerçekten çok sevindim :D

  • Referans olsun diye ekleyeyim: dahili grafik kartlı, bariz düşük özellikli bir dizüstünde bir başka muhteşem slayt gösterisi gibi çalışıyor.
    Eski bir Mate 20 Pro'da da denedim; “Downloading runtime” kısmında takılmış gibi görünüyordu. Sorunun dengesiz 4G'den kaynaklandığını sanmıyorum; USB ile dizüstünden chrome://inspect açıp sekmeyi kontrol edince Uncaught (in promise) Error: Needs OES_texture_float_linear to function hatasını gördüm. Zaten oynayamayacağınızı söylemek için bir hata ekranı yapmaya değer mi, bu da felsefi bir soru tabii.

  • Fikir hoşuma gitti. Ama GPU'm ve tarayıcım gecikme yüzünden ağlıyor; etkileyici bir slayt gösterisi gibi görünüyor.
    Birkaç denemeden sonra ancak başlangıç küresini seçebildim. Başta yüklemenin bitip bitmediğinden bile emin olamadım. Tabii Firefox'ta 1.8GHz Celeron, dahili GPU ve 8GB RAM kullanıyorum; üst seviye donanımdan epey uzağım.

    • Chrome'da biraz daha iyi çalışıp çalışmadığını merak ediyorum. Epey kişinin Firefox sorunu yaşadığı anlaşılıyor. Bundan sonra Firefox'ta da düzenli test yapacağım.
    • Tekrar deneyebilirseniz, bazı makinelerde performansı ciddi ölçüde iyileştiren bir düzeltme az önce yayınlandı.
      Yerel bir oyun motorunu WASM'e port ettiğimiz için sorun, tarayıcı zamanlama API'leriyle iyi uyuşmayan kare hızı sınırlama kodundaydı: https://raverie-us.github.io/raverie-engine/
    • M2 Pro'da da birebir aynı deneyimi yaşadım; ben de Firefox kullanıyordum.
    • Hâlâ Celeron üretiyorlar mı?

  • “Motorumuzda Spaces adlı benzersiz bir özellik vardı; ayrı dünya/seviyeler örneklenebiliyordu” kısmı bana Godot motorunun yaptığı şeyle birebir aynı görünüyor[1].
    O motorun da tarayıcı (WASM) hedefi var. [1]: https://godotengine.org/

    • Sadece WASM hedefi değil, web sürümü de var: https://editor.godotengine.org/
      Projede yüksek öncelikli gibi görünmüyor. Biraz test ettim; çalışıyor gibi :), ama yerel çalıştırmadan daha yavaş.
    • Unity'nin sahnelerinden nasıl farklı olduğundan da pek emin değilim.

  • Tarayıcının Web API'leri ile saf WASM'in, JS katmanı olmadan ya da düşük maliyetle etkileşmesini sağlayacak bir WASM geliştirme akışı var mı merak ediyorum.
    Ara sıra https://github.com/WebAssembly/proposals sayfasına bakıyorum ama çok kafa karıştırıcı. Type imports önerisi yıllarca uzakta gibi görünüyor; neredeyse tamamlanmış GC önerisi ise GC dilleri için, tarayıcı↔WASM için değil gibi. Component model tarayıcı kullanım senaryolarından uzak görünüyor; JS String Builtins, JS dizelerini hızlandırıyor ama DOM'u değil. ECMAScript modül entegrasyonu WASM modüllerini ES modülüne dönüştürüyor, fakat Web API'ler ES modülü olmadığı için yardımcı olmuyor. Katılımcıların konuşmalarına bakınca bazen bu tür bir işlevselliği sağlamanın ne öncelik ne de plan dahilinde olduğu izlenimi oluşuyor; çoğunluk için WASI ve component modelin bulut/kriptografi gibi kullanımlarının daha önemli olduğu anlaşılıyor.

    • Ben de bunu gerçekten istiyorum. Sayfanın sadece WASM olduğu, “tarayıcı”nın da WASI gibi platform import'ları sağlayan saf wasm tarayıcı olduğu bir şey görmek isterim.
      Ama dediğiniz gibi onlar için öncelik değil gibi. Umarım bir gün mümkün olur.
    • Reference types sayesinde teknik olarak tarayıcı API'lerini doğrudan çağırmak zaten mümkün. Çünkü WASM, JavaScript nesnelerini alıp verebiliyor.
      İlgili tüm Web API'lerini import ederseniz, tek tek API çağrıları arasında JS nesnelerini olduğu gibi geçirebilirsiniz; böylece arada neredeyse hiç JS gerekmeyebilir. JS'nin gerçekten gerektiği yer, ilk WASM modülünü başlatma aşaması gibi.
    • Saf WASM'in sorunu, engellenemeyen reklamların olduğu kapalı bir web'e yol açabilmesi.
    • En azından bir kısmının GC önerisinin yöneldiği doğrultu olduğunu düşünüyorum.

  • Harika bir proje. Yüksek çözünürlüklü ekranlarda arayüzü büyütmenin bir yolu var mı?
    2:1 ekranda yazı tipleri pikselli görünüyor. Tarayıcı yakınlaştırmasını %50'ye ayarlayınca arayüz keskinleşiyor ama her şey çok küçülüyor ve kullanması zorlaşıyor.

    • OP'ye: düzeltmenin yolu canvas genişliğini window.innerWidth * window.devicePixelRatio, yüksekliğini de window.innerHeight * window.devicePixelRatio olarak ayarlamak.
      Sonra CSS ile canvas'ı ekrana maksimum boyutta yerleştirmek yeterli.
    • Arayüz için neden tarayıcının yerel render motorunu kullanmadıklarını, en azından SVG bile kullanmadıklarını anlamıyorum.
      Kaynaklar (bellek, ağ, CPU) açısından daha ucuz olurdu; erişilebilirlik desteği de, render etmek de daha kolay olurdu.

  • Trevor! DigiPen'de sözdizimi üzerinden programlama dili tasarımını işleyen CS seçmeli dersini gerçekten çok sevmiştim.
    Ders verdiğin öğrencilerin epey bir kısmı şimdi Minecraft'ta çalışıyor. Şu anda Minecraft scripting API'sini tasarlarken, o zaman öğrendiğim temellerden ve DigiPen dönemindeki pek çok şeyden yararlanıyorum. Hâlâ harika işler yaptığını görmek güzel.

    • Faydalı olmasına gerçekten sevindim! Bir gün yeniden ders vereceğim ;)
      Üzerinde çalıştığınız scripting arayüzünü de mutlaka görmek isterim. Eskiden Minecraft modlarıyla gerçekten çok uğraşmıştım ve her zaman bir tür dinamik scripting istemiştim.

  • Gerçekten çok iyi. Bu alanda saf WASM tabanlı bir ürün görmek güzel. Yalnız M1 Mac Pro'mda epey takılıyor.

  • Bir sorum var: Bu NES'te de çalışıyor mu? Yenilenmiş önden yüklemeli model; parçaların çoğu orijinal ama biraz daha RAM ekledim.
    Üstüne sıcak silikonla yapıştırdım; kasayı da kırmızıya boyayıp birkaç oyuncak asker taktım.

    • WASM > NES dönüştürücüsü yapmak neden gerçekten eğlenceli bir fikir gibi görünüyor…

  • Sadece varsayılan top sahnesini açmış olmama rağmen Radeon Pro 560X'i ve neredeyse 4K ortamda GPU'yu çok sert zorluyor.
    Sadece kamerayı döndürmek bile kare hızını çok düşürüyor. WebGL optimizasyonuyla ilgili bir sorun olabilir mi, bilen var mı?

    • Benim Intel HD Graphics 620 üzerinde gayet akıcı çalışıyor. 7. nesil Intel dahili grafik olduğu için eski ve yavaş sayılır; buna rağmen sadece varsayılan top sahnesine bakarken sistemde çok pürüzsüz çalışmasına şaşırdım. Chrome kullanıyorum.
    • Tekrar deneyebilirseniz, bazı makinelerde performansı ciddi ölçüde iyileştiren bir düzeltme az önce yayınlandı.
      Yerel bir oyun motorunu WASM'e port ettiğimiz için sorun, tarayıcı zamanlama API'leriyle iyi uyuşmayan kare hızı sınırlama kodundaydı: https://raverie-us.github.io/raverie-engine/
    • Ayrık ekran kartını kullanmıyor gibi de geliyor. Diğer WebGL demoları normal çalışıyor mu?