Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1: CommentAuthortomaswoj
   • CommentTime9 Jun 2012

    
   Czesc,
   
   przymierzam sie do hobbistycznego projektu na Atari - gry w stylu "Kupca" i zastanawiam sie w jakim jezyku to napisac. Rozwazam 4 opcje - Atalan, Action!, C (CC65) i TurboBasicXL. Chcialbym skupic sie mniej na technikaliach , a bardziej na samej mechanice gry (i skromnej, acz cieszacej oko oprawie, male piktografiki, ikonki, itd). Wg aktualnego stanu gra ta swoim sposobem rozgrywki (i forma) najbardziej przypominalaby Kupca (lub Przemytnika).
   
   Czy ktorys z w/w jezykow nadaje sie mniej/bardziej do tego typu gier? (turowe, mala dynamika na ekranie, duzo logiki, elementy losowe)
   
   Jesli chodzi o doswiadczenie programistyczne to mam dosc spore w jezykach 'wyzszego' poziomu, jak Java, C/C++. Oczywiscie nie mam nic przeciwko niewielkim wstawkom w maszynowym jesli zaszlaby taka potrzeba, ale chcialbym zeby aplikacja jako calosc byla w wyzszym poziomie, bo spodziewam sie czestych 'refaktoringow' mechaniki rozgrywki (na zasadzie prob i bledow).
   
   Z gory dzieki za wszelkie sugestie!
2. • 2: CommentAuthorstreak
   • CommentTime9 Jun 2012

    
   Jesli chcesz wygodnie programowac dla atari uzywajac crosscompiler'a na PC, to nie masz zbytnio wyjscia. CC65, jest do tego najlepszy. Szczegolnie ze mozesz go sobie samemu skompilowac na wiele systemow bez problemu [linux/win/mac.. itp..].
   
   Osobiscie robie w nim maly projekcik [nic wielkiego] uzywajac do tego tylko i wylacznie OpenPandory, bo prawdziwego ataraka nie posiadam do dawna.
3. • 3:
      
     CommentAuthorxeen
   • CommentTime9 Jun 2012

    
   Z języków wyższego poziomu cc65 jest najlepszy do tego, moim prywatnym zdaniem - polecam kurs Ilmenita z atarionlie - to są wystarczające podstawy do tego, aby zacząć.
   Zalety: piszesz na PC, kompilujesz na PC w swoim środowisku programistycznym itp. Relatywnie wygoda jest. Jazda w Action na XL/XE + kruczki jakie trzeba znać to dla mnie subiektywnie męka. Jeżeli chodzi o Atalana - fajny, nowy język, ale na razie nie było zbyt wielu projektów w tym napisanych, nie ma wsparcia składni w środowiskach - jeżeli chcesz przecierać szlaki - to jest ku temu idealna okazja - pewnie jest szybszy od CC65, ale nie testowałem :) W cc65 masz od biedy zmienne odpowiedniej precyzji (nie za szybkie, ale w atalanie sam będziesz sobie musiał pisać procki - to już lepiej w asmie to robić - bo przynajmniej w eclipsie jest wygoda z pluginami)
   W basic'a się nie baw, jeżeli mogę coś doradzić (ślepy tor - wiem po sobie) - mało pamięci, wolny jak diabli.
   
   kursik:
   
   ->link<-
   
   ->link<-
   
   ->link<-
4. • 4:
      
     CommentAuthorjhusak
   • CommentTime9 Jun 2012 zmieniony

    
   Nie bierz się za atalana. To jest projekt, w którym masochiści piszą:)
   A tak na poważnie - jest problem ze zmiennymi i ograniczeniami. Obszar na zmienne rośnie w niekontrolowany sposób i po prostu w pewnym momencie wszystko przestaje działać. programy często się nie kompilują, bo zamienisz a*b z b*a (obrazowy przykład) Rudla traktuje ten projekt jako pole do eksperymentów, raczej nie inwestuje czasu w nudne rzeczy.
   
   Mimo wszystko da się w Atalanie napisać prostą gierkę; jednak wąż, tetris, czy układanka to szczyt, co można w tym języku zrobić.
   
   W przypadku gier typu Kupiec stosuje się często gęsto liczby zmiennoprzecinkowe, więc i Action! odpada. zostaje cc65 z typem float i TB XL, który jest lekki, łatwy i wygodny. Wbrew pozorom TB może być szybszy ze względu na bardzo szybkie procedury float :)
   
   Jednak sposób operowania zmiennymi tekstowymi może być w TB XL wygodniejszy.
   
   Ja bym spróbował w cc65, bo to jednak C i można taką grę przeportować na co innego :)
5. • 5: CommentAuthorrudla
   • CommentTime10 Jun 2012

    
   Jakub is right. I would not recommend using Atalan right now.
   There are many rough edges and I'm still experimenting with syntax and features (even it it's not entirely true that I do not invest time into boring issues :-)
   
   For example support for strings is not really ready.
   I'm now trying to develop some game in Atalan myself, so some of the usability problems get fixed.
   I have no idea, when the work will be done however.
   I have new 4 month old son now, and have very little time for Atalan.
   
   Rudla
6. • 6:
      
     CommentAuthorMaW
   • CommentTime10 Jun 2012

    
   Rudla, could you change Atalan in Open Project ? It would be better for this...
7. • 7:
      
     CommentAuthorjhusak
   • CommentTime11 Jun 2012 zmieniony

    
   @Rudla, congratulations! A 4-month old man begins to interact with the world - he tries to catch everything. My 7-month old son can catch my moving hand, and he is able to do mess because during carrying he catches various things. And he can keep toys for three hours not letting them fall down!
   
   About atalan:
   Although in it there are many nice features, they are coded as "magic". I was not able to understand the code, only Rudla understands it in 100%.
   Well, there are many many tweaks, optimizations, and ifs which don't make the code easy to read.
   
   I have even heard about: hey, the Atalan is cool, but it is the one-man battlefield. Let's write something similar or even the same, but in a good-old-fashonable way, maybe not so efficient, but working and stable.
   
   The things that have to be cleaned-up:
   The strange code (but time-efficient) generated by expression calculation, which makes a lot (A LOT!) of temporary variables! (am I right yet? or it is done?)
   The nice (in the beginning) method of code generation using code templates which at the end is a real P-I-T-A if one wanted to write it once and all. However it opens the field to code optimizations, etc, in present form it is a dead-end-road IMO.
   Very custom parser and context grammar analysers very prone to errors and not clean-looking at all.
   
   So the first thing would be to write FULL LALR(1) GRAMMAR of atalan. It may be tricky because of indent-driving code blocking.
   
   But in truth i do not see many programmers interested in developing of Atalan (I was once, but I have lost my interest because of instability, returning bugs and things that stop working from version to version - the lack of tests was the main victim).
   
   I personally think at something that PROGRAMMERS WOULD LOVE and yet simple and close to assembler; but for now only in a real deep depths of my mind :)
8. • 8: CommentAuthortomaswoj
   • CommentTime11 Jun 2012

    
   Dzieki za podpowiedzi i sugestie. Szczerze mowiac korcil mnie Action! i TB XL (ze wzgledu na ich niewatpliwa oldskool'owa 'atarowosc') ale moze lepiej zwiekszyc szanse powodzenia realizacji projektu i robic w czyms przenosnym (wieksza motywacja do ukonczenia) i wygodnym (vs. ilosc czasu jaki mozna na projekt poswiecic - czyt. efektywnosc developmentu). Najprawdopodobniej pojde wiec w cc65 :)
   
   Btw. moze trivia (i moze RTFM), ale czy w cc65 jest mozliwosc podania jako targetu x86 - tak zeby pierwsze uruchomienia testowac na PC? Widzialem kiedys posty ilmenita (odnosnie His Dark Majesty zdaje sie) ze zaczynal kodowanie/testowanie mechaniki HDM na PC, a pozniej przeniosl sie na target atari.
9. • 9: CommentAuthorilmenit
   • CommentTime11 Jun 2012 zmieniony

    
   Zrób pośrednią warstwę prezentacji. Te same funkcje (np. wypisz tekst) powinny mieć różną implementację zależnie od platformy. Przy kompilacji dołącz odpowiedni plik .h i .c.
   W ząłączniku kod z HDM odpowiadający za warstwę prezentacji.
   I jeszcze rady:
   1. Używaj zawsze 'unsigned char' i 'signed char' zamiast samego 'char'. W CC65 samo 'char' jest typu unsigned. Wszystko opisane w dokumentacji, warto przeczytać.
   2. Pisząc w CC65 nie używaj struktur. Procesor 6502 nie ma wystarczająco uniwersalnego adresowania by szybko dostać się do pól struktury, gdy masz je np. w tablicy.
   Czyli zamiast:
   

   struct pozycja {
     unsigned char x;
     unsigned char y;
   };
   struct pozycja pozycje[64];
   

   
   używaj:
   

   unsigned char pozycje_x[64];
   unsigned char pozycje_y[64];
   

   • layer.rar
10. • 10: CommentAuthorrudla
    • CommentTime11 Jun 2012

     
    @MaW: Atalan is open source from the beginning. You may fork it if you wish. I will give you some assistance if you want.
    
    @jhusak: Thanks. Having a child is beautiful indeed, even if this one is somewhat demanding :-)
    
    About Atalan:
    
    In my opinion, the compilers generally are mess to read and understand. Maybe not parsers, but code optimization code without the doubt.
    
    I don't know, if Atalan if worse or better in this part, as I understand the code quite well :-) However I know, that I had problem understanding this type of code in other compilers and was basically unable to get some useful insights about how to perform optimizations.
    
    Note, that architecture of 6502 is very compiler unfriendly and many classic optimizations can not be applied.
    
    The main problem with Atalan as I see it is that I always succumb to the temptation of adding another optimization or new language feature or refactor it so it is more readable :-) Very often, it means rewriting significant portions of optimization code and breaking much of existing functionality. And we are talking about major changes like supporting processor flags (something not supported in many commercial compilers) etc. So it's hard to make Atalan stable, while enhancing it this way.
    
    The good news is, that I'm slowly running out of options for major features :-) so maybe I will be able to make Atalan more stable.
11. • 11: CommentAuthorrudla
    • CommentTime12 Jun 2012

     
    Oh, by the way. I believe it should be easy to develop separate parser for Atalan that would produce instructions for translation. And I mean it may be even completely different syntax.