Ha van a kamerádnak viewproj mátrixa akkor esetleg Vector3::Unproject

Itt van 3 kép az esetről:

Az első képen a sprite kitakarja a 2 fal alkotta sarkot. elméletileg, bármerre nézek, sosem szabadna látnom azt a sarkot. De ha elforgatom a kamerát, akkor a sprite is vele fordul kicsit, és előtűnik a sarok. Ez látszik a 2. és 3. képen.

Idézet

---

Sharp :
Ha ezt skalárisan megszorzom a dir-rel, ami egységvektor, akkor megkapom a z-t, tehát R pont kamera síkjára merőleges távolságát.

---

Ez nem csak akkor igaz, ha a kamera síkja átmegy az origón? Szerintem bele kéne kalkulálni a sík origótól való távolságát is.

Szerk.: ja nem, kevertem az R-t az R-rel.

Szervusztok!

A következő problémában lenne szükségem segítségre.

Adott egy pseudo 3D világ, Wolf3D stílusú raycastinggal. Rá szeretnék vetíteni a kamera síkjára egy pontot a 3D-s világból.

Ez a kép egy 3D-s világban az X-Z tengelyt reprezentálná, az én pseudo3D-ben ez az X-Y, de ez lényegtelen, tehát egy kép "felülnézetből".

C a kamera koordinátája.
dir a kemra irányvektora, ami egy egységvektor.
plane a vetítési sík vektora. Ez a vektor mindig merőleges az irányvektorra. Maga a vetítési sík [-1;1] intervallumba van leképezve. Tehát a kamera legbaloldalibb pontja dir - plane, a kamera közepe a dir, a kamera legjobboldalibb pontja pedig dir+plane.
R egy pont a világban, amit le szeretnék képezni a kamera síkjára.



(1)
R: A kamerából a pontba mutató vektor = R - C
Ha ezt skalárisan megszorzom a dir-rel, ami egységvektor, akkor megkapom a z-t, tehát R pont kamera síkjára merőleges távolságát.

(2)
Hasonló háromszögek: |r| / |R| = |dir| / z. Mivel |dir| == 1, ezért r=R/z

(3)
Ezt az r vektort már csak rá kell vetítsem a kamera síkjára, és megkapom a kamera síkja beli pozícióját, ez lesz w = plane egységvektora*r

Ez a w egy [-1;1]-beli érték, ha rajta van a képernyőn. Ezt már csak vissza kell alakítanom a képernyő felbontásához mérten és megkapom a képernyő X koordinátáját( (w+1) * felbontás/2 )

A kérdésem, lát-e ebben valaki valamilyen hibát?
Nagyjából szépen működik, megjelenik a 3D-s pont, viszont a kamera forgatásakor enyhén együtt mozog a forgással a pont, nem marad egy helyben. Ha maga a leírás nem lenne elég, rakok fel képeket majd magáról az esetről.

Előre is köszönöm.

Hát.. úgy látszik, konkrét kódot kell leírni egy lapra.. :[

@HG: Rendben, utánanézek ezeknek a dolgoknak, és köszönöm.!

Mellék.: A 9. évfolyamból senki nem indult, 10-11-12-es osztállyal nézek most szembe..

Kuz: nem csesztetésből, de nálad összemosódik a programozás és a kódolás fogalma. a kódolás csak egy részhalmaza a programozásnak, mint ahogy a tervezés is.

Szerintem meg ez tervezés, nem kódolás. Illetve nálad ez a lenti példával valahol a kettő közt volt. Gondolom a versenyen sem azt fogják kérni, hogy add be a piszkozatot, hanem egy végleges megoldást kérnek. De most már én is kíváncsi vagyok.

A papíron programozásnak sem kell feltétlenül papíron történnie. Tegnap este pl. a programkódba csináltam egy nagy komment-cetlit, és oda szedtem össze, hogy milyen esetekben futhat rá az adott részre a kód. Mivel nem volt egyértelműsítve minden, ezért szükség volt egy kis szelektálásra, határok meghúzására, hogy mit engedek és mit nem. Első körben leírtam folyómondatokkal, felsorolásszerűen négy lehetőséget, amikor ide juthat a kód. Aztán elolvastam, lett belőle három, mert össze tudtam vonni kettőt.
Aztán lekódoltam, ellenőriztem, log-oltattam minden hibaesetet, és megnéztem még egyszer a szöveget és kódot összevetve, majd plusz 2 sor beiktatásával leszűkítettem 2 esetre az egészet.
Mindezt azelőtt, hogy a kódot akár egyszer is futtattam volna. Az eredménye pedig az, hogy jelenleg egy hibát talált a tesztelő, az is egy apróság, ahol a random-szám generálást eggyel tovább engedtem, mint illett volna. A logger viszont elkapta, és be is jött a figyelmeztetés játék közben, hogy a tesztelő tudja, hogy szólni kell nekem, mert gáz van

Röviden: ha nem jártam volna azt a két-három tervezési kört az első futás előtt, csak elfogadom az első, négy lehetőséget tartalmazó 'algoritmust', akkor egy sokkal szarabb minőségű kódom van, sok redundanciával. Ráadásul mivel már működik valamilyen módon, nem akarnám újratervezni, mert hát egy csomó munka benne van. Jön a foltozás... (a többit kitalálja mindenki, aki programozott már nagyobb lélegzetű project-et)

Na, ezért programozom a bonyolultabb részeket 'papíron'. Persze vannak nálam okosabbak, akiknek erre nincs szükségük

Hát úgy látszik az iskolák ilyen maradiak, hogy még ragaszkodnak a papírhoz.

Azt hiszem az alapvető félreértés abból jön, hogy én papíron való programozás alatt tényleg azt értem, hogy leülsz, elkezdesz - akár pszeudoban - kódolni valamit, radírozol, javítasz, etc. Holott pl a mostani feladatomnál egy excelben gyűjtöm össze, hogy milyen classok kellenek, milyen sql táblák, mi-mit tartalmaz, etc, és kódolni egy sornyit nem kódoltam még. De ezt speciel tervezésnek hívom, amit nem feltétlenül papíron csinálsz (sőt, a sebesség miatt jó, ha nem papíron csinálod).
Kicsiben - mint egy verseny is - nyílván nem egy full adatelérési réteget fognak kérni, inkább valami trükkös problémának a 8-10 sorban való megoldását. Arra persze jó a papír, bár erre is azt mondom, hogy ha már programozási verseny, akkor legyen egy választható nyelv lista, és mindhez legyen fejlesztői környezet. Egy futball bírót sem csak az elméleti tudása alapján értékelnek, hanem hogy meccsen ténylegesen hogy vezeti a meccset, és olvasatomban ez fontosabb szempont, minthogy fel tudja sorolni, hogy egy adott helyzetben milyen döntési lépések vannak.

Lehet pszeudokód is. Én vegyesre tippelek, hogy az is kell meg folyamatábra vagy Jackson diagram is (nem hiszem, hogy olyan bonyolult feladatot adnának, ami nem fér el egy A4-esre). Aztán majd kiderül.

Dokumentációs jelentősége van a "papír"-nak, amit jellemzően el szoktak felejteni, mert tényleg gyorsabb a munka, ha fejben dolgozik az ember.

Struktogramhoz végtelen nagy méretű papír kell egy kicsit komplexebb algoritmus esetén is, meg amúgy sem szokták erőltetni, mert macerás a rajzolgatás miatt, ugyanúgy mint a folyamatábra. Inkább pszeudokódot szoktak írni és kérni is, legalábbis oktv-n pár éve még így volt.

Matekórán sem azért tanítanak meg papíron összeadni, hogy később csak így adhatsz össze.
Itt is először szerintem tök alap dolgokra fognak rákérdezni, tudod-e mik azok a vezérlő szerkezetek, tudsz-e ezekből az építőkockákból egy halál egyszerű algoritmust összerakni, ennyi. Aztán utána jöhetnek a konkrét programozási feladatok. Szerintem.

Kuz, valószínű elbeszéltünk egymás mellett, nyilván Te már nem papíron fogsz programokat írni, de itt most nem a haladókról volt szó, hanem egy iskolai verseny első fordulójáról.

Szóval ha tippelnem kellene, hogy mit kérnek "papíron programozás" alatt, akkor szerintem struktogrammot kell rajzolni, és nem feltétlenül konkrét programkódot írni. Úgyhogy én azt javaslom 4Bit, hogy ennek nézzél utána. Szekvencia, szelekció, iteráció. Szerintem.

SZERK: 4Bit, ha megvolt a verseny, légyszi írd már meg ide, hogy végül is mi volt a feladat.

Én ha kicsit bonyolultabb rendszert csinálok, akkor azért néha szoktam ilyet csinálni, hogy az osztályokat nagyjából vázolom ilyen kis dobozokban, összekötögetem, megnyilazom, stb. Főleg akkor, ha suliban vagyok, és hát nincs nálam a gép... valamivel el kell tölteni az időt

Ezt általában elég jól meg szokták fogalmazni a feladatban:
"Írjon kódot, ami..."
"Írjon pszeudo kódot, ami..."

De most akkor rajzoljak ábrákat a papírra, vagy a szimpla kódot írjam le?

Nem kötözködés, csak én még mindig nem látom mivel vagy előrébb, ha papírt használsz (ja, hát mondjuk később a wc-n előnyben leszel), mintha egyből azt kódolod, amit papírra is leírnál. Vagy lehet nem ugyanazt értjük papíron-való programozás alatt? Én lent szerintem elég jól leírtam, hogy mi az én nézetem, de lehet csak a definíciót értjük másképp.

Egy haladóbb programozó nyilván tudja mi az a struktogramm meg a folyamatábra.
Egy iskolai verseny első fordulójába is nyilván csupa haladóbb programozó jelentkezik, ergo tök felesleges a beugró feladat...

SZERK: Nyilván nem az lesz a feladat az első fordulóban, hogy programozzon le papíron egy komplett raytrace engine-t... Nem hiszem, hogy olyan bonyolult feladatot adnának, amit ne lehetne 1-2 ciklussal meg elágazással megoldani... Ha meg ennyit nem tud papíron lerajzolni, akkor még mindig nem késő más hivatást választani.

Szerintem egy haladóbb szintet elért programozónak egy struktogramm vagy folyamatábra nem mondd sokkal többet, mint maga a forrás

Okés, látom nem lehet meggyőzni, hogy van valamicske haszna..

@4Bit: Akkor ha azt kérik tőled, hogy papíron vezess le egy feladatot, mondd azt nyugodtan a tanárodnak, hogy "papíron programozni faszság"... Lehet nem jutsz tovább, de később jó fizetésed lesz majd.

Komolyabb DDD rendszereknél pedig már magával az ábrákkal definiáltam is a programot, aztán generate code és ennyi. Ez persze csak az adatkezelés, meg 1-2 üzleti logikára jó, de faszányos tud lenni, amikor egy jó kis UML ábrából egyből kód lesz, state machine-el mindennel együtt. Ennyit a papírozásról.

SX: érdekes, én is. Lehet egy helyen dolgozunk?

A papíron való programozás szerintem faszság, mert:
- Jóval több időt vesz el tőled, mintha egyből bepötyögöd a kódot és - .Net és értelmes fejlesztői környezet esetén - az intellisense egyből javít téged, egyből látod, ha valami nem áll rendelkezésedre, és emiatt módosítani kell egy modult, etc.
- Sem papíron, sem gépen nem erőből kódolsz, jó esetben először átgondolod, amihez nem hiszem, hogy kell papír (max vázlatnak, de az meg nem papíron programozás, az csak ötletelés).
- Ha annyira bonyolult a feladat, hogy kell hozzá folyamatábra, az meg elég speciális eset, lássuk be, ilyenbe ritkán futunk bele. Bár én erre is inkább excelt, visiot, vagy valami programot használok, mert ott könnyebb/gyorsabb javítani.

Attól meg, hogy tudod hogy kell sütni rántottát, még simán odaégetheted. Ahogy Morpheus is mondta a Matrix-ban: "Más dolog ismerni az utat és járni rajta.".

Idézet

---

Kuz :
Ez csak azért van, mert rossz programozók vagytok.

---

Lehet benne valami, de így is megkapom a béremet minden hónapban

@DMG: Lehet sántít a hasonlatom, de akkor mondom máshogy.
Tegyük fel főzőversenyen azt a feladatot kapod, hogy írd le hogyan sütsz rántotthúst. És akkor leírod szépen a lépéseket, hogy leveszed a fagyasztóról a karajt, kiolvasztod x idő alatt, felvágod, kiklopfolod, megsózod, bepanírozod liszt, tojás aztán zsemlemorzsa, forró olajban kisütőd x perc alatt, közben megfordítod, végül tálalod. Ha le tudod írni hogyan készíted az ételt, akkor azért el lehet dönteni, hogy tudsz-e sütni, anélkül, hogy konkrétan összekoszoltad volna az edényeket...

@Kuz: Nem hiszem el, hogy Te, mint programozó, a suliban nem rajzoltál folyamatábrákat..

Én az adatbáziskezelést tanultam papírom meg az SQL-t, na az is cumi volt.

HG rossz a hasonlat.

ha már főzés, ez KB olyan, mintha ki kéne találnod egy új receptet, de nem tudod megfőzni, hogy kipróbáld élesben, csak a receptet írhatod le, aztán vagy jók az arányok vagy nem.

Ez csak azért van, mert rossz programozók vagytok.

Idézet

---

Kuz :
A papíron való programozás olyan, mint fejben főzni. Lehet, de semmi értelme.

---

Az algoritmusok/fgvek működésének megtervezésére nagyon jó tud lenni a papír. Kritikus részeket én pl. van, hogy napokig tervezek papíron, mikor belefogok valaminek a kivitelezésébe. Többet gondolkodsz, és mivel nem tudod kapásból futtatni, többször körbe is járod, eszedbe jutnak olyan dolgok, amik amúgy esetleg nem fognak, mert a kód fut jól (legalábbis először).
Na, ezen szemlélet bevezetésére jó a sulis papíron programozás. Mi is utáltuk, de ez olyan, mint gyerekkorban a kötelező rendrakás. Később jössz rá, hogy nem is volt hülyeség..

De ha fejben sem tudod a hozzávalókat, akkor hogyan állsz neki főzni? Belerakod a levesbe ami eszedbe jut, aztán ha pl túl csípős lett, akkor kiveszed belőle a paprikát?
Attól, hogy tudsz készételt rendelni, még nem biztos, hogy meg is tudod főzni..

SZERK.: Szerintem ez olyan, (szeretem a hasonlatokat ) mintha 4Bit benevezne egy főzőversenyre egy olasz pizzéria telefonszámával, aztán amikor mondják neki, hogy írja le a receptet, akkor csak pislog, hogy "mi van?"..

A papíron való programozás olyan, mint fejben főzni. Lehet, de semmi értelme.

Ez olyan, mint hogy pl. el sem tudod képzelni, hogy számológép nélkül is össze lehet adni két számot papíron..
Gondolom valami folyamatábrát is kell majd rajzolni.. Attól meg hogy pythonnal nevezel még nem biztos hogy jobban tudsz algoritmizálni mint a pascalosok, sőt..

Valószínűleg csak elméleti és logikai feladatok vannak, általában pszeudó kódban. Azért érdemes rákeresni az előző évi feladatokra, biztos elérhető valahol. Vagy kérdezd meg a tanárod. Egyébként sok sikert!

Ez attól függ, hogy hogyan gondolták.

Jelentkeztem egy programozói versenyre. (Ajajajaj! )

Az első forduló papíron történik meg, pár napon belül, szóval. Szabadon választott nyelvből lehet indulni, (én személy szerint Pythonnal nevezek, míg mindenki körülöttem Pascallal fog szívni.. )
a megmérettetés pár napon belül lesz az iskolában.

Na most azt szeretném kérdezni: Hogy ez a papíron történő programozást mégis hogy a bánatban gondolták? Ugyanazt írjam le, mint amit a gépbe pötyögnék be?

Senki nem szülője most senkinek. Bent van 2 dolog: egy picture box meg egy group box. Mind a kettőnek a main window a szülője. Ha úgy adom hozzá, hogy:
- picture box
- group box
akkor látszik mind a kettő rendesen, ha viszont
- group box
- picture box
akkor olyan, mintha a pb "kitakarná" a groupboxot, és nem látszik.

szerk.:
Ha máshogy csinálok "picture box"-ot, akkor jó

Bár ez nem igazán picture box. Mondjuk amúgy is csak arra használom, hogy ezt adjam át a render device-nak
Avagy a dummyfv szerinti kódnál a STATIC helyére BUTTON-t írok, és akkor megy is.

szerk.2:
Végül úgy lett megoldva, hogy group boxot csinálok, és annak a handler-jét adom át a Game-nek (a feliratot úgy is kitakarja, szóval kvázi nincs vele gond)

A groupboxnak a pictureboxot add meg parent-nek?
Amugy minden logikával ellentétben ha jol emlékszem a groupbox elemeinek nem a groupbox a szülöje.

Nem teljesen ide való, de hátha.
Szóval WinApi-s WinForms-ot használok Asy tutorja alapján.
Az a helyzet, hogy ha először egy picturebox-ot adok hozzá aztán egy groupboxot, akkor jó mind a kettő, de ha fordítva (először group box, aztán picture box), akkor a group box nem látszik. Ötlet, hogy miért? (HWND mindkettőnek ugyan az, a szülő ablak, csak más sorrendben adom őket hozzá...)

Én csak 12x12 -ig rajzoltam le kockás füzetbe, de ezek szerint működik az elgondolás, juppí.

150x150es táblán teszteltem, azon jó

Hát, borsi, nem tudom van-e egyszerűbb megoldás, én addig jutottam, hogy ha a+b páros, akkor n is páros, egyébként páratlan, illetve n<=a+b, kivéve ha a+b==1, mert akkor n=3. Ennyi, feladom, többre most nincs energiám.

SZERK:


SZERK2: és ez se jó, csak a<=8 -ig..


sor nem kell.

Na, akkor a legújabb kísérleti megoldásom (nem próbáltam, csak papíron )



Ennyi. Nem garantálom, hogy jó, le kéne teszteni...

Ami eddig megvolt nekem:



Viszont jó lenne, ha lenne valami könnyebben bizonyítható, egyszerűbb megoldás

HG:
Na ez jó kérdés, lehet, hogy a kannibáloknak is van egy erőssége, vagy simán nem 1, hanem pl 1.5 ös erősségre gondolt a misszionáriusoknak.
Habár az jobb lenne, ha azt lehetne megadni, hogy mennyire éhesek a kannibálok.

@borsi: első próbálkozásom:

de valószínű ennél kevesebb. mondjuk nem próbáltam ki.

SZERK: hát ezt még tuti optimalizálni kell, mert biztos h nem pontos. sőt, tuti nem jó

borsi:
Ez nem nehéz, a lólépés 2 az egyik irányba és 1 a másik irányba. Szóval csak ki kell hozni ,hogy a két dimenzió különbségében milyen arányban kell lépkedni. Nem nehéz.

Szerintem ezt egy sima fa-kereséssel meg lehet oldani, csak le kell tudni írni az aktuális állapotot (hol vannak a misszionáriusok meg a kannibálok, hol a csónak), megnézni, hogy ez egy érvényes felállás-e (megeszik-e valamelyik misszionáriust), illetve átjutottak-e, aztán felírni a lehetséges lépéseket, és jöhet a következő szint.. Esetleg még ki lehet szűrni az egyforma állásokat, vagy egy max mélységet megadni..
De az "erősséget" nem értem, velük van a szentlélek is, vagy mi?
Az erősségnek nem azt kéne jelentenie, hogy ha
misszionáriusok száma * erősség < kannibálok száma
akkor megeszik őket? Ez hogy jön ki a 4:3-ra?

Egy másik probléma: végtelen méretű sakktáblán két mező között a legrövidebb út hossza szabályos lólépéssel. Elég a hossza (viszont az konstans idő alatt kéne), azzal már menne az útkeresés (A*), de annak hiányában csak szélességi bejárással tudom megtalálni a legrövidebb utat.

Ahh, így azért más a helyzet, mint ahogy eredetileg leírta. Csónakokról pl szó sem volt.

Szerintem az erősséggel valamiféle sebzésre gondolt a misszionáriusok részéről(a leírás alapján.) Vagy lehet, hogy inkább védelem, arról nem írt, hogy a kannibálok kinyiffannak, ha kevesebben vannak.

Ez egy érdekes logikai feladat, szerintem erre gondolt: Missionaries and Cannibals
Azt nem pontosan értem, mi az az "erősség"? Definiálnád, kérlek?
Én valami sima rekurzív-szerű kereséssel oldanám meg.

u.i.: elég 1 helyen a hsz, legyen mondjuk itt, a többit törlöm.

Mi kell neked pontosan? Útvonalkeresés?
A balhét(feltéve, hogy jól értem a feladatot, és minden misszionáriusnak ugyanakkora "ereje" van) meg kb ennyivel ki tudod számolni:

if kannibálokszáma - (misszionáriusokszáma * misszionáriuserőssége) >= 1:
<nyert.>

Btw marha sok értelme volt 3 topicba beírni ugyanazt.