Pokaż wiadomości

Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.


Wiadomości - vashpan

Strony: [1] 2 3 4 5 ... 145
1
Platformy mobilne / Odp: Tworzenie softu na konsolę Nintendo 3DS
« dnia: Wrzesień 18, 2012, 23:28:42 »
Cytuj
- gdzie Nintendo wspiera swoim supportem takie osoby jak ja?

Przeczytalem to i troche smutno mi sie zrobilo ze bedziesz musial uslyszec gorzka prawde....

Nintendo "troszeczke" przesypia nowe czasy.

2
Platformy mobilne / Odp: Tablet z Androidem a back-button
« dnia: Lipiec 30, 2012, 08:27:51 »
No coz... cala magia Androida.

I tak, kupiles chyba jakis ruski tablet ;) Na twoim miejscu chyba bym go sprzedal i rozejrzal sie na czyms co ma Androida 4.x, bardziej przyszlosciowy.

3
Narzędzia / Odp: Xcode - testowanie gier (multitouch)
« dnia: Lipiec 30, 2012, 08:24:46 »
http://www.vimov.com/isimulate/

Ew. sam mozesz napisac skrypt/programik z odpowiednia sekwencja, albo np. przypisac odpowiednie miejsca odpowiednim touchom ( to juz zabawa na niskim poziomie w wysylanie eventow inputu ) Nie jestem tez pewien, ale przy gladziku, albo tzw. "magic mouse" chyba dziala multitouch na emulatorze ?

4
Programowanie grafiki / Odp: [SFML] Gui
« dnia: Lipiec 18, 2012, 08:50:19 »
Zalezy jak wiele funkcjonalnosci oczekujesz po tych przyciskach. W najprostszym przypadku moze to byc prosta klasa ( a nawet struktura ) z tekstem i akcja ktora ma sie wykonac po kliknieciu. W oknie zas trzymasz po prostu tablice, albo drzewo takich przyciskow.


5
Java / Odp: Java - w czym problem?
« dnia: Lipiec 11, 2012, 21:31:53 »
Dynax plecie glupotki ;) Jest to normalny natywny kod maszynowy ARM wykonywany przez procesor. Ze wzgledu na architekture systemu czasem po prostu trzeba troche z poczatku Javy uzyc zeby zrobic pare rzeczy.

Asmodeusz: Ja pracuje w firmie ktora zajmuje sie w duzej mierze portowaniem i tworzeniem gier na Androida i 90% tych gier ( a sa to gry z Top100, praktycznie wszystkie. Duzi klienci ) jest napisana w C++. Ale jakos specjalnie to o niczym nie swiadczy, wynika to glownie z tego ze wiekszosc tych aplikacji bylo pisanych na poczatku na iOS ( albo inne systemy )

No wlasnie, dochodzimy do kolejnej rzeczy, Java... nie jest przenosna. Nie jest przenosna w sensie gier... Ze wszystkich istotnych platform dla gier ( Windows, XBox 360, PS3, iOS, Android, Mac OS X ) Java jest dostepna na 3... A na 1 ( Android ) nie w tej formie co na 2 pozostalych ( J2SE ) Jedynym przenosnym w tym kontekscie jezykiem jest C/C++, tym bardziej ze napisano juz w nim ogrom silnikow i frameworkow. ( + ogromne silniki jak Unity  i UE3 )


Co do powolnosci, Java jest powolna i zasobozerna. Tak samo jak C#, i nie mam Javy sprzed 10 lat.... Runtime na takim poziomie abstrakcji po prostu kosztuje. Nie ma tutaj co zaklinac rzeczywistosci. Czy winni sa w duzej mierze marni programisci ? Byc moze... Wiele aplikacji przez to jest po prostu kosmicznie niestabilna i jest wrecz synonimem "syfu" dla przecietnych userow. Z drugiej strony mamy zastosowania serwerowe, gdzie dla mnie np. Java jest naturalnym wyborem ze wzgledu na koniecznosc dlugiego dzialania ( duzo mniejsze prawdopodobienstwo leakow )

6
Branża / Odp: Zarabianie na grach FLASH
« dnia: Lipiec 08, 2012, 13:18:18 »
Co to znaczy "korzysta" z OpenGL ? Wiadomo ze ogolny kod do uzywania z zewnatrz bedzie mniej wydajny niz natywnie napisany renderer dostosowany do wlasnych potrzeb, komunikujacy sie tylko z systemem i gpu.


A ludzie naprawde czesto zapominaja ze runtime moze byc rownie wielkim narzutem. Maszyna wirtualna oczywiscie nim jest, kod kompilowany w locie nigdy nie bedzie takiej jakosci jak ten kompilowany statycznie ( poza paroma wyjatkowymi sytuacjami gdzie VM moze 'inteligentnie' dokonac jakis optymalizacji, np. stosujac odpowiedni zestaw rozszerzonych instrukcji w zaleznosci od sprzetu - moje empiryczne testy jednak wskazuja ze... nie robi tego ) - zwyczajnie nie ma czasu na skomplikowane optymalizacje, bo wszystko dziala w locie. Ale jezyki wyzszego poziomu oprocz samego generowania kodu w locie, maja takze runtime, garbage collector, dynamiczny system typow i cala mase 'sprawdzen', rzutowan etc. ktore wplywaja na wydajnosc oraz zuzycie pamieci.

 

7
Programowanie grafiki / Odp: SFML - spadek fps
« dnia: Lipiec 07, 2012, 19:36:41 »
Karta graficzna nie jest za bardzo przyzwyczajone do przelaczania kontekstu miedzy dwie aplikacje ;)

8
C++ / Odp: Nazewnictwo klas, zmiennych, funkcji itd.
« dnia: Lipiec 07, 2012, 19:31:02 »
Ja uzywam przedrostki tylko do memberow klas oraz zmiennych globalnych, ew. statycznych globalnych ( sg ) ( ostatnio pisze glownie w Objective-C a tam to dosc czesty widok przy implementacji chociazby singletona )

Ostatnio zastanawiam sie nad uzyciem "_" do pol klas, nie lubilem tego ale ostatnio doceniam. Oznaczenie jakos zmiennych klasy jest przydatne. Byc moze ty pamietasz co jest w twojej klasie czym, ale zmienisz zapewne zdanie jak bedziesz czytal cudzy kod, albo swoj po 6 miesiacach ;)

Nazwy funkcji:
void someFancyLongFunction(int a, float b);

Klasy/enumy/struktury/typedefy:
class MySuperHiperClass
w C++/Javie/C# "I" do klas abstrakcyjnych/interfejsow. W Obj-C jakos podazam konwencja systemowa, z nazwy wynika przewaznie czy cos jest interfejsem ( W Obj-C nazywanym 'protokolem' ) czy nie.
Typ to typ. Oznaczanie tego jako "C" czy "Class" nie ma zadnego sensu IMO.

Makra i wszelki stuff zw. z preprocesorem z WIELKICH_LITER

Nazwy plikow - CamelCase jak klas. Od nazwy klasy (glownej klasy ) ktora implementuja. Jak nie ma tam klasy, to po prostu od zadania ktore jest zaimplementowane w danym pliku.  Zreszta, to glownie zalezy od projektu. Czasami sa to tez same male literki. W C++ naglowkom staram sie nadawac roszerzenie .hpp - zeby podkreslic ze chodzi o C++ a nie o C.

===

Wszystko to oczywiscie nie tyczy sie pracy. Tam po prostu przyjmuje sie konwencje ktora jest uzywana wczesniej, albo stworzona przez leada na poczatku projektu ( czyli przewaznie jego konwencja ;) )

9
Branża / Odp: Zarabianie na grach FLASH
« dnia: Lipiec 07, 2012, 19:03:58 »
Kod logiki to nie wszystko, we Flashu to runtime robi ogromny narzut, a nie sam kod gry czy aplikacji.

10
Silniki / Odp: Corona SDK na mobile
« dnia: Lipiec 07, 2012, 18:11:55 »
Zastanawiam sie jakim niby cudem sprawili ze IDE nie dziala na Hackintoshu :) System to system, co ma hardware do tego? Skoro dzialaja na nim wszystkie aplikacje na OS X, takze te od Apple, takze XCode i wszelkie deweloperskie narzedzia z mozliwoscia bezproblemowego budowania aplikacji na urzadzenia, debugowania, tworzenia buildow do dystrybucji i wysylania na AppStore ?

Srodowisko jest ciekawe, jezyk to jak zwykle kwestia preferencji, Lua ma moze latwa, elegancka skladnie, ale latwo sobie strzelic w stope ( jak w kazdym dynamicznym jezyku ) no i nie ma prawdziwej obiektowosci


Dla indie dewelopera jedyne koszty to device i ew. komputer. Kazde +200$ robi jednak roznice ;) Ale SDK wyglada na calkiem sprawne jezeli ktos juz ma troche doswiadczenia albo po prostu mysli w kategoriach biznesowych.

I tak btw: Obj-C, po przebrnieciu przez pierwsze WTF jak sie zobaczy skladnie, to nowoczesny, prosty i jednoczesnie skuteczny jezyk, znacznie latwiejszy do ogarniecia niz C++ i znacznie lepiej od niego nadajacy sie do programowania rzeczy opartych na "zdarzeniach" ( np. UI )

11
Branża / Odp: Zarabianie na grach FLASH
« dnia: Lipiec 07, 2012, 17:53:02 »
Na mobile przeciez wlasnie nie ma zadnego "srodowiska AIR" Ja mowilem o mobile, byc moze niezbyt jasno sie wyrazilem ;)

Trudnosc jest identyczna - kod i tak musi byc w koncu przekonwertowany do kodu natywnego - tylko ze na mobile robi sie to przed odpaleniem aplikacji a nie w trakcie ( zakladajac ze kompilacje JIT przy Air - ale czy tak jest na pewno tego nei wiem )

12
Branża / Odp: Zarabianie na grach FLASH
« dnia: Lipiec 07, 2012, 11:27:26 »
Gry z AIR budowane na mobile dzialaja troche na innej zasadzie niz aplikacje na PC ( tam chyba mamy kompilacje bytecodu Flasha do kodu natywnego + runtime ) i dlatego czesto dzialaja na mobile nawet lepiej i plynniej niz te same Flashowe aplikacje na PC.

13
Produkcja / Odp: iOS developer licence
« dnia: Lipiec 04, 2012, 20:52:12 »
Ale unity korzysta ;) Poza tym sam OS X jest juz na tyle uzalezniony od pomocy GPU przy rysowaniu okien ze po prostu obsluga systemu to niebo a ziemia

Dziadostwo? To odpal emulator Androida :D Tego nie da sie uzywac w ogole. A w symulatorze iOS mozna swobodnie testowac nawet calkiem skomplikowane gierki. Aplikacje 'zwykle' za to mozna w sumie tylko na symulatorze testowac i beda dzialaly elegancko. Renderer jest software'owy dlatego zeby moc w miare dokladnie odzwierciedlic zachowanie sie GPU na urzadzeniu. Przewaznie jest ok.

14
Produkcja / Odp: iOS developer licence
« dnia: Lipiec 04, 2012, 18:30:58 »
Przede wszystkim dlatego ze na maszynach wirtualnych prawie nigdy nie ma akceleracji grafiki....


15
Ludzie z naszych firm mobile wykorzystują rodzinę/znajomych/dziewczyny, by sprawdzać grę na ich device'ach od czasu do czasu. Sami mają co najwyżej kilka urządzeń. To jak PC - testujesz na najpopularniejszych konfiguracjach, nie na wszystkich.
Grę AAA często testuje się na max. 100 kompach i tyle ;)

No rozumiem, te 100 to wiadomo ze na wyrost ;), ale duze firmy ktore portingiem na Androida sie zajmuja to maja i wiecej urzadzen dla QA... Moze nie jest to J2ME, ale rozrzut potrafic byc spory. A dla przecietnego indie-deva co ma jeden telefon ciezko jest np. przetestowac i zoptymalizowac na rozne GPU ( Tegra, Adreno, PowerVR... to tylko 3 najpopularniejsze, kazda nieco inaczej potrafi sie zachowac )

iOS z punktu widzenia dewelopera jest po prostu spojny i przewidywalny, docenia sie to dopiero gdy tworzy sie obie platformy ;) Ale ma tez swoje wady wiadomo.

Strony: [1] 2 3 4 5 ... 145