Várható volt, hogy egy scriptnyelv nem lesz (a python az az, ugye? ). És hát igen, remélem megvan a tanulságod: ne hidd azt, hogy okosabb vagy a hülye pascalosoknál, mert ezek szerint csúnyán rádvertek. (nem úgy értem )

@4Bit: Akkor a pszeudokód volt a nyerő, a folyamatábrával meg melléfogtam, sorry.. :\ Kár, hogy a konkrét feladatsort nem kérted el. Ja, és ki is nevette ki a pascal-osokat?..

Megvolt a programozói verseny, és én szerintem ennyi erővel végig is ülhettem volna azt a 3 órát...

Először. Tanuló neve, Iskola neve, stb... aztán jöttek a keményebb dolgok.
Választható programozási nyelvek:

- C++
- C#
- Pascal
- Delphi
- Java
- Visual Basic

Első kérdésem: (WTF?! HOL-A-PYTHON?) Na jólvan, akkor egy X esik a javára...

Most jön még a JAVA.. (és itt most nem poénkodni akarok, mert kurva szar kedvem van ezután a verseny után..

1. Feladat..

Időjárás... Miva'? Jólvan, egyszerű volt mint a pofon a kód, mivel pszeudo-kódok voltak csak, (ezt még meghálálom, hogy időben tudtam informálódni tőletek ) de aki magát a feladatot írta, szerintem örülhetett hogy nem verték ki onnan, ahol ezt a feladatlapot írta, mert tele volt helyesírási hibákkal, és egy kukkot sem értettem, hogy most mi a francot erőszakoljak azzal a példakóddal, mert a feladatnak legalább 5 jelentése volt, ha nem több...

2. Feladat..

Na, ez mégjobb volt, mert a kód is el lett kurva, és logikája nem volt az egésznek, sőt! Én kifejezetten éreztem, hogy enyhén bugos volt...

3. Feladat..

Kicsit jobban érthető, és áttekinthetőbb szöveg kerül a kezembe.. az illetőnek biztos ebédszünete volt, és helyette bepötyögte valaki más.. jajdekár.

4.Feladat..

Utolsó, egyben egyik legszemetebb feladat volt kérem szépen, függvény létrehozástól kezdve (ami még megy) egészen a funkciónális programozásig (?) mindennel telibe volt verve..

Maximális elérhető pontszám: 100 pont

Én őszintén szólva már 10-nek is örülni fogok..

Köszönöm, meglett a megoldás!

Lássuk csak: A plane hosszát a Field Of View határozza meg. Az én esetemben 0.66 körüli volt a plane hossza. Tehát a valódi vetítési sík [-0.66; 0,66] volt. Amikor az r vektort rávetítettem a vetítési síkra, akkor a plane egységvektorát használtam. Ez adott egy számot [-1; 1] intervallumban, amit vissza kell transzformálni a valódi vetítési síkba, azaz [-0.66; 0.66]-ba.
Nagyon szépen működik, köszönöm szépen az észrevételeket.

Sharp:
Egy tipp, de szerintem a w kiszámítása előtt normalizáld az r-t.

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.