Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 05/18/2018 in all areas

  1. X-Box Game Pass (ważne do 1 lipca): YQTW2-YVTWM-XXRHV-GMHH6-3Q76Z Assassin's Creed 3 (do 20 maja): ME9M-78PM-9GUW-83GW Grotesque Tactics (do 30 czerwca): 8HW4A-9JJYF-AWYFT
    1 point
  2. Ewentualnie trochę drożej wersja z mniejszym SSD, ale w zamian z i7 7700HQ https://www.morele.net/laptop-dell-inspiron-5577-5577-2967-1749615/
    1 point
  3. Brałbym bez zastanowienia takiego Della Inspirona ma wszystko o co prosiłeś https://www.x-kom.pl/p/396956-notebook-laptop-156-dell-inspiron-5577-i5-7300hq-8g-2561000-win10-gtx1050.html -mocny nie niskonapięciowy procesor -kartę graficzną, dzięki której pogra w takie gry jak fortnite, lol na ultra -dysk ssd + zwykły na dane -windows 10 no i to Dell, bardzo ładny zresztą
    1 point
  4. Oczywiscie, ze manipulacja, ale kto tego nie sprawdzi i nie doczyta, ten wiedziec tego nie bedzie, czyli cel TVP zostanie osiagniety. Wiadomo, ze PO swiete ani nie bylo, ani nie jest, ale takie zmanipulowane przekazy robione przez Prawych i Sprawiedliwych podwazaja ich wiarygodnosc i ich swiete darzenie do prawdy.
    1 point
  5. Patrząc na zdecydowaną większość wytworów kultury masowej ( a w szczególności na gry) bardzo szybko dochodzi się do wniosku, że główni bohaterowie mają wręcz obowiązek dokonywać czegoś ważnego. Wiejski parobek albo skazaniec zostaje wywyższony jeśli autorowi zachce się uczynić go postacią kluczową dla opowieści- no bo dlaczego nie? Nic w tym złego nie ma- na pierwszy rzut oka. Na pierwszy rzut oka wiemy również, że czeka nas kolejna, przerysowana historia o zdradzie, miłości i heroizmie. No ale nie do tego zmierzam. Życie jest jakie jest. Mało który gracz miał możliwość zrobienia czegoś ważnego albo przynajmniej zauważalnego w swoim środowisku. Wirtualna postać którą sterujemy bez przerwy niemalże bierze udział w mniej lub bardziej ekscytujących wydarzeniach. Porwania, strzelaniny, eksploracje egzotycznych miejsc albo romanse (oczywiście z wyidealizowanymi partnerkami). Fałsz który bardzo mocno przyciąga nas do monitora. Pewnie dlatego, że w życiu jesteśmy kimś " nie-istotnym". I tutaj zaczyna się moje, małe przemyślenie. Co jeśli odebrać by nam całą "wielkość" i "specjalność"? Dać do zrozumienia, że jesteśmy tylko małym trybikiem w machinie wydarzeń. Oddać komuś innemu uprawnienie do podejmowania decyzji? Większość bohaterów zaczyna jako jakiś kmiot/szeregowiec/adept na najniższym szczeblu organizacji. A jeśli nasza możliwość rozwoju ograniczyłaby się tylko do jednego-dwóch szczebli w hierarchii jak to bywa w życiu? Czasem zaczynamy u boku kogoś "ważnego" i prędzej czy później przejmujemy z jego rąk ster którym kierujemy opowieścią. A co jeśli to właśnie ten szef będzie główną personą opowiadanej historii? Kimś komu będziemy "tylko" lub "aż" pomagać. On będzie decydował o sprawach istotnych mniej lub bardziej. Do niego będą zwracać się o pomoc i jemu będą dziękować. My będziemy jego parobkiem- kimś kto ma za zadanie tylko i wyłącznie usługiwać. Bardzo dobrze wygląda to w przypadku drużynowych gier kooperacyjnych. Są zadania mniej lub bardziej ciekawe. Jeden musi pilnować tyłów aby trzech dobrze bawiło się przy realizacji wytycznych. Zawsze są jęki "dlaczego ja? nie chcę tego! niech on idzie bo ja się nie sprawdzę. teraz ja chcę spróbować." Dlaczego nie kazać nam "pilnować tyłów" przez całą opowieść? Dlaczego nie utwierdzać nas na każdym kroku, że są lepsi, inteligentniejsi i wartościowsi od nas? Wiem, że kłóci się to z ideą dobrej zabawy. Wiem, że to się nie sprzeda. Wiem, że byłoby to ze wszech miar nieszablonowe. Każda postać niezależna ZAWSZE z nami porozmawia. Mówi to co potrzebujemy usłyszeć. Nie ma przed nami tajemnic. Nie ocenia nas i nie ma preferencji. Oczywiście tyczy się to sytuacji kiedy w jakiś sposób nie zamknęliśmy sobie tej, konkretnej drogi (np. poprzez zaszkodzenie NPCowi). Płeć piękna tylko nas traktuje jako potencjalnych partnerów- już nie mówię o tym, że wszystkie są na swój sposób atrakcyjne. Nigdy z nikim nie musimy na prawdę rywalizować o ich względy (tak, wiem Hae'r Dalis i Aerie) i zawsze trafiamy w ich gusta. Żaden NPC nie potrafi nas zawstydzić, zgasić albo przegadać. Racja jest po naszej stronie, nawet jeśli decydujemy się z braku argumentacji na rozwiązania siłowe (czytaj- krwawa jatka w przestrzeli publicznej). Nigdy nie zdarzyło mi się, żeby jakakolwiek postać niezależna mnie ochrzaniła albo krytykowała. Rozumiem przez to wyżywanie się emocjonalne a nie jedną linijkę dialogu którym się nie przejmiemy. A co jeśli przełożony zablokuje nam możliwość rozwoju w danej ścieżce, zredukuje "wypłatę" lub przydzieli nieciekawe zadania? "Wylosuje" mu się zły humor i w związku z tym faktem coś stracimy albo ominie nas interesujące wydarzenie. NPC kreowany przez scenariusz na naszego konkurenta jest uosobieniem męskości i intelektu. Wszyscy go faworyzują i stawiają nam za przykład. Nie mamy możliwości pozbycia się go. Nie mamy możliwości skonfrontowania się z nim lub wygrania takiej walki. W reszcie, nie mamy możliwości zrównania się z nim. I wszyscy nam to mówią. Odradzają pracę nad sobą i negują motywację. Całą opowieść obserwujemy trzymając się w jego cieniu. Nowy wymiar relacji w grach komputerowych. Taki niespotykany. Taki nieprzyjemny. Taki życiowy.
    1 point
  6. W roku pańskim 2016 mamy mnóstwo narzędzi pozwalających na szybkie i wygodne tworzenie gier 3D. Jest Unreal Engine, jest Unity, są i inne rzeczy. Więc oczywiście zawsze znajdzie się jakiś idiota próbujący odtworzyć silnik Wolfensteina 3D w pascalu czy innym basicu. Programowanie luźno interesuje mnie od bardzo dawna, choć sukcesów w tym polu nigdy nie odnosiłem. Ot, rozległy program czy dwa w AMOS (wersja darmowa, czyli lekko okrojona i bez kompilowania), wieloletnie dłubanie w QBasic (pewnie dlatego że to jedyny język do którego mam podręcznik/obszerny kurs), oraz krótkie romanse z TurboPascalem stanowiły całość mojego doświadczenia przez pierwsze -naście lat. Kilka lat temu jednak, w apogeum mojego zainteresowania roguelike'ami wpadłem na rzecz zwaną Let's Build a Roguelike. Jest obszerny przewodnik z objaśnieniami tłumaczący jak stworzyć dość nieskomplikowanego przedstawiciela tego gatunku w języku FreeBasic. FreeBasic jest nowoczesnym rozwinięciem starego QBasica, a więc językiem, który w znacznej mierze już znałem, a czego nie znałem, szybko się douczyłem dzięki dostępnym materiałom typu beginner's guide. Tak uzbrojony zdecydowałem się nie odtwarzać po prostu kroków, a wykręcić własny wariant na podstawie mechanik zawartych w LBaR. Projekt ten, zwany kreatywnie ShadowSpace, osiągnął całkiem sympatyczne, grywalne stadium (brakowało jedynie więcej contentu i paru mechanik typu sklep/konstrukcja), zanim nie wpadłem na pomysł na jeszcze inny projekt RL, którego nigdy więcej nie rozwinąłem ze względów m.in. IRL. Nie, serio ._. ShadowSpace w swoim ostatnim buildzie (download link) Parę lat później wpadłem na inną rzecz, FPS engine in 265 lines. Po obczajeniu rzeczy moim pierwszym instynktem było zaadaptować tę imprezę na FB i wykorzystać do napędzania nowej iteracji ShadowSpace. Wtedy jednak po paru tygodniach nieudanych prób straciłem zainteresowanie. Czyszcząc jednak HDD parę miesięcy temu wpadłem na pliki projektu, działający stary build SS i ruszony nostalgią do dłubania w dim as any ptr i innych type chara znowu podszedłem do reimplementacji javascriptowego silnika. Po kolejnych paru tygodniach prób efekt był taki, że skutecznie znienawidziłem javascript, a także nabyłem przekonania że jedynie w tak niedorobionym języku jak js dało radę wykonać taki bajzel kodu. Sama idea silnika raycastowego jednak zafascynowała mnie nawet bardziej. Silnik raycastowy FPP jest automobilowym odpowiednikiem komarka albo innej warszawy - jest bardzo archaiczny, ale jednocześnie prosty do zrozumienia i rozwinięcia. Operując na nieskomplikowanym gridzie doskonale lubi się z mapową strukturą typowego rogalika. Działa na takiej zasadzie że pionowy pasek po pasku rzucany jest promień (stąd ray cast), który "leci" aż trafi w ścianę. Na podstawie tego, jak daleko zdołał ulecieć obliczana jest wysokość rysowanej ściany, zgodnie z perspektywą im dalej tym ściana mniejsza. Problem zasadza się w kwestii tego, jak dokładnie liczyć promienie tak, aby nie zajęło to zbyt wiele czasu, oraz jak te obliczenia przełożyć na spójny obraz bez deformacji. Szukając materiałów online (a jakże) wpadłem na genialną rzecz: raycasting tutorial dla języka c++, który zawierał odpowiedzi na te pytania, a także mnóstwo innych, jakie nawet nie wiedziałem że mam. Ponadto c++ jest niewiarygodnie bardziej czytelny od js, no i specyfika freebasic oznaczała że w najgorszym razie mogłem bezpośrednio zainterfejsować kod, bez konwersji. Projekt FPP został wskrzeszony. Po tygodniu grzebania miałem pierwsze efekty, w natywnym kodzie FB renderowała się scena ze ścianami pokrytymi jednolitym kolorem: o, tak Problemem jednak było dziwaczne zachowanie sterowania, generalnie silnik nie reagował na strzałki tak jak powinien, zamiast tego wykręcając dziwne tańce. W końcu okazało się że po prostu popełniłem durny błąd - literówkę. Po odkryciu i rozgnieceniu tego buga mogłem rozwinąć podstawy projektu. Z prostego random z szansą 0.3 wymieniłem generator mapy na ten z ShadowSpace (plus kilka tweaków, na dłuższą metę kulawych), dodałem strafe (którego w tutorialu nie ma), dodałem cieniowanie w funkcji odległości. Tak zakończony pierwszy etap silnika ważył po skompilowaniu 123 kilobajty i w rozdziałce 800x600 jechał z prędkością około 80 klatek na sekundę: https://www.youtube.com/watch?v=-JXK7tTdBYI (embedy oczywiście znowu nie działają) Czasy sielanki jednak szybko się kończyły, gdyż rozbestwiony dobrymi wynikami zająłem się kolejnym etapem - teksturowaniem ścian. Tu już nie było tak łatwo, musiałem znaleźć metodę na szybkie pobieranie koloru dowolnego piksela z tekstury. Okazało się, że FB ma kilka narzędzi pozwalających na takie zabawy, jednak w tym miejscu musiałem już osobiście zająć się dostępem do pamięci (Dim as UInteger Ptr, Dim as ScreenPtr i podobne). Wyniki osiągnąłem po paru ledwo dniach: Mimo, że taka metoda jest cholernie szybka, nie była dostatecznie szybka. Raycasting działa wyłącznie w sofcie i polega na sile obliczeniowej procesora (jednego rdzenia!). Wolfenstein 3D działał przecież w rozdzielczości ekranu 320x200, a wewnętrznie castował może nawet w mniejszej! Dlatego został dość szybko wyparty przez nowsze, inteligentniejsze rozwiązania, które też bez kilkudziesięciu megaherców na pokładzie nie szalały. Było to impulsem (ImpulseM cha cha cha) do wprowadzenia pierwszej rundy optymalizacji. Efekt był taki, że miałem fpp.ini, który zawierał rozdzielczość ekranu, a także "rendering resolution", wskazujący z jaką dokładnością robiło się castowanie (1-co do piksela, 2-co dwa piksele itd.). Brudny hack, ale działał póki co zadowalająco. Mogłem przejść do kolejnego etapu, floor casting - renderowania podłogi i sufitu (swoją drogą dość skomplikowanego). Implementacja wyszła, ale tutaj brudny hack na szybkość okazał się być nieadekwatny i podszedłem do sprawy po raz drugi. Kilka programów testowych na szybkość działań array/pointer/bufor/Point() różnymi metodami wpadłem na pomysł z którego nieomal byłem dumny. [nerd talk] Ponieważ ScreenPtr, najszybsza w takim zastosowaniu metoda rysowania na ekranie najlepiej działała z dostępem sekwencyjnym (czyli 1,2,3,4,5,6, a nie np 1, 3, 6), zamiast powielania pikseli przy każdym indywidualnym pasku (raz dla ścian i drugi raz dla podłóg jeszcze) wprowadziłem wirtualny bufor o rozdzielczości castingu, do którego szły obliczenia raycastowe, po czym zostawał błyskawicznie mnożony przy przepisywaniu na ekran. Zamiast dłubania [3, obok też 3, poniżej też 3 i 3, 5, obok 5...] w miarę napływania wyników castowania, program leci błyskawicznie [2x 1, 2x 2, 2x 3, poniżej tak samo, kolejna linijka]. Program zaczął śmigać nawet na dość dużych rozdziałkach typu 1400x800, wyglądając tak: (na lewo render z dokładnością 1, na prawo toż samo z dokładnością 4, kliknij aby zobaczyć pełny obraz) Próbując przyspieszyć sprawę jeszcze bardziej ("a może uda się skopiować od razu cały rządek?") "wynalazłem" jeszcze efekt scanlines, który przy okazji faktycznie przyspieszał biznes: (klik) Dla jaj zrobiłem z tego efekt śnieżenia stareńkich monitorów monochromatycznych, który nie spowalniał sprawy: (tyż klik) Efekt ten był mi chwilowo zbędny, więc go wycofałem, ale w przyszłości kto wie. "Scanlines" mają jeszcze taką przewagę, że w pewnym stopniu maskują kanciastość wynikającą z redukcji rozdzielczości castingu. Nadszedł wreszcie ostatni weekend. Pod kątem przyszłej integracji z różnymi programami (to już prawie silnik!) sprawiłem jeszcze, że gra zamiast czytać każdą teksturę z osobna, czyta jeden plik z teksturami podłogi, jeden ścian i jeden z sprite'ami (których jeszcze nie widać). Na tym etapie jednak wychyliły głowę bugi (yay). Przede wszystkim, jak widać na ekranach powyżej, kafelki podłogi rozjeżdżają się z gridem i ścianami. Same ściany też nieco się rozjeżdżały w bok i lekko w górę/dół. Po około półgodzinie testów i guglowania doszedłem do sedna. Okazało się że biorąc dane tekstur bezpośrednio z pamięci (ekran[x+y*szer]=tekstura[xt+yt*szert]) zapomniałem, że pierwsze 32 bajty zajmuje wewnętrzny nagłówek bitmapy, który powoduje właśnie takie rozjechanie wszystkiego. Dodając "8" (tl;dr 8x4 bajty) do wszystkich obliczeń rozwiązałem i tę kwestię, wszelkie bugi zniknęły! Następnym etapem implementacji jest ostatni fragment tutoriala, sprite'y, które też wesoło będzie się liczyło. Mając to wszystko zaimplementowane, wprowadzę już samodzielnie statyczne oświetlenie, a potem już tylko krok do faktycznego grania. Na tę chwilę silnik wygląda tak: Całkiem chyba nieźle jak na rzecz tworzoną dla zabicia czasu?
    1 point
  • Newsletter

    Want to keep up to date with all our latest news and information?
    Sign Up
×
×
  • Create New...