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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2198
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1654
syam:    1491
Frissebbek | 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] [143]
Pretender - Törzstag | 2498 hsz       Online status #145022   2010.12.16 14:51 GMT+1 óra  
Idézet
Asylum :
Megjegyzés:

Volt szó arról, hogy hogyan lehet egy vektort deallokálásra bírni. Azt mondtam, hogy a destruktort explicit meghívni nagyon nem jó, mert nem ismerjük az implementációját. Ez továbbra is így van, viszont azt javasoltam, hogy használjuk az operator = -t:

Kód:
std::vector<int> myvec;
myvec.reserve(10);

myvec = std::vector<int>();
std::cout << myvec.capacity() << "\n";

// output: 10


Láthatóan nem azt csinálja amit kéne, ott marad a memória.
A helyes megoldás:

Kód:
std::vector<int> myvec;
myvec.reserve(10);

std::vector<int> v;
myvec.swap(v);

std::cout << myvec.capacity() << "\n";

// output: 0



Apropo: az itt nem gond, hogy a "v" vector capacity-je 10 lesz?

szerk.:
Gondolom mar mindenki latta, de azert itt van: http://stackoverflow.com/questions/3054567/right-way-to-deallocate-an-stdvector-object

Ezt a hozzászólást Pretender módosította (2010.12.16 15:15 GMT+1 óra, ---)

   
Pretender - Törzstag | 2498 hsz       Online status #145021   2010.12.16 14:40 GMT+1 óra  
Nem igazan ertem a kulonbseget az std::vector::reserve es az std::vector::resize kozott. Mind a ketto modositja az elemszamot, de mi a kulonbseg? Az elobbi allokal memoriat, az utobbi nem? Az hulyeseg lenne.
A masik:
vectornal nem lehet valahogy ezt egyszerubben kivitelezni?
Kód:
for (std::vector<ParticleEmitter*>::iterator it = m_ParticleEmittersD.begin(); it != m_ParticleEmittersD.end(); it++)
{
    if ((*it) == m_ParticleEmittersD[i])
    {
        (*it)->Unload();
        delete (*it);
        m_ParticleEmittersD.erase(it);
        break;
    }
}

   
Asylum - Törzstag | 5511 hsz       Online status #144805   2010.12.08 18:27 GMT+1 óra  
Const-al túl lehet terhelni!!!

Vagyis ha az ősosztályé const a származtatotté meg nem const, akkor az egy MÁSIK update metódus lesz!!! És ilyenkor aztán nézheted, hogy miért nincs dinamikus kötés. Fordítva ugyanigy igaz.

Tipikusan ha öröklődés van a programban akkor dinamikus kötés is, tehát ha közvetlenül kell meghivni a származtatott osztály metódusát és ott az kéne, hogy const legyen, hát...tervezési hiba
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Joga - Törzstag | 1791 hsz       Online status #144793   2010.12.08 17:24 GMT+1 óra  
Idézet
bit.0x8000 :
Idézet
Asylum :
Ennél nincs olyan "gyakran alkalmazod". Ha egy metódus nem változtatja meg az objektumot azt konvencionálisan const-nak kell deklarálni.


És ha van egy virtuális metódus (pl. update), ami az egyik leszármazottban módosítja az objektumot, a másikban meg nem? Lesz egy olyan metódusod, ami nem módosít, és mégsem const. (Ha const, akkor meg a másik leszármazottnál lesz gondja a fordítónak.)

Az öröklött metódusok azonos, vagy hasonló feladatot végeznek el, így vagy mind const vagy egyik sem, elméletben lehetséges probléma, de gyakorlatban ilyesminek nem kéne előfordulnia

Szerk.: Elvileg attól, hogy a virtuális metódus nem const, attól a leszármazott lehet, viszont ha const, akkor egyértelműen a leszármazottaknak is constnak kell lennie.
(ಠ ›ಠ) Stewie!

   
Pretender - Törzstag | 2498 hsz       Online status #144792   2010.12.08 17:22 GMT+1 óra  
En ezert nem szoktam virtual metodust constnak irni

   
bit.0x8000 - Törzstag | 574 hsz       Online status #144791   2010.12.08 17:18 GMT+1 óra  
Idézet
Asylum :
Ennél nincs olyan "gyakran alkalmazod". Ha egy metódus nem változtatja meg az objektumot azt konvencionálisan const-nak kell deklarálni.


És ha van egy virtuális metódus (pl. update), ami az egyik leszármazottban módosítja az objektumot, a másikban meg nem? Lesz egy olyan metódusod, ami nem módosít, és mégsem const. (Ha const, akkor meg a másik leszármazottnál lesz gondja a fordítónak.)
   
Orphy - Törzstag | 1893 hsz       Online status #144787   2010.12.08 16:46 GMT+1 óra  
Én most rászántam az időt, és végigirogattam mindenhol ahova kellhet, a hasonló furcsa meglepetéseket elkerülendő.
   
proof88 - Törzstag | 530 hsz       Online status #144786   2010.12.08 16:27 GMT+1 óra  
Nálam az osztályok többsége olyan, hogy e nélkül is használhatóak... - ok de egyrészt így a fordító jelez, ha észreveszi h módosítasz annak ellenére h const metódusról van szó, így kivédhető ez a fajta hiba, hogy a programozó a saját terve ellen akart volna dolgozni anélkül, hogy észrevette volna. Valamint, egy külsős ha látja hogy const metódus, akkor biztos lehet benne, hogy a metódus nem módosít semmit. Pontosabban, ahogy Asylum is említette, a mutable miatt még a const metódus is módosíthat, de azt ésszel kell csinálni.
   
Asylum - Törzstag | 5511 hsz       Online status #144783   2010.12.08 15:46 GMT+1 óra  
Idézet
bit.0x8000 :
Ha már szóba került: ti milyen gyakran alkalmazzátok ezt a fajta const módosítót? Nálam az osztályok többsége olyan, hogy e nélkül is használhatóak...



Ennél nincs olyan "gyakran alkalmazod". Ha egy metódus nem változtatja meg az objektumot azt konvencionálisan const-nak kell deklarálni.
Megjegyezném, hogy viszont egy const metódus is meg tudja változtatni a mutable kulcsszóval deklarált membereket.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Orphy - Törzstag | 1893 hsz       Online status #144779   2010.12.08 13:25 GMT+1 óra  
Aha,

Ez az, működik... Ez a szabály kissé kiment a fejemből.
Köszi!
   
bit.0x8000 - Törzstag | 574 hsz       Online status #144778   2010.12.08 13:13 GMT+1 óra  
Kód:
    const char* Getter() const
    {
        return "Something";
    }

?

szerk: vazz
Ha már szóba került: ti milyen gyakran alkalmazzátok ezt a fajta const módosítót? Nálam az osztályok többsége olyan, hogy e nélkül is használhatóak...

Ezt a hozzászólást bit.0x8000 módosította (2010.12.08 13:21 GMT+1 óra, ---)
   
Asylum - Törzstag | 5511 hsz       Online status #144777   2010.12.08 13:09 GMT+1 óra  
Azért mert a Foo-nak const refet adsz át, de a Getter metódus nem const.
Igy lesz jo:

Kód:
const char* Getter() const
{
    return "Something";
}


Viszont const char* -okat adogatni nagyon nem jó ötlet, ugyanis tudni kell, hogy az ilyenek, hogy "alma" meg "dio" a statikus és readonly memóriaterületen foglalódnak le és implicit módon a pointert kapod meg rájuk. Tehát semmiféleképpen nem érték szerinti átadás történik. Térj át std::string -re.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Orphy - Törzstag | 1893 hsz       Online status #144776   2010.12.08 12:30 GMT+1 óra  
Lenne egy kérdésem:


Kód:
class A
{
public:
    const char* Getter()
    {
        return "Something";
    }

    static void Foo(const A& a)
    {
        Bar(a.Getter());
    }

    static void Bar(const char* str)
    {

    }
};



Compier error:
passing 'const A' as 'this' argument of 'const char* A::Getter()' discards qualifiers


Mi a baj ezzel?
Ha a foo-nak átadok egy const A refet, azzal azt jelzem, hogy a Foo A-t nem fogja megváltoztatni.
A függvényben annyit csinálok, hogy hivok egy Getter-t, ez A-t tényleg nem állitja át...

Ha a Foo függvényből kiveszem a const-ot, akkor hiba nélkül fordul - de const nélkül meg nem akarom irni, mert úgy konvencio szerint nálam azt jelenti, hogy abban a ref-ben visszatérési értékre számithatok...

MinGW - GCC
   
proof88 - Törzstag | 530 hsz       Online status #144752   2010.12.07 20:28 GMT+1 óra  
GetCurrentDirectory()-val egyszerűbb, ha a program indulásakor egyből lekéred és eltárolod, hogy a FileHelper::GetExeDirectory()-dnak már nem is kell másik függvényt hívnia, csak berakod output-ba amit korábban eltároltál.
   
Pretender - Törzstag | 2498 hsz       Online status #144735   2010.12.07 18:50 GMT+1 óra  
Van-e ennek valami jobb modja?
Kód:
std::string FileHelper::GetExeDirectory()
{
    char path[MAX_PATH+1];
    int size = sizeof(path)-1;
    path[size] = 0;
        GetModuleFileName(NULL, path, size);
    std::string output = path;
    output = output.substr(0,output.rfind("\"));
    return output;

}

   
dvorgaz - Törzstag | 576 hsz       Online status #144727   2010.12.07 15:09 GMT+1 óra  
Gondolom ugyan az mint az első verzió, azaz a lefoglalt memóriát nem szabadítja fel.
   
Pretender - Törzstag | 2498 hsz       Online status #144724   2010.12.07 14:11 GMT+1 óra  
es egy sima clear utan mi lesz?

   
Asylum - Törzstag | 5511 hsz       Online status #144723   2010.12.07 14:05 GMT+1 óra  
Megjegyzés:

Volt szó arról, hogy hogyan lehet egy vektort deallokálásra bírni. Azt mondtam, hogy a destruktort explicit meghívni nagyon nem jó, mert nem ismerjük az implementációját. Ez továbbra is így van, viszont azt javasoltam, hogy használjuk az operator = -t:

Kód:
std::vector<int> myvec;
myvec.reserve(10);

myvec = std::vector<int>();
std::cout << myvec.capacity() << "\n";

// output: 10


Láthatóan nem azt csinálja amit kéne, ott marad a memória.
A helyes megoldás:

Kód:
std::vector<int> myvec;
myvec.reserve(10);

std::vector<int> v;
myvec.swap(v);

std::cout << myvec.capacity() << "\n";

// output: 0
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Joga - Törzstag | 1791 hsz       Online status #144240   2010.11.22 15:28 GMT+1 óra  
Jaja, közben rájöttem, és inkább írtam egy osztályt, ami eltárolja a hivatkozást egy mutatóval, ezzel elég hamar meg is oldódtak a problémáim
(ಠ ›ಠ) Stewie!

   
Asylum - Törzstag | 5511 hsz       Online status #144226   2010.11.22 10:02 GMT+1 óra  
Gyerekek, a referencia az csak deklarációkor/inicializáláskor kaphat értéket, utána minden hivatkozás az objektumra fog történni. Referenciákat nem lehet egymásnak értékül adni.

Megoldás: használj pointert vagy gondold át mégegyszer (nem igazán látom a kód értelmét).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Wolfee - Törzstag | 1337 hsz       Online status #144213   2010.11.21 22:10 GMT+1 óra  
pár sör után tipp:
Kód:
class Foo
{
private:
int x;
void operator=( const Foo& foo );
}

Foo a;
Foo b;
Foo& aref( void )
{
return a;
}
int main(){
...
    Foo& ref = b(aref());
...
}

?
FZoli jóváhagyásával XD

   
Joga - Törzstag | 1791 hsz       Online status #144195   2010.11.21 17:25 GMT+1 óra  
Kód:
class Foo
{
private:
int x;
void operator=( const Foo& foo );
}

Foo a;
Foo b;
Foo& aref( void )
{
return a;
}
int main(){
...
    Foo& ref = b;
    ref = aref();
...
}

Ilyen esetben a fordító meg akarja hívni a privát = oprátort, de én nem azt szeretném csinálni, hanem a hivatkozást akarom felülírni, ebben az esetben mit tegyek?
Szerk.: Most van egy olyan érzésem, hogy ilyet nem is szabadna csinálni, szal inkább írok egy handle osztályt

Ezt a hozzászólást Joga módosította (2010.11.21 17:32 GMT+1 óra, ---)
(ಠ ›ಠ) Stewie!

   
dizzygran - Tag | 5 hsz       Online status #143757   2010.11.15 14:30 GMT+1 óra  
understand

   
Asylum - Törzstag | 5511 hsz       Online status #143756   2010.11.15 14:24 GMT+1 óra  
@Pretender: erről már volt szó, hogy a fordító kiegésziti a strukturákat kettö hatvány méretre, ezért a sizeof() nem mindig nyerö.
A Color-hoz: most nem tudom hirtelen nálam hogy van, de szépen meg lehet csinálni ha irsz a strukturádnak operator D3DCOLOR és/vagy operator DWORD metódusokat (msdn: conversion operators).

@dizzygran: mert a pascal egy halott nyelv (legalábbis a szakmában; tanitásra még használják).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
dizzygran - Tag | 5 hsz       Online status #143702   2010.11.14 22:28 GMT+1 óra  
hopp bocsi, ezt az ogl topikba szántam:/
sry, bár ide is illiik picit...

   
dizzygran - Tag | 5 hsz       Online status #143701   2010.11.14 22:27 GMT+1 óra  
hy all
általános kérdésem lenne: megéri elkezdeni ogl-t pascalban?

psacalhoz vizsonylag értek, c++-t csak régen ismerkedés szinten csináltam (elagazások, ciklusok kb ennyi...) de mostanában érdekel a 3d, és találtam egy tutorialt pascal alatt, de sehol máshol nem találok hozzá semmit, mindenhol csak c++-ben, és háát érdekel h miért csak cpp alatt csinálják?? és h megéri-e 1általán pascal alatt elkezdenem?

thx all

   
syam - Törzstag | 1491 hsz       Online status #143607   2010.11.13 10:17 GMT+1 óra  
Ehh,

ezt most kaptam MSVC++tól miközben a fordító lefagyott

XXXXXXXXXXXX.cpp(121) : fatal error C1001: An internal error has occurred in the compiler.
1>(compiler file 'msc1.cpp', line 1393)
1> To work around this problem, try simplifying or changing the program near the locations listed above.
1>Please choose the Technical Support command on the Visual C++
1> Help menu, or open the Technical Support help file for more information
alias aalberik
   
Pretender - Törzstag | 2498 hsz       Online status #143606   2010.11.13 06:46 GMT+1 óra  
szerk.:
Rajottem, csak nem ertem. Van egy struct ParticleVertex-em, kirajzolashoz ebbol hasznalom a
Kód:
Vector3 m_Position;
Color m_Color;
float m_Size;

valtozoit. Ez osszesen 20 byte, ezert el is taroltam konstansban. Emellett van meg sok valtozom, ami a reszecske mozgasat/szinet/meretet hatarozza meg. Ha kirajzolaskor azt mondom, hogy.
Kód:
m_Device->DrawPrimitiveUP(D3DPT_POINTLIST, m_ActiveParticles, m_Particles, sizeof(ParticleVertex));

akkor mukodik (igy a meret 68 ), viszont
Kód:
m_Device->DrawPrimitiveUP(D3DPT_POINTLIST, m_ActiveParticles, m_Particles, ParticleVertex::SizeInBytes);

eseten csak egyetlen reszecsket rajzol ki. Legyen ket kulon struktura erre (amit rajzolok, amivel szamolok), vagy igazabol nem lassit az, hogy 20 helyett 68 byte?

Ezt a hozzászólást Pretender módosította (2010.11.13 06:59 GMT+1 óra, ---)

   
Pretender - Törzstag | 2498 hsz       Online status #143594   2010.11.12 15:03 GMT+1 óra  
Ugy nezem nekem jo lehet a
Kód:
D3DDECLTYPE_D3DCOLOR
Four-component, packed, unsigned bytes mapped to 0 to 1 range. Input is a D3DCOLOR and is expanded to RGBA order.

vagy
Kód:
D3DDECLTYPE_UBYTE4
Four-component, unsigned byte.

Bar az input nekem nem d3dcolor, hanem sajat color struktura (bar tudok belole konnyen d3dcolor-t is csinalni)

   
Asylum - Törzstag | 5511 hsz       Online status #143590   2010.11.12 14:00 GMT+1 óra  
Úgy számít a sorrend, hogy fixed function pipelineon pl. pozicio, szin, texkoord, normál (asszem). Programmable pipeleineon viszont a szemantika mondja meg, ugyh ott nem számit.

Color: D3DDECLTYPE_COLOR vagy D3DCOLOR vagy DIFFUSE nem tudom már..
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #143579   2010.11.12 12:59 GMT+1 óra  
D3DVERTEXELEMENT9 tomb meghatarozasakor a valtozok deklaralasanak sorrendje szamit? pl.:
Kód:
Vector3 m_Position;
Color m_Color;
float m_Size;

ja, es ha a Color byte R, byte G, byte B, byte A valtozokat tartalmaz, akkor D3DDECLTYPE_UBYTE4-t, vagy siman D3DDECLTYPE_FLOAT-ot hasznaljak?

   
bit.0x8000 - Törzstag | 574 hsz       Online status #143476   2010.11.10 00:33 GMT+1 óra  
Közben megoldottam a dolgot:
Kód:
StandardLib::ResourceManager<FontFile>
  Graphics::fontFiles("../resources/graphics/fonts/");

void Graphics::destroy()
{
  fontFiles.empty();
  TTF_Quit();
}


písz
   
bit.0x8000 - Törzstag | 574 hsz       Online status #143475   2010.11.09 23:49 GMT+1 óra  
Idézet
TheProGamer :
Háát, arra tudok megoldást hogy velük együtt hívódjon meg (szal valahol a felszabadulási láncban), de hogy utánuk, arra hirtelen nem tudok semmit. Mit akarsz megoldani? Hátha megoldható másképpen is.


A konkrét probléma:
Az SDL_ttf használata előtt a TTF_Init, a végén a TTF_Quit függvényt kell meghívni.
Egy font használatakor a TTF_OpenFont, utána a TTF_CloseFont függvényt.
Viszont, ha a TTF_CloseFont-ot a TTF_Quit után hívom meg, abból csúnya dolgok lesznek.

Ami eszembe jutott, hogy a TTF_CloseFont függvényt nem a destruktorba teszem, hanem egy "normál" függvénybe, amit manuálisan hívok kilépéskor - ez működne, csak nem túl elegáns...
   
TPG - Tag | 3402 hsz       Online status #143474   2010.11.09 23:32 GMT+1 óra  
Idézet
bit.0x8000 :
C++-ban megoldható, hogy bizonyos függvények csak a statikus változók felszabadítása után hívódjanak meg?


Háát, arra tudok megoldást hogy velük együtt hívódjon meg (szal valahol a felszabadulási láncban), de hogy utánuk, arra hirtelen nem tudok semmit. Mit akarsz megoldani? Hátha megoldható másképpen is.
Reality is almost always wrong. - House

   
bit.0x8000 - Törzstag | 574 hsz       Online status #143472   2010.11.09 23:29 GMT+1 óra  
C++-ban megoldható, hogy bizonyos függvények csak a statikus változók felszabadítása után hívódjanak meg?
   
warlock - Törzstag | 704 hsz       Online status #143388   2010.11.08 20:29 GMT+1 óra  
És megjelenik az emlegetett szamár.

Szóval az én véleményem az, hogy az Android platform baromi gyorsan fejlődik. Ahogy syam is írta Galaxy S teljesítménye a maga nemében lenyűgöző.
Szóval lassacskán egész értelmes kis játékokat is lehet majd androidra írni. Hozzáteszem, hogy én biztos nem venném még egyszer a fáradtságot rá.

   
tescodr - Tag | 103 hsz       Online status #143377   2010.11.08 18:08 GMT+1 óra  
syam igen igazad van de ne gondolj nagy efektes valamire grafikát szeretném belőni kb ps1 színvonalra ami már bőven futtatható kategória
   
syam - Törzstag | 1491 hsz       Online status #143372   2010.11.08 17:21 GMT+1 óra  
Mi (vagyis én is) többféle platformmal foglalkozunk és az Android most már kinőtte az ilyen kínjait. Jelenleg a Galaxy kb. egy szinten van 3GS-vel (az ájfon négy pedig magasan a csúcson van) és ezeken relatív sok a memória.
Bár hiába van OpenGL ES 2.0 támogatás egy komolyabb effekt még megfekteti a hardvert.
alias aalberik
   
Orphy - Törzstag | 1893 hsz       Online status #143370   2010.11.08 17:08 GMT+1 óra  
tescodr:


Az Androiddal csak óvatosan!
A protálról Warlock már próbálkozott ezzel, és nem voltak tól jó tapasztalatai.
Idézem:

"Felkerült a marketre a játék.
24 óra alatt 240 ember töltötte le. Sajnos a játék értékelése nem a legjobban alakult. Mint kiderült a legtöbb android telefonban nincs 3ds gyorsítás. Így mivel én openglt használtam a renderhez, meglehetősen lassan futhatott a készülékeken.
Közel 140 highscore bejegyzés került a szerveremre. "
   
tescodr - Tag | 103 hsz       Online status #143366   2010.11.08 16:28 GMT+1 óra  
köszönöm válaszotok igazat megvallva 3d-s játékban gondolkodtam elérhető platformok között pedig a legnépszerűbbek jönnének számításba eddig ezeken a telefonokon tudnám tesztelni:samsung galaxy 3,galaxy s,samsung omnia,htc hero,iphone 3g/4g
valaki írta a különféle verziókat és különböző hardvereket,erre válaszolva elsődlegesen android 2.1 és 2.2 froyo lenne a célközönség hardverileg pedig a snapdragon processzorral szerelt telók hiszen ezekben már elérhető az opengl 2.0 támogatás

saját telefonom:samsung galaxy 3 on tesztelgettem kicsit és most felvetődött bennem egy quake 2 /quake 3 engine használata,ötlet onnan merült fel hogy a telefonom támogatja az opengl grafikus motorokat konkrét tesztem ezzel kapcsolatban:

quake 2 full grafon az én telefonomon 22fps-t produkált kb a quake 3 is,természetesen ettől még szükségem lenne egy programozóra akivel a relatíve kevés memória miatt tovább tudnánk a kódot optimalizálni esetleg átfarikcsálni 1-2 dolgot és nem elhanyagolható tény hogy ezek az enginek ingyenesek.

de javítsatok ki ha tévednék
   
Orphy - Törzstag | 1893 hsz       Online status #143363   2010.11.08 16:01 GMT+1 óra  
Idézet
mark576 :
Kicsit le vagy maradva. Az NFSU-t már rég kiadta az EA mobilra XNA-ban, meg kb minden A kategóriás játékot. Rohadtul nem a teljesítmény, hanem a platformfüggetlenség a C++ lényege.



Hát nem tudom...
A mobil eszközök gyorsan fejlődnek, de egyelőre még igencsak elmaradnak a desktopból mind CPU, mind RAM, mind videokártya tekintetében. Egy ilyen platformon szerintem nem kéne a bármennyire interpretált, jit-telő, vm-es stb nyelveket erőltetni, mert tovább lassit, ráadásul erőforrást zabál... Mobil eszközökre igenis tessék nativan kódolni!

Én pl konkrétan nem lennék boldog egy telefonos NFSU-tól, ha pikk-pakk lemeritené, vagy megfőzné a telómat...
   
Asylum - Törzstag | 5511 hsz       Online status #143362   2010.11.08 15:57 GMT+1 óra  
msdn? Én csak a tapasztalatomat mondom. Sőt dev-c++ -ban sem emlékszem, hogy kellett volna __dllexport-ot irnom (rég volt már az).

XNA mobile: >.< lassan már az lesz, hogy nemiskell programozni wazze, void makeCrysis6() és kész...
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
mark576 - Tag | 256 hsz       Online status #143359   2010.11.08 12:49 GMT+1 óra  
Idézet
Asylum :
Más: mobilcuccokhoz saját enginet fejlesztenek, mert ott kvára ügyelni kell az erőforrások használatára. Már várom mikor jön ki az "XNA mobile edition"... -.-


Kicsit le vagy maradva. Az NFSU-t már rég kiadta az EA mobilra XNA-ban, meg kb minden A kategóriás játékot. Rohadtul nem a teljesítmény, hanem a platformfüggetlenség a C++ lényege. Mobilon cumi van, mert ahány féle mindegyiken más a prognyelv.

A DLL-re visszatérve: Ha a VS automatikusan megoldja, akkor mégis, hogy szabályozod, hogy mi legyen public, meg mi "internal"?
   
Asylum - Törzstag | 5511 hsz       Online status #143351   2010.11.07 22:59 GMT+1 óra  
Idézet
Pretender :
libbel miert nem erdemes publikalni? Ha jol tudom csak annyi, hogy nagyobb az exe, mert beleforditja.



Mikor mondtam, hogy nem érdemes?

Más: mobilcuccokhoz saját enginet fejlesztenek, mert ott kvára ügyelni kell az erőforrások használatára. Már várom mikor jön ki az "XNA mobile edition"... -.-
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
mark576 - Tag | 256 hsz       Online status #143349   2010.11.07 22:35 GMT+1 óra  
Idézet
tescodr :
Én sajna nem igazán találtam hozzá,ahogy észrevettem a mobil fejlesztők nem szívesen nyilatkoznak milyen grafikus motor hajtja meg a terméküket.


Ilyen kis ugri-bugri 5 perces cuccokhoz nem kell különleges engine. Pár hét alatt meg lehet írni. Amúgy az Android pont a legrizikósabb, mert össze-vissza van mindenféle OS verzió, meg gyártónként különböző felület stb. :Lesz sok olyan felhasználó, akinél kiakad a program hiába teszteled 6 féle telefonon is. A másik a terjesztés, fizikailag nincs védve a telefon, bárki bármit rátehet, de ez már off. Ebbe az egészbe PC-n a legkönyebb beletanulni, mobilon csak szenvedni fogsz.
   
Pretender - Törzstag | 2498 hsz       Online status #143345   2010.11.07 19:45 GMT+1 óra  
libbel miert nem erdemes publikalni? Ha jol tudom csak annyi, hogy nagyobb az exe, mert beleforditja.

   
Asylum - Törzstag | 5511 hsz       Online status #143344   2010.11.07 19:40 GMT+1 óra  
VS-ben be lehet állitani, hogy dll-be forditsa és akkor sehova nem kell kitenni a __dllexport-ot (mert alapbol ugy forditja valszeg).
Viszont ezzel sok probléma van...ha változtastz valamit a dll-t ujra kell forditani, ha elfeljted akkor olyan hibákat kapsz amiket aztán az életbe nem találsz meg.
Dll-be akkor forditsd amikor már publikálni akarod a cuccot.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
tescodr - Tag | 103 hsz       Online status #143343   2010.11.07 19:31 GMT+1 óra  
üdv lenne pár kérdésem mint laikus,előre szólok nem vagyok programozó tehát előre is elnézést kérek ha hülyeségeket kérdezek,

Szóval:

első kérdésem az lenne hogy mi az az api?
Grafikus vagyok mobilfejlesztésbe szeretnék belevágni ezen belül is android platform
namost olvastam hogy ezek az okos telefonok opengl-t támogatják.
Opengl api csak vezérlés a hardverhez?Vagy pontosan mi a szerepe?
Másik kérdés ismertek opengl alapú mobil grafikus motorokat?
Én sajna nem igazán találtam hozzá,ahogy észrevettem a mobil fejlesztők nem szívesen nyilatkoznak milyen grafikus motor hajtja meg a terméküket.

Előre is köszönöm a válaszotok,még ha nagyon hülyeségeket is kérdeztem gondoltam a lehető legjobb helyen kérdezek.
   
Pretender - Törzstag | 2498 hsz       Online status #143338   2010.11.07 12:43 GMT+1 óra  
az osztalyok/strukturak elott ottvolt a dllexport, nem tudtam, hogy const ele is kell, de mar mindegy, jo nekem igy libbel is

   
mark576 - Tag | 256 hsz       Online status #143336   2010.11.07 12:01 GMT+1 óra  
A DLL-hez kell egy export-import rész, amit behívsz.
Kód:
#ifdef ENGINE_EXPORTS
#define ENGINE_LIBRARY __declspec(dllexport)
#else
#define ENGINE_LIBRARY __declspec(dllimport)
#endif


És a const-ot is az osztályba kell tenni és elé a defines cucc, meg mindent, amit a DLL-en kívül is használni kell. Ha nincs a define-s dolog, az olyan, mint C#-ban az internal.
Math.h
Kód:
class ENGINE_LIBRARY Math
{
    public:
        static const float PI;
};


Math.cpp
Kód:
const float Math::PI = 4.0f * atanf(1.0f);

Ez VC++ alatt megy, másik fordítónál libet használok én is. Ja és pesze a DLL projectben meg kell adni ezt a preprocesszort.
   
Frissebbek | 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] [143]