Hirdetés
- Android alkalmazások - szoftver kibeszélő topik
- Fotók, videók mobillal
- CES 2026: Érintőceruzát támogató komolyabb Motorola várható
- Google Pixel topik
- Samsung Galaxy S25 Edge - a tegnap határán
- iPhone topik
- Honor Magic5 Pro - kamerák bűvöletében
- Vivo X200 Pro - a kétszázát!
- Minden a BlackBerry telefonokról és rendszerről
- Vivo X300 Pro – messzebbre lát, mint ameddig bírja
Új hozzászólás Aktív témák
-
#10246
quailstorm
félisten
Tomi_78
#10245
quailstorm
félisten
válasz
Tomi_78
#10245
üzenetére
"Direkt csináltam úgy, hogy esésnél ne lehessen az irányt módosítani, mert így tűnik természetesnek a mozgás."
Ezt gondold újra kérlek. Hacsak nincs valami nagyon durva közegellenállás, az oldalirányú mozgásvektorod megmarad. Különben a papírrepülő is függőlegesen zuhanna lefelé pár méter után."Bár megmondom őszintén, nagyon "kocaprogramozó" vagyok, mert az ilyetén tudásom nagyjából kimerül a feltételes elágazások, ciklusok és tömbök ismeretében és használatában."
Ehhez kb. mindegy melyiket használod.
-
#10243
quailstorm
félisten
Tomi_78
#10242
quailstorm
félisten
válasz
Tomi_78
#10242
üzenetére
Tegnap éjfélkor behalt az oldal így nem tudtam elküldeni, így elküldöm most.
Amúgy nem, az a kék nagyon nem szemnyugtató.Komoly nosztalgia trip volt az oldal meg a sok GameMaker, DarkBasic csoda.
Kis code review:
Ez inkább hasonlít valami 90-es évek eleji TurboPascal kódra, mint C#-ra. Lényegében semmit sem használsz a C#-ból. 30 millió mélységű ifek, szörnyű.
Szét kéne bontani függvényekre mert ez így átláthatatlan. OOP pattern, fájlokra bontás, rendes szerializálás a mentésre, pálya reprezentációra.A játékról: a fehér körvonalát el kéne tüntetni a talajnak, csúnya. Ez a Hold gravitáció meg nagyon lelassítja a mozgást, nem túl kellemes. 2 pálya után meguntam. Azt értem hogy ugrás után csak valamennyit lehet mozogni oldalra, bár egyet nem értek vele. De a felugrás és leesés sebessége nagyon lassú.
Biztos jó volt a SharpDevelop valamikor, de nagyon bekorlátozod vele magad. Ha áttérnél Visual Studio Code-ra, vagy Visual Studio Community-re vagy JetBrains Rider Communityre akkor sokat segítene az IDE is, meg hozzáférnél a modern nyelvi funkciókhoz. .NET 4.5 óta sok minden változott, ahhoz nem férsz hozzá. Ugyanúgy külső könyvtárakból is csak ősi verziókat tudnál behúzni.
Azt a kérdést tenném fel, hogy programozni szeretsz, vagy játékot csinálni? Lehet csúnya kóddal is jó játékot csinálni, ilyen például a VVVVVV.
Ha programozni akarsz tanulni, akkor ezt a meglévő kódbázist kalapálnám át a paradigmáknak megfelelően meg még optimalizálnám a játékmenetet kicsit. Azzal talán többet tanulsz mint egy új projecttel. -
#10234
quailstorm
félisten
Tomi_78
#10233
quailstorm
félisten
válasz
Tomi_78
#10233
üzenetére
Szerintem a koordinátákkal van gond igen. A példák alapján én úgy látom hogy a gombok Locationje a panelen belül abszolút koordináta, te pedig a teljes ablakhoz képes abszolútként adtad meg, így kívül van a panelen.
Szóval mindig a közvetlen szülő koordinátaterén belül kell gondolkozni. -
#10230
quailstorm
félisten
Tomi_78
#10229
quailstorm
félisten
válasz
Tomi_78
#10229
üzenetére
Itt már esélyesebb hogy összehoztál egy not all paths return a value hibát. Gondolom a case-en belül az if-en belül volt a return, de ifen kívül nem volt csak jött a break és a függvény végén sem volt.
Azt az if valamit ki kéne szervezni, ha fix dolog akkor a függvény elejére, ha nem az akkor így hirtelen passz hogy hova, túl pszeudokód ahhoz hogy lássam.
-
#10228
quailstorm
félisten
Alexios
#10226
quailstorm
félisten
válasz
Alexios
#10226
üzenetére
Igaz, benéztem bocs. Annál több elágazás kéne (köztes else if) hogy ez előforduljon.
#10227Tomi_78:
Változtattál valamit a fejlesztőkörnyezeten? Vagy mégsem teljesen olyan ez a kód mint az előzőek?Olyasmi kódra mint a mintád, most az RCS1073-at adja vissza a VS2022.
Redundant else keyword hibát nem tudtam előhozni. -
#10224
quailstorm
félisten
Tomi_78
#10222
quailstorm
félisten
válasz
Tomi_78
#10222
üzenetére
Ez nem hiba, csak kódstílus.
Early return esetén a függvény végére rakunk egy mindig konstans return false-t. Az első if után még lehetne kód a végső returnig, ami további feltételkiértékeléseket tartalmazhatna (és további returnokat).
Most nálad az else ág üres, az if után pedig nincs semmi így ugyan felesleges kiírni hogy else, de jelen esetben sem szintaktikai sem szemantikai hibát nem jelent.
Viszont ha bármit írnál az else után, az else alá, akkor az syntax error mert hirtelen nem minden ágnak lenne visszatérési értéke. Ezt megelőzendő (meg az átláthatóság miatt) nem kell az else ilyenkor. -
#10221
quailstorm
félisten
Tomi_78
#10219
quailstorm
félisten
válasz
Tomi_78
#10219
üzenetére
Lehet, de nem érdemes.
Ugyanúgy meg lehet tanulni egy szerializálós libet mint a programozás alapjait.Abban amit csinálsz nagyon sok a munka, nagyon sok a hibalehetőség és nem tesz hozzá a játékhoz semennyit. Csak szaporodnak a kódsorok a semmiért.
Persze mindent fel lehet találni nulláról, de nem célszerű.
#10220martonx: ha jól számolom 5 éve csiszolja, de már akkor nagyon elavult alapokon kezdte.
-
#10218
quailstorm
félisten
martonx
#10217
quailstorm
félisten
válasz
martonx
#10217
üzenetére
Milyen új projecten?
Egy 90-es évek szimulátorhoz ajánlottam ahol a kókányolásállóság és a kompatibilitás régi frameworkkel sokkal jobban számít.
Ráadásul ha visszakeresel a nevére:
SharpDevelopot használ. Az nem támogat 4.5.1-nél újabb .NET Frameworkot. Tehát valószínűleg nem tudja használni a System.Text.Json-t.Úgyhogy szerintem de, elegáns helyzetre szabva olyan libet ajánlani ami biztos működik nála. Ahhoz a pet project játékhoz óriási előrelépés lenne neki a Newtonsoft is.
-
#10216
quailstorm
félisten
Alexios
#10215
quailstorm
félisten
válasz
Alexios
#10215
üzenetére
Persze, teljesen másképp lett megoldva végül a probléma. Integrációs tesztek miatt mondtam a többieknek hogy felesleges custom resolvert meg normalizálást meg minden féle bonyolult dolgot implementálni. Deszerializálás helyett inkább a referencia is szerializálva van és a két szerializált json van összehasonlítva.
Előző projectemen is elég keményen van abuzálva a Newtonsoft plugin architektúrás workspace deszerializáláshoz, úgyhogy ott is azért nem éri meg váltani.
-
#10214
quailstorm
félisten
martonx
#10212
quailstorm
félisten
válasz
martonx
#10212
üzenetére
Felhasználásfüggő. Nem teljes helyettesítő a System.Text.Json.
De persze, Tominak valószínű elég, meg az átlag projectbe is elég. Munkában előző projectemnél biztosan nem volt érdemes lecserélni a Newtonsoftot, mert csak a rengeteg szívást és kompatibilitási problémát kaptuk volna a nyakunkba, de mostani projectemen is volt olyan eset (bocs, elfelejtettem), ahol a megoldás egyszerűbb lett volna és jobban dokumentált volt Newtonsofttal.
Szóval én még nem temetném a Newtonsoftot, de nyilván új projecten nem azzal kell kezdeni feltétlen.
-
#10211
quailstorm
félisten
Tomi_78
#10210
quailstorm
félisten
válasz
Tomi_78
#10210
üzenetére
Tegyél breakpointot a kiírás közben. Csak ez a kód ír ki pontot?
A for-t én Count - 1-ig futtatnám. A switchet kitenném helper methodba. A pontírás maradna a foron belül a helper method után. For végeztével meghívnám mégegyszer a helper methodot az utolsó elemre.
De igazából az egésznek nem sok értelme van. Miért szívatod magad saját szeralizátorral? Legyen rendes game state objected és használj valami XML vagy JSON szerializáló libraryt (Newtonsoft mondjuk).
Ez így 90-es évek szimulátor.
-
#10054
quailstorm
félisten
Tomi_78
#10053
-
#10028
quailstorm
félisten
Tomi_78
#10027
quailstorm
félisten
válasz
Tomi_78
#10027
üzenetére
Az osztály egy absztrakt fogalom, egy memóriaértelmezési térkép. Abból először példányokat kellene létrehozni hogy legyen mit foreachelni. A foreach nem típusokon tud iterálni hanem típuspéldányok felsorolásán.
Az általad említett könyvben benne van a C# és úgy egyáltalán a programozás elméleti alapjának összefoglalása, de nem a legérthetőbb és néhol pongyola. Inkább menj át a Ruzsinszki könyvön és utána csak a konkrét játékprogramozós részekkel folytasd.
-
#10026
quailstorm
félisten
Tomi_78
#10024
quailstorm
félisten
válasz
Tomi_78
#10024
üzenetére
Mi alapján tanulsz? Eddigi kommentjeidből úgy néz ki, hogy nem vagy birtokában stabil tudásnak, nem érted a fogalmakat és eszközöket amiket próbálsz használni, csak másolsz és csavarsz rajta valamit.
Mielőtt nekiállsz egy grafikus játéknak, legalább egy programozás könyvön rágd át magad.#10025 Alexios: amúgy ki lehet gyűjteni reflectionnel egy assemblyben egy adott típus összes implementációját. Pl. arra jó, hogy a tesztpluginunkba így elég egy új osztályt behajítani és a lefordított plugin már ki is teszi az új osztályt a UI-ra mint választható test scenario.
-
#9967
quailstorm
félisten
savior
#9966
quailstorm
félisten
Objektum-orientáltság, öröklődés erre jól ráhúzható.
Fegyver interfész, vagy absztrakt osztály virtuális függvényekkel és azt implementálod az egyes fegyvertípusok szerint.
-
#9923
quailstorm
félisten
Alu
#9922
quailstorm
félisten
A BackgroundWorker az egy jó pattern erre.
Ugyan ez WPF de itt is szépen el van magyarázva.Ha simán csak egy UI változót kell pörgetni akkor pedig az IProgress egy jó pattern. [link]
-
#9905
quailstorm
félisten
CPT.Pirk
#9904
quailstorm
félisten
válasz
CPT.Pirk
#9904
üzenetére
Igen, így van. A Peek üres stack esetén exceptiont dob. Szóval az utolsó pop után a következő feltételellenőrzés a while-ban exception, nem pedig false. A Count ellenőrzése jó lesz.
-
#9830
quailstorm
félisten
ReSeTer
#9829
quailstorm
félisten
válasz
ReSeTer
#9829
üzenetére
"Teljesen mindegy mi a method, az a lényeg, hogy nem UI-n belül lévő method-on belül akarom megváltoztatni az UI-n lévő feliratot."
Ilyet nem tudsz csinálni, amennyiben a számolás másik szálon történik. Ha csak egy változót akarsz pörgetni, arra tökéletes az IProgress. Egyébként pedig én callback eventet használnék és dispatcherrel vissza UI threadre (hogy a workerben ne legyen direkt UI kód).
Ha nincs több szál a dologban, akkor elég a sima event invoke és a callbackben meg UI elem setelés. De ha hosszabb számolás, és a UI-t nem szeretnéd fagyasztani, akkor jobban jársz a külön threaddel.
Eventek.
DispatcherFire/SOUL/CD mutatja a statikus elérését a UI elemnek, azt is lehet, viszont az nem szép és nem moduláris megoldás. Bedrótozod az egyik komponensbe a másik komponens struktúráját.
-
#9800
quailstorm
félisten
leslie23
#9798
-
#9770
quailstorm
félisten
Sokimm
#9769
quailstorm
félisten
Ide egy gráf adatstruktúra kell.
Szerencsére megvan a lehetőséged, hogy kész függvénykönyvtárat használj:
[link] [link] [link]
Ha szeretnéd a hátterét kicsit elolvasni.Az össze vissza elnevezett változóid meg teljes tévút és felejtsd el. Objektumokban kéne gondolkozni és a relációk adattagként tárolásában.
-
#9762
quailstorm
félisten
ReSeTer
#9761
quailstorm
félisten
válasz
ReSeTer
#9761
üzenetére
YAML az van olyan egyszerű és letisztult, mint az INI, én azt javaslom ebben az esetben. De INI-hez is létezik library: például.
Én INI-vel úgy találkoztam, hogy GSD (PROFIBUS). Ahhoz képest a GSDML (PROFINET, XML alapú), az sokkal könnyebben használható programozás oldalról. INI-be nem tudsz szerializálni és deszerializálni sem (vagy kutatni kell olyan libet, ami tud).
-
#9759
quailstorm
félisten
fatal`
#9758
quailstorm
félisten
Semmihez nem kell WCF. Az csak egy példakód DataContract szerializációra és deszerializációra. Linkelhettem volna ezt is.
Múlt héten kellett pont, ideiglenes megoldásként egy projektbe. Nem volt szabad berakni külső libet és régi .NET*, a DataContract-os szerializáció meg nagyon könnyen elérhető, mert csak a System.Runtime.Serialization reference kell hozzá.*Tehát Newtonsoft-ot nem szabad, de System.Text.Json meg még nincs.
-
#9757
quailstorm
félisten
cattus
#9756
quailstorm
félisten
Lehet én vagyok kocka, de nekem a json már bőven az ember által jól olvasható kategória, beautified formázással. Itt van rá NewtonSoft és System.Text.Json opció is.
Tény, hogy a DataContract az nem szép Json-t exportál, ahhoz a szövegszerkesztőben kell automata formázni (nálam Notepad++ és JSTools plugin, vagy Visual Studio Code).
TOML-t én elvetném, annyira nem tiszta annak sem a szintaxisa. YAML valóban megfelel az olvashatóság és az objektum konvertálás kritériumainak is, elsőre nem jutott eszembe, köszi, hogy bedobtad.
@ReSeTer: mennyire "kocka", aki szerkeszteni fogja azt a szöveges fájlt? Mennyire állandó a konfigurációs fájl struktúrája? Ha nagyon egyszerű, vagy állandó, akkor egy GUI-t sem nagy cucc összedobni hozzá.
-
#9755
quailstorm
félisten
ReSeTer
#9754
quailstorm
félisten
válasz
ReSeTer
#9754
üzenetére
Json, vagy XML.
INI egy rémálom, TXT meg 80-as évek.Találj ki valami jó kis objektumos reprezentációt, aztán szerializáció, deszerializáció.
DataContractTudom, hogy nem ez a legszebb megoldás, amit linkeltem, de ezt régi .NET-en is meg lehet oldani külső libek, NuGet és függőségek nélkül.
-
#9746
quailstorm
félisten
ReSeTer
#9743
quailstorm
félisten
válasz
ReSeTer
#9743
üzenetére
Van egy magyar könyv, Evosoft alkalmazott írta. Szerintem ez elég jó alap.
#9745 Victoryus : megjelenítés rétegben mindegy milyen DB van alatta, szóval inkább általános adatbáziskezelős tutorialokat nézz, meg az accdb driver API kézikönyvét.
-
#9741
quailstorm
félisten
robotjatek
#9739
quailstorm
félisten
válasz
robotjatek
#9739
üzenetére
Ja igen, így már értem én is, hogy mit nem látott. Pedig észrevettem a commandot elsőre is...
A Binding (ICommand implementáció) amit néznie kell és F12-vel nyomkodnia. A Click handlert lehet hogy valaki véletlen hozzáadta, de az nem csinál semmit most, inkább törölni kellene.
Ha paraméter kell a Command-hoz, akkor a CommandParameter attribútummal megteheti.#9740 cigam
ICommand WPF MVVM
Új hozzászólás Aktív témák
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- Xiaomi Redmi Note 9 / 4/128GB / Kártyafüggetlen / 12 Hó Garancia
- Apple iPhone 12 Pro 512GB,Átlagos,Dobozával,12 hónap garanciával
- Endgame Gear gamer egerek /OP1 8K, XM2we, XM1R, XM1 RGB (fehér/fekete/lila)/
- BESZÁMÍTÁS! Dell Latitude 3530 üzleti notebook - i5 1235U 8GB DDR4 512GB SSD Intel Iris Xe WIN11
- Ezviz BC1 1 kamerás kamera szett / 12 hó jótállás
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest