Autor Wątek: Dab -- język programowania na potrzeby gier  (Przeczytany 24654 razy)

Offline rm-f

  • Użytkownik
    • Tu trolluje

# Wrzesień 09, 2011, 00:37:00
Tylko dodaj opcję do optymalizacji, bo ktoś wpadnie napisać demo a kompilator wygeneruje wszystkie assety osiągając rozmiary binarki na poziomie np. 1.5GB

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Dab

  • Redaktor
    • blog

# Wrzesień 09, 2011, 00:43:42
Fakt. :) Swoją drogą, proceduralna generacja to byłoby ciekawe podzastosowanie języka :)

Offline counterClockWise

  • Użytkownik

# Wrzesień 09, 2011, 12:36:58
Chociażby eliminacja zarządzanych automatycznie obiektów.
W sensie w ogóle zrezygnowanie z automatycznego zarządzania tak? Tak należy to zdanie rozumieć?

Przykładem jest hashowanie stringów w czasie kompilacji, co daje sporego kopa hashmapom.

Ale to tylko da się zrobić dla stringów znanych w czasie kompilacji, więc chyba nic dynamicznego (np. proceduralnie wygenerowanego, otrzymanego przez HTTP czy wczytanego z pliku) już nie. Ciekawe, bo pisałem niedawno interpreter zmodyfikowanego podzbioru Prologa - więc inspiruje się trochę, ale tam niestety gdzie indziej jest nacisk - bardziej na leksykalne, symboliczne reguły niż obliczenia na liczbach. Hashowanie stringów też by się tam przydało, ale nie widzę opcji, gdy symbole są dynamicznie dodawane, a wygenerowanie wszystkich potencjalnych połączeń symboli (reguły + uporządkowane n-tki symboli realizujące reguły) spowodowałoby ogromną eksplozję kombinatoryczną.

« Ostatnia zmiana: Wrzesień 09, 2011, 12:38:47 wysłana przez counterClockWise »

Offline mosowski

  • Użytkownik

# Wrzesień 09, 2011, 12:39:12
Cytuj
Hashowanie stringów też by się tam przydało, ale nie widzę opcji, gdy symbole są dynamicznie dodawane
Prawda, ale zawsze można hashować stringi leniwie.

Offline Dab

  • Redaktor
    • blog

# Wrzesień 09, 2011, 13:57:59
Tutaj problem jest trochę inny, bo zbiór wszystkich możliwych własności (Position, ModelFilename, Color, itd itp) jest znany i niezbyt duży (góra sto kilkadziesiąt elementów). Oczywiście, na nazwy generowane dynamicznie hashowanie w czasie kompilacji (w skrócie HWCK) nic nie da, ale to jest mały % use-casów (skrypty, wczytywanie plików itd). W większości przypadków po prostu renderer czy fizyka leci po obiektach i zawsze odwołuje się do tych samych kluczy. Z HWCK nawet w debugu odwołania po kluczach mogą bez żadnych większych kombinacji być tak szybie jak normalna tablica.
« Ostatnia zmiana: Wrzesień 09, 2011, 14:00:04 wysłana przez Dab »

Offline Kos

  • Użytkownik
    • kos.gd

# Wrzesień 11, 2011, 23:32:56
Perfect hashing?

Offline Xender

  • Użytkownik

# Wrzesień 11, 2011, 23:56:46
@Kos - a od kiedy to perfect hashing znajduje zastosowanie w hashmapach?

Offline Kos

  • Użytkownik
    • kos.gd

# Wrzesień 11, 2011, 23:59:02
Ale mowa o hashmapach compile-time, więc perfect hash zaoszczędziłby tu nieco miejsca... O ile dobrze rozumiem, o czym mówimy. :)

Offline Dab

  • Redaktor
    • blog

# Wrzesień 12, 2011, 01:29:56
Zamiast perfect hashing można też wstawić resolvowanie enuma po kluczu i wyjdzie na to samo, a prościej. ;)

Offline virtfanxyr5

  • Użytkownik

# Wrzesień 24, 2011, 11:13:52
Witam
Jeśli chodzi o to twoje narzędzie, to u mnie też nie-działa:
- przyciski na pasku narzędzi: nowy plik, otwórz, wytnij, kopiuj, wklej
- debugger-a nie-mogłem przetestować, gdyż wciśnięcie ,,Run'' wywala program, a przy wciśnięciu ,,Run internally'' co prawda uruchamia się, ale nie-da się zatrzymać ani przyciskiem ,,Stop'' ani ,,Pause''
- wciśnięcie ,,Fix definitions'' także wywala program
- i sugestia: gdyby menu ,,File'' umieścił na pasku narzędzi, zaoszczędził by sporo miejsca

Ja także miałem podobny pomysł, ale nieco odmienny od twojego, takie elastyczne IDE przeznaczone do tworzenia gier, w którym łatwo można by testować tworzoną grę (zawsze w narzędziach do C++, nie-podobał mi się długo trwający proces kompilacji), ale narzędzie nie-powstało bo brakło motywacji, ale może warto by do tego wrócić
« Ostatnia zmiana: Wrzesień 24, 2011, 11:20:34 wysłana przez virtfanxyr5 »

Offline assa

  • Użytkownik
    • Assa.log

# Wrzesień 27, 2011, 19:29:45
Język spoko, jednak ma kilka wad:
-wzorujesz się na C++ - to nie jest dobry przykład dobrze rozplanowanego języka,
-z tego co widzę brak obiektowości(chyba na razie?) - zaimplementuj coś w stylu SmallTalk'owym jednak skłaniając się w stronę CLOS( Common Lisp Object System) czy COS( C Object System),
-brak binarki do pobrania....
-mało info o platformie,
-zmień nazwę bo to brzmi co najmniej dziwnie...
btw.z tego co wiem LLVM kompiluje do bytecodu a nie do natywnych plików binarnych. Zatem twoje dzieło i tak do szybkich nie należy...
PS: to nie jest próba ataku, obrażania etc.

Offline rm-f

  • Użytkownik
    • Tu trolluje

# Wrzesień 27, 2011, 20:53:38
assa, prawie same kule w płot.

Offline qad

  • Użytkownik

# Wrzesień 27, 2011, 21:48:39
mam takie pytanie może trochę od końca (zależy od punktu siedzenia)...... kto jest targetem tego produktu ? bo narzędzie ma niezły potencjał komercyjny

Offline Dab

  • Redaktor
    • blog

# Wrzesień 27, 2011, 21:55:19
virtfanxyr5: te przyciski po prostu nie mają (jeszcze) implementacji. ;)

assa: może przeczytaj najpierw dokładnie czym jest Dab i/lub LLVM. :)

qad: początkowo: małe projekty (prototypowanie, konkursy z limitem czasowym itp), docelowo: gry i technologia AAA, tudzież inne projekty wymagające wysokiego zarówno stosunku wydajność/wysiłek jak i jego składowych.
« Ostatnia zmiana: Wrzesień 27, 2011, 22:15:49 wysłana przez Dab »

Offline qad

  • Użytkownik

# Wrzesień 27, 2011, 22:02:48
qad: początkowo: małe projekty (prototypowanie, konkursy z limitem czasowym itp), docelowo: gry i technologia AAA, tudzież inne projekty wymagające wysokiego zarówno stosunku wydajność/wysiłek jak i jego składowych.

sorki, chodziło o target ludzki nie projekty
czyli mówiąc moim ulubionym językiem komu to sprzedać ;-) a nie poco