Tabii sürekli "bu adamlar bu formatı kendileri mi icat ettiler" diye düşünüp durdum. Bir iki mesaj önce gönderdiğim kitaba da öyle denk geldim, yani belki bir tool vardır filan common sense kullanılan diye. Bir ara yanılmıyorsam @Ref bunlar AMOS Pro ile okunur gibi bir şey demişti... Şöyle bir kaynak var: https://amospromanual.dev/14-appendix-e-memory-bank-structures.html#05-work-banks-and-data-banks-stored-on-disc, belki biliyorsunuzdur.

Belki bu kısımda @Ref yardımcı olmak ister ben AMOS Pro 2.0 diskini açtım ama bir DIM yazıp save ettirip dosya neye benziyor diye bakana kadar akla karayı seçtim

Neyse, çok keyifli bir serüvendi... şimdi artık iş ciddiye binebilir. Elimizde teoride bütün haritalar ve bütün senaryolar programlanabilir bir şekilde var. Ben arkada kart oyunu için bir combat engine zaten yazdım, aparılabilir. Inventory management, art work, biraz güzel savaş mekaniği... karakter yaratma vs... elimizdeki işler bunlar

2. level'ı da yapıp Özgür'ün kapısında dayanalım diyorum

Bakın ne buldum

https://gitlab.com/amigasourcecodepreservation/ultimate-amos/-/raw/master/pdf/ultimate-amos-1994-holborn.pdf

  [ You are not allowed to view attachments ]    [ You are not allowed to view attachments ]    [ You are not allowed to view attachments ]  

Bizimkiler bu kitaptan etkilenmişler midir acaba? sadece iki sayfa ayırmış kitap ama...

Sizlere bir sürpriz yapayım dedim ama beceremedim. İstanbul Efsaneleri'nin 1995 yılında çıkan mavi kutu kapağı/posterini yapan kişi arkadaşımdır. Kendisinden duruyorsa orijinal çalışmasını isteyecektim ki daha İstanbul Efsa... demeye kalmadan epey bir tepki aldım. Detaylara girmeyeceğim ama anlaşılan geliştiren ekiple iyi ayrılmamışlar. Paylaşmak istemedi. Preservation konusundan Unesco'ya varıncaya kadar bahsettim, "gidin yeni oyun yapın, uğraşmayın böyle şeylerle" gibi laflar etti, ben de daha çok üzerine gitmedim.

Biraz daha dig ettim. 04 bir şey gösterme demiştik, 0403 resimli bir şey gösterme. bundan sonra gelen 0d resim ID’si. İlk senaryoda 0403 iki kere geçiyor, birinde köpek, birinde baygın adam resmi var.

Daha sonra dedim ki bunları manipüle etmenin daha kolay bir yolu olmalı, böyle dosyayı değiştir diskete yaz yeniden başla falan çok uzun iş…

Neden daha önce denemedim bilmiyorum ama, Mac'te vAmiga kullanıyordum FS-UAE ile birlikte... vAmiga çok kullanışlı geldi... ama memory visualizer'ı biraz sıkıntılıydı. Konsolu da vardı ama pek önem vermemiştim. Bugün biraz daha baktım, konsolda direkt memory'ye erişip değiştirebiliyoruz... Önce daha önce bahsettiğim "inventory ekranı açma" sekansıyla oynadım, o dolarla kıvrık arasındaki byte mark'mış ) 5 dolar, 10 mark, 30 kıvrık falan verilebiliyor. 03 de item gerçekten, başka bir item'la değiştirilebiliyor. Yanındaki word’e yeni bir item da eklenebiliyor. vAmiga makinenin anlık snapshot'ını alıp yüklemeyi de sağladığı için memory'deki byte'ları değiştirerek ne olduklarını görmek çok daha kolay hale geldi. Bu şekilde bu resim gösterme opcode’unu test ettim, gerçekten de tahminim doğruymuş, başka başka değerler vererek başka resimler göstertebiliyoruz

Fantastik gelişmeler gerçekten. State machine’i çözmeye çok az kaldı, bu haftasonu bunu bitirmek istiyorum. Tabii bu daha ilk bölüm. Event’leri uzunluklarına göre bölme işi her bölümde çalışıyor ama ilk bölümün haritasındaki 1111 1112 şeklinde giden metadatalar ileriki bölümlerde daha farklı. Orada belki başka opcode’lar da olacaktır.

orijinal baygın adam:
 [ You are not allowed to view attachments ]  
silikonbaba: 
 [ You are not allowed to view attachments ]  

--------

Bu arada resimleri küçük göstermenin bir yolu yok mu ya? Bulamadım forumda

Ufak bir update: senaryo dosyalarında event'ler de length byte'la birlikte sadece sıralı olarak tutuluyorlar.

Senaryo dosyalari AmBk formatında demiştik, 20 byte header'ı var. Sonrasında 12 byte metadata var, asıl data 33. byte'tan başlıyor. Metadatanın ilk word'ü (2 byte'ı) senaryodaki event sayısını gösteriyor (haritadaki metadata olan odalarla örtüşüyor). Sonraki word'ü ilk event'in uzunluğunu gösteriyor (ama garip bir şekilde uzunluklar ikişer kere kaydedilmiş.). Neyse, arada birkaç ne idüğü belirsiz byte var, sonra ilk event'in uzunluğu 32. byte'ta. Dediğim gibi, 33. byte'tan itibaren bu uzunluk kadarını okuyunca ilk event'in bütün trigger ve metinlerine ulaşıyoruz. Sonra bir word atlıyoruz (bu duplike—ama 2 fazla—length byte'ı). Bir sonraki word yine uzunluk, sonra sıradaki event var.

Böyle böyle bütün event'leri düzgün parse edip görebiliyorum. Conditional event'lerin state machine'ini hala çözemedim, fakat 0x05'in soru, 0x08'in savaş olduğunu söylemiştim. Inventory'yi unutmuşum, 0x0409 da inventory'yi açıyor.

Örneğin üzerini aradığımız adamın üzerinden kısa zopa çıkıyor. Byte sekansı şöyle: 04 09 05 00 01 00 03 00 00 00 00. Biz bu ekranda 5 dolar, 1 kıvrık, bir de kısa zopa buluyoruz. Demek ki 3. byte dolar sayısı, 5. byte (belki word'dür) kıvrık sayısı, 03 de item olsa gerek. Memory'de kısa zopa 3. item'a denk geliyor, dolayısıyla hesap tutuyor gibi.

Bu arada 0xac de aslında caesar cipher'la encode edilmiş, aslında 0xb6, yani paragraf karakteri

Bunun için bir visualizer yazdım, elini yüzünü toplayıp atacağım. Fakat branching logic'i çözememek beni deli ediyor