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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2189
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
syam:    1491
> 1 <
Csizmás Kandur - Tag | 436 hsz       Online status #97265   2008.10.20 05:53 GMT+1 óra  
Q3-nál azt írták, hogy azért gyorsabb, mert a virtuális gépet cserélték le .NET-re. Ilyen alapon az Unreal3-ban is az unreal script helyett lehetne .NET, lehet gyorsítana rajta.
dynamic calc = GetCalculator();
var sum = calc.Add(10, 20);
   
Asylum - Törzstag | 5455 hsz       Online status #96887   2008.10.10 08:04 GMT+1 óra  
hmmm...mintha kevernék a harry pottert a való világgal..
most (is) a szekptikus szólt belölem, de oké legyen
quake es játékokkal nem nagyon játszok mostanában de pl. a jedi academy elöször fut többé-kevésbé normálisan (igen egy ilyen atomerömüvön...).

Ezt a hozzászólást Asylum módosította (2008.10.10 08:10 GMT+1 óra, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Orphy - Törzstag | 1893 hsz       Online status #96886   2008.10.10 07:40 GMT+1 óra  
Meg fogsz lepődni...

A C++/CLR képes úgy buildelni, hogy a natív kódból x86, a managedből MSIL-re fordít, és ezt ha minden igaz, ráadásul egy assembly-n belül is képes keverni...
Ami azt jelenti, hogy az átalakítástól a Quake nem lesz lassabb! Cserébe az automap extension-höz viszont lehetett használni a .NET teljes fegyvertárát...

Link:
http://www.winterdom.com/cppclifaq/archives/000413.html
   
Asylum - Törzstag | 5455 hsz       Online status #96885   2008.10.10 07:26 GMT+1 óra  
hihetelten hogy valakinek ennyi ideje van, hogy .net alá irja az egyébként tökjol müködö quake -et. mintha nem lenne igy is elég lassu, még rátesznek egy lapáttal...ajh
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Orphy - Törzstag | 1893 hsz       Online status #96883   2008.10.10 07:17 GMT+1 óra  
Idézet
kicsy :
Nemegészen értem, .NET környezetből amúgy is lehet natív dll-eket használni, mi a különleges ebben?


.NET környezetből lehet natív dll-t hívni, de ha megfigyelted, ezek mindig önmagukban álló statikus függvények. Ha egy saját/third party osztályt szeretnél behúzni, ami már a saját adattagjaival is dolgozik, akkor már bajban vagy. Ebben a környezetben viszont egyszerűen be tudod húzni akár azt is, sőt, ha szeretnél, akkor szintén elég egyszerűen írhatsz rá egy wrapper-t, amit C# alatt egy sima "Add reference"-el beteszel, és megy.
A másik jó dolog a C++/CLI-ben a C#-os dllimport-tal szemben, hogy itt fordítási időben kibukik, ha pl egy függvényt nem teljesen azzal a definícióval hívsz, amivel kéne - pl felcseréltél két paramétert, megváltozott időközben a natív dll, stb. A C#-os dllimport ezt nem veszi észre, és futásidőben fog szétesni az alkalmazás.


Láttam olyat is, hogy valaki C++/CLI-vel írt .NET-es managed automap kiegészítést a Quake2 engine-hez, és működött... ERRE tessék


SZERK:
Mosta találtam, a Quake 3 Arena-t is hasonló módszerrel portolták.
Quake III Arena .NET port


Idézet
Asylum :
amit viszont utálok benne, hogy a már korábban megirt normál c++ os osztályokat nem lehet keverni a managedekkel...



Hmm, itt pontosan mire gondolsz?
Egy managed osztályon belül simán használhatod mindkettőt, a wrappereket is pont így lehet megírni. A teljesen natív projektedben természetesen nem használhatsz managed osztályokat, ilyenkor vagy event-eket küldesz a natív class-okból, amiket majd a managed-ek elkapnak, vagy a kérdéses osztályokat/projektet átrakod CLR-esre, és onnantól keverhetsz...
   
kicsy - Szerkesztő | 4304 hsz       Online status #96880   2008.10.10 06:51 GMT+1 óra  
Nemegészen értem, .NET környezetből amúgy is lehet natív dll-eket használni, mi a különleges ebben?
kicsy ● SilentVertigo Team - project Solarah
http://blog.yscik.com
   
Asylum - Törzstag | 5455 hsz       Online status #96875   2008.10.10 05:52 GMT+1 óra  
amit viszont utálok benne, hogy a már korábban megirt normál c++ os osztályokat nem lehet keverni a managedekkel...
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Orphy - Törzstag | 1893 hsz       Online status #96872   2008.10.10 05:23 GMT+1 óra  
Egy kis betekintés a CLR-es WinForms-os kódba:

Kód:
#pragma once

namespace CLRWinForms {

using namespace System;
using namespace System::ComponentModel;
using namespace System::Collections;
using namespace System::Windows::Forms;
using namespace System::Data;
using namespace System::Drawing;

...

private:
/// <summary>
/// Required designer variable.
/// </summary>
System::ComponentModel::Container ^components;

#pragma region Windows Form Designer generated code
/// <summary>
/// Required method for Designer support - do not modify
/// the contents of this method with the code editor.
/// </summary>
void InitializeComponent(void)
{
this->SuspendLayout();
//
// Form1
//
this->AutoScaleDimensions = System::Drawing::SizeF(6, 13);
this->AutoScaleMode = System::Windows::Forms::AutoScaleMode::Font;
this->ClientSize = System::Drawing::Size(292, 275);
this->Name = L"Form1";
this->Text = L"Form1";
this->Load += gcnew System::EventHandler(this, &Form1::Form1_Load);
this->ResumeLayout(false);

}
#pragma endregion
private: System::Void Form1_Load(System::Object^  sender, System::EventArgs^  e) {
}
};
}


Amint látszik, annyira nem is ronda, hasonlít a C#-ra, csak meg kell szokni...

Különbségek:
- a namespace-eknél, statikus dolgoknál a Cpp-ban használt dupla kettőspont van a C#-ban használt sima pont helyet.
- A .NET-es osztályok típusa után ^-t kell tenni, és gcnew-al kell őket létrehozni ( a sima new a natív típusoknak van fenntartva)
- A public, private, protected definíciók is a Cpp-s szabvány szerint alakulnak

Ami itt elsőre nem látszik:
- Nincsen references könyvtár, a projekt properties menüpontnál kell hozzáadni a .NET-es assembly-ket (a general beállítások felett található, legfelül)
- A managed osztályok property-jeit kicsit másképpen kell definiálni:

Kód:
[BrowsableAttribute(true)]
[DescriptionAttribute("Gets the string contained in the native class...")]
property System::String^ CStr
{
System::String^ get()
{
return Get_Str();
}
void set(System::String^ value)
{
Set_Str(value);
}
}


A C# alatt megszokott IDisposeable interfészről még szólok pár szót, ezt ugyanis nem lehet annyira simán használni (A fordító beszól, hogy a Dispose() függvénynevet fenntartja magának), de kis trükkel ez áthidalható. A megoldás itt:
http://www.codeproject.com/KB/mcpp/CppDerivingDispose.aspx

Egyelőre nagyjából ennyire mentem bele a dologba, per pillanat nem kellett több - neten egy csomó minden le vagyon még írva - pl lehet event-eket küldeni natív kódból is managed kódba...

Ezt a hozzászólást Orphy módosította (2008.10.10 05:28 GMT+1 óra, ---)
   
Orphy - Törzstag | 1893 hsz       Online status #96870   2008.10.10 05:15 GMT+1 óra  
A leggyorsabb megoldás szerintem az, ha ki sem wrappeled...

Csinálsz egy C++/CLI-s (CLR-es) WinForms-os alkalmazást, azzal kb a C#-hoz hasonlóan fel lehet építeni a felületet, és direktbe be tudod linkelni a natív motorodat is. Ezzel a módszerrel maximum azokat az osztályokat kell wrappelni, amit használni akarsz a propertygriddel (az attribútumok miatt).

A wrappelés kb így néz ki:
Kód:
// clrwrapper.h
#pragma once


// import NATIVE dll...
#define DLLIMPORT __declspec(dllimport)
#pragma comment(lib,"include/test.lib")
#include "include/string.h"
using namespace Test;


//.NET namespaces
using namespace System::Runtime::InteropServices; // for class Marshal
using namespace System;
using namespace System::ComponentModel;


namespace clrwrapper {

        //a ref class azt jelenti, hogy ez egy managed class lesz
public ref class ManagedClass
{
private:
                //A natív osztályokra csak pointert tudsz csinálni
Test::cNativeClass* pNativeClass;

public:
               ManagedClass()
               {
                       //A natív osztályt a konstruktorban inicializálni kell
                       pNativeClass = new Test::NativeClass();
               }
               ~ManagedClass()
               {
                      //A natív osztályt a destruktorban fel kell szabadítani
                      SAFE_RELEASE( pNativeClass );
               }

               void SomeMethod()
               {
                     pNativeClass->CallMethod();
               }


Itt a fő nehézséget a managed és a natív típusok közötti átjárás okozhatja, ezt a problémásabb helyeken (pl string) a Marshal osztállyal lehet megoldani:

.NET string -> const char*
Kód:
const char* unmngStr = (const char*)(void*)Marshal::StringToHGlobalAnsi(str);

//ha végeztük a használatával, szabadítsuk fel
Marshal::FreeHGlobal((System::IntPtr)(void*)unmngStr);


const char* -> .NET string
Kód:
System::String^ str = gcnew System::String( unmngStr );
   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #96859   2008.10.09 21:47 GMT+1 óra  
Engem leginkább az érdekelne, hogy az engine-emet hogy a legyérdemesebb ki-wrappelni v interface-t írni fölé, hogy pl. egy tool-ban (most pl. robbanás szerkesztő) tudjam használni, a lehető leggyorsabban (mert ugyebár az idő pénz...) = legkevesebb kódolással.
   
Orphy - Törzstag | 1893 hsz       Online status #96763   2008.10.08 05:50 GMT+1 óra  
Bemelegítésnek az alábbi linken lehet találni egy csomó tutorialt (angolul).

http://www.functionx.com/cppcli/index.htm
   
Orphy - Törzstag | 1893 hsz       Online status #96762   2008.10.08 05:47 GMT+1 óra  
Kicsit hiánypótló jelleggel nyitom ezt a topic-ot, hátha valakinek hasznos lesz, vagy kedvet kap hozzá...


A C++ / CLI a Microsoft Managed C++ nyelvének az újabb változata, ami elég sokat javult az elődjéhez képest... Hatalmas előnye, hogy eléri mind a natív, mind a managed kódot is, így kiválóan használható például saját, Cpp-s játékmotorhoz tool-ok írására: a tool felületét kedvünkre alakíthatjuk a már C#/VB alatt megszokott egyszerű, és gyors eszközökkel, az engine-specifikus kéréseket pedig könnyen továbbíthatjuk a natív kód számára. A C++ / CLI segítségével könnyedén írhatunk C#/VB számára elérhető osztálykönyvtárakat amúgy csak natív kódból elérhető külsős libekhez is.
   
> 1 <