gnysek

Wspomniany build jest już dostępny. Btw. w update po premierze pełnej wersji będzie podobnoż info jak długo dokładnie trwa jeszcze beta (jakiś licznik czy cos).

Sprawdź w 39dll, on tak czyta pliki :)

Odczyt plików w GM jest baaaaardzo wolny. Dopiero w GM:Studio 1.1 albo 1.2 zostanie to poprawione, że zamiast czytać bajt bo bajcie, będzie ładować plik do pamięci i tylko zwracać odpowiednie fragmenty do których jest szybki dostęp.

Czy nie można tych roślin zapisać w tablicy/gridzie/liście/ds_mapie ?

Win XP na czysto zuzywa raptem 100MB ramu, tymczasem na Win 7 nie da się pracować dobrze bez co najmniej tych 2GB ramu, a co dopiero na Win8 (jesli ktos twierdzi, ze jest inczaczej - to tylko marketingowe zagrywki). Poza tym, Win 8 nie jest jeszcze w sprzedaży, zatem nie wszystko do niego trafiło.

No, w kolejnym buildzie zapis na dysk poprawiony, już nie nadpisuje spritów których się nie edytowało, dzięki czemu jak się edytuje tylko kod pomiędzy testami, to zapisuje się w pół sekundy. Można teraz będzie pracować z większymi projektami, gdzie jest więcej spritów, bez doczytywania z dysku :)

widocznie rysujesz tego surfece'a w innym obiekcie.

Wiec, jakbyś oba urządzenia postawił na biurku i o coś oparł, obraz by nie trząsł i zyskał na jakości nawet nagrywając podpaską. Ja ostatnio z iPadem zrobiłem ten sam błąd i mimo, że mój aparat nagrywa w HD, obraz był rozmyty...

Ten film jest prywatny :(

W samym programie działa to jakby po staremu - znaczy im więcej zasobów, tym dłużej trwa kompilacja i zapis, ale, jeśli dwa poniższe tickety zostaną zrealizowane, to będzie faktycznie szybko działać: - #3493 - jeśli jakiś sprite czy background od ostatniego zapisu nie był zmieniany, powinien być pomijany przy zapisie (zatem edytując tylko kod pomiędzy zapisami, zapisuje się tylko kawałek kodu), oraz gdy odpalamy grę, zasoby które lecą przez asset compilera który buduje z nich dużą teksturę, powinny być cacheowane - dzięki czemu jak zmienimy tylko kawałek kodu, to odpalają ponownie grę, zostaną użyte ostatnie tekstury, zamiast utworzone na nowo. Dzięki temu projekty powyżej 30 spritów powinny działać tak samo jak te z jedną małą grafiką. - #3492 - dźwięki są konwertowane za każdym razem na nowo, mimo, że nie ma takiej potrzeby - to potrafi wydłużyć kompilację o nawet kilka minut. Jeśli te zmiany zostaną wprowadzone (a pewnie w którymś momencie zostaną), to faktycznie nie będzie potrzeby ładować z osobnych folderów w locie. Btw. na Androidzie czy iPadzie ten trick i tak w sumie obecnie nie działa. Russell je przypisał do siebie, nie komentując, że pojawią się w GM:Next, więc pewnie w ciągu kilkunastu dni się tymi zmianami zajmie.

Licencje na betę są ważne na okres bety, więcej nie mogę mówić - wiecie, są translatory :P

Do czasu zakończenia bety - a ta już nie potrwa długo - tak.

UWAGA! Dziś kończy się okazja, aby pobrać program - od jutra nie można już dołączać do bety. ( https://twitter.com/#!/lordoftheyoyo/st...511219112513536 )

Zmienić depth obiektu który go rysuje.

To zostanie poprawione dopiero jakieś 2-3 tygodnie po premierze. (Im mniej będzie nowych bugów tym szybciej).

Chyba widziałem kotecka. Edit: tak, ja naprawde widziałem kotecka... Hello Kitty kolego?

Cośtam przebąkiwano, ale na 100% tego nie mogę potwierdzić.

Ja wiem, raptem 1 klocek na event, a przy dobrym dziedziczeniu czasem nie trzeba dopisywać nic.

W jakim sensie dynamiczne? Skoro potrzebujesz stworzyć jakiś obiekt w trakcie gry i przypisać do niego kod, który i tak musisz przecież wpisać wcześniej w GM, równie dobrze możesz dodatkowy obiekt stworzyć, a jak chcesz coś rozszerzyć, to masz parenty - aczkolwiek jak przejdziemy na pełne OOP to na pewno będzie więcej możliwości, niestety pierwsze wersje GM9/GMNext dopiero późną jesienią.

javascriptem mozna height zmienić :)

ta, ale w 50% przeglądarek to nie działa

Opcje są dwie - zeby muzyczka się nie wyłączała, strona nie moze sie przeładować. Więc - albo treść ładujesz do jakiegoś diva AJAXem - albo strona wyświetla się w iframe wielkim na całą stronę, co jest łatwiejsze do zrobienia - bo wtedy wszystkie linki będą się w tym iframe otwierać (o ile nie zostnaie ustawiony im inny target) - więc jakby nie trzeba wkładać w to specjalnie pracy, poza tym, że obecnej stronie głównej trzeba zmienić nazwę pliku, a zamiast niej dać taką z ramką która ten plik wyświetli - reszta powinna działać już bez zmian.

Po staremu, gdy GML był interpretowany w czasie rzeczywistym, to jest "w wirtualnej maszynie", a po nowemu kompilowany jest do pliku binarnego. Z tym, że tutaj prawdopodobnie jest zły opis i działa to dokładnie na odwrót - znaczy odznaczone pole to maszyna wirtualna, zaznaczone to binarka. Opcja zniknie w następnych wersjach i będzie się już domyślnie kompilować do binarki, po to wyleciało zresztą execute_string i variable_xxx.

Zapytam, jak dostanę odpowiedź to ją tu dam. btw. No, to chyba już tworzenie apek będzie działać.

Ale nie pozwalało na kompilację do binarki, dzięki czemu trudniej gry zdekompilować i działają szybciej.