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

NeverEngine
Háromdimenziós alkalmazások készítésére alkalmas játékmotor.
Kategória: 3D Engine
A projectről:
A projektet szakdolgozatnak szántam. Egy háromdimenziós alkalmazások készítésére alkalmas játékmotor fejlesztése.

A motor D nyelven íródik (http://dlang.org/). Működését tekintve a JMonkeyEngine 3D és a Panda3D-ből merítettem ötleteket, így egy színtérgráfot manipuláló engine-t kell elképzelnünk.

Amint a szakdolgozatot elbírálták, elérhetővé fogom tenni bárki számára, amiben részletesem leírom egy ilyen motor működéséhez szükséges ismereteket, és a motor működését.

Már most is sok mindent támogat a motor, úgy mint bill- és egérkezelés, mindenféle színezett, textúrázott mesh megjelenítése, fények, shaderek, erőforrásmenedzsment, frustum culling, task-alapú alkalmazáslogika-fejlesztés, stb.

A szakdolgozat határideje miatt a kód nem sikerült olyan minőségűre, amilyennel szívesen publikálnám, így első lépésként ennek szépítése folyik (ajánlom a Tiszta kód című könyvet mindenkinek).

Második lépésben pedig az engine belső működése kerül átkódolásra. Sajnos csak most, a szakdolgozat elkészülte után, bukkantam egy fantasztikus, a témát nagyszerűen kifejtő könyvre*, ami sok hasznos információval látott el, amik miatt elengedhetetlennek tartom az engine alapjainak újratervezését és implementálását (* 3D Game Engine Architecture: Engineering Real-Time Applications with Wild Magic).

Tehát előbb-utóbb a teljes forráskódot publikálom.

A fejlesztésnek egyik célja a szakmai kíváncsiság illetve a tudás iránti vágy. Másik célja a D nyelv gyakorlása és hírének terjesztése. A szakdolgozatom első fejezete tárgyalja a nyelv erősségeit röviden.

A fejlesztés jelenleg Windows-on folyik, bár elméletben nem használtam még - a platformfüggetlen library-kon kivül - platformspecifikus szolgáltatásokat.
A project honlapja, letölthető verzió:
Fejlesztőeszköz, segédeszközök:
Visual-D, Mono-D;

Fejlesztés kezdete: Tervezett befejezés:
2012.09.20
2013.06.01
Beküldve:
2012.12.13 05:58
Fejlesztő:
NeverMind Software (1 fő)
Elérhetőség:
e-mail: sharp1113@hotmail.com
Tagok:
beküldő: Sharp
regisztrált tagok:



Fejlesztés állapota:
Fejlesztés alatt
Fejlesztés alatt
Készültség: %

Képek - NeverEngine

2012.12.13. 07:58

2012.12.13. 07:54

2012.12.13. 07:54

2012.12.13. 07:54

2012.12.13. 07:53

2012.12.13. 07:53

2012.12.13. 07:53

2012.12.13. 07:49

Fejlesztési napló - NeverEngine
Sharp 2013.01.23. 03:46
Lezárult a szakdolgozat védés, így publikálom az elkészült művet:

https://www.dropbox.com/s/btvya5i7l99rgm4/szakdolgozat.pdf

A dolgozat segítséget nyújthat azoknak akik csak most ismerkednek a 3D-vel, és szükségük van az alapvető matematikai ismeretekre. Azoknak is hasznos lehet, akik már használnak valamilyen színtérgráfon alapuló motort, de beletekintenének egy ilyen belső működésébe.
Végül a dolgozat első fejezetében található rövid leírás bemutatja a D programozási nyelvnek azon néhány előnyös tulajdonságát, ami kedvet adhat a nyelv mélyebb megismerésére.

Hozzászólások - NeverEngine
petyur - Tag | 54 hsz       Online status #190915   2013.01.30 14:17 GMT+1 óra  
Helló,

szintén átvizslattam, Asylum kolléga helyes kommentjei mellett a következőket tenném hozzá:
- túl részletesnek érzem a bevezetést [D-nyelv, lineáris algebra], ellenben kevésnek a játékmotor komponenseinek bemutatását
- rengeteg a helyesírási hiba, a stílus pedig egyedi: egy szakdolgozathoz azonban elegendő, diplomamunka esetén meggondolandó
- az Ogre3D nem játékmotor, csak grafikus motor
- Ez a mondat csak részben igaz:
Sharp
Beláthatjuk, hogy ha az apró darabokat ellátjuk ilyen, a helyes funkcionalitást igazoló szerződésekkel, akkor a darabokból összeálló egész is helyesen fog működni.

Akkor válik igazzá, ha hozzáteszed, hogy az apró darabok kooperációja is validálható.
- Ez nagyon nem így van:
Sharp
A magasszintű rétegbe tartozik például a játékbeli objektumokat irányító mesterséges
intelligencia. Ez teljesen játékspecifikus, ezért nem térek ki rá.
Az MI a rendereléstől teljesen független, nagyon leegyszerűsítve az állapot reprezentációtól és a lehetőséges akcióktól függ.

Összességében BSCs szakdolgozatnak megfelelő, az alapokat korrekten összegyűjtötted

   
Sharp - Tag | 130 hsz       Online status #190741   2013.01.24 06:48 GMT+1 óra  
Ejej. Ismételten csak köszönöm, nagyon hasznos észrevételek.

   
Asylum - Törzstag | 5444 hsz       Online status #190733   2013.01.23 19:10 GMT+1 óra  
Hujuj elolvastam a szakdogádat, gyorsan leirom mielött elfelejtem (elnézést )

- a virtuális metódusokat felüldefiniálni (override) lehet és nem túlterhelni (overload)
- lineáris trafó nem csak R3->R3 lehet, illetve 3D-ben nem csak lineáris, hanem ennél több, affin trafókat is lehet használni
- a renderelés része az MI?
- "fixált csővezeték"
- "egyszerre több millió objektumon" hát ööö nem...tudtommal egy átlagos kariban van ~7 vertex pipeline; egy 1920x1080 as monitoron meg 2 milka pixel, ezt a kari elosztja a compute unitok között (szal mondjuk 16 felé), de azokon is sok thread fut egyszerre
- nem hatékony külön tárolni a vertex attribokat

kb. ennyi, egyébként elég jól leírtad a dolgokat. (ahogy egyik tanárom mondta "szakdolgozhathoz elegendő"
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #190720   2013.01.23 15:25 GMT+1 óra  
Tudom, hogy nem a fele, nem úgy értettem... hanem csak egyetlen példának hoztam fel azt. Elolvastam, inkább a hivatalos oldalt (amit linkeltél a szakdogádban), megnéztem a main featureket, stb.

   
Sharp - Tag | 130 hsz       Online status #190717   2013.01.23 14:44 GMT+1 óra  
Fusd át a fent belinkelt szakdoga megfelelő fejezetét.

Ott felsoroltam néhány általam kifejezetten kedvelt feature-t, aminél azért sokkal több létezik. Ezen feature-k között a GC csak az egyik, véletlenül sem a fele.

A Garbage collector 1 sorral kikapcsolható. Onnantól kezdve programozhatsz kedvedre C (malloc) vagy C++ (overloadolható new és delete operátorok) módon.

   
Pretender - Törzstag | 2498 hsz       Online status #190716   2013.01.23 14:26 GMT+1 óra  
Megnéztem én is ezt a D-t egy kicsit, vannak benne jó dolgok, de nekem ez a Javas/C#-os megközelítés nem tetszik annyira. Bár tény, hogy aki eddig managed nyelvet használt, annak érdemes átgondolnia, hogy mostantól esetleg ezt használja (mert natív kódra fordul), de engem személy szerint zavarna pl. a garbage collector, stb. Bár arra meg azt írták, hogy meg lehet kerülni, de ha meg kikerülöm a feature-k felét, akkor miért használjam azt? Minden esetre nem egy rossz dolog az szerintem, és azért jobb, mint a Java és a szísárp.

   
Sharp - Tag | 130 hsz       Online status #190715   2013.01.23 14:18 GMT+1 óra  
Idézet
Asylum :
Huhh...nehany tipp ha mar olvasom a kommenteket:

- opengl 4 eleg meresz, foleg ha nem is hasznalod ki...a gepek nagy reszen nem fog mukodni
- on demand betoltes?...ennek van becsuletes neve, ugy hivjak hogy streaming, na de shadert???


Valóban hatalmas hibák voltak .

Idézet

- ez egy ujratervezett valtozat es ilyen hibakkal van tele h el sem indul? milyen lehetett az eredeti?


Mind a szakdolgozatban mind a feltöltött demóban az eredeti program szerepel. Az átdolgozott verzó most készül, ami nagyrészt kódszépítést és dokumentációt fog tartalmazni, illetve a fentiekhez hasonló nagyobb melléfogások lesznek benne újratervezve. Ennek a forráskódja szabadon elérhető lesz.

Idézet

- a tobbiek azt mondjak h a D nyelvben sok jo dolog van, de enszerintem hatalmas mellefogas... (lehet h pont olyan lib nincs hozza ami esetleg neked kene)


A cél választja az eszközt. Ha egy adott célhoz a D nem tartalmazza a szükséges elemeket, libeket, természetesen nem célszerű ezt választani.

Viszont ha nem függünk a libektől, vagy a csilli-villi IDE-től, érdemes olyan nyelvet választani, ami nem csak ez a 2 dolog miatt népszerű és sikeres, és valóban támogat az alkotásban, nem pedig korlátoz.

Csak egy olyan IDE létezik D-hez, ami támogatja a debugolást. Próbáljátok csak ki, micsoda pozitív hatással van a unit test írásra egy debug-lehetőség nélküli fejlesztőkörnyezet

Köszönöm az észrevételeket Asylum .

   
Asylum - Törzstag | 5444 hsz       Online status #190714   2013.01.23 13:37 GMT+1 óra  
Huhh...nehany tipp ha mar olvasom a kommenteket:

- opengl 4 eleg meresz, foleg ha nem is hasznalod ki...a gepek nagy reszen nem fog mukodni
- on demand betoltes?...ennek van becsuletes neve, ugy hivjak hogy streaming, na de shadert???
- ez egy ujratervezett valtozat es ilyen hibakkal van tele h el sem indul? milyen lehetett az eredeti?
- a tobbiek azt mondjak h a D nyelvben sok jo dolog van, de enszerintem hatalmas mellefogas... (lehet h pont olyan lib nincs hozza ami esetleg neked kene)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Sharp - Tag | 130 hsz       Online status #190707   2013.01.23 11:47 GMT+1 óra  
"Lezárult a szakdolgozat védés, így publikálom az elkészült művet..."
Lásd fentebb.

   
Pretender - Törzstag | 2498 hsz       Online status #189667   2012.12.21 18:26 GMT+1 óra  
A veszélyes alatt gondolom azt értette, ami most is történik. Megy a program, nagyban játszik a játékos, erre valami olyan shadert akar betölteni, amit eddig nem, és elcrashel a program.
Attól függetlenül a mesh betöltés mehet "on-demand" (nyilván azért nem teljesen, az kemény akadásokhoz vezetne), de pl. a shadereket le lehet fordítani / be lehet tölteni indításkor, a vertex buffereket szintén létre lehet hozni, stb.

Legfeljebb a textúrákra lehet értelme, de azt meg érdemes előre, még mielőtt látható lenne, és egy másik szálon, hogy ne okozzon akadást, mert az sokkal idegesítőbb, mint ha egy kicsit több memória kellene a gépbe.

   
Sharp - Tag | 130 hsz       Online status #189666   2012.12.21 15:56 GMT+1 óra  
Az első és könnyen vitatható, performanciai okok. Ez gyenge lábakon áll, és mindössze annyit takar, hogy ha egy több ezer vertexből álló modell valami furcsa oknál fogva soha nem kerül a képernyőre, akkor a vertexattribútumai, textúrája stb inicializálása ne vegyen el időt, és ne foglalja fölöslegesen a gpu memóriáját. Tudom, manapság ez annyira nem releváns indok.

A második ok pedig a párhuzamos programozás. Azt szerettem volna elérni, hogy az OpenGL szolgáltatásait szigorúan egyetlen szálról lehessen elérni, anélkül, hogy erre a felhasználókat külön kérni vagy kényszeríteni kellene. Mivel első körben nem óhajtottam foglalkozni a párhuzamosítással, ezért az engine-ben el szerettem volna kerülni mindenféle szinkronizációs megoldást, szigorúan egyszálas működést akartam megvalósítani. Ehhez pedig a legkönnyebb út az volt, ha nem ajánlok ki semmilyen API-t, ami közvetlen OpenGL erőforrások kezelésével foglalkozik, vagy esetleg belső szinkronizációs kódot igényelne.

Ezek voltak a meglátásaim. Az engine egyik célja számomra is a tanulás volt, így természetes, ha rossz döntéseket hoztam, és örömmel fogadok mindenféle helyreigazítást, köszönöm

Veszélyes alatt mit értesz pontosan?

   
Seeting - Törzstag | 2306 hsz       Online status #189640   2012.12.20 14:39 GMT+1 óra  
Ez az 'on demand' shader fordítás nagyon veszélyes megoldás szerintem. Említetted, hogy vannak előnyei. Mik ezek? Akárhogy is nézem, én nem látok gyakorlati előnyt.
   
peti634 - Tag | 148 hsz       Online status #189634   2012.12.20 10:41 GMT+1 óra  
F-secure vírusosnak érzékeli, pedig ált. nem szokott nagyon semmit.
(mármint ami nem olyan)
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
SX - Törzstag | 361 hsz       Online status #189553   2012.12.16 20:54 GMT+1 óra  
Amíg nem kerül 1-2 percnél többe a tesztelés, addig nincs gond Meg érdekelt is.
Most megy, az apró röccenés is megvan, mikor tölti be a shader-t, szóval lehet ki kéne venni ezt az on-demand betöltést.. Egyébként érdekes. Várom majd a továbbiakat, ha lesznek.

   
Sharp - Tag | 130 hsz       Online status #189546   2012.12.16 19:03 GMT+1 óra  
Idézet
collerblade :
NEVER will work ENGINE....



Ez jó Bár sajnos jogos

SX, szörnyen kitartó ember vagy, köszönöm
Felkerült egy újabb verzió.

SX
Most elindul, megmozgatom az egeret, és mikor több figura kerülne a kamera látószögébe, kilép.

Ez azért van, mert jelenleg az engine on demand allokál minden grafikai erőforrást. Tehát csak akkor fordítja le egy objektumhoz tatozó shadert, amikor az objektum először kerül renderelésre. Ennek megvannak az előnyei és hátrányai, és gondolkozom, hogy megszüntetem ezt a funkciót, mivel kisebb akadásokhoz vezethet.

   
collerblade - Tag | 84 hsz       Online status #189542   2012.12.16 17:59 GMT+1 óra  
NEVER will work ENGINE....

Egyébként nekem kilép ha nagoyn mozgatni akarom az egeret. XD

   
SX - Törzstag | 361 hsz       Online status #189536   2012.12.16 13:09 GMT+1 óra  
Most elindul, megmozgatom az egeret, és mikor több figura kerülne a kamera látószögébe, kilép.

Kód:
object.Exception@renderer\gl\glrenderer.d(609): Error during shader creation: \n
                #version 330
#define VERTEX_UV

                uniform mat4 projMatrix;
                uniform mat4 worldMatrix;
                uniform mat3 normalMatrix;
                uniform vec4 color;
                struct Light {
                        vec3 pos;
                        vec3 dir;
                        vec3 color;
                        float radius;
                        int disabled;
                };
...
                void main(void) {
                        vertex4 = vec4(vertex, 1.0);
                        worldCoords = worldMatrix * vertex4;
                        #ifdef VERTEX_COLOR
                                vec4 actualColor = color * vertexColor;
                        #else
                                vec4 actualColor = color;
                        #endif
...
                        lightIntensity = actualColor;
                        #ifdef VERTEX_UV
                        uv = vertexUv;
                        #endif
                        gl_Position = projMatrix * worldCoords;
                }
        \nError:\nVertex shader failed to compile with the following errors:
ERROR: 0:48: error(#247) Function return is not matching type
ERROR: error(#273) 1 compilation errors.  No code generated

----------------
0x0041274C
0x004125D7
0x00418ED6
0x00402CE6
0x0042E01C
0x0042DB05
0x00409145
----------------

   
Sharp - Tag | 130 hsz       Online status #189534   2012.12.16 10:37 GMT+1 óra  
Idézet
Pretender :
ha jól láttam a lightFunc függvényben egy vec3-mat szorzol egyéb dolgokkal, amit egy vec4-es visszatérési értékké akarsz automatikusan alakítani. Nem emlékszek teljesen, de ilyet mintha nem (mindig) tudna, szóval ha ez a baj esetleg, akkor
Kód:
return vec4(..., 1)

Amúgy nem tudom, hogy a későbbi glsl verziókban hogy van (meg ez talán nem is attól függ), de shaderben feltételt írni az valami hasonlót jelent azzal, hogy az if-en belüli részt végrehajtja, majd utólagosan értékeli ki. Javítsatok ki, ha tévedek, valamiért nekem ez az információ rémlik.

Amúgy hajrá!



Köszönöm, igen pontosan ez volt az egyik probléma, és úgy látszik az egyik shader javítása elmaradt. Pótlom.
Megtörtént.

Ezt a hozzászólást Sharp módosította (2012.12.16 11:05 GMT+1 óra, ---)

   
Tibsy - Tag | 307 hsz       Online status #189507   2012.12.15 11:07 GMT+1 óra  
Nálam is kilép.

CPU: Intel Pentium Dual Core 2.9 GHz
GPU: Nvidia GT 620 (1 GB )
OS: Win7 64-bit
   
Pretender - Törzstag | 2498 hsz       Online status #189506   2012.12.15 07:50 GMT+1 óra  
ha jól láttam a lightFunc függvényben egy vec3-mat szorzol egyéb dolgokkal, amit egy vec4-es visszatérési értékké akarsz automatikusan alakítani. Nem emlékszek teljesen, de ilyet mintha nem (mindig) tudna, szóval ha ez a baj esetleg, akkor
Kód:
return vec4(..., 1)

Amúgy nem tudom, hogy a későbbi glsl verziókban hogy van (meg ez talán nem is attól függ), de shaderben feltételt írni az valami hasonlót jelent azzal, hogy az if-en belüli részt végrehajtja, majd utólagosan értékeli ki. Javítsatok ki, ha tévedek, valamiért nekem ez az információ rémlik.

Amúgy hajrá!

   
SX - Törzstag | 361 hsz       Online status #189502   2012.12.14 22:48 GMT+1 óra  
Még mindig nem. Most lerövidítettem a log-ot, kivágtam belőle a kód nagy részét:

Kód:
object.Exception@renderer\gl\glrenderer.d(609): Error during shader creation: \n
                #version 400
#define VERTEX_UV
#define ANIMATED

                struct Light {
                        vec3 pos;
                        vec3 dir;
                        vec3 color;
                        float radius;
                        int disabled;
                };

...
                        color = actualColor;
                }
        \nError:\nFragment shader failed to compile with the following errors:
ERROR: 0:37: error(#174) Not enough data provided for construction constructor
ERROR: 0:43: error(#247) Function return is not matching type
ERROR: error(#273) 2 compilation errors.  No code generated

----------------
0x0041274C
0x004125D7
0x00418ED6
0x00402CE6
0x0042E933
0x0042E433
0x00462686
0x00409145
----------------

   
Sharp - Tag | 130 hsz       Online status #189501   2012.12.14 22:31 GMT+1 óra  
Fent van a javított demó.

A más konfigon való tesztelés alatt jó pár bug előkerült.

   
Sharp - Tag | 130 hsz       Online status #189500   2012.12.14 22:12 GMT+1 óra  
Köszönöm SX, időközben nekem is sikerült reprodukálnom és megkapnom ezt a hibát. Hamarosan javítás is lesz.

   
SX - Törzstag | 361 hsz       Online status #189499   2012.12.14 21:43 GMT+1 óra  
Szintén kilép.
Core i5-2500 / ATI 6850 / Win7HomeProf 64bit

Ezt löki ki:
Kód:
C:\Users\SX\Desktop\JFre>AnimationDemo.exe
object.Exception@renderer\gl\glrenderer.d(604): Error during shader creation: \n#define ANIMATED
#define VERTEX_UV

                #version 400

                struct Light {
                        vec3 pos;
                        vec3 dir;
                        vec3 color;
                        float radius;
                        int disabled;
                };
                uniform Light directionalLight;
                uniform Light light0;
                uniform Light light1;
                uniform Light light2;
                uniform Light light3;
                uniform Light light4;
                uniform int lightCount;
                uniform sampler2D texture;

                in vec3 positionF;
                in vec3 normalF;
                // Interpolated values from the vertex shaders
                in vec4 lightIntensityF;
                in vec2 uv;

                // Ouput data
                out vec4 color;
                float distanceToLight;

                const int levels = 3;
                const float scaleFactor = 1.0 / levels;

                vec4 lightFunc(Light light, vec3 lightDir) {
                        if (distanceToLight > light.radius) {
                                return vec3(0, 0, 0);
                        }
                        float cosine = max( 0.0, dot(lightDir, normalF));
                        // 1 / (1 + (2/r)*d + (1/(r*r))*d*d)
                        float r = light.radius;
                        float att = 1.0/(1.0 + ((2/r)*distanceToLight)+((1/(r*r))*distanceToLight*distanceToLight));
                        return light.color *floor(cosine*levels)*scaleFactor;
                }


                void main(void) {
                        vec4 actualColor = lightIntensityF;
                        #ifdef VERTEX_UV
                                actualColor += texture2D(texture, uv);
                        #endif
                        if (directionalLight.disabled == 0) {
                                distanceToLight = -1;
                                actualColor += lightFunc(directionalLight, directionalLight.dir);
                        }
                        if (lightCount > 0) {
                                vec3 s = normalize(light0.pos - positionF.xyz);
                                distanceToLight = length(light0.pos - positionF.xyz);
                                actualColor += lightFunc(light0, s);
                                if (lightCount > 1) {
                                        s = normalize(light1.pos - positionF.xyz);
                                        distanceToLight = length(light1.pos - positionF.xyz);
                                        actualColor += lightFunc(light1, s);
                                        if (lightCount > 2) {
                                                s = normalize(light2.pos - positionF.xyz);
                                                distanceToLight = length(light2.pos - positionF.xyz);
                                                actualColor += lightFunc(light2, s);
                                                if (lightCount > 3) {
                                                        s = normalize(light3.pos - positionF.xyz);
                                                        distanceToLight = length(light3.pos - positionF.xyz);
                                                        actualColor += lightFunc(light3, s);
                                                        if (lightCount > 4) {
                                                                s = normalize(light4.pos - positionF.xyz);
                                                                distanceToLight = length(light4.pos - positionF.xyz);
                                                                actualColor += lightFunc(light4, s);
                                                        }
                                                }
                                        }
                                }
                        }
                        color = actualColor;
                }
        \nError:\nFragment shader failed to compile with the following errors:
ERROR: 0:37: error(#247) Function return is not matching type
ERROR: 0:43: error(#247) Function return is not matching type
ERROR: error(#273) 2 compilation errors.  No code generated

----------------
0x0041274C
0x004125D7
0x00418ED6
0x00402CE6
0x0042BC37
0x0042B78F
0x004617F2
0x00409145
----------------


Na, jó hosszú lett. Mindegy, most már így marad.

   
bolyzsolt - Törzstag | 607 hsz       Online status #189495   2012.12.14 18:06 GMT+1 óra  
Nálam is kilép.

CPU: Intel Pentium Dual Core 2.0 GHz
GPU: ATI Mobility Radeon HD 3450
OS: Win7 32-bit

   
LugaidVandroiy - Törzstag | 504 hsz       Online status #189488   2012.12.14 10:31 GMT+1 óra  
Nálam működik:

CPU: Intel i7-2630QM @ 2.0Ghz
GPU: Geforce GT 520MX 1GB
OS: Win8 Pro 64-bit (nemsokára wipe lesz)

   
Lord_Crusare - Törzstag | 1288 hsz       Online status #189485   2012.12.14 09:15 GMT+1 óra  
Idézet
Sharp :
Köszönöm a visszajelzést. Utánanézek mindenképpen.

Mondanátok pár szót légyszíves a konfigurációtokról? CPU-, GPU típus és oprendszer érdekelne főleg.



CPU: Intel Core i7-2600 3.4 Ghz
GPU: GeForce GTX 560 Ti 1GB
OS: Win7 64-bit

   
LBandy - Tag | 271 hsz       Online status #189484   2012.12.14 08:00 GMT+1 óra  
Nálam sincs ez másképp, pedig érdekesnek tűnik.
Intel Core 2 Duo E7400 2.8 Ghz proci és GeForce 9600 GT kártya, Win7 32 bit.
   
Sharp - Tag | 130 hsz       Online status #189482   2012.12.14 07:46 GMT+1 óra  
Köszönöm a visszajelzést. Utánanézek mindenképpen.

Mondanátok pár szót légyszíves a konfigurációtokról? CPU-, GPU típus és oprendszer érdekelne főleg.

Ezt a hozzászólást Sharp módosította (2012.12.14 07:54 GMT+1 óra, ---)

   
Lord_Crusare - Törzstag | 1288 hsz       Online status #189481   2012.12.14 01:54 GMT+1 óra  
Nálam is.

   
fpeti - Törzstag | 1290 hsz       Online status #189480   2012.12.14 01:24 GMT+1 óra  
Nálam csak feljön a sd_app ablak, majd kilép pár mp után.
   
Sharp - Tag | 130 hsz       Online status #189469   2012.12.13 13:58 GMT+1 óra  
NeverMind Software: NeverEngine

   
> 1 <