Zgodnie z obietnicą, dzisiaj będzie o wykorzystaniu OpenGL w skryptach .BAT. Chciałbym jednak od razu przypomnieć, że .BAT z szybkością dużo wspólnego nie ma ;> (mimo to pod koniec co nie co o optymalizacji napiszę i tak).

(źródła + binarki są na końcu artykułu spakowane ZIPem i gotowe do ściągnięcia)

Jak wiadomo w skryptach .BAT obsługi OpenGL nie ma. Ale jak również wiadomo, obsługi OpenGL w żadnym języku nie było, do póki ktoś nie zrobił interfejsu OpenGL dla tego języka - sprawa jest więc prosta, musimy stworzyć interfejs OpenGL dla batcha.
Na początek rozważmy architekturę takiego interfejsu. Ponieważ .BAT nie ma możliwości tworzenia okna (tak btw, jak by miał taką możliwość, to właścicielem tego okna był by cmd.exe), to musimy stworzyć "coś" co stworzy nam okno. Hmm, i tu się pojawia problem - uruchamiamy "coś", "coś" stworzyło okno (w sensie - zrobiło CreateWindow + setup OpenGL, lub użyło libSDL/GLUT/cokolwiek do tego), i zrobiło exit - bo musiało zwrócić kontrolę batchowi - a garbage collector systemowy usunął okno. Uh. Ale nam przecież chodzi o to żeby okno nadal istniało, a aplikacja wyszła lub przynajmniej pozostała w tle. No dobra, w takim razie zostawimy aplikację w tle, niech trzyma otwarte okno. Nazwijmy to "coś" w takim razie uruchamianym na żądanie daemonem OpenGL.
Hmm, a teraz, jak coś "narysować" w tym "trójwymiarowym" oknie? Ano trzeba w kontekscie daemona wywołać jakieś funkcję OpenGL, typu glTranslatef, glBegin, glVertex3f, etc. Trzeba więc jakoś skomunikować się z daemonem. Jak? Tworząc kolejny program, nazwijmy go GLOpcode, który wyśle pojedyncze polecenie do daemona i zwróci kontrolę batchowi. Samo przesyłanie komend z GLOpcode do GLDaemon może odbywać się na kilka sposobów:
- sockety TCP/UDP
- named pipe'y
- komunikaty (SendMessage etc)
- wszelkie inne mechanizmy do IPC, typu DDE, dzielona pamięć, lub nawet jakiś driver
Co wybrać? Ja wybrałem sockety TCP, bo akurat pod ręką mam dość wygodny lib ;>, chociaż rozsądniejszym wyborem były by tutaj pipe'y, komunikaty, lub UDP.

OK, jak powinien działać GLDaemon? Przede wszystkim po uruchomieniu powinien stworzyć okno OpenGL, a następnie powinien oczekiwać na polecenia. W moim przypadku założyłem że GLDaemon nie wykonuje poleceń od razu po ich otrzymaniu, lecz zapisuje sobie otrzymywane polecenia na listę, i wykonuje je na żądanie. Tak więc pierwsze trzy polecenia GLDaemona będą poleceniami operującymi na liście poleceń (taka uwaga - będę podawał od lewej najpierw nazwę funkcji w interfejscie .BAT, następnie opcode przesyłany przez GLOpcode do GLDaemona, a potem krótki opis):

gl.LockRender, L - Zatrzymanie wykonywania listy, wszystkie otrzymane polecenia będą do niej dopisywane
gl.ClearRender, C - Wyczyszczenie listy poleceń OpenGL
gl.UnlockRender, U - Wznowienie wykonywania listy (lista jest wykonywana non stop - po zakończeniu listy, jest wykonywana od początku)

Reszta poleceń jest dobrze znana z OpenGL:

gl.Translatef, AglTranslatef %1 %2 %3 - Wywołanie glTranslatef (przesunięcie) z parametrami X,Y,Z
gl.PushMatrix, AglPushMatrix - Zapisanie macierzy na stosie
gl.PopMatrix, AglPopMatrix - Przywrócenie macierzy
gl.Begin, AglBegin %1 - Rozpoczęcie podawania koordynatów obiektu (parametr to typ obiektu, np. GL_TRIANGLE)
gl.End, AglEnd - Koniec podawania koordynatów
gl.Color3f, AglColor3f %1 %2 %3 - Ustawienie obowiązującego koloru
gl.Vertex3f, AglVertex3f %1 %2 %3 - Podanie koordynatu
gl.Rotatef, AglRotatef %1 %2 %3 %4 - Obrót wg podanego wektora

A teraz, stwórzmy statyczną klasę w .BAT, która zawiera interfejs. Najpierw konstruktor (który m.in. odpala w tle GLDaemona):

:gl.init
start GLDaemon
rem Dajmy 2 sekundy daemonowi na start
sleep 2
set gl.Translatef=call :gl.Translatef
set gl.PushMatrix=call :gl.PushMatrix
set gl.PopMatrix=call :gl.PopMatrix
set gl.Begin=call :gl.Begin
set gl.End=call :gl.End
set gl.Color3f=call :gl.Color3f
set gl.Vertex3f=call :gl.Vertex3f
set gl.Rotatef=call :gl.Rotatef
set gl.LockRender=call :gl.LockRender
set gl.UnlockRender=call :gl.UnlockRender
set gl.ClearRender=call :gl.ClearRender
goto :EOF

A teraz, jak wygląda implementacja którejś ze statycznym metod? Weźmy np gl.LockRender oraz gl.Rotatef (one wszystkie są ultra podobne):

:gl.LockRender
GLOpcode "L"
goto :EOF

:gl.Rotatef
GLOpcode "AglRotatef %1 %2 %3 %4"
goto :EOF

Mamy więc interfejs OpenGL dla .BAT. Jak wygląda przykładowe użycie takowego interfejsu? Spójrzmy na przykład który rysuje obracający się kolorowy trójkąt (<hermetyczny_dowcip>w stylu XBOX 360</hermetyczny_dowcip>).

@echo off
call :gl.init

set r=0
:loop
 !gl.LockRender!
 !gl.ClearRender!
 !gl.Translatef! 0 0 -10
 !gl.PushMatrix!
 !gl.Rotatef! !r! 1 0.3 0.2
 !gl.Begin! GL_TRIANGLES
 !gl.Color3f! 1 0 0!
 !gl.Vertex3f! 0 1 0
 !gl.Color3f! 0 1 0
 !gl.Vertex3f! -1 -1 0
 !gl.Color3f! 0 0 1
 !gl.Vertex3f! 1 -1 0
 !gl.End!
 !gl.PopMatrix!
 !gl.UnlockRender!
 set /a r=!r!+20
goto loop
goto :EOF


Sprawa jak widać jest dość prosta. Na początku wywołujemy konstruktor interfejsu, a potem mamy pętelkę, która czyści listę renderingu, wrzuca trochę poleceń OpenGL (podając mu koordynaty trójkąta obróconego o r), każe wykonać listę, i zwiększa r o 20 stopni.

Na zachętę screen (w jego górnej części widać okno GLDaemona):


OK, a teraz trochę C++. Zacznijmy od implementacji GLOpcode (przypominam że wszystko jest w paczce na dolę postu):


#include <cstdio>
#include <cstring>
#include <cstdlib>
#include "NetSock.h"

int
main(int argc, char **argv)
{
 if(argc == 1)
   return 1;

 NetSock a;
 a.Connect(0x7f000001, 31337);
 a.Write((unsigned char*)argv[1], strlen(argv[1]));
 a.Disconnect();
 
 return 0;
}


Noo jak widać trudne to nie jest. Sprawdza czy jest argument, a jeżeli jest to łączy się na 127.0.0.1 na port 31337 ;D, wysyła polecenie, się rozłącza (dlatego lepiej by było żeby to UDP było, ale nvm).

Implementacja daemona jest kapkę dłuższa, więc nie będę jej całej zamieszczał. Wrzucę tylko back-end funkcji które cytowałem w przypadku .BAT - gl.LockRender (L) i gl.Rotatef (AglRotatef):

Najpierw Lock:

[...]
   else if(Buffer[0] == 'L') // Lock
   {
     puts("Lock");
     UserLock = true;
   }
[...]
void
static scene()
{
 if(Connection || UserLock)
   return;
[...]


W skrócie, Lock ustawia flagę UserLock. Jeżeli ta flaga jest ustawiona, to funkcja scene (zawierająca procedury wykonujące rendering) się nie wykonuje.

A teraz glRotatef:

   else if(strcmp(Cmd, "glRotatef") == 0)
   {
     float a, b, c, d;
     sscanf(*i, "%*s %f %f %f %f", &a, &b, &c, &d);
     glRotatef(a,b,c,d);
   }


Za dużo nie ma co komentować nie? Bierze i-ty element listy, parsuje go (tak, wiem, w liście powinny być sparsowane elementy, żeby szybciej się wykonywała... ale kod miał być łatwy i w miarę krótki >), i wykonuje glRotatef z podanymi parametrami ("%*s" btw oznacza "jest tam string, ale go zignoruj", dlatego w sscanf jest 5 formatów podanych, ale tylko 4 zmienne docelowe dla nich).

Jak wygląda FPS tego cuda? Niestety, powinno się raczej pytać o SPF (Seconds Per Frame). Można natomiast trochę to pooptymalizować. Rozwiązań jest kilka.

Pierwsze rozwiązanie dotyczy przejścia z TCP na coś szybszego w przypadku lokalnego komputera. Tak jak pisałem już ze dwa razy wcześniej, dobrym pomysłem byłyby komunikaty, named pipe'y lub UDP - sprawi to że GLOpcode będzie wykonywał się szybciej.

Drugą sprawą jest zmniejszenie ilości wywołań GLOpcode. W takim przypadku robimy drobną przeróbkę GLOpcode tak aby umiało naraz wysyłać więcej niż jedno polecenie:

 int i;

 NetSock a;
 a.Connect(0x7f000001, 31337);

 for(i = 1; i < argc; i++)
 {
   a.Write((unsigned char*)argv[i], strlen(argv[i]));
   Sleep(0); // Niech sie wysle ;D
 }

 a.Disconnect();

A następnie przerabiamy interfejs tak aby tworzyło listę parametrów, i wysyłało ją w momencie wywołania gl.UnlockRender. Kilka głównych zmian wygląda tak:

:gl.init
[...]
set gl.CommandList=
goto :EOF

:gl.LockRender
set gl.CommandList=%gl.CommandList% "L"
goto :EOF

:gl.UnlockRender
set gl.CommandList=%gl.CommandList% "U"
GLOpcode %gl.CommandList%
goto :EOF

:gl.ClearRender
GLOpcode "L" "C" "U"
set gl.CommandList=
goto :EOF

:gl.Translatef
set gl.CommandList=%gl.CommandList% "AglTranslatef %1 %2 %3"
goto :EOF


To rozwiązanie całkiem ładnie przyspiesza sprawę (stworzenie procesu jest dużo wolniejsze niż operacje na zmiennych środowiskowych). Wrzuciłem je do katalogu "opt".

Kolejnym pomysłem byłoby stworzenie kilku oddzielnych list poleceń, i mówienie daemonowi które listy, i w jakiej kolejności ma wykonywać (hehe, jeżeli ktoś zna OpenGL to za pewne widzi analogię do optymalizacji przy użyciu CallList, czy choćby, idąc o krok dalej, VBO).

Za pewne jeszcze kilka pomysłów by się znalazło, ale zostawiam je do wymyślenia samodzielnie w ramach zadania domowego ;>

Paczka ze źródłami i binarkami: batgl.zip (305 KB)

OK tyle na dzisiaj. Zapraszam do wrzucania pomysłów optymalizacyjnych w komentarzach ;>