Gönderen Konu: Merhaba retrojen (ve ilk 3D denemelerim)  (Okunma sayısı 9785 defa)

0 Üye ve 6 Ziyaretçi konuyu incelemekte.

Çevrimdışı Alpyre

  • RAAT
  • Retro Meraklısı
  • *
  • İleti: 106
Merhaba retrojen (ve ilk 3D denemelerim)
« : 01 Haziran 2017, 14:32:14 »
Tekrar merhaba Retrojen ailesi. Bu ne biçim başlık demeyin.
Retrojen’e Alcofribas’ın ikinci davetiyle, ikinci kez üye olmuş bulunmaktayım (sistem ilk üyeliğimi etkinsizlikten silmiş) :D

Madem bir fırsat daha verildi, bu defa iyi kullanayım ve şöyle etkili bir giriş yapayım dedim…

Ahem...

Bir süre önce YouTube’daki Bisqwit kanalında “bu iş bu kadar kolay mıymış?” dedirten şu videoyu izlemiştim.
https://www.youtube.com/watch?v=HQYsFshbkYw&t=188s

Arkadaş prototyping için Basic kullanıyordu. Ben de acaba bu kodu AMOS’a port etsem Amiga’da nasıl çalışır diye düşündüm ve satır satır aktarmaya başladım. Tabi ufak değişiklikler de yaptım. Bisqwit videosunun 2:51’nci saniyesinde VectorCrossProduct adlı bir formül kullandığını, bunu Vikipedi’den öğrendiğini ve tam olarak nasıl çalıştığını kendisinin de anlamadığını “karaBüyü gibi bir şey” diyerek belirtiyor. Formüle bakınca açıkçası ben de pek bir şey anlamadım, ancak bu formülle neyin amaçlandığını (sanırım) anladım ve aslında bir sürü çarpma ve bölme işlemine neden olan bu formülün aslında gerekli olmayabileceğini düşünerek, sadece tek bir çarpma ve bölmeden oluşan çok daha basit bir trigonometri formülüyle aynı işi hallettim. Bir de Inkey$ yerine çok daha hızlı çalışan Scancode kullandım.

Sonra basit bir harita oluşturup denemelere başladım. Baktım oldukça hızlı çalışıyor. Acaba buna texture mapping eklesem performans nasıl olur diye düşünmeye başladım. Daha önce texture mapping ile ilgili hiç araştırma yapmamıştım. Ama kafamda nasıl yapıldığına dair tahminler vardı. O tahminlerimi bir değerlendireyim bakayım ne performans alacağım dedim. Bir sürü deneme yanılmadan sonra o da oldu. Tabi performans pek düşük. Standart A1200’de saniyede 0.5 kare ancak çizebiliyordu. :)

060 A1200’de de saniyede  5 kare falan çizebiliyor sanırım. (tabi timer.device’ı açıp benchmark kodu yazmaya üşendim, göz kararı söylüyorum bunu :D)…

Sonra acaba bu kodu C’ye aktarsam ne kadar performans artışı olur diye düşünmeye başladım. Kullandığım komutlara göre AMOS her bir piksel için önce p2c sonra c2p çevrimi yapıyor olmalıydı. C’de bitleri (texture bitMap’inden, ekran bitMap’ine) doğrudan kopyalayarak bu çevrimleri aşabilirim ve hızlanır diye düşündüm. Hem C'ye geçince döngüler falan da daha hızlı çalışırdı herhalde. Bu sıralar C/C++ dillerinde kendimi geliştirmeye çalıştığım için güzel de bir antrenman olacaktı benim için.

Tabi bu bir sürü destek kodu yazmayı gerektirdi. AMOS’ta tek satır ile halledilebilen, DoubleBuffered ekran açmak ve bir ILBM brush dosyasını yüklemek için 600 küsur satır ilave kod yazmak gerekti. :(

Sonra dedim belki çok hızlı çalışırsa oyun falan yaparım bundan, iyisi mi harita koordinatlarını bir metin dosyasından parse ederek yükleyeyim dedim. 700 küsur satır da o tuttu iyi mi?

Yaptığım envai çeşit mantık ve söz dizimi hatasını gidermekle geçen bir hafta ardından sonunda çalıştırdım. Saniyede 10 kareye falan çıktık galiba. :)

Sonra bildiğim optimizasyonları uyguladım. Gereken fonksiyonları inline etmek, matematik işlemlerinde sadeleştirmeler, dinamik değişkenlerin DCache’de hit olması için MemoryPool kullanmak vs, vs… Derken saniyede 20 kareye falan çıkmış olabiliriz. Tabi bu 60Mhz 060 bir makinede, 4 renkli  100x100 bir ekranda, zemin ve tavan texture’ları olmadan.

https://www.youtube.com/watch?v=-jg18aASQFo

Benzer bir grafik motoru kullanan Gloom oyunu bu makinede, 64 renkli, tam ekranda (320x256), tavan ve zemin döşemeleri dahil 30 kare saniye verebiliyor.

Şöyle üstün körü baktığım birkaç makalede okuduğum kadarıyla, texture mapping için bazı aproksimasyonlar varmış. Düz Amiga’larda dişe dokunur kare saniyelere ulaşmak için sanırım onları öğrenmem ve uygulamam gerekiyor.  Ha tabi geliştirilmiş Amiga’lar daki FPU’dan yararlanır hale getirmek de lazım. Tabi bunlar uzun, zorlu ve pek çok şey öğrenmemi gerektiren işler. Bakalım zamanla nereye varır bu macera?

Alcofribas'a teşekkürler ve her birinize tekrar selamlar arkadaşlar. Fikir ve yorumlarınızı bekliyorum.

Not: Kaynak kod paylaşmadım. Şimdi konunun gerçek uzmanı NightLord falan burada, görürse falan rezil olmayayım. :D Şaka şaka… isteyen olursa paylaşırım ama önce biraz derleyip toparlasam iyi olur. :)

Çevrimdışı witchdoktor

  • RAAT
  • Normalleşmiş Retroman
  • *
  • İleti: 757
Ynt: Merhaba retrojen (ve ilk 3D denemelerim)
« Yanıtla #1 : 01 Haziran 2017, 16:57:35 »
Hoşgeldin Alper :)

Çok sağlam bir içerikle gelmişsin doğrusu, tebrikler. Bu arada geliştirme araçları olarak neler kullanıyorsun? Ben de adım adım Amiga sistemi kurmaya hazırlanıyorum da, aradan geçen 22 yıldan sonra. Ben 1995 yılında bıraktığımda AMOS Pro ve SAS/C kullanıyordum...

Çevrimdışı Alpyre

  • RAAT
  • Retro Meraklısı
  • *
  • İleti: 106
Ynt: Merhaba retrojen (ve ilk 3D denemelerim)
« Yanıtla #2 : 01 Haziran 2017, 22:19:02 »
Hoşgeldin Alper :)

Çok sağlam bir içerikle gelmişsin doğrusu, tebrikler. Bu arada geliştirme araçları olarak neler kullanıyorsun? Ben de adım adım Amiga sistemi kurmaya hazırlanıyorum da, aradan geçen 22 yıldan sonra. Ben 1995 yılında bıraktığımda AMOS Pro ve SAS/C kullanıyordum...

Teşekkürler witchdoktor. Hoşbulduk. :)

Şimdilik Windows üzerinde AmigaOS 3.9 kurulu WinUAE ile geliştiriyorum.
Amos kodunu AmosPro ile yazdım. C kodu için Windows'ta (kendi hazırladığım language-amigaos-c paketi yüklenmiş) Atom ile yazıyorum. Sonra WinUAE geçip SAS/C ile derliyorum. Tabi Amiga tarafında CubicIDE de kurulu. Aslında projelere onunla başlıyorum. Yeni proje oluşturunca SAS/C ve AmigaOS uyumlu bir "Hello World" ve otomatik makefile hazırlıyor. Ardından Windows tarafındaki Atom'a geçip onunla devam ediyorum tabi.

Aslında idealim Linux üzerinde Atom ve m68k-gcc ile derlemek. Ama 64bit Linux'larda JIT destekli bir Amiga emülatörü henüz yok. 32bit Linux'u da makinaya ana işletim sistemi olarak kurmak istemiyorum (Chrome falan çalışmıyor).

Şimdilik böyle idare ediyorum. Linux'a düzgün bir emülatör gelirse değişiklik yapabilirim.

Çevrimdışı Ref

  • Yönetici
  • Özgür Retrocu
  • *
  • İleti: 2882
  • Advanced User Simulator
    • ae unutmadan
Ynt: Merhaba retrojen (ve ilk 3D denemelerim)
« Yanıtla #3 : 02 Haziran 2017, 10:58:29 »
Tekrar merhaba Retrojen ailesi. Bu ne biçim başlık demeyin.
Retrojen’e Alcofribas’ın ikinci davetiyle, ikinci kez üye olmuş bulunmaktayım (sistem ilk üyeliğimi etkinsizlikten silmiş) :D
evet ilk açıldığımızda bayağı sert bir politika izliyorduk üyelikler konusunda. sonra gevşedik. :)
tekrar hoşgeldin.

Alıntı
Sonra basit bir harita oluşturup denemelere başladım. Baktım oldukça hızlı çalışıyor.
amos'u çok severim. Lakin amiga karmaşık bir makine. Bir sürü custom chip. Hepsini öğrenmek gerekiyor çok basit bir kod için bile. Amos bugün benim maintain ettiğim basin gibi, all-in-one bir araç. Kodlamayı eğlenceye çeviren düzgün bir editörü var vs. En son gui extension ile workbench uygulamaları yazıyordum, doğrusu amigadan windows'a geçişimi acaip hızlandırmıştı.

Amosta texture'suz haliyle kaç fps çiziyordu acaba?

Alıntı
Bu sıralar C/C++ dillerinde kendimi geliştirmeye çalıştığım için güzel de bir antrenman olacaktı benim için.
Hmm ne tür bir dil? Var olan bir dilin dialekti mi yoksa brainfuck gibi yeni bir tür mü :D bir de neden?

Alıntı
Derken saniyede 20 kareye falan çıkmış olabiliriz. Tabi bu 60Mhz 060 bir makinede, 4 renkli  100x100 bir ekranda, zemin ve tavan texture’ları olmadan.


bu işlemlerin tamamını cpu ile yaptırdığını tahmin ediyorum. 20 fps hiç de az değil. Amiga'dan bahsediyoruz, 60mhz 060 bile olsa. Oyun olsa mis gibi oynanır :D  Bence sen 680x0'in sınırına dayanmışsın. C kod optimizasyonu en azından elindeki kod ile 1-2 kareden fazla eklemeyecektir. Artık amiga kodlamaya geçmen gerekiyor büyük ihtimal. lakin işi bozan amiganın planar buffer'ı oluyor en başta. Al rengi, böl kanallara, ayrı ayrı yaz falan... Ekranı boyamak için sprite'ları vb. kullanmak mümkün olabilir mi acaba? İşi paula yapsın. Amigada time critical kod yazmamış biri olarak bunu önermek ne kadar sağlıklı bilmiyorum :D

Alıntı
Ha tabi geliştirilmiş Amiga’lar daki FPU’dan yararlanır hale getirmek de lazım.
FPU mutllaka çok yardım edecektir ama amigada FPU küçük bir zümrenin deneyimleyebildiği bir lüks :D fpu gelene kadar bazı fonksiyonları asm olarak kodlasan/unroll etsen? 3-5 kare de ordan gelecektir bence.

Alıntı
Kaynak kod paylaşmadım. Şimdi konunun gerçek uzmanı NightLord falan burada, görürse falan rezil olmayayım. :D Şaka şaka… isteyen olursa paylaşırım ama önce biraz derleyip toparlasam iyi olur. :)
Hahahah, bence kod paylaşırsan wisdom, mert, skate, ve nightlord'dan babalar gibi öneriler gelebilir.


Alıntı
Benzer bir grafik motoru kullanan Gloom oyunu bu makinede
Gloom ile karşılaştırdığın için eklemek istiyorum, stok a500'de çalışan iki oyun vardı:
https://www.youtube.com/watch?v=Q_rFTtQ9Kuk
7mhz için çok hızlı, kısmen küçük texture'lar var falan. Kimbilir ne tür bir trick var burda, belki gerçekten 3D bile değildir. :)

Son dönem citadeli oynuyordum (ya da oynamaya çalışıyordum--bende adspeed var--):
düz a500 1mb'da 4fps falan çiziyor: https://www.youtube.com/watch?v=g33XP9hXbdI
benim makinede demekki 8fps çiziyormuş, o sırada pc de vardı wolfenstein falan oynuyorduk, citadel hakkındaki görüşlerim çok karanlık...

Çevrimdışı nightlord

  • RAAT
  • Tedavideki Retromanik
  • *
  • İleti: 389
    • Night Network
Ynt: Merhaba retrojen (ve ilk 3D denemelerim)
« Yanıtla #4 : 02 Haziran 2017, 11:35:27 »
İşte aslanlar gibi bir girizgah :) Ellerine beynine sağlık Alpyre...

Ama 2 fps'den 20 fps'ye giden yolda hissettiklerin tek kelime ile "harika" değil mi? 10x bir hız farkı.

Amiga hakkında hiç tecrübem olmadığı için benim yapabileceğim yorumlar kısıtlı olacak. Bunları ihtimalen düşünmüşsündür ama bu tür motorlar için aklıma gelenler standart olarak:
- loop'ların içinden çıkabilecek şeyleri arayıp bir üste çıkarmak. Yani per-frame olması gereken birşeyin per scanline (veya per pixel) yeniden hesaplanmaması, immutable birşeylerin per frame olmaması vs.
- faydalanabilecek simetri aramak. Mesela texture'ları y yönünde simetrik yapsan bir texture lookup ile iki piksel basabilir misin? Veya haritayı dizayn ederken yapabileceğin, kodu hızlandıran hileler var mı? Bazı corner-case'ler level dizayn ile elimine edilebiliyor mu?
- mesela duvarlar hep birbirine dik olursa (yani hep kuzey güney veya doğu batı yönünde olursa) hızlanır mısın?
- matematiği mümkün olduğunca fixed-point integer tutmak da Amiga'da daha iyi sonuç verebilir.

Bu önerilerin bazıları yine modern yazılım mühendisliği çevrelerde insanların yüreğine indirebilecek öneriler :) ama daha bugün bir John Romero videosu izledim. Id'in ilk yıllarından takip ettikleri kurallardan biri:

"Kodu sadece şu anda yaptığınız oyun için yazın, bir sonraki oyuna yeni kod yazarsınız"

heheheh ama motor lisanslayan ilk firma da id olduğuna göre varın siz karar verin John abi'yi ne kadar dikkate almalıyız :)

Tekrar tekrar eline sağlık

Çevrimdışı fullgrim

  • Retro Meraklısı
  • ***
  • İleti: 152
    • Adventure Attacks!
Ynt: Merhaba retrojen (ve ilk 3D denemelerim)
« Yanıtla #5 : 03 Haziran 2017, 01:25:55 »
Harika bir çalışma, elinize sağlık. Coder olmadığımdan bir yardımım dokunamayacak, ancak A500 ve A1200 ile geçirdiğim 7 yıldan sonra, Amiga'da işin içine texture'lar girdiğinde 3D performansının daima dibe indiğini gördüğümden, başardığınız işi tebrik etmeden geçmemek istedim. Özellikle son optimize hali Amiga için çok yumuşak çalışıyor.

Gloom ile karşılaştırdığın için eklemek istiyorum, stok a500'de çalışan iki oyun vardı...
Belirttiğin oyunları hiç görmemiştim, özellikle Behind The Iron Gate müthişmiş. Her ne kadar birkaç doku haricinde vektörel ağırlıklı olsa da A500'de çalıştığına inanmakta zorlandım. Benim bildiğim A500'de çalışan Death Mask vardı, A500'üm ile ayrılmadan önceki son günlerimde çıkmıştı ve fps sevmediğim halde ne kadar yapabildiklerini merak ettiğimden almıştım. A500'e optimize edebilmek için olabilecek hemen her hileyi kullanmışlar oyuna gerçekten 3D demek mümkün mü bilemiyorum, kesintisiz hareket bile yok, her şey 4 yönlü:

https://www.youtube.com/watch?v=842i-OqL18U

Çevrimdışı Ref

  • Yönetici
  • Özgür Retrocu
  • *
  • İleti: 2882
  • Advanced User Simulator
    • ae unutmadan
Ynt: Merhaba retrojen (ve ilk 3D denemelerim)
« Yanıtla #6 : 03 Haziran 2017, 02:20:47 »
Benim bildiğim A500'de çalışan Death Mask vardı

death mask'ı biliyordum, dungeon master'ın sürekli aksiyon şeklinde geçmesi hali.

Çevrimdışı Alpyre

  • RAAT
  • Retro Meraklısı
  • *
  • İleti: 106
Ynt: Merhaba retrojen (ve ilk 3D denemelerim)
« Yanıtla #7 : 03 Haziran 2017, 15:49:02 »
@Ref
Hoşbulduk.

Bu sıralar C/C++ dillerinde kendimi geliştirmeye çalıştığım için güzel de bir antrenman olacaktı benim için.
Hmm ne tür bir dil? Var olan bir dilin dialekti mi yoksa brainfuck gibi yeni bir tür mü :D bir de neden?
Yok. Bildiğin C ve C++ dilleri. Nedenine gelince de... Bilmem ki. Yıllardır hep heves edip fırsat bulamadığım bir şeydi C öğrenip Amiga programı yazmak. :)

Derken saniyede 20 kareye falan çıkmış olabiliriz. Tabi bu 60Mhz 060 bir makinede, 4 renkli  100x100 bir ekranda, zemin ve tavan texture’ları olmadan.

bu işlemlerin tamamını cpu ile yaptırdığını tahmin ediyorum. 20 fps hiç de az değil. Amiga'dan bahsediyoruz, 60mhz 060 bile olsa. Oyun olsa mis gibi oynanır :D  Bence sen 680x0'in sınırına dayanmışsın. C kod optimizasyonu en azından elindeki kod ile 1-2 kareden fazla eklemeyecektir. Artık amiga kodlamaya geçmen gerekiyor büyük ihtimal. lakin işi bozan amiganın planar buffer'ı oluyor en başta. Al rengi, böl kanallara, ayrı ayrı yaz falan... Ekranı boyamak için sprite'ları vb. kullanmak mümkün olabilir mi acaba? İşi paula yapsın. Amigada time critical kod yazmamış biri olarak bunu önermek ne kadar sağlıklı bilmiyorum :D
Yok yapabileceğim pek çok optimizasyon daha var gibi görünüyor. Planar ekran hiç problem değil. Çünkü texture'ım da planar. Chunky2Planar çevrimi hiç yapmıyorum. Kordinatlar hesaplandıktan sonra, her plane için texture'ın ilgili konumunda bit set mi diye bakıp, set ise ekran bitmapinde de o biti set yapıyorum. Tabi bu bütün yükü CPU'ya bindiriyor. Blitter'ı sadece ekranı hızlı şekilde temizlemek için kullanıyorum şimdilik.

Ha tabi geliştirilmiş Amiga’lar daki FPU’dan yararlanır hale getirmek de lazım.
FPU mutllaka çok yardım edecektir ama amigada FPU küçük bir zümrenin deneyimleyebildiği bir lüks :D fpu gelene kadar bazı fonksiyonları asm olarak kodlasan/unroll etsen? 3-5 kare de ordan gelecektir bence.
asm bilgim sıfır. O yüzden şimdilik mecburen C'den devam... :)

Sonra basit bir harita oluşturup denemelere başladım. Baktım oldukça hızlı çalışıyor.
amos'u çok severim. Lakin amiga karmaşık bir makine. Bir sürü custom chip. Hepsini öğrenmek gerekiyor çok basit bir kod için bile. Amos bugün benim maintain ettiğim basin gibi, all-in-one bir araç. Kodlamayı eğlenceye çeviren düzgün bir editörü var vs. En son gui extension ile workbench uygulamaları yazıyordum, doğrusu amigadan windows'a geçişimi acaip hızlandırmıştı.

Amosta texture'suz haliyle kaç fps çiziyordu acaba?
Aynen dediğin gibi. Amos ergenliğimin en eğlenceli yanıydı. Hala da dönüp dolaşıp ona dönüyorum baksana. :D
Amos'ta texture'sız hali stok A1200'de 6-9 FPS arasında gidip geliyor. 060'ta ise 25-30 arası. (Bu defa göz kararı değil, koda FPS sayacı ekledim. Hatta kodu da ekledim. Amiga'sı olanlar deneyebilir. Amos'u olmayanlar için derlenmiş executable da attım.)

Benzer bir grafik motoru kullanan Gloom oyunu bu makinede
Gloom ile karşılaştırdığın için eklemek istiyorum, stok a500'de çalışan iki oyun vardı:
https://www.youtube.com/watch?v=Q_rFTtQ9Kuk
7mhz için çok hızlı, kısmen küçük texture'lar var falan. Kimbilir ne tür bir trick var burda, belki gerçekten 3D bile değildir. :)
3D değil zaten. 2.5D diyorlar buna... Bu oyunu hatırlıyorum. Biraz inceleyeyim bakayım kopya çekebilirim belki bazı özelliklerinden. Çok teşekkürler.

Çevrimdışı Alpyre

  • RAAT
  • Retro Meraklısı
  • *
  • İleti: 106
Ynt: Merhaba retrojen (ve ilk 3D denemelerim)
« Yanıtla #8 : 03 Haziran 2017, 16:25:18 »
@nightlord
İşte aslanlar gibi bir girizgah :) Ellerine beynine sağlık Alpyre...

Ama 2 fps'den 20 fps'ye giden yolda hissettiklerin tek kelime ile "harika" değil mi? 10x bir hız farkı.
Kesinlikle harika. Tabi 1 saatte yazdığım kodu bazen 1 günde debug ettiğim için, en büyük keyif çalıştığını gördüğüm an oluyor. Ahaha :D

Amiga hakkında hiç tecrübem olmadığı için benim yapabileceğim yorumlar kısıtlı olacak. Bunları ihtimalen düşünmüşsündür ama bu tür motorlar için aklıma gelenler standart olarak:
- loop'ların içinden çıkabilecek şeyleri arayıp bir üste çıkarmak. Yani per-frame olması gereken birşeyin per scanline (veya per pixel) yeniden hesaplanmaması, immutable birşeylerin per frame olmaması vs.
Optimize ederken ilk yaptığım bu oldu zaten. Hissedilir kazanç bundan oldu sanırım.

- faydalanabilecek simetri aramak. Mesela texture'ları y yönünde simetrik yapsan bir texture lookup ile iki piksel basabilir misin?
İşte bu satır "mind blow" yaptı be abi... Texture'ım simetrik olursa ufuk çizgisinin üstü ve altı (bu uygulamada) tamamen simetrik olur. Hatta duvarların sadece üst kısmını çizip, alt kısmını blitter çipiyle kopyalayabilirim. Hatta çizim öncesi ufuk çizgisinin altında kalan kısmı temizlemem bile gerekmez bu durumda. Ya bu gerçekten çok aşırı hızlandırabilir ya... Süper oldu bu! Çok çok çok teşekkürler...
Tabi oyun yapacaksam bu çok tek düze bir görsele neden olabilir. Bazı ufak duvarları da eski yöntemle asimetrik çizersem ikisinin karışımı ne yaptığımı gizleyebilir.   

- mesela duvarlar hep birbirine dik olursa (yani hep kuzey güney veya doğu batı yönünde olursa) hızlanır mısın?
Bu sadece oyuncunun haritanın hangi sektöründe olduğunu hesaplarken ve duvarların içinden geçememesini sağlarken kazanç sağlayacak bir şey gibi. Henüz oralara hiç girmedim :)

Bu önerilerin bazıları yine modern yazılım mühendisliği çevrelerde insanların yüreğine indirebilecek öneriler :) ama daha bugün bir John Romero videosu izledim. Id'in ilk yıllarından takip ettikleri kurallardan biri:

"Kodu sadece şu anda yaptığınız oyun için yazın, bir sonraki oyuna yeni kod yazarsınız"

heheheh ama motor lisanslayan ilk firma da id olduğuna göre varın siz karar verin John abi'yi ne kadar dikkate almalıyız :)

Tekrar tekrar eline sağlık

Sağol Nightlord. Bu yazdıkların gerçekten enerji ve yeni fikirler verdi. Hatta ilgisi yok ama, düşünürken serbest çağrışımla sanırım Gloom oyununda uzaktaki duvarların nasıl daha karanlık çizildiğini de buldum.
Şimdi işten çıkıp eve gidip klavyeye gömülmek için can atıyorum. Çok çok sağol.

Çevrimdışı Ref

  • Yönetici
  • Özgür Retrocu
  • *
  • İleti: 2882
  • Advanced User Simulator
    • ae unutmadan
Ynt: Merhaba retrojen (ve ilk 3D denemelerim)
« Yanıtla #9 : 04 Haziran 2017, 22:15:01 »
koda ben de baktım biraz önce. Amos'da 7 fps çiziyor gibi görünüyor. Ortadaki haritayı çizen kodu kapatınca 9-10fps oldu.
sürekli olarak float hesaplar var, dediğin gibi hız, precision sebebiyle kaybediliyor. Integer math, sin ve cos'u tabloya çekmek, iç içe küçük FOR..next'leri  unroll etmek acaba ne kadar kazandırır (0.5 kare falan?). Belki bir ara denerim :D

ayrıca blitter ile çizgi çizdirilebiliyor. amosda pload ile derlenmiş asm kullanılabiliyor. bu kod çok hızlı çalışabilir büyük olasılıkla.

Ahah, bu kod 1991'de olacaktı ki elimde :) kimbilir daha neler kaçırdım...

Çevrimdışı Alco

  • Yönetici
  • Özgür Retrocu
  • *
  • İleti: 2130
  • "Kahraman olmak, dürüst olmaktan kolaydır" Luigi P
    • Sizin Amstrad
Ynt: Merhaba retrojen (ve ilk 3D denemelerim)
« Yanıtla #10 : 07 Haziran 2017, 13:40:54 »
Alpyre hoşgeldin! Bu harika başlığı fazla meşgul etmemek adına, eğer kabul ediyorsan hemen siparişlerimi verip kaçıyorum. Bu bağlamda ileride senden görmeyi arzu ettiğim örnek başlıklar:

1-) Amiga'da Müzik üretimi (Temel müzik bilgisi de içeren HowTo tarzı bir manual) (Amiga dedim ama PC de olabilir fakat çok hardcore ve crack gerektiren programlarla olmasın, düsturumuz KISS metodu biliyorsun)

2-) Yıldızı barışmayanlar veya kullanım alışkanlığı edinemeyenler için Linux

Ağanın eli tutulmaz :)

Çevrimdışı Alpyre

  • RAAT
  • Retro Meraklısı
  • *
  • İleti: 106
Ynt: Merhaba retrojen (ve ilk 3D denemelerim)
« Yanıtla #11 : 25 Haziran 2017, 21:26:29 »
Tamam Alcofribas. Siparişleri aldım. :)
(Gerçi bu kadar üstadın arasında Linux hakkında konuşmak ne kadar bana düşer onu bilemedim ama... neyse... seni kıramam.)

Şimdi şöyle özet bir bayram güncellemesi yapayım şu başlığa. :)
Ref'in ve nightlord'un önerilerini değerlendirdim ve elimden geldiğince uygulamaya çalıştım.

İlk önce PPaint'te tuğla duvar kaplamamı ufuk çizgisinin üstü ve altı simetrik olacak şekle getirdim.


Programı ekranın sadece ufuk çizgisinin üstündeki kısmını çizdirdikten sonra, alt kısma ters çevirerek BlitCopy yapacak şekilde değiştirdim. FPS bir anda yaklaşık iki katına çıktı.

Tabi hepsinden önce çok önemli bir eksiğim vardı. Oyuncuya yakın olan duvarların ardında kalan duvarların sadece görünen kısımlarının çizilmesi gerekiyordu (Amos kodumda da, C kodumda da bu yoktu, sadece oyuncunun durduğu yere göre duvarların çizim önceliği değişiyordu).
Öğrendiğim kadarıyla bu üç farklı şekilde hallediliyor.
1) John Carmack'ın Wolfenstein 3D'de kullandığı ray casting...
2) veya (IDTech1'de) kullandığı BSP ağacı...
3) veya Ken Silverman'ın (Build Engine'de) kullandığı "portal" yöntemi...

Ray Casting kodumuzun hali hazırdaki haline zaten uygun değil. Komple yeniden tasarlamayı gerektirir.
BSP, harita formatımı çok değiştireceği için üşendim fakat bazı fikirleri aldım.
Portal yöntemi aklıma yattı (bisqwit de bunu uyguluyor videosunda bu arada).

BSP ile Portal yöntemlerinin sadeleştirilmiş bir karışımını uygulamaya karar verdim. Harita verisinde çok ufak değişiklik ile duvarların arkasında kalan duvarların sadece görünen kısmı çiziliyor artık. Ayrıca sadece bir iki tam sayı karşılaştırma ile de portallar görüş alanında değilse hiç hesaplama yapmadan tamamen atlanıyor. Aşağıdaki animasyonda bakış açısına göre hesaplanan duvarlar görüntüleniyor:


Not: Bu arada IDTech1'deki gibi duvarların çizimi görüş alanını doldurduğunda (yani ekran yatay çözünürlüğü kadar piksel yazıldığında) tüm döngülerden erken break yapmak da aklımda. Bir ara onu da ekleyeceğim.

Vertex struct'larında ekran kordinatları için iki buffer açtım. Bir vertex en az iki duvar tarafından ve bazen de portallar için kullanılabiliyordu. Aynı vertex için iki üç defa transform işlemleri yapılmamalıydı. Artık ilk yapıldığında sonucu bellekte tutuyor, ikinci kez ihtiyacı olduğunda bellekten çağırıyordu.

Sonra Sin ve Cos değerleri için bir look-up tablosu hazırladım. Zaten oyuncuyu 5'er derece döndürüyordum. 72 değerlik bir tablo can yakmazdı. Sonra baktım ki bu değerlerin çoğu birbiriyle zaten aynı (işareti ve sırası değişiyor sadece). Look-up fonksiyonunu geliştirdim, tablo 18 değere düşüverdi. :)

Orada burada bir kaç optimizasyon daha yaptıktan sonra bahsettiğiniz şu Floating Point kullanmama konusu. Bunun olabileceğini hiç düşünmemiştim... fakat bir aralar StackOverflow.com'da bir kullanıcının "asla Float kullanma, değişkenlerini bir katsayı ile çarp, tüm işlemlerini yap, sonra o katsayıya böl" gibi bir önerisini okuduğum aklıma geldi.

Okuduğumda 'yav hiç olur mu öyle şey be...' demiştim. Çünkü işlemler sırasında değişkenler birbiriyle çarpılırsa katsayının karesi ortaya çıkardı... ama aklıma gelmişken denemeliydim.

Evet değişkenlerim bazen birbirine çarpılıyor, bazen de bölünüyordu. Fakat işlem sıralarıyla biraz oynayarak doğru sonuçları elde etmeyi başardım ve koddan tüm FLOAT değişkenleri temizledim. Her şey INT artık.

Katsayı olarak da önce 100 seçtim. Sıfırdan sonra iki basamak precision yeterdi. Sonra kendime dedim ki, neden 100? (Sonuçta bilgisayarlar ondalık sayı kullanmıyor). 128 olsun, çarpma bölme yerine de bitshift kullan. Daha sonra 64'te karar kıldım. 6 bitlik precision yeterli görünüyordu.

Vertex hesaplamaları yeterince yaklaşık sonuç veriyor, duvarlar yerli yerinde ancak texture mapping o kadar iyi olmadı. Aşağıdaki gibi bir glitch ortaya çıktı (sanırım buna benzer glitchleri PlayStation 1 oyunlarında görmüştüm... onlar da mı Float kullanmıyordu acaba? Bilmiyorum).

Duvara yaklaşınca ortaya çıkan üçgen üçgen görüntüleri sineye çekebilirim. Hatta oyuncunun duvarlara fazla yaklaşmasını engelleyerek gizleyebilirim de... fakat uzak duvarlardaki texture'lar sağa sola sallanıyor hatta bazen hepten yok oluyorlar, bu hiç hoş değil:


Bu haliyle 060 Amiga'mda 30-45 (hatta bazı açılarda 50) FPS elde ettim. Stock A1200'de ise 7-10 arası. Hala düşlediğim kadar iyi değil. :(

İşte denemelerimin ulaştığı nokta aşağı yukarı bu. Belki yalnız texture'lar için FLOAT kullanmayı deneyebilirim. Hayli uzun bir yazı oldu. Burada noktalasam iyi olur. Sabırla okuyan herkese iyi bayramlar dilerim. Görüşmek üzere. Sağlıkla kalın.  :-*

Çevrimdışı Alco

  • Yönetici
  • Özgür Retrocu
  • *
  • İleti: 2130
  • "Kahraman olmak, dürüst olmaktan kolaydır" Luigi P
    • Sizin Amstrad
Ynt: Merhaba retrojen (ve ilk 3D denemelerim)
« Yanıtla #12 : 25 Haziran 2017, 22:40:01 »
Ray Casting kodumuzun hali hazırdaki haline zaten uygun değil.
Ray Casting dedi. Hemen @Wisdom 'ı sahneye davet ediyoruz.

http://retrojen.org/pano/index.php?topic=345.0

Alıntı
Sabırla okuyan herkese iyi bayramlar dilerim. Görüşmek üzere. Sağlıkla kalın.  :-*
Peki ya sabırla okumayan varsa... Onlara iyi bir bayramlar dilemiyor muyuz :)

Çevrimdışı Ragnor

  • RAAT
  • Retro Meraklısı
  • *
  • İleti: 187
Ynt: Merhaba retrojen (ve ilk 3D denemelerim)
« Yanıtla #13 : 26 Haziran 2017, 23:48:18 »
Nacizane bir paylaşımda bulunayım bari bende. Amiga'daki çeşitli doom klonu fps oyunları üzerine güzel bir video derlemesi https://www.youtube.com/watch?v=Tv6aJRGpz_A

Çevrimdışı nightlord

  • RAAT
  • Tedavideki Retromanik
  • *
  • İleti: 389
    • Night Network
Ynt: Merhaba retrojen (ve ilk 3D denemelerim)
« Yanıtla #14 : 30 Haziran 2017, 01:52:13 »
Süper gelişiyor ellerine sağlık.

Alıntı
fakat uzak duvarlardaki texture'lar sağa sola sallanıyor hatta bazen hepten yok oluyorlar, bu hiç hoş değil:

Bu problemin başka bir bug olmadığından emin misin. mesela precision'ı 6 bit yerine 8 bite veya 16 bite çıkarınca bug ortadan kalkıyor mu? (Ayrıca 8 bit kullanırsan direk byte-sınırına geldiğin için bölme/shift yapmaya gerek kalmayabilir.

bir de aslında teknik olarak çok önemli değil ama texture tasarımı da burada önemli rol oynuyor. Bu tip texture renderer'larda texture'ın nasıl dizayn edildiği sonucu etkiliyor. Genel olarak fazla "yüksek frekanslı" tasarımlardan kaçınmak lazım. Bir texture ne kadar düşük frekanslı olursa bu tip nearest-neighbor türevi renderer'larda yaklaşıp uzaklaşırken o kadar iyi görünür. Mesela,
* duvar şu anda olduğu gibi 7 tuğla değil de 5 tuğla yükseklikte olsa. yani daha büyük tuğlalar ile (duvarın toplam yüksekliği aynı kalarak)
*  bir piksel kalınlıkta tuğla sınırı çizgileri yerine tuğlanın tamamına gradient verirsen yani bİr tuğla şöyle birşey


Kod: [Seç]
***+++..
*****++.
*******+
*****++.
***+++..

Yani sözün özü bir piksel kalınlığında ve etrafından çok kontrastlı bir renkle ayrılan detaylar bazı uzaklıklarda kaybolacağı için bunun yerine hep gradientli şeyler kullanıyoruz

Çok detaylı yazamıyorum şu aralar. Aslında bu thread bayağı bir güzelleme hakediyor. Kusuruma bakmayın. Ama süper gidiyor.