Wpis z mikrobloga

@xan-kreigor: Wtedy wykorzystam inny sposób. Jednak wydaje mi się, że gdy będę potrzebował ponad 192 typy kafelków będę miał inny problem. Mianowicie korzystając z VertexArray jestem skazany na jedną texture per tileset.
Ale zarówno jedna jak i druga sytuacja nie powinna mnie spotkać przy planowanych grach więc będę się trzymał tego sposobu. :P
@xan-kreigor: to wtedy a) będzie można zapisać mapę w innym formacie o innym rozszerzeniu i również ją wczytywać b) zrobić na początku słownik i dynamicznie alokować paletę klocków c) kodować klocek w zmiennej ilości znaków (ale to zepsuje "podgląd" w notatniku. A niedrukowalne znaki można wprowadzać z każdej klawiatury. :P

@Leinnan: szanuję za grzebanie od podstaw a nie juniti. xD Pamiętaj żeby cache'ować VertexArray.
szanuję za grzebanie od podstaw a nie juniti. xD


@BennyLava: Unity ma swoje zalety, pozwala się skupić na tworzeniu samego gameplay'u. Mimo wszystko posiadanie większej ilości rzeczy(nie wszystkiego- w końcu to nie czysty OpenGL) pod kontrolą też ma swoje zalety :P
No i z zalet w C++ z SFML mogę pracować nawet na netbooku(o dziwo CLion wyrabia)

Pamiętaj żeby cache'ować VertexArray.


@BennyLava: A tutaj rozwiń o co ci chodzi :P
@Leinnan: Unity jest świetne do szybkiego prototypowania, ew. prostych gierek, ale nie powinno się na nim uczyć. Zaraz ktoś wyskoczy że albo się pisze silnik albo grę, ale myślę że każdy programista gamedevu powinien zrobić swój silnik, żeby wiedzieć co się dzieje pod maską. A osobiście to Unity mi nie pasuje, bo czuję się źle kiedy nie mam bezpośredniej kontroli nad pamięcią. xD

Możesz bez problemu mieszać rendering przez SFML-a i
No i wykorzystałem VertexArray zamiast Rectangle(kto korzystał z SFML wie o co mi chodzi)


@Leinnan: tutaj masz mnóstwo innych opcji do wyboru i znacznie szybszych, np. VertexArray/VBO+atlas textur, VertexArray/VBO+texture array. Inne podam jak sobie przypomnę, jednak nie warto tego tak optymalizować, bo dzisiejsze karty wyświetlą to bez zająknięcia, w dodatku wyświetlanie kafli będziesz optymalizował np. jakimiś drzewkami lub prościej testem na sprawdzanie widoczności biorąc pod uwagę górny lewy kafel i prawy
czuję się źle kiedy nie mam bezpośredniej kontroli nad pamięcią. xD


@BennyLava: to nie pasuje ci nie tylko unity, ale też C# .Net, Python i Java - praktycznie wszystkie popularne rozwiązania do gier oprócz C++. Nie widzę nic złego w tym, że garbage collector sprząta za nas pamięć - chroni to nasz ram przed złymi programistami :) A Unity jest bardzo wygodnym środowiskiem deweloperskim, również dla tych którzy wiedzą "jak to
@rotflolmaomgeez: no i dobrze, w tych językach nic większego się nie napisze, bo szybko poczujesz gc które zacznie wywoływać co chwilę takie małe lagi, no proste gierki w 2d oczywiście da radę.
No i znacznie większe zużycie pamięci.
(Piszę głównie z myślą o javie, bo tam najwięcej pisałem)
@Vitin:
@rotflolmaomgeez: minecraft tnie przez gc, to widac podczas profilowania, ale to też w dużej mierze wina kodu który momentami jest na prawdę chu... Więc beznadziejny przykład, bo gc w mc naprawdę czuć, a serwery też się z tym męczą.
W javie gc czuć w takich aplikacjach które muszą płynnie działać prawie każde przejście gc, widziałem już sporo jak i sam robiłem i profilowalem moje lub istniejące

I świetnie argumenty,
@rotflolmaomgeez: Noo nie koniecznie c# odpada:
Kontrole nad pamiecia mozesz sprawowac swobodnie przy uzyciu bloku kodu unsafe{}
Ostatnio bylem na spotkaniu grupy i gosc opowiadal.
Bardzo fajnie o tym oopwiadal Szymon Kulec w "Moja podróż do Krainy Ekstremalnej Współbieżności w .NET"

Do kontrolowania pamieci w grach jak najbardziej