Symulator EU07 (i nie tylko) > Poszukuję, chcę zrobić
Ekrany w lokomotywach.
ShaXbee:
@mamut: Propozycja wyglada super, pojawia sie tylko problem w postaci przywiazania obecnego kodu symulatora do Borland C++ Buildera (czesc kodu jest w Pascalu). Mimo wszystko jest to mozliwe do zrobienia - byc moze w nieco uproszczonej formie. Nalezy wygenerowac plik eksportu .lib do python33.dll i owrapowac recznie (przy pomocy C API Pythona) klase wedlug Twojego pomyslu. Na poczatek proponowalbym przetestowanie prostego callbacka ktory bedzie przyjmowal jako pierwszy argument uchwyt na teksture / adres do bufora / whatever, a nastepnie kwargs lub normalny argument z parametrami (prad, cisnienie, wlaczony / wylaczony). Powinno sie to latwo zintegrowac ze starym kodem.
Co do SPT - edytor jest w Pythonie ze wstawkami C++. Klient mial wrappery C++/Python, ale to jest dosyc upierdliwe i jesli kiedykolwiek znajde czas na ruszenie SPT to bedzie to raczej w formie klienta w C++ i uslug w Pythonie komunikujacych sie za pomoca socketow/ipc wiadomoscami zapakowanymi za pomoca protobuf.
Edit:
@Ra: da sie to zrobic w sposob relatywnie bezbolesny dla FPS - uzywamy dwoch PBO, symek uzywa PBO z poprzedniego przebiegu skryptu, skrypt w osobnym watku szykuje kolejna ramke.
mamut:
@ShaXbee: Przeprowadziłem udaną kompilacje z wykorzystaniem Borlandowego kompilatora w wersji 5.5 prostszego przykładu połączenia z Pythonem (bez OpenGL), niestety wersja 5.2 nie radzi sobie z tym (brak wchar.h a zarazem brak obsługi typu wchar_t).
Co do wydajności przetwarzania mogę przytoczyć gdzieś zasłyszany cytat (chyba dotyczy sytuacji w onet.pl)
--- Cytuj ---- jak napisać wydajny kod w Pythonie?
- napisać go w C
--- Koniec cytatu ---
tutaj leżące pod spodem biblioteki graficzne są właśnie w taki sposób implementowane (mam wrażenie, że Blender na tej samej zasadzie jest napisany)
W pierwszej kolejności chce sprawdzić jak by to wyglądało przy renderowaniu do pamięci nowej tekstury wyświetlacza co którąś ramkę, dalej osobno renderowanie tekstury do pamięci w jednej ramce, a potem wysłanie jej z pamięci do OpenGL w drugiej. Mam wrażenie, że na forum czytałem, że jak na razie nie ma wielowątkowości w MaSzynie stąd jej wprowadzanie uważam za ostateczność (trudniejszy debug, różne dziwne zachowania). [tutaj jeszcze nie wiem co oferuje Borland głównie robiłem takie rzeczy forkami na linuxie i przez OpenMP co tutaj raczej nie ma zastosowania]
ShaXbee:
@mamut: Bezpieczniej ze względu na kompatybilność z Borlandem jest przesyłać do callbacku uchwyt na zmapowaną pamięć, a wywołania OpenGL trzymać po stronie C++ - dzięki temu oszczedzisz sobie też dużej zależności w postaci PyOpenGL. Jeśli chodzi o wchar_t można to obejść używając Python'a 2.7 - tam stringi są jednobajtowe.
Nawigacja
Idź do wersji pełnej