Nie ma mnie

Neverwinter Nights 2 + dodatek i dwa duże mody, nowa książka i film. Raczej nic nowego nie stworzę w ciągu najbliższych paru dni

Kółko i krzyżyk w konsoli

W ramach odpoczynku od pisania frameworka pod grę napisałem sobie dzisiaj grę z gatunku tych, które chyba każdy pisał ucząc się programować – kółko i krzyżyk. Żeby było ciekawiej, napisałem to w Lua i z przeznaczeniem na działanie w konsoli, którą wyklepałem ostatnio. 99 linii razem z komentarzami i pustymi liniami – teraz chyba wezmę się za ponga A tutaj screenshot:

Konsolka

Po napisaniu loggera zabrałem się za kompletowanie reszty frameworka do następnej produkcji – wziąłem się za konsolkę. Powstało jej kilka wersji (2 oparte na overlayach OGRE i jedna na CEGUI). Po podłączeniu jej do zaczątków systemu skryptów i napisaniu wyjścia loggera, który wypluwa tekst na konsolę fajnie to już wygląda Co można zrobić dzięki tej konsoli?

• wywołać funkcje podłączone do systemu skryptowego
• tworzyć i zmieniać zmienne
• tworzyć, używać i usuwać obiekty klas wyeksportowanych z kodu programu
• definiować i wywoływać własne funkcje
• definiować własne klasy i tworzyć ich obiekty

Nic specjalnego, jeśli weźmie się pod uwagę to, że komendy konsoli interpretowane są jako skrypty, ale używa się całkiem wygodnie

A oto screen z jednego z testów konsolki:

Ładne, prawda?

Loggery, mono, C++ i C#. I Ubuntu…

Postanowiłem wczoraj pobawić się w napisanie loggerów o podobnej funkcjonalności pod C# i C++, co pozwoliło mi porównać wygodę i szybkość pisania w obu tych językach. Do tego ostatnio zastanawiałem się nad kwestią uruchamiania programów z platformy .NET na linuksowym mono (głównie z powodu edytora do Shadow Clones – żeby był wykorzystywany, musi działać na Linuksie), co zaowocowało połączeniem tych dwóch kwestii i napisaniem programu wykorzystującego Windows.Forms, który testuje logger z C#. Ale po kolei…

Część 1: Loggery w C# i C++

Loggery do gier nie są zbyt skomplikowanym zagadnieniem, dlatego też etap projektowania zakończył się na napisaniu kilkunastu słów na kartce A4. Potem włączyłem edytor… i nie wiadomo kiedy skończyłem pisać. Dzięki sisharpowemu, niezawodnemu IntelliSense logger był gotowy dużo wcześniej, niż przewidywałem. Program testowy z wyjściami loggera na plik tekstowy, konsolę, plik HTML i TextBox także powstał szybko i wygląda tak:

Następnie przyszła kolej na logger w C++ – tutaj już bardziej przyłożyłem się do zaprojektowania wszystkiego i powstał nawet ładny diagram klas na kartce A3. Jeśli chodzi o napisanie tego, to był to dużo wolniejszy proces niż w przypadku pierwszego loggera – IntelliSence z VC++ nie może się równać z tym z VC#, zatem tym razem większość literek, cyferek i innych znaczków została jednak wciśnięta przeze mnie na klawiaturze – przynajmniej czuć w palcach, co się napisało

Mimo nieco trudniejszego procesu tworzenia, bardziej podobało mi się pisanie loggera w C++. Może to dlatego, że ten język znam dużo lepiej? Albo po prostu się przyzwyczaiłem. W każdym razie, loggery są. Teraz pora na…

Część 2: Ubuntu i mono

Uznałem za warte sprawdzenia to, czy ten arcyprosty program testowy uruchomi się bez żadnych zmian pod Linuksem. Ponieważ żadnej dystrybucji Linuksa zainstalowanej nie mam (szkoda miejsca, skoro i tak nie używam), konieczne było Linuksa zdobycie. Ściągnąłem więc Ubuntu. Pierwsza próba instalacji nie powiodła się – Virtual PC zaprotestował i nie pozwalał instalatorowi się wyświetlić. Takie życie Linuksa w końcu udało mi się zainstalować używając VirtualBox (instalowanie na właściwym komputerze uznałem za ostateczność) i niemal od razu poczułem się jak przed laty – kiedyś używałem Linuksa. Czemu tak się poczułem, mimo, że w każdym momencie mogłem się przełączyć na Vistę? Otóż, magia pakietów. Jako kilkuletni użytkownik Windows przyzwyczaiłem się do tego, że jeśli chcę mieć jakiś program, to zdobywam instalator (ściągam, kupuję) i go włączam, ewentualnie podaję parę informacji. Natomiast niebywale user-friedly Ubuntu ciągle krzyczał o niespełnionych zależnościach… Gdy w końcu udało mi się zaktualizować mono do najnowszej wersji, musiałem wyłączyć VirtualBox, czyli także Ubuntu. Jakie było moje zdziwienie, kiedy system nie mógł się podnieść po ponownym uruchomieniu wirtualnej maszyny… Każdy słyszał o stabilnym i niezawodnym linuksie, ale chyba nikt nie widział

Dobra, koniec poematu i propagandy. Ostatecznie dałem sobie spokój z własnymi próbami zmuszenia Ubuntu do współpracy i poprosiłem o test kogoś, kto Linuksa używa na codzień – jaką odczułem ulgę, gdy zobaczyłem poniższego screena, można sobie wyobrazić

Jednak działa – to dobrze. Pozostaje mieć nadzieję, że deklarowane przez jeden z .NETowych wrapperów Ogre wsparcie dla mono działa. Bo sam bardzo nie chciałbym pisać własnego wrappera…

Wykorzystanie kodu C++ w C#

Przymierzam się do stworzenia edytora poziomów do Shadow Clones. Zamierzam użyć C# i Windows.Forms – wybór taki głównie z powodu szybkości i wygody pisania, ale także z chęci zdobycia większego doświadczenia w pisaniu na tę platformę. Na razie jednak czynię pewne przygotowania (niewiele ich jest – bo i niewiele ostatnio chce mi się robić) – między innymi uczę się Ale po kolei: zamówienie na edytor wymaga ode mnie użycia części kodu gry w edytorze, by pewne rzeczy były zrealizowane identycznie (z tego, co udało mi się wymyślić, przeczytać i usłyszeć, chodzi głównie o wyszukiwanie ścieżek). Ponieważ przepisywanie kodu z C++ do C# mi się nie uśmiecha (szczególnie, jeśli byłoby tego dużo), postanowiłem poszukać sposobu na wykorzystanie kodu w C++ pod C#.

I znalazłem – zaraz go przedstawię i napiszę, co o nim myślę

Zakładam, że kod C++, który chcemy uruchomić spod C# jest w bibliotece DLL (nie jest to konieczne). W każdym razie, do zrobienia są 3 projekty:

• C++, DLL – tu będzie ten ważny kod C++
• C++/CLI, Class Library – wrapper powyższego
• C#, Console Application – program testowy

Projekt 1 – normalny DLL, żeby można było z tego normalnie korzystać. Projekt 3 to zwykły test, w którym jedyna “ciekawa” operacja to dodanie referencji do DLLki wyprodukowanej przez najważniejsze projekt 2. To w nim jest najbrzydszy kod. Czemu? Wystarczy spojrzeć na “C++/CLI” i wszystko jasne

Cała sztuka polega na tym, żeby dołączyć DLL pierwszego projektu do projektu 2 i napisać klasy .NET opakowujące i dające dostęp C#-owemu kodowi do klas C++ z projektu 1. Tutaj trzeba też dokonać ewentualnych konwersji (np. std::string <-> System::String).

Pokrótce napisałem, o co chodzi – teraz pora na komentarz. Ogólnie rzecz biorąc, to cieszę się że to wszystko jest w ogóle możliwe w dosyć prosty sposób. Natomiast samo wykonanie… właściwie aż tak strasznie złe nie jest. Co prawda ciężko się pisze w Visual C++ ze szwankującym IntelliSensem kod z typowo sisharpowymi pozagnieżdżanymi namespace’ami, konieczność używania konstrukcji typu daszki (“^”) czy “gcnew” też nie jest przyjemna, jednak wszystko to jest poukładane w miarę logicznie. Podsumowując – jest fajnie

Dopisane:

Okazało się, że niezbyt klarownie wytłumaczyłem, o co mi chodzi Dodam więc trochę kodu: to powinno być już całkiem zrozumiałe

Część 1: kod C++

// Plik Foo.hpp
#include <string>

class DLLDEF CFoo
{
public:
  CFoo();
  ~CFoo();

  std::string getString() const;

  unsigned int getNumber() const;
  void setNumber(unsigned int _value);

private:
  std::string mString;
  unsigned int mNumber;
};

// Plik Foo.cpp
#include "Foo.hpp"

CFoo::CFoo()
{ }
CFoo::~CFoo()
{ }

std::string CFoo::getString()
{
  return mString;
}

unsigned int CFoo::getNumber() const
{
  return mNumber;
}

void CFoo::setNumber(unsigned int _value)
{
  mNumber = _value;
}

Część 2: Kod C++/CLI

// Plik FooWrapper.h
#include "Foo.hpp"
#using <mscorlib.dll>

namespace Bar
{
public ref class Foo
{
public:
  Foo();
  ~Foo();

  System::String^ GetString();

  unsigned int GetNumber();
  void SetNumber(unsigned int value);

private:
  Foo* NativePtr;
};
}

// Plik FooWrapper.cpp
#include "FooWrapper.h"
namespace Bar
{
Foo::Foo()
{
  NativePtr = new CFoo();
}
Foo::~Foo()
{
  delete CFoo();
}

System::String^ Foo::GetString()
{
  std::string nts = NativePtr->getString();
  System::String^ out = gcnew System::String(nts.c_str());
  return out;
}

unsigned int Foo::GetNumber()
{
  return NativePtr->getNumber();
}

void Foo::SetNumber(unsigned int value)
{
  NativePtr->setNumber(value);
}
}

Do tego trzeba jakoś dolinkować implementację CFoo – można dołączyć LIB (jeśli jest w DLLce), albo po prostu dołączyć plik Foo.cpp do projektu.

Część 3 – Kod C#

// Plik FooTest.cs
using System;

namespace FooTest
{
    class Program
    {
        static void Main(string[] args)
        {
            Bar.Foo foo = new Bar.Foo();
            string str = foo.GetString();
            uint num = foo.GetNumber();
            foo.SetNumber(666);
        }
    }
}

Trzeba tylko dołączyć referencję do wrappera do projektu. I śmiga

Wrapper robi tutaj konwersję std::string -> System::String, równie dobrze może konwertować obiekty pojemników STL na ich .NETowe odpowiedniki, jak również wiele innych rzeczy

Coś tam robię

Ostatnio nie piszę dużo, ale coś tam powstaje. Głównie na potrzeby Shadow Clones. Co robiłem?

• tool do automatycznego robienia paczek z najnowszą wersją gry
• dołączenie do reszty gry managera konfiguracji autorstwa Wysza
• koncepcja użycia skryptów w grze

To właściwie tyle. Naprawdę niewiele ostatnio robię