játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5444
FZoli:    4892
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2519

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2188
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
syam:    1491
Korábbi postok
> 1 < [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] [60] [65] [70] [75] [80] [85] [90] [95] [100] [105] [110] [115] [120] [125] [130] [135] [140] [141]
Instalok - Tag | 539 hsz       Online status #210977   2017.02.07 18:23 GMT+1 óra  
Nahát, meglepődve jöttem rá, hogy
Kód:
T1 t1;

nem (feltétlen) ugyan az, mint
Kód:
T1 t1{};

továbbá az
Kód:
int a;

nem ugyan az, mint
Kód:
int a{};

Hogy mik vannak.

Default Initialization
Value Initialization

   
Asylum - Törzstag | 5444 hsz       Online status #210938   2017.02.03 22:53 GMT+1 óra  
Nekem inkább azt szokták mondani h a röhögéstől nem tudnak kódolni (pozitív értelemben)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 539 hsz       Online status #210936   2017.02.03 19:46 GMT+1 óra  
De más meg nem írt sehol deklarációt/definíciót.

Amúgy ja, a blog tényleg jó, emberi nyelven van megfogalmazva.

   
Asylum - Törzstag | 5444 hsz       Online status #210932   2017.02.03 18:37 GMT+1 óra  
@Instalok: b+ nem neked mondtam, a te hsz-ed tökéletesen helyes volt, ne legyél már ilyen érzékeny...

@Bukta: a blogomról többet tanulhatsz, mint gondolnáld Ha valamit nem értesz kérdezz.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Bukta - Tag | 308 hsz       Online status #210928   2017.02.02 20:07 GMT+1 óra  
Ja igen kösz Instalok, ez így már oké lett

Asylum aa tényleg a blogodon is van cpp. Na ezt már elfeledtem, majd ezt is végigfutom
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
Instalok - Tag | 539 hsz       Online status #210926   2017.02.02 19:04 GMT+1 óra  
Tökéletesen használtam a definíció fogalmát. Idézve a cikkedből:
Idézet
Azt amikor megmondjuk egy változó típusát és nevét, deklarációnak hívjuk (pl. extern int i. Amikor a változónak "memória foglalódik" az a definíció (pl. int i. Egy változót tetszőlegesen sokszor lehet deklarálni, de pontosan egyszer lehet csak definiálni.

Ha azt a sort leírod még egyszer, akkor multiple definition lesz. Próbáld csak ki.

@Bukta
A lényeg ennyi:
Kód:
// header

#include <vector>

struct Foo
{
    static std::vector<int> cucc;

    static void use();
};

// cpp

std::vector<int> Foo::cucc;

void Foo::use()
{
    cucc.clear();
}

Ezt a hozzászólást Instalok módosította (2017.02.02 19:13 GMT+1 óra, 260 nap)

   
Asylum - Törzstag | 5444 hsz       Online status #210925   2017.02.02 19:00 GMT+1 óra  
Bakker tényleg olyan qva nehéz megtanulni mi a különbség deklaráció és definíció között? Mi a sz*rnak írom ezt a rengeteg cikket????

http://darthasylum.blog.hu
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 539 hsz       Online status #210922   2017.02.02 18:45 GMT+1 óra  
Nem-nem, nem úgy.
Kód:
// cpp

// definíció
std::vector<Vector3> Foo::positions;

void doit()
{
    // használat
    positions.clear();
}

A typedef meg azért jó, h ne kelljen 50 helyen leírni a típust: std::vector<Vector3> hanem helyette Vectors.

   
Bukta - Tag | 308 hsz       Online status #210921   2017.02.02 18:24 GMT+1 óra  
Hogy őszinte legyek, nem jött össze még mindig error-t dob:
error: qualified-id in declaration before '.' token
std::vector<Vector3> ObjMeshLoader::positions.clear();


Csak most más a szöveg. Az ObjMeshLoader.cpp-be. Typedef C-ből ismerős, de anélkül is mukodni kéne szerintem (Persze majd megnézem C++-ba miként van)
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
Instalok - Tag | 539 hsz       Online status #210919   2017.02.02 16:10 GMT+1 óra  
Kód:
// header

class Foo
{
static std::vector<Vector3> positions;
};

// cpp

std::vector<Vector3> Foo::positions;

+ nézz utána a typedef-nek is, elég hasznos
Kód:
typedef std::vector<Vector3> Vectors;

   
Bukta - Tag | 308 hsz       Online status #210918   2017.02.02 15:40 GMT+1 óra  
Hali
C++ tanulok, eddig C#-oztam és vannak problémák Van nekem egy objmeshloader.h amibe van egy statikus vector<Vector3>. Na most az objmeshloader.cpp-be Undefined reference 'ObjMeshLoader::positions' error-t ír ki. Nem tudok rájönni miért (am #include "objmeshloader.h" ott can a objmeshloader.cpp-be). Statikus a változó, a fv amibe használom csak a class nem statikus, de ha azzá teszem megint előjön valami más hiba...

Kód:
static std::vector<Vector3> positions;


Kód:
positions.clear();
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
Instalok - Tag | 539 hsz       Online status #210796   2017.01.16 09:01 GMT+1 óra  
Azt írták itt-ott, hogy nem annyira optimális scalarokat const refként használni. Az EASTL esetében például azt írták: (bár ez ugye a return-re vonatkozik, nem a paraméterre)
Kód:
/// Some compilers (e.g. VS20003 - VS2013) generate poor code for the case of 
/// scalars returned by reference, so we provide a specialization for those cases.
/// The specialization returns T by value instead of reference, which is
/// not that the Standard specifies.

template <typename T>
inline EA_CONSTEXPR typename eastl::enable_if<eastl::is_scalar<T>::value, T>::type
min(T a, T b)
{
    return b < a ? b : a;
}

template <typename T>
inline typename eastl::enable_if<!eastl::is_scalar<T>::value, const T&>::type
min(const T& a, const T& b)
{
    return b < a ? b : a;
}

Persze egyelőre úgy hagytam const refként, mert hát miért is ne. Release buildet meg majd nem MSVC-vel fordítok, hanem GCC-vel.

   
Asylum - Törzstag | 5444 hsz       Online status #210795   2017.01.16 08:55 GMT+1 óra  
Miért baj a const ref? Semmi extra memóriát nem jelent. Ennél elegánsabb megoldás egyébként a template specializáció.

Kód:
template <typename T>
T Abs(const T& a) { ... }

template <int>
int Abs(int a) { ... }


Vagy valami hasonló, majd bent kipróbálom.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 539 hsz       Online status #210794   2017.01.14 23:59 GMT+1 óra  
Elkezdtem valami ilyesmivel próbálkozni, hogy scalar típusokra ne const refet használjak.
Kód:
using SelectArgT = conditional_t<is_scalar<T>::value, const T, const T&>

template <typename T>
static T Abs(SelectArgT<T> val);

A probléma annyi, hogy azt mondja a fordító, hogy: could not deduce template argument for 'T'. Ami valahol érthető, valahol meg mégsem. Persze megoldható lenne úgy, hogy pl. Abs<uint32>(...), de ezt el szeretném kerülni.

Persze annyira pici ez a függvényt, hogy enable_if és újraimplementálás segítségével meg tudom csinálni. Azonban kíváncsi vagyok, hogy meg lehet-e oldani másképp.

   
Parallax - Tag | 579 hsz       Online status #210786   2017.01.11 07:03 GMT+1 óra  
Saját cuccokat akkor érdemes írni, ha azok több funkciót nyújtanak és/vagy gyorsabban működnek és/vagy átláthatóbbak. Mivel úgyis TDD-vel dolgozik az ember, vagy legalábbis lefedett tesztekkel a cucc a működés helyessége itt is garantált. Azt nem tudom az std mennyire tesztelt, de hogy nem átlátható, nem gyors és kellően túl általános az biztos.

   
Instalok - Tag | 539 hsz       Online status #210783   2017.01.09 17:05 GMT+1 óra  
Akkor végső soron jó irányba indultam el, mert én is mallocot használtam. Amit láttam még trükköt az az, hogy void*-ra szokták castolni, mert a new operátor egyébként felülírható, így, ha valaki akkora állat, akkor elronthatja a containert.

Terveztem amúgy én is teljes container-library-t írni, csak meg kell húzni egy egészséges határt. Ott van például a string, meg a különböző type_traits, algoritmusok és a többi. No meg ott a vector, az alapvetően nem (biztos, hogy) annyira rosszul implementált dolog, és legalább jól tesztelt.

Arról nem is beszélve, hogy az std namespace-t nem lehet teljesen kiírtani a kódból egyébként sem. Ott van pl. az std::initializer_list, abból ugyan írhatunk sajátot, csak éppen nem fog működni.

További apróság, hogy std és saját mixeléskor előjönnek a naming convention különbségek. Én például a típusokat (és a függvényeket) upper-camel-case írom, a változókat meg camel-case, míg az std egységesen kisbetűket és underscore-okat használ mindenhol. Persze lehetne követni az std namespace alatti naming convention-t, de az a saját szabályaim félrelökése lenne

   
Asylum - Törzstag | 5444 hsz       Online status #210782   2017.01.09 16:46 GMT+1 óra  
A belső konténerek valóban value_type*-ot használnak adatnak. Ezt azonban nem a new kifejezéssel, hanem malloc()-al foglalják le (így tulajdonképpen típustalan memória marad). Ezek után a placement new az, ami a konkrét konstruktort meghívja:

Kód:
template <typename value_type>
void vector<value_type>::push_back(const value_type& item)
{
    if( mysize >= mycap )
        reserve(mycap + 1);

    new(data + mysize) value_type(item);
    ++mysize;
}


(saját implementáció)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 539 hsz       Online status #210780   2017.01.09 13:26 GMT+1 óra  
Úgy láttam, h a legtöbb esetben, amikor valamilyen konténerbe teszünk elemet, placement new-t használnak, hogy az adott T copy constructora fusson, ne az assignment operatora. Ez igazából nem bug? Adott egy class, ami a default constructorában valamilyen allokálást hajt végre:
Kód:
struct DontDoThis
{
    DontDoThis()
        : arr(new uint8[12])
    {
    }
    DontDoThis(const DontDoThis& other)
        : arr(new uint8[12])
    {
        memcpy(arr, other.arr, 12);
    }
    ~DontDoThis()
    {
        delete[] arr;
    }
   
    uint8* arr;
};

Amikor egy konténer T típusú arrayt használ belső tárolóként, akkor a new T[size] híváskor a T default konstruktora meghívódik. Amikor pedig hív egy push_back(const T&)-t, akkor a placement new meghívja az adott elem copy konstruktorát.
Kód:
template <typename T>
class vector
{
public:
    vector()
        : arr(new T[4]) // T::T() hívások
    {
        end = arr;
    }
   
    void push_back(const T& v)
    {
        ::new (end) T(v); // T::T(const T&)
        ++end;
    }
   
private:
    T* arr;
    T* end;
};

Nem tudom, hogy pontosan így csinálják-e, de ha igen, akkor az nyilván nem jó. Gondolom érdemesebb valami olyan belső reprezentációt választani, ami nem hív default konstruktort (pl. malloc, vagy byte array), vagy nem placement new-t (azaz T copy konstruktort), hanem mondjuk operator= -t használni.

   
Instalok - Tag | 539 hsz       Online status #210764   2017.01.02 22:52 GMT+1 óra  
Ezek szerint ARM-en nincs implicit padding? Csak mert, ha a Header meg a T is paddolva van, akkor elvileg mindig word-boundary-ra esik a cím, nem?

szerk.:
Ahha, mondjuk olyat simán lehet csinálni, hogy a template paraméter egy uint8 lesz, és máris borul az egész, mert akkor a következő Header nem megfelelő címre kerülne.

Ezt a hozzászólást Instalok módosította (2017.01.03 11:48 GMT+1 óra, 291 nap)

   
Asylum - Törzstag | 5444 hsz       Online status #210763   2017.01.02 20:48 GMT+1 óra  
Igen, elő. Pl. ARM-en nagyon kell vigyázni az ilyen kasztolásokkal (pl. volt olyan elszállásom, hogy vector3&-é kasztoltam egy memóriaterületet és a cím invalid lett; szerencsére az xcode elkapta, mint alignment exception).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 539 hsz       Online status #210762   2017.01.02 19:18 GMT+1 óra  
Adott egy byte buffer, abba szeretnék változó méretű adatokat elhelyezni. Nyilván ehhez egy-egy headert tárolok el az adatok előtt, amivel be lehet azonosítani az adatot és a méretét.
Kód:
--------------------------------------------
header | data | header | data | ...
--------------------------------------------

Eddig nem foglalkoztam alignmenttel, simán csak egymás után pakoltam az adatokat, kb. ilyesmi:
Kód:
template <typename T>
T* Push(IdType id)
{
    // reinterpret_cast
    Header* header = (Header*)&buffer[pos];
    header->id = id;
    header->size = sizeof(T);

    pos += sizeof(Header);   
    T* data = (T*)&buffer[pos];
    pos += sizeof(T);
   
    return data;
}

Ha jól tudom a sizeof() beleszámolja a paddingeket, ami viszont compilerenként/platformonként más és más lehet. Előfordulhat olyan eset/architektúra, hogy a fenti kód nem fog jól működni?

   
Matzi - Szerkesztő | 2519 hsz       Online status #210712   2016.12.20 20:52 GMT+1 óra  
Atomical lehet meg lehetne oldani tobbszálú esetben is a mukodést. Esetleg csinálj egy olyat, hogy statikusan inicializálsz példányokat, és még nevet is adsz neki. Lényegében egyfajta szegény ember RTTI-je, ami ugyan nem jó minden típusra, de úgysem kell hogy jó legyen minden típusra.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Instalok - Tag | 539 hsz       Online status #210711   2016.12.20 19:39 GMT+1 óra  
Inline nélkül multiple definition.

Az ilyen egyszerű trükkök (mint pl. egy static counter) pedig ugye problémásak lehetnek, amint 1-nél több szál van a dologban. Lehetne még esetleg a preprocesszorral szórakozni, de az sem az igazi. Nem akarok csak ezért RTTI-t használni, az annyira gáz.

   
Matzi - Szerkesztő | 2519 hsz       Online status #210706   2016.12.20 12:32 GMT+1 óra  
Konnyen megeshet, hogy ez megtorténik. http://stackoverflow.com/questions/2175302/unique-numerical-id-for-a-templated-class-using-function-address
"I tested this with VS 2015 and it works when compiling for Debug but not when compiling for Release. When compiling for Release, the optimizer combines all classID() functions into a single one."

Az sem jelent sok jót, hogy inline-osítottad. Ha inline lesz, akkor a fuggvény nem is létezik, szóval nem is nagyon lesz címe. Valószínuleg ebben az esetben inkább csak figyelmen kívul hagyja az inline-t.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Instalok - Tag | 539 hsz       Online status #210705   2016.12.20 09:11 GMT+1 óra  
Régebben olyan megoldást választottam egy típus azonosítására, hogy:
Kód:
template <typename T>
class IdGenerator
{
public:
    static uint64 Get();
};

template <typename T>
inline uint64 IdGenerator<T>::Get()
{
    return reinterpret_cast<uint64>(&Get);
}

De most kicsit elbizonytalanodtam: mi történik, ha a fordító ügyeskedik, és nekiáll bőszen optimalizálni. Megtörténhet az, hogy az összes függvény tulajdonképpen ugyan az lesz (ezzel elveszítve a címuk egyediségét)? Igazából elvileg megtörténhet, mert maga a függvény nem (és az osztály sem) függ a T-től.

   
gopher - Törzstag | 496 hsz       Online status #210673   2016.12.15 15:05 GMT+1 óra  
@Geri:

Cities: Skylines
Dead Effect 2
Ori and the Blind Forest
Lara Croft: Relic Run
..és a sor bőven folytatható. Teljesen más a Unity, mint egy Game Maker, és kár úgy fikáznod valamit, hogy sosem próbáltad ki. A labda pattintgatós játékból meg kihagyod, hogy mostanában nem elég hogy megcsinálod a játékot, nem árt ha ez fut Android/iOS kombón és eléri az adott platform service-ait (pl. Play Services, Admob). Ami Unity-ben egy-egy plugin, illetve egy-egy klikk a build, míg ezt only C-ben elég sokáig fog tartani összehozni.

@Matzi: sorry, ezt közben írtam. De Geri, válaszolj az általános topicban

Ezt a hozzászólást gopher módosította (2016.12.15 16:15 GMT+1 óra, 309 nap)
   
Matzi - Szerkesztő | 2519 hsz       Online status #210672   2016.12.15 14:54 GMT+1 óra  
Ezzel át lehet menni az Általános Offtopicba.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Parallax - Tag | 579 hsz       Online status #210671   2016.12.15 14:41 GMT+1 óra  
Igen pont arról volt szó, hogy nem programozók fejlesztenek, már amennyire a pár soros fgv alapú scriptelést, meg a visual scriptinget a nem programozók csoportjának tekintjük. Szóval igen, nekik már az is sok, hogy van egy engine/lib, amit le kell fordítani forrásból, esetleg linkelni, vagy kódolni C/C++ ban, ezt mint negatívumot hozzák fel már kapásból és már nem is foglalkoznak vele. Még a "maker" motoroknál is kifogás, ha nem elég egyszerű a használata a közel 0 programozás mellett is, nincsen mondjuk match3, vagy booble template, hanem dokumentációkat kell olvasni (phejj). Hátrány, hogy egy Hello alkalmazás is 200 mb és nyilván szuboptimális lesz az eredmény egy sokféle igénynek megfelelő motorral, egy adott célra kifejlesztettel szemben.

Most a JF azt a korszakát éli, ami az üzleti szoftvereknél volt a 90-es években. Szakértői rendszerek, vizuális fejlesztői eszközök voltak, ahol pár kattintással szinte 0 programozással lehetett létrehozni alkalmazásokat. (Progress, Magic stb.) Aztán rájöttek, hogy egyéni igényeknek nem lehet megfelelni ilyen "maker" eszközökkel és ma már még a felhasználói felületet is programozással kell létrehozni (lásd WPF). Szóval majd lehet a JF is túljut ezen az időszakon, ha lesz rá igény, ki tudja.

   
Geri - Törzstag | 2188 hsz       Online status #210670   2016.12.15 14:17 GMT+1 óra  
szerintem egyszerűen arról van szó, hogy parallax, szerintem egy valamihez hozzá kell pattintani egy labdát jellegű játékot egyszerűbben megcsinálsz mondjuk C-ben mint bármi másban pusztán azért, mert C/c++-ban szabadabban és nagyon gyorsan meg tudod csinálni hozzá az azt hajtó logikát és koordinátageometriát, míg mondjuk egy librarykból összedobált szkriptelőtool erre nem biztos, hogy alkalmas pusztán azért, mert ha ehhez a logikához valami épp nincs leimplementálva mellé, akkor egy ilyen környezetben erősen valószínű, hogy érdemben nem is fogod tudni leimplementálni. mivel a c# a statok szerint már halott, mondjuk előlegezzük meg, hogy egy ilyen tetszőleges toolban is vagy C-vel, c++-al, vagy esetleg javaval, basiccel, vagy a tool saját nyelvével kell majd dolgozni eleve, tehát ebből a szempontból nincs különbség. egy alapvető engine néhány ezer sor valamilyen tetszőleges apira építve (de ha meg valaki vadállat eléggé, az is megvan 2ezerrel több sorból, ha nagyon akarja), és akkor az tud már keyframe animot, meg alapvető effekteket is, elég mondjuk 10 évente újat írni belőle. középiskolás mateknál sem kell sehová több. tehát nem egy olyan traumatikus programozási probléma, amit el kell kerülni. a munkának talán 1-2%-át teszi ki, az adott játékban lévő kódnak talán 5-10%-át. a többi meg mondjuk az engine azon része, ami már a konkrét játékot vezérli - pl fps esetén egy fps logic ami irányítja az npc-ket, a fegyverek lövéseit, meg mondjuk azt, hogy a falon ne sétálj át, meg a töltény se mindenhol menjen át. tehát egyszerűen arról van szó, hogy aki ezt is le akarja spórolni arra hivatkozva, hogy milyen bonyolult, az általában nem egy rendes programozó, de még csak nem is egy rendes játékfejlesztő, ugyanis az engine magjának a leimplementálása több nagyságrenddel egyszerűbb, mint mondjuk felhúzni egy pokemon-rpg harcrendszert. ha az első nem megy neki, akkor a második sem fog. hogy akar egy 40ezer soros battle logicot lekódolni, ha az 5 ezer soros enginetől összefossa magát valaki, hogy az milyen bonyolult? sehogy. ezzel nem spórol sem időt, se semmit, csak a világ felé teszi a szépet, hogy ő milyen király, meg hogy mennyit haladt, és hogy már wasd-vel lehet repkedni benne, ő itt a király. így aztán a kezei közül kikerülő alkotások is szarok, mint ahogy mondjuk unity kapcsán látjuk a sok hulladékot. az eredmény aztán nem komolyan vehető, nem eladható, nem továbbfejleszthető, 10x nagyobb, 5x annyi erőforrást használ, tud pár ezer letöltést és max 40 eladást, azok is a haverjai a fórumokról... vannak persze jó enginek, csak azok eléggé célirányosak szoktak lenni, nem ilyen toolcopy, szintűek, de ha valaki ténylegesen alkotni akar valamit, akkor azokat is érdemes hanyagolni.

ma már olyan egyszerűen meg lehet írni bármit normálisan, hisz az internet korát éljük, kontrasztban mondjuk 1995-el és 2000-el, amikor még csak 1-2 embernek volt internetje, semmiről nem lehetett semmit sem tudni, egy pixelt sem lehetett kirajzolni, mert minden információ rejtve és titkolva volt, hogy egyszerűen nincs értelme annak, hogy thirdparty toolokkal akadályozza az ember saját magát.

   
Lord_Crusare - Törzstag | 1288 hsz       Online status #210669   2016.12.15 10:55 GMT+1 óra  
Csak az első.

A másodikat már az Obsidian fejlesztette:

http://store.steampowered.com/search/?developer=Obsidian%20Entertainment

   
Asylum - Törzstag | 5444 hsz       Online status #210668   2016.12.15 10:49 GMT+1 óra  
Hé, a KOTOR az Bioware!

(nem?)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Parallax - Tag | 579 hsz       Online status #210667   2016.12.15 08:04 GMT+1 óra  
Idézet
Geri :
nem hagyhatom, hogy idegen, homályos érdekeket szolgáló propaganda olyan inproduktív és rossz toolokra vigye rá az érdeklődőket, amelyekbe kár minden belefektetett energia.


Azt azért szögezzük le, hogy a C/C++ ban írjunk engine-t hullám már lecsengett jópár éve. Hozzá kell szoknod, hogy "maker" = fejlett editorral rendelkező motorral nem feltétlen programozók fejlesztik ma már a játékok többségét. Hobbiból, tanulási céllal, vagy valamilyen más indíttatásból van 1-2 fanatikus (pl én is), aki C/C++ szal ír engine-t, de ez ma már elenyésző, ebbe bele kell törődni. Egyszerűen nem éri meg ezzel vesződni, gyorsan, akár minden hónapban/héten ki kell termelni 1-1 játékot, amik szintje akár egy c64-es profi címet is alulmúlhat, de most erre van igény. Elnézem én is, hogy mikkel játszanak a mai fiatalok pl.: egy forgó geometriai forma lapjaihoz kell pattintani egy labdát, ennyi a játék, ettől mesze van van pl egy c64-es Turrican, Elite stb színvonal, vagy akár egy Mario is, de most ez a menő és ehhez "maker" eszközökkel kell futószalagon termelni, ez van. Ma, aki a játékfejlesztésbe fog inkább designer, mint programozó és olyan eszközt keres, ahol lehetőleg programozás nélkül is lehet fejleszteni. Mivel jól lehet automatizálni egy engine-t így a programozók innen ki is koptak, mint a dinoszauruszok.

   
Lord_Crusare - Törzstag | 1288 hsz       Online status #210665   2016.12.14 21:41 GMT+1 óra  
Jah, mondjuk ennek az egésznek nem sok köze van a C++-hoz, az tény. Lehet törölve is lesz pont emiatt.

   
Geri - Törzstag | 2188 hsz       Online status #210664   2016.12.14 21:30 GMT+1 óra  
Lord_Crusare, itt elsősorban a félig már megdöglött c#-ról volt szó a beszélgetésben - eleve a c++ topikban vagyunk - és annak kapcsán lett megemlítve az unity talán parallax részéről, hogy a c# és unity kombó micsoda jelentős meg fantasztikus dolog (hát nem az). az már csak hab a tortán, hogy itt a c#+unity házassággal a sánta a hátára veszi a púpot, tehát mindkét megoldás önmagában is rossz, hát még együtt...

és miért baj az, hogy az unityt a game makerhez hasonlítom? a konkrét működési elve nem lényeges ahhoz, hogy a két dolgot párhuzamba állítsam. nem kell értenem ahhoz a ledek tervezéséhez, meg a wolfram szál izzásához, hogy össze tudjam hasonlítani a két izzót abból a szempontból, hogy melyiket veszem meg. a game maker egy nagyon komoly tool, a maga idejében hasonló szerepet töltött be, mint most az unity, és alapvetően hasonló véleményem is volt róla eleinte, de ma már valamennyivel jobb a véleményem a game makerről, mint az unityről.

én se game makert se unityt személyesen nem láttam, meg használni nem is akartam - és a jövőben sem fogom egyiket sem, tehát személyesen problémám sem lehet egyikkel sem.

pusztán a fát terméséről bibliai elv alapján bennem egy igencsak kedvezőtlen kép alakult ki az unityről a benne elkészített dolgok alapján, meg alapvetően a közösségéről is azok alapján, amit eddig láttam tőlük, róluk. de például a c#-ot használtam egyszer már személyesen is, szóval annak sokkal személyesebb tapasztalatok alapján is nekimehetek, és ezt, ha szűkséges, meg is teszem., mert nem hagyhatom, hogy idegen, homályos érdekeket szolgáló propaganda olyan inproduktív és rossz toolokra vigye rá az érdeklődőket, amelyekbe kár minden belefektetett energia.

   
Lord_Crusare - Törzstag | 1288 hsz       Online status #210663   2016.12.14 21:13 GMT+1 óra  
A piacképességet a kereslet határozza meg, amit pedig az eladott példányszámokból lehet lemérni. A felsorolt játékok kivétel nélkül elég durva példányszámmal keltek el, és ha utánanézel Steam-en, láthatod, hogy nem csak ezek a Unity-s játékok sikeresek ennyire.

Egyébként a vita C#-re vonatkozó része azért ferdítés (részemről is), mert szigorúan véve amivel a Unity-t scriptelik, az igazából nem C#, csak úgy néz ki. Épp ezért az ilyen statisztikákba általában nem szokták beleszámítani.


A "böki a csőröd" részt inkább arra értem, hogy anélkül, hogy utánanéznél a Unity működési elvének, támadod és a game makerhez hasonlítgatod (elárulom, a kettő bőven nem ugyanaz a szint, a Unity-hez azért vastagon tudni kell programozni is). Mivel agyatlanul nekimész újra és újra, meg automatikusan feltételezed, hogy rossz, ezért gondolom, hogy neked kifejezetten valami személyes problémád van az ilyesmivel.

   
Geri - Törzstag | 2188 hsz       Online status #210662   2016.12.14 21:05 GMT+1 óra  
Idézet
ami neked valamiért nagyon böki a csőröd, és ezért valótlan dolgokat próbálsz állítani


miért bökné, mi hasznom, vagy károm származik belőle? valótlanságot meg nem állítottam, amiket leírtam. amiket belinkeltél, azok sem nagyrészt épp a piacképesség csúcsai, főleg ilyen ár mellett nem. érvelési szempontból azért ez sem valami nagy érv, hogy van olyan, ahol az unity sikeres játék mögött dohog, mert hát biztos, a kivétel erősíti a szabályt alapon a szovjetunióból is kerültek ki jó termékek, csak épp a döntő többség mégsem volt piacképes, mint ahogy unity esetén sem az.

tessék, itt egy könnyűszerrel kikereshető tényszerű számadat: például a c# 4 év alatt elvesztette a piaci részesedése 70%-át a tiobe index alapján. ez például egy tény, és nem vélemény. biztos nem azért, mert olyan nagyon szupcsi unitys játékokat írtak vele.

   
Lord_Crusare - Törzstag | 1288 hsz       Online status #210661   2016.12.14 20:59 GMT+1 óra  
Itt arról van szó, hogy továbbra is bőven készülnek piacképes játékok C# alatt, ami neked valamiért nagyon böki a csőröd, és ezért valótlan dolgokat próbálsz állítani. A statisztika nem hazudik. Többszázezer, esetenként milliós eladással rendelkező játékokról van szó, amiket Unity-vel készítettek. Tehát, a rendszer működik és sokan használják, sikerrel.

Ezekután az, hogy neked ezek nem tetszenek, érvelési szempontból lényegtelen. Az én véleményem is az. Egyszerűen arról van szó, hogy az általad tényként közölt információk teljességgel alaptalanok és könnyűszerrel cáfolhatók.

   
Geri - Törzstag | 2188 hsz       Online status #210660   2016.12.14 20:51 GMT+1 óra  
ha szimbólumokban egyáltalán nem akarnánk gondolkodni, és szigorúan szó szerint vesszük a wasd-vel való röpködést, akkor nyilván túlmutatnak... mondjuk a quern nem annyira ugorja meg még ezt sem

nem látom azt, hogy tévednék ennek az infrastruktúrának a megítélésével kapcsolatban, ezeket én nem tartom semmilyen szempontból sem említésre méltó alkotásoknak, persze elfogadom a véleményed, csak épp sehogy sem tudja ez megváltoztatni az enyémet.

   
Lord_Crusare - Törzstag | 1288 hsz       Online status #210659   2016.12.14 20:42 GMT+1 óra  
"ezek szerintem nem érnek szart sem"

Nem erről volt szó. Arról volt szó, hogy túlmutatnak-e a wasd-al röpködés szinten. És mint ahogy te is elismerted, igen, túlmutatnak.

Az utolsó az rejtvényjáték, hasonló a Myst-hez, de oké, ha gondolod, lecserélem pl. erre:

http://store.steampowered.com/app/289130/

Masszív körökre osztott stratégiai játék.

Manapság már ezt használja a Ubisoft, a Square Enix is egyébként, hogy csak párat említsek a nagyobb nevek közül.

Tehát, visszatérve arra, amit eredetileg mondtál: igen, még bőven használják a C#-t arra, hogy "wasd-al repkedés"-nél komolyabb dolgokat fejlesszenek. A magánvéleményedhez jogod van, de a tények, amiket állítani próbálsz, tévesek.

   
Geri - Törzstag | 2188 hsz       Online status #210658   2016.12.14 20:35 GMT+1 óra  
Idézet
Lord_Crusare :
Ja, és tévedsz! A Pokemon GO is Unity-s.




a pokemon go egy szkript, ami pokemonokat renderel ki a kamera képe elé, és meghívja a c-ben megírt poke-enginet (mert androidra még nincs nekik enginejük vagy kóduk). maguk a pokemon játékok már nem unitysek.

   
Geri - Törzstag | 2188 hsz       Online status #210657   2016.12.14 20:33 GMT+1 óra  
Tyranny: ez a grafika és animáció nekem a red alert 2-t idézi fel, talán ha annak az enginét használják, nem kéne 6 giga ram ahhoz, hogy elindítsd. ebben a játékban az unity engine aligha csinál mást, minthogy kirajzolja a tájat és a karaktereket rajta, semmi extra, ezt akár egy sima for ciklussal is össze lehetett volna rakni, és akkor talán 50 euró/stück helyett ki lehetett volna hozni 20-30 euróért, hogy valaki esetleg meg is vegye. itt az unity szerintem sokkal több kérdést felvetett, mint amennyit megoldott, mert nem hiszem, hogy annak a pár modellnek a kirajzolása, és a tök béna keyframe animációhoz egy külsős enginet kellett mindenképp igénybevenni. 4 nap alatt 13 ember bírt hozzászólást írni hozzá, csak hogy érezzük, mekkora egy valami is ez (semekkora).

SUPERHOT: ez egy rohadtul gagyi effektes-pálcikaemberes játéknak tűnik, ha agyonvernének sem játszanék vele. tipikusan olyan játék, amit értelmes ember nem vesz meg, hanem csak az olyan unatkozó félmilliomos, aki már virtuális lobotómiát csinált a fején önkéntesen. teljesen mindegy, hogy miben írja meg az alkotó ezt a hatalmas semmit, akár 30 éves qbasicben is megírhatta volna, akkor sem töltötték volna le se többen és se kevesebben, inkább adta el a marketing meg az a fajta hírnév, ami a The Brick nevű butatelefont is 2014-ben.

Shadow Tactics: Blades of the Shogun: a grafikája tetszett, gondolom erre idomították rá a polygonfaragó szakmunkásokat, tényleg szép munkát végeztek az átvezető animációkon, de semmi extra. a játék maga már megintcsak az a tipikus red alert 2 szint csak 2016 révén 35 euróba kerül, meg 13 giga szabad helyet kér... meg egy kicsit több effekt van benne. nem mondom hogy rossz, mert nem rossz, csak valahogy ugyanazt érzem, mint a Tyranny esetében, mintha ugyanazt adnák el nekem ők is, csak ők most ilyen guminő-shogunokkal. ezzel sem játszanék soha a büdös életben.

Quern - Undying Thoughts: íme a lejjebb már említett teljesen értéktelen wasd-vel röpködős ,,játék'', ami annyit tud, hogy wasd-vel röpködsz benne, és játék. az engineírást láthatóan teljesen megspórolták, az unity mint modellrenderer szerepét tölti be, összedobtak hozzá pár modellt, aztán viszont látás, tessék, itt a játék, repkedj benne wasd-vel a föld fölött, mert az olyan fantasztikus dolog, meg fizess érte 23 eurót kedves pcbleb, elvégre néhány csillogó modell, amiben wasd-ben repkedhetsz, nyilván pénzt is ér. élvezhetetlen, egy percet se játszanék ezzel sem.

szerintem végtelen hosszan folytathatnánk, úgyis tudom, hogy az összes unitys game ugyanilyen mint ezek, te is nyilván ezért adtad példának ezeket. game makerben is ezerszer különbb alkotások születtek, mint ezek, ezek szerintem nem érnek szart sem.

   
Lord_Crusare - Törzstag | 1288 hsz       Online status #210656   2016.12.14 20:18 GMT+1 óra  

   
Lord_Crusare - Törzstag | 1288 hsz       Online status #210654   2016.12.14 20:14 GMT+1 óra  
"ami mondjuk bonyolultabb annál, hogy wasd-vel repkedni lehet benne"

A teljesség igénye nélkül:

http://store.steampowered.com/app/362960/

Az Obsidian új szerepjátéka. Ha nem tudod kik ők, nos, ők korábban a StarWars: Knights of the Old Republicot készítették, valamint a Dungeon Siege és Fallout játékokat. A saját enginejüket cserélték Unity-re, mert a Unity jobb.

http://store.steampowered.com/app/322500/

Az idei év egyik nagy dobása volt, majdnem 300 000 példányban kelt el csak Steamen (ezt az adatot itt tudod ellenőrizni: https://steamspy.com/app/322500 ). Ez egy Unity-s FPS.

http://store.steampowered.com/app/418240/

A régi Commandos játékokat fejlesztő cég egy része új céget alapított. Ez egy Commandos-hoz hasonló taktikai játék, szintén Unity-s, jelenleg a toplisták élén van.

http://store.steampowered.com/app/512790/

Egy magyar Myst-szerű kalandjáték full 3D grafikával, szintén Unity alatt fut.


És ez csak pár példa a rengetegből. Mint láthatod, mindegyik bőven túlmutat a "wasd-vel repkedni lehet benne" szinten.

   
Geri - Törzstag | 2188 hsz       Online status #210652   2016.12.14 20:11 GMT+1 óra  
a pokemon nem azzal készült, meg a miku miku dance sem. más meg idén nem keltette fel az érdeklődésem. hogy józsika otthon mit kattint össze benne hogy 10 letöltést produkáljon, az meg pont hogy nem érdekel.

   
Lord_Crusare - Törzstag | 1288 hsz       Online status #210651   2016.12.14 19:58 GMT+1 óra  
Mint mindig, most is tévedsz a Unity-vel kapcsolatban. Nézz már körbe, hogy mik készülnek vele!

   
Geri - Törzstag | 2188 hsz       Online status #210650   2016.12.14 19:46 GMT+1 óra  
parallax, már eltemettünk egy managed dx-et, egy taot, meg egy xna-t annélkül, hogy bárki az univerzumban bármit is csinálni tudott volna velük. nagyon örülök neki, hogy semmire sem való csodalibrarykat ki tudsz googlizni te és mások c# alá az elmúlt 12 évből, csak valamit már fel kellett volna mutatnia velük a közösségnek, ami mondjuk bonyolultabb annál, hogy wasd-vel repkedni lehet benne. (ez mondjuk az egész unityre is vonatkozik).

ez c# alatt eddig még mindig nem sikerült senkinek, és ennek az a legvalószínűbb magyarázata, hogy aki képes valóban létrehozni valamit, az általában normális programnyelveken csinálja meg, nem ,,microsoft librarygyűjtemény for kóklers sharp'' jellegű függvénygyűjtemények fölött. ez egy technológiailag impotens nyelv.

az meg, hogy valamiben wasd-vel repkedni tudsz, az nem engine, hanem maximum egy ügyes renderer.

Idézet

Na és aztán már melyik krőzus kincse engine nincs fent a github-on?


én még olyan valamire való enginet nem láttam, ami opensource lett volna. nem nyílt forrású a wow alatti engine, nem nyílt forrású a final fantasy sorozat alatti engine, nem nyílt a pokemon. semmilyen valamire való játékengine nem nyílt forráskódú, semmilyen valamire való játék nem épül nyílt forrású enginere. egy komoly szoftver sosem nyílt forráskódú. egy nyílt forrású engine azért nyílt, mert semmit sem ér, eladhatatlan, vagy szar, vagy már annyira elavult, hogy semmire nem lehet már felhasználni, így aztán jó eséllyel kiadják a forráskódját. hisz az már nem eladható úgysem.

Idézet

Meg amúgy is dokumentáció nélkül mire mész több millió soros obfuscated JavaScript kóddal? Ami pénzt ér egy motorban az a support és a content, nem a forráskód.


hát ha egy engine több millió soros, akkor az annyira már nem szokott sokat érni, hisz túl van azon a bonyolultsági fokon, hogy átlátható, módosítható, felhasználható legyen - tehát lásd az előző pontban, semmit sem ér, így aztán ki is lehet adni nyugodtan, hisz úgysem ér semmit. nem attól lesz valamit is érő egy engine, hogy nagy, meghogy szét van dokumentálva. a cryengine sem ér semmit, ezért is ment csődbe a crytek karácsonyra. valaha persze ért, mint ahogy a quake3, meg a doom, csak ma már nem, ezért ki lehet adni. úgysem fog bennük senki SEMMIT, értsd szó szerint, SEMMIT sem csinálni.

   
Parallax - Tag | 579 hsz       Online status #210633   2016.12.12 08:03 GMT+1 óra  
Idézet
Geri :
dehogy... a c#-ból már rég kiveszett minden 3d, meg úgy az egész nyelv is eltűnt szerencsére a süllyesztőben.


Aha, akkor a Xenko-ból el is tűnt a 3D, a Unity nem is használ C#-ot semmire, mert eltűnt a süllyesztőben. A valóság inkább az, hogy az MS cross-platform irányba terelte a .NET-et és már mindenütt ott van.

Idézet
Geri :
ki a fene rakná már ki a nagy nehezen megírt forráskódját a weboldalba, nem azért dolgozik az ember, hogy lelopják


Na és aztán már melyik krőzus kincse engine nincs fent a github-on? Meg amúgy is dokumentáció nélkül mire mész több millió soros obfuscated JavaScript kóddal? Ami pénzt ér egy motorban az a support és a content, nem a forráskód.

Ezt a hozzászólást Parallax módosította (2016.12.13 11:40 GMT+1 óra, 312 nap)

   
Asylum - Törzstag | 5444 hsz       Online status #210619   2016.12.11 09:13 GMT+1 óra  
Ez a cikk egy hót baromság; az így megírt kódot krvanehéz átlátni is és használni is. "Milyen metódusai vannak az array-nek? array:: és nincs ott semmi wtf?" Egyébként meg nem hallott még precompiled header-ről?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Geri - Törzstag | 2188 hsz       Online status #210615   2016.12.09 12:13 GMT+1 óra  
Idézet
Parallax :
a motorokat már C#-al, meg JavaScript-el írják



dehogy... a c#-ból már rég kiveszett minden 3d, meg úgy az egész nyelv is eltűnt szerencsére a süllyesztőben. a javascript meg tulképp egy minimalisztikus c, változótípusok nélkül, de szinte csont ugyanaz a kód lefordul (vagy akár direktben a C-t is át lehet jsé konvertálni, van hozzá compiler). csak ugyebár ott az a baj, hogy ki a fene rakná már ki a nagy nehezen megírt forráskódját a weboldalba, nem azért dolgozik az ember, hogy lelopják.

   
Instalok - Tag | 539 hsz       Online status #210614   2016.12.09 09:27 GMT+1 óra  
@Geri
Hát, nekem azért egy kicsit túlzás, amit írsz.

Konkrétan ugye arról beszélt, hogy inkább fogja, és szétválasztja az adatot az operációtól, azaz nincs olyan osztály, ami függvényeket is definiál. Kicsit olyan, mint c#-ban az Extension különböző osztályokhoz - csak ott szebben van megoldva, mert az egész olyan lesz, mintha az adott osztály memberfüggvénye lenne.

Nekem alapvetően tetszik a blog, vannak olyan felvetései, amik engem is foglalkoztattak. Például az általad is emlegetett VFC tud problémás lenni nagy jelenetekre. Brute-force módon végigiterálni az elemeken nem túl szerencsés, ha meg mégis, akkor az lehet egy érdekes kérdés, hogy hogyan optimalizálod (többszálúsítás, SIMD, stb.)

@Parallax:
Na igen, én sem akartam fejest ugrani, és így csinálni, nekem alapvetően nem tetszik ez a megközelítés. Persze elviekben van értelme, de gyakorlatilag csak szenvedés lenne belőle. Ráadásul azzal a megkötéssel élni, hogy az ilyen osztályok memberjei publicok, de azért ne módosítsa már őket senki, mert "_"-al kezdődnek.

   
Korábbi postok
> 1 < [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] [60] [65] [70] [75] [80] [85] [90] [95] [100] [105] [110] [115] [120] [125] [130] [135] [140] [141]