Odkryj potencjał systemu Windows XP
Windows XP jest pełny nowych funkcji. Nie wszystkie z nich są udokumentowane i opisane. Kiedy pozna się podstawy jego obsługi, nadchodzi czas na opanowanie zaawansowanych możliwości i odkrycie tych, które przy pierwszym kontakcie są niewidoczne.
Sprawna praca z komputerem wymaga nie tylko opanowania funkcji systemu operacyjnego, ale również poznania innych, szybszych sposobów korzystania z nich. Często jednak trudno samodzielnie znaleźć rozwiązanie niektórych problemów. W takich sytuacjach przydaje się ilustrowany przewodnik, przedstawiający sposoby wykonania zadań.
W książce "Windows XP PL. 100 najlepszych sztuczek i trików" znajdziesz przejrzyście zilustrowane instrukcje wykonania 100 zadań. Pozwolą one odkryć nieznane możliwości systemu i zawierają sztuczki, które gwarantują, że praca z systemem Windows XP stanie się bardziej wydajna.
* Poprawa efektywności pracy z plikami i folderami
* Dostosowanie wyglądu pulpitu do własnych przyzwyczajeń
* Poprawa wydajności systemu
* Kopiowanie zdjęć z aparatu cyfrowego
* Nagrywanie płyt CD
* Rozwiązywanie problemów z systemem operacyjnym
* Przeglądanie stron WWW, korzystanie z poczty elektronicznej i faksu
W związku z brakiem obsługi przez Slideshare filmów zamieszczonych w prezentacji oraz sporadycznych rozbiezności z plikiem źródłowym zalecamy najpierw go ściągnąć.
Due to the fact the movies are not supported by Slideshare conversion and a few minor discrepancies with the source file, we recommend that you first download it.
Odkryj potencjał systemu Windows XP
Windows XP jest pełny nowych funkcji. Nie wszystkie z nich są udokumentowane i opisane. Kiedy pozna się podstawy jego obsługi, nadchodzi czas na opanowanie zaawansowanych możliwości i odkrycie tych, które przy pierwszym kontakcie są niewidoczne.
Sprawna praca z komputerem wymaga nie tylko opanowania funkcji systemu operacyjnego, ale również poznania innych, szybszych sposobów korzystania z nich. Często jednak trudno samodzielnie znaleźć rozwiązanie niektórych problemów. W takich sytuacjach przydaje się ilustrowany przewodnik, przedstawiający sposoby wykonania zadań.
W książce "Windows XP PL. 100 najlepszych sztuczek i trików" znajdziesz przejrzyście zilustrowane instrukcje wykonania 100 zadań. Pozwolą one odkryć nieznane możliwości systemu i zawierają sztuczki, które gwarantują, że praca z systemem Windows XP stanie się bardziej wydajna.
* Poprawa efektywności pracy z plikami i folderami
* Dostosowanie wyglądu pulpitu do własnych przyzwyczajeń
* Poprawa wydajności systemu
* Kopiowanie zdjęć z aparatu cyfrowego
* Nagrywanie płyt CD
* Rozwiązywanie problemów z systemem operacyjnym
* Przeglądanie stron WWW, korzystanie z poczty elektronicznej i faksu
W związku z brakiem obsługi przez Slideshare filmów zamieszczonych w prezentacji oraz sporadycznych rozbiezności z plikiem źródłowym zalecamy najpierw go ściągnąć.
Due to the fact the movies are not supported by Slideshare conversion and a few minor discrepancies with the source file, we recommend that you first download it.
4Developers: Krzysztof Narkowicz- Programowanie w branży gier komputerowychPROIDEA
Celem wykładu jest pokazanie od kuchni jak wygląda programowanie w branży gier komputerowych i czym się różni od innych branż. Ogólnie opowiem o specyfice projektów w naszej multidyscyplinarnej branży oraz o poszczególnych specjalizacjach programistów i wyzwaniach z jakimi muszą się zmierzyć. Pokażę jak projektujemy kod aby był możliwie optymalny i jak wykorzystujemy wielowątkowość. Opowiem jakich narzędzi używamy, dlaczego lubimy wymyślać koło na nowo i piszemy wszystko sami, dlaczego nasza branża jest ostoją języków wizualnych, które zostały uznane za ślepy zaułek na początku lat 90, dlaczego dalej optymalizujemy ręcznie kod oraz dlaczego używamy kilku języków programowania w jednej grze.
Prezentacja pokazuje po krótce rozwój komputerów, oraz opowiada z czego sa zbudowane i jakie urządzenia można do komputera dopiąć. Porusza również konieczność posiadania oprogramowania.
4Developers: Krzysztof Narkowicz- Programowanie w branży gier komputerowychPROIDEA
Celem wykładu jest pokazanie od kuchni jak wygląda programowanie w branży gier komputerowych i czym się różni od innych branż. Ogólnie opowiem o specyfice projektów w naszej multidyscyplinarnej branży oraz o poszczególnych specjalizacjach programistów i wyzwaniach z jakimi muszą się zmierzyć. Pokażę jak projektujemy kod aby był możliwie optymalny i jak wykorzystujemy wielowątkowość. Opowiem jakich narzędzi używamy, dlaczego lubimy wymyślać koło na nowo i piszemy wszystko sami, dlaczego nasza branża jest ostoją języków wizualnych, które zostały uznane za ślepy zaułek na początku lat 90, dlaczego dalej optymalizujemy ręcznie kod oraz dlaczego używamy kilku języków programowania w jednej grze.
Prezentacja pokazuje po krótce rozwój komputerów, oraz opowiada z czego sa zbudowane i jakie urządzenia można do komputera dopiąć. Porusza również konieczność posiadania oprogramowania.
1. czyli jak dokumentować swoją pracę, aby
po 20 latach móc napisać o tym książkę
Maciej Miąsik, WGK 2013
2. Projekty pomniejsze:
2013: Big 2 Bonanza
2011: Call of Juarez: The Cartel
2010: Jodie Drake and the World
in Peril
2011: Wiedźmin 2: Zabójcy Królów
2008: Wiedźmin (Edycja
Rozszerzona)
2007: Overclocked: A History of
Violence
1997: Wyspa 7 Skarbów
1997: Katharsis
1996: A.D. 2044
Projekty główne:
2012: Neuroshima Apocalypse
2007: Wiedźmin
2004: Sentinel: Descendants in
Time
2003: Mysterious Journey II:
Chameleon
2003: Codename: Nina
2001: Schizm: Mysterious
Journey
1998: Reah: Face the Unknown
1996: Fire Fight
1994: Heartlight PC
1994: Robbo
1992: Electro Body (aka Electro
Man)
3. O prawdę, bo prawda jest
najciekawsza, czyli kwestie
historyczne, czyli jak to tam było.
O sentymenty, czyli powroty do gier
młodości.
O nowe możliwości, czyli nowe
edycje, remake’i oraz nowe platformy.
O dobre pomysły, które zawsze można
wykorzystać ponownie.
4.
5. Czasem ktoś naprawdę chce napisać
książkę/artykuł o naszych grach.
Zostaniemy zaproszeni na wspominkową
konferencję.
Chcemy powspominać stare czasy.
Uczymy innych na naszych błędach.
Chcemy przypomnieć sobie dawnych
kolegów i zapomniane projekty.
6. Poczta elektroniczna jest łatwa w
archiwizacji.
Archwizujemy i backupujemy.
Dbajmy o ponadczasowe formaty (np.
mbox).
Nie kasujemy poczty, poza spamem.
7. From: "Tim Sweeney" <TIM@epicgames.com>
To: mail@xland.krakow.pl
Date: Wed, 29 Mar 1995 02:56:49 EST
Subject: Excessively Excellent!
Hi, Mark just sent me Excessive Speed a few minutes ago. This game is
*EXCELLENT*. Very impressive work, guys! This is going to be the
best-looking driving game on the PC -- it looks *much* better than
anything else I've seen.
This game is going to be a big hit!
We'll start playing through it and writing down suggestions. This
game needs a lot of fine-tuning, but it's not really very far away
from completion.
Thanks! Keep up the great work!
-Tim
---------------------------------------------------------------------
Tim Sweeney (tim@epicgames.com), Epic MegaGames, Inc. FTP:ftp.uml.edu
10. Działające wersje gry przy ważnych
milestone’ach.
Regularne snapshoty – gry jako
całości, oraz działań poszczególnych
ludzi.
Filmiki z prototypów oraz postępów
rozgrywki.
RSS czy inny zapis historii prac z
programów wspierających zarządzanie
(jeśli to możliwe).
11. Zdjęcia i filmiki:
Z pracy w biurze i poza nim.
Z integracji i zabawy.
Z premier i innych powiązanych wydarzeń.
12.
13.
14. Gramy, by powróciły wspomnienia.
Ktoś inny poprosi o możliwość zagrania w
naszą „vintage” grę.
Będziemy chcieli pochwalić się przed
znajomymi lub rodziną (szczególnie
dziećmi).
Będziemy chcieli użyć własnej gry jako
przykładu w edukacji/prezentacji.
15. Działające wersje (buildy) gry, wolne od
zależności i dziwnych systemów, np. DRM.
Emulatory czy wirtualne maszyny.
Czasem oryginalny hardware.
Będą problemy:
Kłopoty z emulacją i wirtualizacją –
konfiguracja, brak akceleracji.
Nie zawsze łatwo stworzyć build bez
zależności, szczególnie w przypadku gier
online.
Klucze i certyfikaty.
16.
17. Nowe platformy ożywiają stare schematy
rozgrywki.
Czasem drobny facelifting to wszystko,
czego trzeba – bo reszta daje radę.
Częściej jednak musimy dokonać
większych zmian – remake, ale
zachowując sedno starej gry.
Mamy też okazję „uwolnić” grę spod
reżimu praw autorskich – prawdziwe
abandoware.
18. Kody źródłowe oraz biblioteki zależne.
Środowisko programistyczne –
edytory, kompilatory, skrypty buildujące.
Dane gry (assets), najlepiej także w
wersjach źródłowych
Często także emulacja lub wirtualna
maszyna ze starym systemem
operacyjnym.
19.
20. Odrzucone prototypy z jednej gry mogą
przydać się w innej.
Oszczędzajmy sobie ponownego
prototypowania.
Mechanizmy rozgrywki można
recyklingować.
Historie raz opowiedziane można
opowiedzieć ponownie.
23. Dobre systemy nazewnictwa.
Eleganckie źródła, trochę komentarzy.
Dobra struktura plików i bibliotek.
Zależności archiwizowane ze źródłami.
Skrypty buildujące (automatyzacja).
Źródła assetów, najlepiej w osobnym
eleganckim repozytorium.
Regularnie archiwizowane działające
buildy.
24. Trzymamy pełne historie – kto wie, co
może się przydać.
Systemy się zmieniają – migrujmy
repozytoria na nowe wersje.
Archiwizujmy całe serwery z
oprogramowaniem i danymi – fizycznie
lub wirtualnie.
26. Backup, backup i jeszcze raz backup!
On site.
Off site.
Cloud.
Backupy trzeba weryfikować – testy
odzyskiwania, testy buildowania.
Rozmnażajmy backupy i
archiwa, szczególnie przy rozstaniach.
Nośniki nie są wieczne! Odświeżanie.
28. Najlepiej zachować je dla siebie.
Trzeba wiedzieć, kto po dekadzie je
posiada (jeśli nie my).
Jeśli prawa przysługują grupie, po
rozpadzie warto kogoś umocować do
łatwiejszego dysponowania.
Unikajmy blokady przez jednostki.
Przenosimy prawa majątkowe, ale dzieła
mogą zostać u nas (sprawdzić umowę).
29. To umowa zachowania poufności, a nie
umowa wymazania pamięci.
Zadbajmy, aby umowa NDA kiedyś
wygasała (5, 10 lat).
30. Firmy upadają i w raz z nimi giną nasze
dzieła (Sprawdzić, czy to nie Beretta
istniejąca od 1526).
Zadbajmy o własne kopie, nawet jeśli to
nie będzie w100% zgodne papierami.
31.
32. Trzeba proces dokumentowania prac i
archiwizacji efektów uwzględniać w
harmonogramach, bo zajmuje to czas.
Koniec projektu/produkcji powinien
obowiązkowo kończyć się porządną
archiwizacją z myślą o odległej
przyszłości.
Dbajmy, aby archiwa mogły przetrwać.
Nie oszczędzajmy na przestrzeni
dyskowej, nieustannie przecież tanieje.
34. Dobre archiwa to kopalnia wiedzy
designerskiej, produkcyjnej, edukacyjnej i
historycznej.
Niech ta wiedza nie ginie bezpowrotnie.
Nie możemy polegać na innych w kwestii
archiwizacji naszych dzieł – to nasz
obowiązek.
35.
36. Praktycznie abandonware.
Wciąż grane i wspominane.
W 2006 roku zaproponowałem
„uwolnienie” gier na licencji CC-BY-SA.
Miałem źródła, dane i biblioteki zależne.
Znalazłem kompilator Borland C++ 3.1.
Przekompilowałem w emulatorze DOSBox
zmieniając stosownie notę copyright.
Puściłem w świat.
37. Aktywiści projektu ScummVM wyrazili
chęć sportowania gry na ten system i
wiele platform go wspierających.
Nie było problemu ze zgodą właściciela
praw autorskich.
Nie mam źródeł. Być może ma je jedyny
programista, ale nie zgodził się ich
udostępnić.
Nie udało się ocalić projektu od
zapomnienia.
38. Niedoceniona, bo dobra, pierwsza
polska gra dla Electronic Arts.
Jest kompletny backup, danych i źródeł.
Nie udało mi się uruchomić samej gry –
konieczna wirtualizacja Windows 95.
Nie wiadomo, kto właściwie ma do gry
prawa autorskie – Epic nie ma umowy w
archiwach elektronicznych, EA ma to w
nosie, ja nie zatrzymałem kopii umowy.
„Modernizacja” tkwi w zawieszeniu.
39. Taka zabawa – wierny port gry Electro
Man w Pythonie, open source.
Wprawka programistyczna po
godzinach.
Koszmarny kod źródłowy – brak
praktycznie komentarzy, sprytne
makra, choć jest bardzo bazowa
dokumentacja.
Próba analizy kodu to prawdziwa męka –
nie starczyło mi cierpliwości.
40. Ukończona – pełna beta – ale nie
wydana gra platformowa.
Doskonały przykład edukacyjny.
Nietypowe narzędzie (3D Game Studio).
Nie uruchamia się poprawnie we
współczesnych systemach.
Wirtualizacje bez akceleracji nie dają
rady.
Nie wszystko stracone.
41. Społecznościowa gra online.
Aplikacja rozproszona – serwer i klient.
Serwer – Java, Frontend – Flash, Core –
Unity 3D.
Zależna od Facebook API.
Różne repozytoria, różne środowiska.
Nie mamy koncepcji na
archiwizację, szczególnie z
uwzględnieniem przyszłego upadku FB.