- Symulator MaSzyna -
Symulator EU07 (i nie tylko) => Na warsztacie => Wątek zaczęty przez: HTD w 19 Grudnia 2014, 00:10:02
-
Witam wszystkich serdecznie.
Podjąłem decyzję o udostępnieniu niedokończonego narzędzia do edycji plików scenerii, bo być może zbiorę jakiś feedback, uwagi, być może ktoś nawet pomoże w tworzeniu tego narzędzia.
Na chwilę obecną mówimy o wersji 0.7.0 - czyli jak z numerka wersji wynika - jest to alpha, wersja testowa, nie ma jeszcze wszystkich funkcji, które chcę w nim zaimplementować.
Po pierwsze: po co kolejny edytor i co on właściwie potrafi?
ScnEdit jest w odróżnieniu od większości istniejących i rozwijanych edytorów scenerii edytorem czysto tekstowym, który znacząco wspomaga bezpośrednią pracę nad plikami scenerii, zwłaszcza plikami ctr zawierającymi zdarzenia. Ponadto bezpośrednia edycja plików źródłowych daje największą kontrolę nad ich strukturą i działaniem.
Ponieważ pliki scenerii mają swoją oryginalną składnię, potrzebny był edytor, który potrafi tę składnię rozpoznać i oznaczyć odpowiednimi stylami i kolorami. Definicje obiektów i zdarzeń są bez wyróżniania różnymi kolorami praktycznie zupełnie nieczytelne, stanową ściany tekstu gdzie jakiegokolwiek błędu można bardzo długo szukać, nie mówiąc już o tym, że łatwo ten błąd popełnić.
Mój edytor prezentuje tekst w kolorze, ponadto kolory można wybrać z kilku gotowych schematów, w zależności czy ktoś preferuje jasne tło, ciemne, czy może łagodne dla oczu, a jednocześnie czytelne. W przyszłych wersjach pojawi się także opcja tworzenia własnych schematów kolorów.
Kolejną ważną cechą edytora jest drzewo projektu, które zawiera wszystkie pliki dołączane przez główny plik scenerii. Koniec z szukaniem plików. Otwieramy główny plik w scenerii, wszystkie odwołania do innych plików zostaną umieszczone w drzewie projektu po prawej stronie i stamtąd można je natychmiast otworzyć. Pliki otwierane są w zakładkach, które można dowolnie przenosić, przyklejać do krawędzi okna czy nawet przenieść na inny monitor.
Bardzo przydatną funkcją jest globalne wyszukiwanie symboli (F12). Po zaznaczeniu symbolu w pliku i wciśnięciu F12 w oknie na dole wyświetli się lista wszystkich odwołań do tego symbolu. Kolejna wersja będzie umożliwiać także globalną zmianę nazwy tego symbolu.
Ostatnią ukończoną przeze mnie funkcją jest sortowanie i nazywanie torów nienazwanych. Po wybraniu tej opcji na pliku, w którym znajdują się definicje torów zostaną one posortowane w sposób taki, że odcinki połączone ze sobą będą występować w pliku kolejno po sobie, a ich nazwy będą także odzwierciedlać tę kolejność, jeśli wcześniej odcinki tych nazw nie posiadały. Kolejne przypisywane do ciągłych odcinków nazwy mają też zawartą w sobie odległość w metrach od pierwszego odcinka serii. Jeśli po nazwanym 100 metrowym odcinku "peron_1" będą występować kolejne 3 o długości 100m, zostaną nazwane "peron_1_100", "peron_1_200" i "peron_1_300". Dzięki temu w pliku z definicjami torów będzie bezpośrednio widać układ torów i przypisywanie do nich zdarzeń będzie dużo łatwiejsze.
Zupełnie przy okazji operacji sortowania i nazywania torów, każdemu torowi zostanie także przypisana jego długość, która jest parametrem opcjonalnym i czasami ma po prostu wartość zero. Mimo, że ten parametr nie jest istotny dla symulatora, może być pomocny przy przypisywaniu zdarzeń i orientacji w układzie torów.
Jeśli w pliku z torami znajdują się także definicje innych obiektów, posortowane definicje torów zostaną umieszczone na początku tego pliku, wszystko poza definicjami torów zostanie umieszczone na końcu pliku, po komentarzu "Original content". Operacja sortowania i nazywania torów jest całkowicie bezpieczna i była przetestowana na kilku scenariuszach.
Wszystkie w edytorze (w tym sortowanie i nazywanie torów) można cofać via Ctrl+Z. Działa to nawet po zapisaniu pliku, dzięki czemu można przetestować zmianę i jeśli nie zadziałała właściwie, cofnąć ją i jeszcze raz zapisać plik.
Edytor jest praktycznie codziennie intensywnie rozwijany. Wersja 1.0 ma umożliwiać zastępowanie globalne symboli, pokazywać podpowiedzi do wszystkich elementów składni, obsługiwać zakładki i makra, a także umożliwiać wyszukiwanie obiektów po współrzędnych X, Z (np spisanych z symulatora). Podobne sortowanie i nazywanie jak w przypadku torów będzie także działać dla trakcji.
Dojdzie jeszcze (przy współpracy @youBy) bardzo rozbudowany moduł wspomagania tworzenia rzeczywistych rozkładów jazdy, w oparciu o trasę i parametry składu. Być może uda się nawet jakoś zautomatyzować tworzenie rozkładów dynamicznych.
Zapraszam do testów, zgłaszania uwag i pomysłów. W sumie nazwa jest do zmiany :) Pomysły na nową nazwę mile widziane, podobnie jeśli chodzi o ikonkę.
Program powinien działać pod systemami Windows Vista i nowszymi, jest rozwijany i testowany głównie pod Windows 8.1. Wszystkie znane bugi z poprzedniej wersji zostały poprawione. Do optymalnego działania zalecane są komputery z procesorami wielordzeniowymi (i5 i lepsze), gdyż edytor dość intensywnie wykorzystuje wielowątkowość. Dostępne są 2 wersje językowe, polska i angielska, wybierane automatycznie zgodnie z językiem ustawionym w Windows.
Instalka:
http://nisza.org/dl/ScnEdit-0.7.0.msi (http://nisza.org/dl/ScnEdit-0.7.0.msi)
Źródła:
https://github.com/HTD/ScnEdit (https://github.com/HTD/ScnEdit)
Wersja portable (x86)
http://nisza.org/dl/ScnEdit-0.7.0.7z (http://nisza.org/dl/ScnEdit-0.7.0.7z)
.NET Framework 4.5.1 (wymagane)
http://www.microsoft.com/pl-PL/download/details.aspx?id=40779 (http://www.microsoft.com/pl-PL/download/details.aspx?id=40779)
Razem z wydaniem wersji 1.0 pojawi się także oficjalna strona projektu z tutorialami video, jak wykonać w edytorze różne skomplikowane zadania.
-
"Pakiet nieobsługiwany przez procesor tego typu". Czyli istotnie tylko vista+. Kompilacji się nie podejmę. Jeśli jest jakakolwiek szansa uruchomienia na xp, to poproszę wypakowane+ewentualne wpisy rejestru, jeśli są konieczne do pracy. Jak nie, to trafia obok makr Mariusza wymagających excela.
-
@HTD: czy jest/będzie możliwość pobrania twojego narzędzia w wersji "portable" czyli bez konieczności jego instalacji? Z góry dziękuję za odpowiedź.
-
C# ? Istnieje opcja zapisu zgodnego wstecznie z VS2010? Pooglądałbym sobie ten projekt, ale nie odpala sie w moim VisualStudio... (a 2012 nie chcę instalować, bo do pracy potrzebuję mieć 2010 - a dwa grzyby w barszcz to o jeden za dużo :) )
-
Jak to się ma do tego, że jednak ponad połowa PC nadal pracuje na systemie XP. Popieram także prośbę o wersje portable. Twoja wizja nie koniecznie trafia w nasze oczekiwania, możliwości techniczne. @HTD nie zauważył, że większość tutaj to młodzi, których nie stać na I5. Jest (będzie) to kolejne narzędzie z którego lamer nie skorzysta. Nie odnoszę się merytorycznie do edytora, nie mam Visty (najgorszy system), a Win 7 używam sporadycznie.
-
Po zainstalowaniu na win 7:
Szczegółowe informacje na temat wywoływania debugowania w trybie JIT (just in time)
zamiast tego okna dialogowego znajdują się na końcu tego komunikatu.
************** Tekst wyjątku **************
System.InvalidOperationException: Nie można zarejestrować elementu DragDrop. ---> System.Threading.ThreadStateException: Bieżący wątek musi być ustawiony na tryb jednowątkowego apartamentu, aby można było wykonywać wywołania OLE. Upewnij się, że w funkcji Main jest zaznaczony element STAThreadAttribute.
w System.Windows.Forms.Control.SetAcceptDrops(Boolean accept)
--- Koniec śladu stosu wyjątków wewnętrznych ---
w System.Windows.Forms.Control.SetAcceptDrops(Boolean accept)
w System.Windows.Forms.Control.OnHandleCreated(EventArgs e)
w FastColoredTextBoxNS.FastColoredTextBox.OnHandleCreated(EventArgs e)
w System.Windows.Forms.Control.WmCreate(Message& m)
w System.Windows.Forms.Control.WndProc(Message& m)
w System.Windows.Forms.ScrollableControl.WndProc(Message& m)
w System.Windows.Forms.UserControl.WndProc(Message& m)
w FastColoredTextBoxNS.FastColoredTextBox.WndProc(Message& m)
w System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
w System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
w System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
************** Zestawy załadowane **************
mscorlib
Wersja zestawu: 4.0.0.0
Wersja Win32: 4.0.30319.18444 built by: FX451RTMGDR
CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll
----------------------------------------
ScnEdit
Wersja zestawu: 0.6.3.0
Wersja Win32: 0.6.3.0
CodeBase: file:///C:/Program%20Files/ScnEdit/ScnEdit.exe
----------------------------------------
System.Windows.Forms
Wersja zestawu: 4.0.0.0
Wersja Win32: 4.0.30319.18408 built by: FX451RTMGREL
CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System.Drawing
Wersja zestawu: 4.0.0.0
Wersja Win32: 4.0.30319.18408 built by: FX451RTMGREL
CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System
Wersja zestawu: 4.0.0.0
Wersja Win32: 4.0.30319.34238 built by: FX452RTMGDR
CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
WeifenLuo.WinFormsUI.Docking
Wersja zestawu: 3.0.0.0
Wersja Win32: 3.0.0.0
CodeBase: file:///C:/Program%20Files/ScnEdit/WeifenLuo.WinFormsUI.Docking.DLL
----------------------------------------
ScnEdit.resources
Wersja zestawu: 0.6.3.0
Wersja Win32: 0.6.3.0
CodeBase: file:///C:/Program%20Files/ScnEdit/pl-PL/ScnEdit.resources.DLL
----------------------------------------
System.Windows.Forms.resources
Wersja zestawu: 4.0.0.0
Wersja Win32: 4.0.30319.18408 built by: FX451RTMGREL
CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms.resources/v4.0_4.0.0.0_pl_b77a5c561934e089/System.Windows.Forms.resources.dll
----------------------------------------
FastColoredTextBox
Wersja zestawu: 2.16.2.0
Wersja Win32: 2.16.2.0
CodeBase: file:///C:/Program%20Files/ScnEdit/FastColoredTextBox.DLL
----------------------------------------
System.Configuration
Wersja zestawu: 4.0.0.0
Wersja Win32: 4.0.30319.18408 built by: FX451RTMGREL
CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Xml
Wersja zestawu: 4.0.0.0
Wersja Win32: 4.0.30319.34234 built by: FX452RTMGDR
CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
System.Core
Wersja zestawu: 4.0.0.0
Wersja Win32: 4.0.30319.18408 built by: FX451RTMGREL
CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll
----------------------------------------
System.Data
Wersja zestawu: 4.0.0.0
Wersja Win32: 4.0.30319.18408 built by: FX451RTMGREL
CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_32/System.Data/v4.0_4.0.0.0__b77a5c561934e089/System.Data.dll
----------------------------------------
ScnSyntax
Wersja zestawu: 0.0.0.0
Wersja Win32:
CodeBase: file:///C:/Program%20Files/ScnEdit/ScnSyntax.DLL
----------------------------------------
mscorlib.resources
Wersja zestawu: 4.0.0.0
Wersja Win32: 4.0.30319.18408 built by: FX451RTMGREL
CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/mscorlib.resources/v4.0_4.0.0.0_pl_b77a5c561934e089/mscorlib.resources.dll
----------------------------------------
************** Debugowanie w trybie JIT **************
Aby włączyć debugowanie w trybie just in time (JIT), plik .config tej
aplikacji lub komputera (machine.config) musi mieć
wartość jitDebugging ustawioną w sekcji system.windows.forms.
Aplikacja musi być również skompilowana z włączonym
debugowaniem.
Na przykład:
<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>
Gdy debugowanie JIT jest włączone, wszystkie nieobsługiwane wyjątki
są wysyłane do debugera JIT zarejestrowanego na komputerze
i nie są obsługiwane w tym oknie dialogowym.
Dodano: 19 Grudnia 2014, 11:01:53
Stało się to po pierwszym uruchomieniu, po kliknięciu plik -> otwórz -> i wybraniu "quarkmce2007.scn". Teraz już działa.
Dodano: 19 Grudnia 2014, 11:05:49
1. Brakuje opcji przy include plik "otwórz ten plik".
2. Po naciśnięciu F12 na ścieżce do pliku robi się jak w załączniku
Używaj znacznika code, a nie quote.
Benek
-
Ok, ok, spróbuję zrobić wersję z mniejszymi wymaganiami jak się da. Może wystarczy skompilować pod x86 i może starszą wersję .NET. Dzisiaj nic z tego bo mam remont od rana, jutro pewnie się uda.
Co do skompilowania pod x64 - po prostu wydajność. Duże pliki, przetwarzanie w czasie rzeczywistym. Co do .NET 4 a nie 2 - lepszy kod.
Co do XP, w pewnym momencie skończyły się programy dla DOS-a. Skończył się x86 i tryb rzeczywisty. Komórki mają 64-bitowe proce i są szybsze od kompów, które nie dały rady pociągnąć 7. XP to taka trochę graficzna nakładka na DOS-a.
OK, target da się zmienić na x86 + NET 4.0. Taka wersja powinna pójść wszędzie. Odpali też z ZIP-a bez instalacji, pod warunkiem posiadania .NET framework, to trzeba sobie ściągnąć i zainstalować ze strony Microsoftu.
Po instalacji masz w katalogu C:\Program Files\ScnEdit kilka plików o łącznej wielkości 1.5MB. Żadnych zbędnych wpisów w rejestrze, poza powiązaniem rozszerzenia SCN z programem. Oczywiście da się odinstalować do zera przez "usuń programy". Przy okazji, jak nie masz .NET, instalka go sama pobiera i instaluje.
Reg. zakazy 10, obowiązki 16.
Proszę nie rozpoczynać każdego zdania od nowej linii, proszę zamienić angielskie słowa na polskie.
Benek
-
To może być kwestia tego, że ktoś korzysta z komputera służbowego itp. i nie może nic zainstalować na nim.
-
Na win8 nie działa.
-
Gdyż? Może OS x86, jutro puszczę kompilację x86, musi działać. Prawdę mówiąc nie testowałem, czy installer pobiera .NET Framework (jest wbudowany w Win 8.1). Tak na wszelki wypadek:
https://www.microsoft.com/en-us/download/details.aspx?id=40779 (https://www.microsoft.com/en-us/download/details.aspx?id=40779)
OK, może spróbuję wersję portable i x86 wrzucić jeszcze dziś pod wieczór jak zdążę.
Dodano: 19 Grudnia 2014, 22:32:01
OK, wrzuciłem wersję portable (x86). Co do zgłoszonych rzeczy - ścieżki nie dają się jeszcze klikać, chociaż wyglądają jak linki. Będzie działać w następnej wersji.
Co do wsparcia dla XP - obawiam się, że to grubszy problem, musiałbym cofnąć projekt w rozwoju do .NET 4.0, a jeden z jego komponentów używa funkcjonalności .NET 4.5. Trzeba by pokombinować jak to przerobić - owszem, do zrobienia, ale na chwilę obecną (przed wersją 1.0) nie jest priorytetem. Miałbym także problem z testowaniem tego pod XP, po prostu nie posiadam. Jeśli ktoś byłby zainteresowany rozwojem forka dla XP - zapraszam do współpracy.
Wersja portable powinna zadziałać po wypakowaniu do jakiegoś katalogu, konieczne jest jednak zainstalowanie .NET Framework 4.5.1. Zależność nie jest specjalnie rzadka w dzisiejszym oprogramowaniu, jasne, że dałoby się to wszystko napisać w C++ i bez zależności, tyle, że zajęłoby mi to powiedzmy kilka miesięcy dłużej. A pisanie pod przestarzałe frameworki to trochę cofanie się w rozwoju.
-
HTD, który komponent?
Zamiast ustawiać x86 możesz ustawić "Any CPU" (i odhaczyć "prefer 32-bit") i wtedy .NET będzie sobie kompilował kod (JIT) pod architekturę, na której jest uruchamiana aplikacja (przynajmniej w teorii). .NET 4.5.2 przynosi poprawę wydajności, więc możesz podnieść wersję.
PS. Wiem, że użyłem tu słownictwa, które dla większość brzmi jak zaklęcia, ale post jest czysto techniczny.
-
Wersja portable jest pod x86. Nie pójdzie jednak na systemie, na którym nie da się zainstalować .NET Framework 4.5.1 (czytaj XP i starsze).
Co do komponentów - tu chodzi o zależność od wersji .NET 4.5. Gdybym chciał zbić wersję do 4.0 musiałbym zmienić sposób zbierania konfiguracji od schematów kolorów, bo używają klasy TypeInfo, której nie ma w .NET 4.0. Domyślam się, że sporo kombinowania będzie potrzeba, żeby zrobić prostą rzecz, więc zostawiam to na razie do ukończenia wersji 1.0. Oprócz tego nie mam pewności, czy wyświetlanie karetki kursora w edytorze będzie działać prawidłowo - jest rysowana z użyciem komponowania warstw, czyli funkcji wprowadzonej w Vista. Co prawda ma zastępczy tryb pracy, ale nie testowałem tego.
Nie będę Was zanudzać technicznymi detalami, czemu .NET minimum 4.0 jest niezbędny do uruchomienia, a w zasadzie nawet 4.5.1 na chwilę obecną. Najkrócej - to biblioteka programistyczna, która oszczędza ogromną ilość czasu programistom. Można dzięki temu tworzyć krótszy, dużo czytelniejszy i odporny na błędy kod, a standardowe operacje i algorytmy są dobrze zoptymalizowane. Biblioteka jest wbudowana w Windows 8.1 i nawet część komponentów samego systemu zależy od niej. Można go zainstalować na systemach Windows Vista i nowszych. Biblioteka jest sama w sobie częścią systemu Windows.
Wsparcie techniczne dla Windows XP wygasło, Microsoft wydaje jedynie łatki bezpieczeństwa. Nie wydaje jednak żadnych innych aktualizacji. Kompatybilność z XP jest dziś dość trudna do uzyskania i prawie zawsze odbywa się kosztem pogorszenia wydajności i funkcjonalności.
-
OT: MS nie wydaje już łatek bezpieczeństwa do XP
-
Wrzuciłem właśnie aktualizację do wersji 0.7.0.
Poprawione:
- błędy synchronizacji wątków (losowe wysypywanie),
- wyszukiwanie symboli (teraz działa z wszystkimi plikami, prawidłowo wyświetla znaczniki),
- normalizacja (poprawia także unixowe zakończenia linii),
- wydajność i stabilność (zastępowanie instancji edytora),
- sortowanie i nazywanie torów (teraz całkowicie bezpieczne dla pliku, poprawiona wydajność, dokładne obliczanie długości torów)
Dodane:
- globalna zamiana symboli,
- podpowiedzi dla składni elementów event i trainset
- otwieranie plików include za pomocą Ctrl+LMB na ścieżce w edytorze
Co ma pójść na pierwszy ogień? Wyszukiwanie po współrzędnych? Automatyczne rozkłady? Wyświetlanie map torów i zaznaczanie tras?
Tak. Troszeczkę zmieniam koncepcję - edytor będzie jednak wyświetlał trochę grafiki ;)
Instalka (x86):
http://nisza.org/dl/ScnEdit-0.7.0.msi (http://nisza.org/dl/ScnEdit-0.7.0.msi)
Źródła:
https://github.com/HTD/ScnEdit (https://github.com/HTD/ScnEdit)
Wersja portable (x86)
http://nisza.org/dl/ScnEdit-0.7.0.7z (http://nisza.org/dl/ScnEdit-0.7.0.7z)
.NET Framework 4.5.1 (wymagane)
http://www.microsoft.com/pl-PL/download/details.aspx?id=40779 (http://www.microsoft.com/pl-PL/download/details.aspx?id=40779)
-
Co do skompilowania pod x64 - po prostu wydajność. Duże pliki, przetwarzanie w czasie rzeczywistym. Co do .NET 4 a nie 2 - lepszy kod.
Takie podejście jest dobre w firmie, która ma jakieś zadania do zrealizowania i pod nie dobiera sprzęt oraz oprogramowanie. Gdy masz setki użytkowników indywidualnych, raczej nie wymienią sobie sprzętu "ot tak".
Co do XP, w pewnym momencie skończyły się programy dla DOS-a. Skończył się x86 i tryb rzeczywisty. Komórki mają 64-bitowe proce i są szybsze od kompów, które nie dały rady pociągnąć 7. XP to taka trochę graficzna nakładka na DOS-a.
Skąd wiesz, że 7 nie jest kolejną nakładką graficzną na DOS? A może ktoś po prostu ustawił komputer pod swoje potrzeby i nie ma ochoty szukać, jak co się nazywa w nowszej wersji Windows i gdzie to znaleźć?
-
Takie podejście jest dobre w firmie, która ma jakieś zadania do zrealizowania i pod nie dobiera sprzęt oraz oprogramowanie. Gdy masz setki użytkowników indywidualnych, raczej nie wymienią sobie sprzętu "ot tak".
Mamy zadania do zrealizowania. Nasze. Indywidualni użytkownicy także je mają, skąd pomysł że nie? Indywidualni użytkownicy też podchodzą poważnie do życia.
Mówimy o niewielkich wydatkach (w przeliczeniu na rok), a nie zakupie superkomputerów. Co więcej - dzieciaki naciągają rodziców na te wydatki co parę lat ze względu na głupie gierki. Młodzież wydaje więcej na telefony (komputery nadające się do pracy dziś są tańsze od części smartfonów).
Jeśli ktoś, kto rozumie kod komputerowy mówi, że go nie stać na komputer, powinien natychmiast zmienić robotę ;) W IT zarabiam kijowo. Ale bez przesady. Wiesz co jest drogie? Życie jest drogie. Jedzenie, opłaty za mieszkanie i media. Podatki. ZUS. To stałe wydatki, rocznie przebijają wszystko. Dalej znacznie częściej niż wymieniać komputer muszę wymieniać ciuchy. Nawet ostatnio sprzęt AGD lubi się psuć częściej niż kompy. A, byłbym zapomniał, jak ktoś regularnie dojeżdża - bilety na komunikację są drogie.
Skąd wiesz, że 7 nie jest kolejną nakładką graficzną na DOS?
Z praktyki zawodowej i prywatnej. Znajomość systemu jest mi po prostu potrzebna.
A może ktoś po prostu ustawił komputer pod swoje potrzeby i nie ma ochoty szukać, jak co się nazywa w nowszej wersji Windows i gdzie to znaleźć?
Jeśli ten ktoś zajmuje się programowaniem, to coś poszło mocno nie tak. Niechęć do rozwoju u programisty? Paskudnie pechowe rozdanie. Hej - ja też jestem dinozaurem. Uczyłem się programować na małym Atari :) Robiło się dema na 8-bitowce. Ba - nawet gierki pisałem :) Swojego czasu robiłem własną "nakładkę na DOS" ;) To były czasy :)
Nie cierpiałem Windows 3.1! TYLKO DOS! Windows 3.1 zamulał tak bardzo! I po co to, na co?! ;) Później 95, 98, ME... Chyba właśnie XP, który w miarę od biedy jakoś działał i nie zamulał jakoś strasznie.
Po drodze różne odmiany Linuxa. Niezbyt wiele. Najpierw Debian, potem... Gentoo ;) I powrót do Debiana skrzyżowanego z Ubuntu (Mint).
Moje pierwsze doświadczenia z Vistą były złe. Dlatego, że kiedy wyszła Vista, komputery nie spełniały wymagań sprzętowych. Jeszcze przez parę lat nie spełniały. Windows 7 nie różni się tak bardzo od Visty. Dlatego ludzie uważają go za dużo lepszy system, bo w chwili wydania ich komputery dawały radę go bez problemu obsłużyć. Także Vista zainstalowana na tych komputerach mogła już pracować bez zarzutu.
Microsoft uczył się na swoich błędach. Od Visty - wszystkie kolejne systemy są mocno optymalizowane pod kątem wymagań sprzętowych i mają je wręcz coraz mniejsze, coraz mniej "zbędnych" bajerów.
I jeszcze jedno. Miałem wątpliwą "przyjemność" popracować na starszym sprzęcie dziś. Nie wyobrażam sobie tego. To był koszmar, kiedyś sam tak pracowałem. Większość życia tracona na "paski postępu", wiecznie harczący dysk. Zamulanie, zamulanie, zamulanie. Wieszanie wszystkiego co chwila. Dopiero w dzisiejszych czasach komputera się po prostu używa. Bo PO PROSTU DZIAŁA. Bez czekania, zamulania, ciągłej z nim walki. Powiem tak, jak chcesz się bawić, nawet hobbystycznie w majsterkowanie - kup sobie narzędzia. Serio mówię. Stację lutowniczą kupisz za mniej niż 100. A lutowanie SMD bez tego to po prostu "nie, nie". Programujesz? Kup sobie sprzęt co najmniej z Win7 i 8GB RAM (bo daje radę). I nie ścibol 200 zł na dysk SSD, bo zaoszczędzi całą masę godzin czekania.
BTW, zeszliśmy z tematu trochę :)
-
Wrzuciłem właśnie aktualizację do wersji 0.7.0.
Proponuję, żebyś wrzucając nową wersję aktualizował linki w pierwszym poście.
Dodano: 22 Grudnia 2014, 21:25:12
A nie, ślepy ja.... nie zauważyłem że są zaktualizowane...
Dodano: 22 Grudnia 2014, 21:26:28
Możesz przerobić instalator, żeby z automatu wywalał/aktualizował znalezione starsze wersje?
-
Mamy zadania do zrealizowania. Nasze. Indywidualni użytkownicy także je mają, skąd pomysł że nie? Indywidualni użytkownicy też podchodzą poważnie do życia.
Nadal nie odróżniasz firmy IT od działalności społecznej. Ja od lepszego peceta wolałbym sobie kupić latającą kamerę albo drukarkę 3D. Dla mnie programowanie to przede wszystkim wymyślanie koncepcji na rozwiązania, rzadko mi się zdarza wypróbowywanie wszystkich kombinacji. Ale być może jestem w błędzie. MaSzynę optymalizowałem na "bardzo powolnym" komputerze, bo na szybkim to nawet nie było widać, że coś przycina albo się za długo robi.
-
Możesz przerobić instalator, żeby z automatu wywalał/aktualizował znalezione starsze wersje?
Podpowiedź dla HTD: trzeba zmieniać "UpgradeCode" i "Version" instalator za każdym razem, a nie ruszać ProductCode.
-
@muri:
A nie robi tak? U mnie wywala automatycznie starszą i instaluje nowszą. Przy każdym podbiciu wersji odpalam instalkę i zastępuje mi starszą. Ale jeszcze przetestuję to później.
Dodano: 22 Grudnia 2014, 23:17:33
Ja od lepszego peceta wolałbym sobie kupić latającą kamerę albo drukarkę 3D. Dla mnie programowanie to przede wszystkim wymyślanie koncepcji na rozwiązania, rzadko mi się zdarza wypróbowywanie wszystkich kombinacji. Ale być może jestem w błędzie. MaSzynę optymalizowałem na "bardzo powolnym" komputerze, bo na szybkim to nawet nie było widać, że coś przycina albo się za długo robi.
Testy lepiej robić na wolniejszym sprzęcie, ale to ma swoje pułapki. Pierwsza z brzegu - rezygnujesz z jakości. Efektem są np kanciaste wielokątne gałki zamiast okrągłych. Od wielu lat żaden problem. Ludzie sobie kupują lepsze kompy, żeby na ich monitorkach wyświetlały się okrągłe gałki. Tymczasem, odpalają produkt robiony na słabszej maszynie i co widzą? Kanciastość. Abstrakcyjny przykład, ale czujesz o co chodzi. Dalej - nowsze kompy (czytaj z ostatnich 5 lat) mogą mieć powiedzmy 4x wyższą wydajność obliczeń przy tym samym taktowaniu, pod warunkiem że wykorzystujesz 4 rdzenie procesora do wykonywania obliczeń równolegle. Wymaga to oczywiście odpowiedniej optymalizacji kodu, którą jest bardzo trudno uzyskać nie mając 4 rdzeni CPU. Owszem, system operacyjny będzie emulował wielowątkowość, ale spowoduje to na tej maszynie spadek wydajności zamiast wzrostu. Itd. itp.
Co do samej pracy - jak Ci narzędzia zamulają, nie ważne czy robisz charytatywnie czy zawodowo - tracisz czas. Albo cenny wolny czas, albo cenny płatny czas. Mi nawet bardziej szkoda czasu wolnego.
Gdyby tak szło połączyć pasję z pracą... Musi być jakiś sposób. Szukam.
-
Mogę prosić print screeny z widoku gotowego narzędzia? :>
-
Od wielu lat żaden problem. Ludzie sobie kupują lepsze kompy, żeby na ich monitorkach wyświetlały się okrągłe gałki.
Nie zgodzę się. Microsoft wykupił Skype, ulepszył go, ale nie zapewnił kompatybilności wstecznej. Tym samym użytkownicy bez sprzętu, który obsługuje protokół SSE2, nie są w stanie korzystać z tego programu. Poczytaj sobie na forach zagranicznych komentarze na ten temat. Microsoft też się zasłania tym, że ludzie wymieniają sprzęt. No a tak nie jest, wiele osób używa jeszcze XP, bo ma stare komputery, niezdolne do uciągnięcia nowszych systemów.
-
No cóż, ja się akurat cieszę. Kompatybilność wsteczna jest największym hamulcem rozwoju, a jeśli chodzi o komputery - rozwój jest najszybszy i najbardziej pozytywny.
Nowe komputery są bez porównania przyjaźniejsze dla ludzi. Nie tyle prostsze w obsłudze, bo z tym jest różnie, ale przyjaźniejsze, bo działają. Robią to to mają robić, a nie to co muszą ze względu na ograniczenia. Wcześniej człowiek musiał się przyzwyczaić i dopasować, że system operacyjny musi się ŁADOWAĆ i na to trzeba dość sporo poczekać. Człowiek się dopasowywał do tego, że jak korzysta z jednej aplikacji, to niestety nie z drugiej. Że każda rzecz musi swoje trwać, nawet jeśli jest to tak banalna sprawa jak wyszukanie wiadomości czy zmiana jakiegoś ustawienia systemu.
W końcu do tego, że praca z komputerem to ciągłe szarpanie się i użeranie, tłumaczenie temu komputerowi najprostszych rzeczy, wybieranie w kółko najbardziej oczywistych opcji.
Niebieskie ekrany. I inne błędy - co chwila. Losowe działanie.
Znam ludzi, którzy przez długi czas używali przestarzałych komputerów. Nie cierpią ich. Nie cierpią firm softwarowych. Nie cierpią większości przeglądarek. Technologii. Dlaczego? Bo stale im się wszystko sypie. Zawiesza. Nie działa tak jak powinno. Stale jakieś problemy. A to drukarka nie drukuje. A to film się nie odtwarza. A to program się wywala zaraz po kliknięciu na niego. W ich głowach wyrył się obraz niechlujnych producentów, robiących badziewne oprogramowanie, które w sumie rzadko kiedy normalnie działa, do tego jest oczywiście niemożliwie wolne.
Będąc w tym miejscu nie masz nawet pojęcia, że może być zupełnie inaczej. Że każdy ten "nowy, głupi program" - może działać idealnie, szybko, dokładnie tak jak chcesz. Że nic się nie musi sypać i się nie sypie. Że można na prawdę zapomnieć jak wygląda jakiś błąd systemowy czy zawieszenie. Że można nie restartować kompa przez kilka tygodni.
Nigdy nie kręciły mnie gigaherce, moc dla samej mocy. Był czas, kiedy ten sprzętowy wyścig zbrojeń był dla mnie absurdalny. Być może był to czas, w którym zapotrzebowanie na moc rosło i tak szybciej, niż dostępna dla przeciętnego Kowalskiego moc. Kupowałeś komputer - po roku czy dwóch był przestarzały. Ba - czasem był już przestarzały w chwili zakupu, bo soft wymagał maszyn, na które mogli sobie pozwolić tylko bogaci mieszkańcy zachodniego świata.
To się zmieniło, i była to największa zmiana w ciągu ostatnich 50 lat. Mniej więcej w czasach wydania Windows 7. Zaczął się czas, w którym komputer można kupić na kilka lat i przez te kilka lat będzie działał bez zarzutu, szybko, sprawnie i stabilnie. Pewne rzeczy okrzepły i przestały się gwałtownie zmieniać. Np pamięć. Zatrzymała się na rzędzie gigabajtów. Nieprędko będą nam potrzebne terabajty RAM. A mam już pewność, że dostaniemy je ZANIM będą nam do czegokolwiek potrzebne. To samo jeśli chodzi o dyski. Po zatrzymaniu się na poziomie pojedynczych TB praktycznie nie da się ich zapchać. Limit, z którym zawsze trzeba było się liczyć zniknął.
Jako dinozaur pamiętam jeszcze dobrze coś takiego jak "konflikt sprzętowy". Jak urządzenia nie chcące współpracować z innymi urządzeniami w tym samym PC. Jak "problem ze sterownikami". Nie ma. Skończyło się. Pamiętam instalację XP i wczesnych siódemek. Przygotowana tona sterowników, często na jakiś płytkach nawet - bez tego ani rusz. I modlenie się, żeby nic się nie spierdaczyło przy instalacji. A i tak prawie zawsze się pierdaczyło.
Nie dziś. Dziś jest "włącz i zapomnij". Wszystko zrobi się samo. Tak jak trzeba. I będzie działać. Na reszcie można temu ufać. I to wszystko od ładnych kilku lat. Nie ma już "reinstalek systemu". Format?! Dziś?! Trzeba być zdolnym psujem, żeby tak zepsuć system. BTW, jak w XP każdy program miał praktycznie nieograniczone prawa zapisu gdziekolwiek - to było wręcz niesamowite, że te komputery mogły w ogóle tak długo działać bez uszkodzenia.
Last but not least - ekologia. Stare kompy - hałas i grzanie. Był czas (jeszcze nie tak dawno) gdzie kaloryfery nie mieściły się w budach. Ryk wiatraków był nieodzowny. Znów - przeszłość. Teraz to wszystko zużywa tak mało prądu, że może działać z baterii. W skali świata - różnica musi być kolosalna.
Całe szczęście, że poszczególne programy i sprzęt zrywają kompatybilność wstecz. Między innymi temu zawdzięczam te wszystkie zmiany. Tanią i powszechnie dostępną nową technologię. Rzeczy działające tak jak powinny. Kto kiedykolwiek poprawiał błędy w jakiś programach powinien wiedzieć, jak mocno różnią się kolejne wersje od siebie. O ile są lepsze. Np taka MaSzyna ;) Developerzy powinni wiedzieć ile bugów usunęli. Ile przydatnych rzeczy dodali. Pomyślcie, że to samo tyczy się systemu operacyjnego i to na dużo większą skalę. To setki tysięcy, jeśli nie miliony poprawionych bugów. Tyle samo ulepszeń i optymalizacji. To wszystko widać gołym okiem. Wystarczy tylko po prostu zacząć tego używać.
Zacząłem swoją przygodę z komputerami jak były nowinką techniczną, jako ciekawy świata dzieciak. Na szczęście to się nie zmieniło. Nie zramolałem, nie zacząłem bać się nowego. Nie pozwalam sobie na to.
Kiedyś dostosowywałem sobie system i programy do własnych przyzwyczajeń coraz bardziej wzmacniając przyzwyczajenia. Jak coś się nie dało dostosować, albo po prostu działało troszkę inaczej niż się spodziewałem - omijałem to. Ogromne samoograniczenie. Przełamałem to i było warto. Takie ograniczenia to trochę tak, jakby umieć prowadzić tylko swojego forda i żadnego innego samochodu.
-
Cały długi wywód, a ja napiszę jedno słowo: KASA. Nie chce mi się sprawdzać, ilu jest zarejestrowanych użytkowników forum i robić jakieś statystyczne porównania, pewnie nikt już nie ma celerona 400 i RivęTNT2 z wypasioną ilością pamięci 256mb. Ale próżno liczyć na to, że użytkownicy będą kupować nowe sprzęty i OS, dla MaSzyny. Do tego potrzebna jest większa motywacja i KASA. Z pozycji dobrze ustawionego finansowo "piernika" może tego nie widać. Ponad to, większość, to ludzie kompletnie nie znający się na sprzęcie i zawiłościach systemów operacyjnych. Resztę napisał @Ra i nie ma co powtarzać.
-
Właśnie po to masz mieć normalny (niezabytkowy) komputer. Nie musisz się już dalej znać na sprzęcie, konfiguracji itp. To zabytki wymagały kombinowania i wiedzy.
Co do kasy, nie żartuj. Normalny (nie z górnej półki, nawet nie ze średniej) komputer to nie jest żadna kasa. I do bycia ustawionym piernikiem to mi jeszcze bardzo daleko. Póki co najlepszy soft robię za darmo.
BTW, bywam często na wsi - ale z informatyzacją u ludzi nie jest tak źle :) Nie widziałem u miejscowych ani jednego XP ;) Może dlatego, że w tamtych czasach nikt tam w ogóle nie miał komputera. To między innymi powód, dla którego Polska ma bardzo nowoczesną infrastrukturę telekomunikacyjną na tle świata. Zaczynaliśmy trochę później i nie blokowały nas tak bardzo zaszłości.
Rozwijam soft z użyciem .NET Framework, bo mogę dzięki niemu pisać programy kilkukrotnie szybciej niż bez niego. Nie myśl sobie, że "nie umiem C" czy coś w ten deseń. Programowałem w kodzie maszynowym jako dzieciak (nie assemblerze, KODZIE MASZYNOWYM, wpisując cyferki), pisałem własne kompilatory w czasach, kiedy nie można ich było w Polsce dostać. SZKODA CZASU.
Wracając do KASY - właśnie, tworzę narzędzia ZA DARMO. Więc chyba zrozumiałe jest, że ułatwiam sobie i przyśpieszam pracę, żeby zrobić jak najwięcej jak najszybciej? Do tego jak najlepiej.
Mi szkoda, że ludzie marnują czas i potencjał na wyważanie otwartych drzwi, robienie dawno rozwiązanych pierdółek tysiące razy ze względu na jakiś absurdalny wręcz upór, bo inaczej tego nie umiem nazwać.
-
Ja dodam tylko, że dzisiaj kupić system operacyjny od Microsoftu w wersji OEM to nie jest jakiś horrendalnie spory wydatek jak to bywało kiedyś. Ja za swojego Windows 7 w wersji Home Premium do swojego netbooka zapłaciłem tylko 399,- PLN, ponieważ miałem dość ograniczeń, jakie nakładał system Windows 7 w wersji Starter, który był orginalnie zainstalowany w komputerze i zaśmiecony przez tzw. crapware od producenta komputera. Rozumiem, że niektórzy mają rodziny na utrzymaniu oraz bzika na punkcie XP i uważają go za system nie do zastąpienia, no ale niestety, trzeba iść z postępem. Systemu nie kupuje się na okres jednego roku, tylko na okres zapewne 5-6 lat. Jak ktoś napisał wyżej, Windows XP nie jest już wspierany, więc nie są już do niego wydawane żadne łatki bezpieczeństwa.
-
Odniosłeś wszystko do siebie, nie taka była intencja. Gimnazjalista nie kupi sam komputera (brak kasy), musi zadowolić się tym, co do stanie od rodziców... i na tym pracuje i tu nie żartuje. Jako były pracownik telekomunikacji (Orange, dawniej TP) pionu technicznego, nie podzielam Twoich poglądów:
Polska ma bardzo nowoczesną infrastrukturę telekomunikacyjną na tle świata. Zaczynaliśmy trochę później i nie blokowały nas tak bardzo zaszłości.
Pozwolę sobie zauważyć, że zmieniła się także filozofia działania tej firmy, odkąd przestała świadczyć usługi powszechne. Typowy produkt Funpack ma tyle ograniczeń i wymagań infrastrukturalnych, że w większości przypadków zwyczajnie klient jest niezadowolony. Czytając Twoje teksty mam wrażenie jakbym słuchał konsultanta z Orange usiłującego sprzedać staruszce NEO+TV+Telefon internetowy, razem ze wszystkimi kanałami HDTV. Czemu? Bo takie są wytyczne korporacji. Dość oftopu, ja mam dość tłumaczenia i obalania teorii, jak to tu, czy tam, jest dobrze, a u nas jest źle. Tylko z jednym jest problem, brak jednolitej koncepcji rozwoju symulatora.
PS: Skąd "gimbus" weźmie 400zł? Poza tym, najmniej chodzi o OS.
-
Ja mam 5,5 roku komputer z Windowsem XP i mimo iż bywało że coś się sypnęło, to instalacja systemu jest bez przerwy ta sama, bez żadnego formatu :)
Wprawdzie po tym czasie system chodzi wolniej - dysk jest stary, talerze zużyte, tutaj cudów nie ma + procesor dwurdzeniowy i 2 GB Ramu - ale pamiętając jak często i jak bardzo psuł się mój poprzedni komputer to jestem zadowolony z tego jak długo mi służy. Wprawdzie najnowszych gier nie zainstaluję, ale wszystko co mi potrzebne działa.
Na razie nic mnie nie zmusiło do zmiany systemu, a w razie czego mam w zanadrzu laptop z Win7 na którym wszystkie nowe rzeczy pójdą.
-
OK, masz rację, szkoda czasu na sprawy typu "Windows kontra Linux" i podobne. Wszyscy chcemy coś zrobić i to się liczy. Z mojego punktu widzenia - OS jest chyba ważniejszy od sprzętu. Nowe mogą więcej, nawet na tym samym sprzęcie. A jeśli chodzi o wymagania symulatora - to się musi skalować. Jedną z lepszych zmian było wprowadzenie automatycznego obliczania MaxDistance w zależności od FPS. Dobra robota. Ktoś pisał też o poligonach w modelach, żeby tworzyć ich do oporu, i ewentualnie przycinać już na końcowym etapie, mając cały czas gotowe pliki z większą ilością detali.
Co do doświadczeń moich z XP, były różne. Bywało że rok podziałał bez problemu, a bywało że nawet dłużej. Jak na swoje czasy to był niezły system. Ale, że czasami lubię sobie w coś pograć - trafiłem na twarde ograniczenie XP. Owszem, w tych czasach wszystkie gry odpalały się na XP, ale jeśli chodzi o FPS, na 7 chodziły kilkukrotnie szybciej (serio). Może kwestia sterowników do Radeona, nie wiem.
Aha, co do telekomunikacji - ja nie mówię o jakości świadczonych usług (tym bardziej cenach), ja mówię o technicznej jakości sprzętu i łącz. Z tego co czytam jak się z tym użerają i płaczą w USA - u nas jest bajka. Przy ich mafiach telekomowych to nawet nasz Orange (nie polecam, odradzam, negatyw!) jest porządną firmą :) Miałem kiedyś umowę z Orange - to są bandyci. Potwierdza to nawet mój kumpel z UK - tak samo traktują klientów w reszcie Europy.
-
Jedną z lepszych zmian było wprowadzenie automatycznego obliczania MaxDistance w zależności od FPS. Dobra robota.
To od razu sprostuję. Pojęcie MaxDistance dotyczy maksymalnej widoczności obiektów i kiedyś dla poprawy FPS było ustawiane na kilkaset metrów, co z kolei teraz na lepszym sprzęcie powoduje dziwne ujawnianie się obiektów (dobrze widać w obecnym Manewrowo3, jak pojawiają się budynki z MaxDistance=1000). Natomiast wprowadzona jest automatyczna regulacja promienia widocznej scenerii — obiekty scenerii rozlokowane są w sektorach o boku 200m, a liczba widocznych sektorów jest regulowana stanem FPS. Od czasu wprowadzenia tego mechanizmu skończyły się masowe narzekania na niski FPS oraz spadki FPS na stacjach, bo automat stara się utrzymywać go w zakresie 15÷25. Inna sprawa, że wydajność sprzętu też poszła do przodu.
-
Jeśli jesteśmy w tym temacie, to moim skromnym zdaniem wielka szkoda, że część użytkowników, która posiada słaby sprzęt, ogranicza, pod kątem wyświetlanej grafiki, całą resztę. To znaczy: ja mam słaby komputer, który przy większej ilości trójkątów przejdzie w tryb "pokazu slajdów", więc będę protestował przeciwko zmianom, nie pozwolę, żeby ktoś mógł mieć, odnosząc się do przykładu z postów @HTD, okrągłe gałki. Wiem, że nikt w ten sposób nie myśli, tzn. nikt (prawie nikt) nie robi tego (nie bojkotuje postępu) naumyślnie, a jedynie wyrażają swoje obawy przed tym, że po drodze ktoś o nich zapomni i już nie pograją sobie w MaSzynę, bo wymagania sprzętowe zbyt urosną.
Według mnie jest to czynnik w dużej mierze spowalniający rozwój symulatora. Ogranicza on ilość nowych użytkowników, których być może przyciągnęłaby bardziej realistyczna grafika. Jak możemy liczyć na to, że do zespołu dołączy się dobry grafik, skoro typowy grafik z doświadczeniem spojrzy na screeny i z marszu będzie przekonany o ułomności naszego silnika graficznego?
-
A co jeśli dołożyć 1 poziom podkatalogów do modeli? Np dodatkowy katalog HD, z którego byłyby brane modele z większą ilością trójkątów czy dodatkowymi atrybutami? W sumie technicznie to dołożenie 1 stringa do kodu i konfiguracji. Coś w stylu modelDirectory = hd ? "models" : "models\\hd" ;) Wtedy wilk syty i owca cała. O grafice 3D mam pojęcie mgliste, ale czytałem, że modele z 3DS przed eksportem przechodzą przez dzielenie na trójkąty z różną precyzją. Gdyby tak było, to źródło miałoby zawsze możliwość wygenerowania 2 zestawów plików.
Podobnie mogłoby być z teksturami. Mało tego, można by ściągnąć wersję SD lub HD - tzn podstawowa paczka byłaby SD, HD byłaby jako opcja. Widziałem takie rozwiązania w modach do gier. Przejście na HD sprowadzało się do wypakowania 1 zipa. Zip miał readme z opisem wymagań sprzętowych dla wersji HD.
BTW, szkoda, że jakaś spółka PKP nas nie sponsoruje, w końcu reklamujemy kolej w czasach, gdy reklama jest im jak najbardziej potrzebna.
-
Wiem, że nikt w ten sposób nie myśli, tzn. nikt (prawie nikt) nie robi tego (nie bojkotuje postępu) naumyślnie, a jedynie wyrażają swoje obawy przed tym, że po drodze ktoś o nich zapomni i już nie pograją sobie w MaSzynę, bo wymagania sprzętowe zbyt urosną.
Według mnie jest to czynnik w dużej mierze spowalniający rozwój symulatora. Ogranicza on ilość nowych użytkowników, których być może przyciągnęłaby bardziej realistyczna grafika. Jak możemy liczyć na to, że do zespołu dołączy się dobry grafik, skoro typowy grafik z doświadczeniem spojrzy na screeny i z marszu będzie przekonany o ułomności naszego silnika graficznego?
Trzeba raz wreszcie spojrzeć prawdzie w oczy i powiedzieć to co jest przykre ale prawdziwe. Jak kupisz nowy komputer, to po 5 latach użytkowania tenże sprzęt nadaje się do obsługi programów tekstowych (tu ironia). Niestety, taka jest żywotność tego typu sprzętów i nic na to nie poradzisz. Druga prawda, silnik graficzny Maszyny to stareńki dziadunio wymyślony epokę temu. Myślę jednak, że nie jest to największą bolączką "Maszyny". Niech ktoś mi powie, kiedy pojawiła się ostatnia nowa sceneria, 2, 3, 5 lat temu? Bo już nie pamiętam, ale chyba jeszcze byłem kawalerem.... Co mi z realizmu, skoro każdy scenariusz przejadę z opaską na oczach. Tu jest główny problem tego projektu, brak atrakcyjności. Kolejny, to kosmiczny stopień skomplikowania. Weźmy taki MSTS dla przykładu, symulator też stary jak świat i kiepski graficznie. Ma za to jedną niesamowitą zaletę. Powiedzmy, chcę sobie stworzyć własny scenariusz w jakiejś tam misji, niech będzie CMK. W edytorze MSTS zajmuje mi to góra pół godziny. Mam zrobione mijanki, wiele składów z naprzeciwka i inne bajery jak mi się chce. W "Maszynie" podobny scenariusz ile czasu zajmuje? Miesiąc, dwa? I to jest chyba główny powód tego, że chętnych do równania góry kilofem, jest bardzo niewielu.
-
Czyli wystarczy zrobić dobry edytor ;) Tylko ;) Plus rzeczy takie jak SRK muszą być zautomatyzowane. Jest pokusa, żeby robić coś, co widać. Ba - przekleństwo mojej pracy w IT jest podobne. Pracodawców interesuje tylko to co widać, na samym wierzchu. Podczas gdy najciekawsze rzeczy są pod maską. Pracując nad nimi trudno pochwalić się efektem, dopóki się ich nie skończy. Nawet 90% to za mało. Pokazać można, jak działa 99. Ale to jałowa dyskusja. Rozwój ogranicza brak sponsora. Myślę, że nawet 1 osoba byłaby w stanie zrobić w rok w pełni funkcjonalny edytor tras i misji. Wystarczyłoby zatrudnienie na etat. Ten projekt nie musiałby kosztować milionów, ani nawet być płatny. Firmy wydają więcej na kampanie reklamowe. Ja to sobie myślę tak - że jakby zrobić trochę atrakcyjnych dla NOWYCH userów rzeczy, można by przyciągnąć więcej ludzi (zauważ, że problem z tym, że znamy trasy na pamięć odpada - nowi nie znają). A więcej ludzi, to większy ruch, większa rozpoznawalność, większa atrakcyjność dla potencjalnych sponsorów. Plus pewnie efekt masy. Nawet jeśli nie wiem jak mały odsetek tej dużej masy ludzi coś będzie tworzyć - sumarycznie będzie już trochę znaczącej mocy przerobowej.
Tymczasem - znalazłem parę miesięcy temu MaSzynę zupełnie przez przypadek. Pierwszy kontakt był odstraszający nawet dla mnie. Ale to są rzeczy dość łatwe do zmiany. Wystarczy zrobić nową stronę projektu, bardziej na czasie, z większą ilością grafiki i filmów. Materiałów do tego jest do oporu. Do tego w samym symku zrobić tutorial - na to akurat mam dobry pomysł i we właściwym czasie pokażę to zrobione. Z resztą, stronę też mogę walnąć. Tylko jest powód, dla którego ani ja, ani nikt inny chyba tego nie robi TERAZ. Priorytety. Jest do dopracowania kilka ważnych detali. Np rozkłady, bez których misje tracą dużo na atrakcyjności. Np masa drobnych bugów, które psują obraz całości. Np brak narzędzi wspomagających szybszy rozwój. Wg mnie to się wszystko da zrobić, i to nawet bez sponsora. I myślę, że nawet dość szybko.
A wtedy - odjazd. Ruszy się to.
-
Taki mały off i moja opinia na to wszystko. Brakuje tu nowych userów, bo? Starzy potrafią ich zrugać za to, że zapytają, kiedy będzie nowa publikacja później się dziwicie, że nie ma chętnych na robienie czegoś tak wigilijnie, ale szczerze, dlatego się tu nie wypowiadam a chciałbym pomóc, ale nie ma nikogo, kto cię "poprowadzi" zarzucą ci linkiem do edytora albo usuną twój post, bo się nie znasz. Dziękuje.
-
chciałbym pomóc, ale nie ma nikogo, kto cię "poprowadzi"
Ja też poproszę, żeby mnie ktoś poprowadził, bo wielu rzeczy zrobić nie umiem.
-
Mogę prosić print screeny z widoku gotowego narzędzia? :>
Dłuższą chwilę przypatrywałem się temu z boku... i jako deweloper oprogramowania, i jako dawny tester Igora, i jako użytkownik. Mógłbym znieść wszystko ale jakoś strasznie wesołą sprawą jest pobieranie .Net'a. Program ma w ciemno, nie więcej niż 50MB... a paczka .Net z tym jednym komponentem to prawie 3GB. Czy tylko ja widzę jakieś błędne założenie?
-
Przecież HTD pisał, żeby sobie nowy komputer kupić, z dyskiem 1TB, a nie tracić życie na mulenie starego.
-
:) NET 4.5.1 zostaje do wersji 1.0. Być może da się zbić do 4.0, po ukończeniu. Jakieś inne, konstruktywne uwagi? ;)
-
To jest najbardziej konstruktywna. To tak, jakbym ja skompilował prosty program bazodanowy ze wszystkimi bibliotekami Qt, tylko dlatego że użyłem jakiegoś gotowca - przecież to żadna różnica czy narzędzie zajmuje 10MB czy 2800MB... zwłaszcza, że jest niewiele potrafiącą alfą. To jest ten moment gdzie porzuca się projekt i zaczyna od nowa z uwzględnieniem przypadłości krytycznych.
-
Poprawiając poprzednią rozwlekłą i mętną odpowiedź: obniżenie .NET do 4.0 dopiero po zakończeniu fazy alpha. Wersji bez .NET nie będzie, ale jak ktoś chce, może dodać samodzielnie do projektu, albo przesłać pliki i sam je dodam. Kolejne uwagi odnośnie .NET proszę kierować w formie poprawek i plików bezpośrednio na GitHub. Poprzez GitHub można także zgłosić chęć dołączenia jako developer. Z góry dziękuję.
-
Mam mieszane uczucia co do Twojej szczerości. W ostateczności kłamiesz i z prawdziwą developerką masz wspólnego tyle co Andrzej Gołota. Wyobraź sobie, że manager projektu, po pierwszych opiniach od testerów stwierdza, że dążenie do osiągnięcia funkcjonalności w aktualnie przyjęty sposób jest złe. Potrzeba nieadekwatnych do tego celu zasobów. Przyjęte rozwiązanie uznane jest samo w sobie jako błąd krytyczny. W normalnej firmie IT projekt na tym stadium porzuca się i zaczyna od razu od nowa, ale z pominięciem błędów. Gdyby rozumować tak jak to robisz obecnie, EU07.EXE powinno mieć 40GB.
Dodano: 26 Grudnia 2014, 13:33:29
Pozwolę sobie na jeszcze jedną małą podpowiedź, sprawdź sobie jaki odsetek tego forum korzysta z komputerów wyposażonych w W8 i W8.1... statystyczna reszta to W7, a następnie XP oraz pozostałe.
A teraz już personalnie, zarabiam tyle że mógłbym spokojnie zmienić komputery na takie jakie dałyby mi przyjemność pracy znaną z W7, i zrobiłbym to od ręki ale na pewno nie z powodu marnych umiejętności deweloperskich programisty ;)
-
Wyobraź sobie, że manager projektu, po pierwszych opiniach od testerów stwierdza, że dążenie do osiągnięcia funkcjonalności w aktualnie przyjęty sposób jest złe. Potrzeba nieadekwatnych do tego celu zasobów. Przyjęte rozwiązanie uznane jest samo w sobie jako błąd krytyczny. W normalnej firmie IT projekt na tym stadium porzuca się i zaczyna od razu od nowa, ale z pominięciem błędów.
I zamienia .NET na co? Ma 100 programistów C#/.NET i mówi: "słuchajcie, od dzisiaj jesteście programistami C++ i używacie wxWidgets. Zamiast jednej linijki piszecie 200. Nie znacie C++? To już wasz problem."
Bez jaj. Żaden menedżer nie zwiększy budżetu na projekt 200 razy. .NET tyle waży, więc to do MS trzeba się żalić. Od wersji 4.6 ma nie wymagać instalowania całego środowiska, tylko będą dołączane dllki z instalatorem.
-
Może się nie znam, ale mnie np. przeraża to, że do różnych programów muszę mieć .NET 2.0, 3.0, 3.5, 4.0, 4.5.1, a co jeden to większy. Do tego mam kilkanaście "Microsoft Visual C++ Redistibutable", też po jednej wersji dla każdego programu. Być może tak właśnie to musi wyglądać i lepiej się nie da. Być może edytor tekstowy najszybciej się zrobi w C#, a do tego sobie trzeba kupić specjalny komputer, żeby nie zamulał. Zasadnicze pytanie, po co to robimy. Jeśli ma to być narzędzie dla wszystkich, to ślepa uliczka. Jeśli tylko po to, żeby ktoś jeden mógł zrobić coś tam, to ma to sens. Z innej strony, np. Mariusz zrobił narzędzia do Excela, ale że wymagają Excela, to wiele osób ich nie używa, chociaż by się przydało zapuścić je przed wydaniem paczki...
-
Czesc,
To ja Mariusz, mnie sie wydawalo, ze Excela ma raczej wiekszosc. Ja w zasadzie pisalem te narzedzia pod swoje potrzeby, bo swego czasu mialem hopla na punkcie automatycznego lub polautomatycznego likwidowania bugow. W samych narzedziach tez moga byc bugi, ale to inna sprawa.
Nie wiem czym kieruje sie HDT. Jesli pisze przede wszystkim sam dla siebie ok, jesli nie, to bedzie musial poczekac, az wiekszosc zmieni sobie sprzet a nie na odwrot.
-
Witaj Mariusz. Ja odniosę się do pierwszego postu w tym wątku. Jestem chyba mało kumaty, nadal nie wiem, co tym niepowstałym, a już kontrowersyjnym edytorem można zrobić. Dowiedziałem się z całego wątku wiele o zawiłościach jego budowy, nadal jednak nie wiem, czy i jak położę nim tory, jak wstawię semafory, zwrotki lub angliki. O sieci trakcyjnej nie wspomnę. Urwałem się z choinki, teraz jest na to czas, więc pytam, co ja będę mógł zrobić tym edytorem... zdanie:
ScnEdit jest ... edytorem czysto tekstowym, który ... wspomaga bezpośrednią pracę nad plikami scenerii, zwłaszcza plikami ctr zawierającymi zdarzenia. Ponadto bezpośrednia edycja plików źródłowych daje największą kontrolę nad ich strukturą i działaniem.
kompletnie mnie o tym nie informuje. Ponieważ pliki scenerii mają swoją oryginalną składnię, potrzebny był edytor, który potrafi tę składnię rozpoznać i oznaczyć odpowiednimi stylami i kolorami.
Dla mnie to tak oczywiste, że nie trzeba o tym pisać (kolory to taki bajer).
Mój edytor prezentuje tekst w kolorze, ponadto kolory można wybrać z kilku gotowych schematów, w zależności czy ktoś preferuje jasne tło, ciemne, czy może łagodne dla oczu, a jednocześnie czytelne.
Taaak, skórki dobra rzecz, jak już się wie co tym edytorem zrobię. Mógłbym tak każde zdanie wyciąć i napisać, że nadal nie dowiedziałem się najważniejszego. Wytykanie wersji .NET coś tam nie ma sensu, skoro wiemy tylko tyle o funkcjonalności projektu.
-
OK, ulżyło wszystkim? :) Swoją drogą, lincz jest bardzo merytoryczną dyskusją w wątku. Nie podoba Wam się mój projekt i użyta technika, więc jedziecie mi personalnie kwestionując umiejętności? To jest po prostu żałosne i żenujące. Dalsza dyskusja na tym poziomie nie ma sensu i nie będę się do niego zniżał. Dajcie szansę normalnym użytkownikom i nie spamujcie proszę.
-
Moim celem nie bylo linczowanie Ciebie. Jesli tak to odbrales, to przepraszam :)
-
...jedziecie mi personalnie kwestionując umiejętności?
Pomyłka, wyszczególniłem czego chciałbym się dowiedzieć o tym, co zamierzasz zrobić. Póki co, chwaliłeś obraną technologię tworzenia, nie przyjmując do wiadomości, ani jednego argumentu dotyczącego sprzętu czy oprogramowania. Jak myślisz, warto dyskutować jak nie przyjmujesz żadnych uwag? Dajcie szansę normalnym użytkownikom i nie spamujcie proszę.
A niby kto to jest? Ja się czuję normalny i wszyscy co tu pisali też. 4588 osób zarejestrowanych na forum, piszących może 50, może 100, kto tu ma być normalny? Mam wrażenie jakbyś pomylił nasze forum z jakimś informatycznym. Do Ciebie nie dociera nawet głos tych kilku osób, którzy potrafią dopisać linijki kodu do exe. Tych najbardziej będących w temacie softwarowym. Odpisz na stawiane zarzuty i pytania, nikt nie podważy wtedy Twoich umiejętności...
-
Mam odpowiadać na zarzuty? Serio? Wow. To było pytanie retoryczne. Dobrej nocki.
-
Tak, serio, zarzuty (czytaj wątpliwości) i pytania dotyczyły ScnEdit i nie były linczem. Miałeś zwracaną uwagę, że słownictwo Twoich wypowiedzi nie pasuje tutaj. Językiem IT możesz tu porozmawiać z kilkoma osobami, reszta nic z tego nie zrozumie, kapujesz? Potrafisz zmienić język na inny? A teraz masz żal, bo ktoś napisał co czuje, bo ktoś odważył się zapytać, a inny że tego nie chce. Możesz temu stawić czoło lub nie, Twój wybór.
Wiem, co to pytanie retoryczne, tym niemniej Tobie odpowiedziałem.
-
Oj tam, wyluzuj. Mi nie podoba się słownictwo sądu kapturowego. Nie przyszedłem się tłumaczyć, bo nie muszę. Na grzecznie zadane pytania odpowiadam, na inne mi się nie chce. Napisałem, czemu użyłem .NET. Gdybym miał się powtarzać, spamowałbym. I tak spamuję odpowiadając w tej zupełnie niemerytorycznej dyskusji, tym samym naruszając regulamin, bo nie powinienem odpowiadać na posty, które naruszają regulamin. Byłem poproszony przez moderatora, żebym nie powtarzał się, nie pisał rzeczy, które nic nie wnoszą ciekawego do dyskusji i pozwól mi proszę dostosować się to tej prośby. Staram się, tylko jakoś nie wychodzi.
Jeśli czymś Ciebie lub kogokolwiek uraziłem, najmocniej przepraszam. Może troszę za bardzo upierałem się, że .NET 4.5 czy Win 8 to fajne rzeczy. To nie było mądre. Zostaniemy przy swoich zdaniach. Teraz po co zrobiłem ten edytor? Jeszcze nie wiem. Ciekawi mnie, co się da z tym zrobić, czego się nauczę, dokąd mnie ta zabawa zaprowadzi. Na razie potrafi parsować część plików, wyciągać ładnie informacje, sortować i nazywać tory. Trochę podłubię, i wyświetli ich ładną i przyjazną mapę. Potem wyświetli trasy poszczególnych składów na tej mapie. Potem wyliczy im rozkłady. A potem się zobaczy, czy serio muszę przedstawiać jakiś biznesplan? Wyluzujmy. Robimy różne rzeczy dla zabawy, bo lubimy. Po co się denerwować i brać wszystko tak serio? Róbmy swoje bez niepotrzebnych ciśnień.
Tak na marginesie, proszę nie stawiaj sprawy tak, że albo się wytłumaczę, albo będziesz Ty czy ktoś inny kwestionował moje umiejętności. Mam nadzieję, że rozumiesz, że nie jest to specjalnie rozsądne, prawda? Ja nie kwestionuję niczyich umiejętności tu, bo na dobrą sprawę nawet ich nie znam. Tak samo jak Wy nie znacie moich. Nie ma sensu sobie przygadywać czy coś udowadniać. Przynajmniej mi nie o to chodzi. Jeśli byłem uparty czy upierdliwy z tym .NET-em, ok, przepraszam, rozumiem, że niektórzy go nie znoszą, uważają za zbędną rzecz itd. Co do tłumaczenia dlaczego .NET jest przydatną technologią, to bym musiał używać już brzydkiego języka, a inaczej, prościej jest ciężko. No i trzeba by założyć chyba jakiś kompletnie nowy wątek, z odpowiednim tematem.
Zaproponowałem już wcześniej kompromis. .NET 4.0. Ta biblioteka pójdzie pod XP, więc program powinien być dostępny dla wszystkich zainteresowanych. Pozdrawiam.
-
Wiele narzędzi jest już zrobionych http://eu07.pl/forum/index.php/topic,24985.0.html . Jak będzie czas to dorobię do tego jakiś notatnik by widzieć dokonywane zmiany na bieżąco.
-
Zapraszam do testów, zgłaszania uwag i pomysłów.
Potrzebne by było takie coś: otwieramy sobie ileś plików do edycji (tak z 10), pliki zostają wstępnie sparsowane. Wybieramy opcję z menu, która tworzy nowy plik, a następnie analizuje kolejne wpisy z otwartych pierwotnie plików — jeśli jakiś wpis występuje w każdym z nich, to jest usuwany i wklejany do tego nowego. Na wyższym poziomie trudności powinny być jeszcze sprawdzane nazwy obiektów — jeśli w niektórych plikach jest nazwa, a w pozostałych none, to wpis jest traktowany jako identyczny we wszystkich i przenoszony z nazwą. Dalej, podobnie powinny być traktowane isolated i velocity w torach — jeśli występują chociażby w jednym z plików, to wpisy bez tych własności mają być traktowane jako identyczne.
-
Rozumiem, że chodzi o wszystkie "node" i "event", nie tylko tory? Myślałem o tym, żeby przeparsować to z ignorowaniem typu obiektu i potraktować obiekty jako równe, jeśli wszystkie pola z wyjątkiem nazwy są równe. Względnie, jeśli potrzeba można także uznać za równe obiekty, których współrzędne są odległe o maksymalnie n mm. Zaplanowane do końca tygodnia.
-
Moim celem nie bylo linczowanie Ciebie. Jesli tak to odbrales, to przepraszam :)
...jedziecie mi personalnie kwestionując umiejętności?
Pomyłka, wyszczególniłem czego chciałbym się dowiedzieć o tym, co zamierzasz zrobić.
Panowie, czy egocentrym aż tak bardzo Was zaślepia?
Wystarczy spojrzeć trzeźwym okiem na tę stronę w wątku, żeby stwierdzić, że post o linczu autorstwa @HTD odnosi się do postów @pol102 oraz Ry. Od Waszego świętego oburzenia bardziej irracjonalnym byłoby chyba święte oburzenie wyrażone przez użytkownika @ryba825.
Kolejnym bezsensem jest Wasze zaangażowanie w ten temat. Staję, być może jako adwokat diabła, w obronie @HTD, bo czuję, że jest osądzany podobnie jak ja byłem, swego czasu. Prezentowałem wtedy, czy to rozjazdy, czy wysięgniki, czy inne elementy infrastruktury i byłem równie dobitnie przekonywany, że projekt jest bezsęsu, bo za dużo poly. Skoro duża ilość poly Wam przeszkadza, skoro Wasze komputery tego nie pociągną, skoro z góry wiadomo, że nie będziecie z tego projektu korzystać, to pomijając uwagi konstruktywne, jaki jest sens zabierania głosu? Produkowania bezsensownych ilości nic niewnoszącego contentu? Tak samo, skoro Win8.1, czy .NET 4.5 Wam tak bardzo przeszkadza, to po co w ogóle zabieracie głos? Krótki komentarz, że .NET jest be zdecydowanie wystarczyłby, aż nadto. Należy uznać, że projekt jest bezsęsu, przejść nad tym do porządku dziennego i zapomnieć.
Ale być może, być może gdzieś tam na szerokim stepie znajdzie się odważny śmiałek, który dysponuje czymś więcej niż Celeronem Coppermine i ATI RAGE i odważy się zapuścić te miliony poly, a jego zasilacz nawet nie zatrzeszczy. Być może doceni on nawet to, że słupy i wysięgniki nie są boxami wyciętymi alphą, tylko złożonymi bryłami, a pomiędzy szyną a podkładem znalazła swoje miejsce przekładka sprężysta. Być może, analogicznie, znajdzie się ktoś, kto ma WIN8 i kto zainstaluje edytor @HTD, bez mrugnięcia i ani jednego monitu o brakujące środowisko .NET. Niewiarygodne? Bynajmniej.
I jeszcze słowo odnośnie żargonu: dlaczego osoby techniczne związane z koleją mogą używać żargonu kolejowego, który niekoniecznie jest przyswajalny dla wszystkich użytkowników, natomiast programiści piszący programy na nasze potrzeby nie mogą używać swojego żargonu?
-
Tolein, masz cos do mnie?
Niebardzo Cie zrozumialem np. Dlaczego nie mialbym zabierac glosu?
Znaczy sie, cos rozumiem, ze mam milczec, bo przyjdzie jedyny sprawiedliwy Tolein i zrobi ze wszystkimi porzadek, jak ten lesniczy z partyzantami ;)
-
OK, ulżyło wszystkim? :)....
Ten zwrot odnosi się tylko do @Pol102? Czy może do @Ra?
Jakbyś nie wiedział @Tolein, zwrot "wszystkim" dotyczy również mnie i Mariusza. Przestań więc odgrzewać koleta jak już ostygł.
-
Dlatego wolalem przeprosic za wczasu, gdyz nie siedze w umysle HDT i nie wiem co On moze uznac za lincz, co Ty, a co uzna za lincz osobnik X. Ponadto, spozniles sie troche Tolein, gdyz z HDT sobie wszystko przez PW wyjasnilismy.
Ogolnie, to pierwotnie nie mialem zamiaru sie wypowiadac a raczej spowiadac Tobie z przeprosin HDT i zabierania glosu bo to juz jest szczyt bezczelonsci, galopujacy. Jednak dla przejrzystosci intencji, uczynilem to. KPW?
WAZNE:
Twoj post Tolein jakis taki malo merytoryczny. Moze warto zanim bedziesz pouczal innych, samemu przestrzegac nalezy. Zartowalem, bo jakas merytoryka jest w twoim poscie. No ale wyglada to tak, jesli ludzie sa za pomyslem, posty sa jak najbardziej merytoryczne. Jesli maja cos przeciw, to juz nie sa merytoryczne. Tak wyglada ocena merytoryki okiem Toleina.
-
OMG. Ja myślę, że chodzi tu wyłącznie o jedną sprawę - trzymajmy się meritum. Meritum wg mnie jest takie, że zacząłem, jako entuzjasta tworzyć jakiś soft i interesował mnie feedback, żeby zmotywować się bardziej do roboty. Wyszło jednak tak, że zaczęliśmy wszyscy coraz bardziej zbaczać z tematu, tak, że większość wątku (także z mojej strony) powinna dawno trafić na bocznicę. Zaczęło się od drobnej sprzeczki, która szybko eskalowała do flejma, a w końcu zamieniła się w kompletnie niepoważne przygadywanie. A już zupełnym WTF-em zaskoczyło mnie, że nagle mam się tłumaczyć, jakby to nagle stało się tematem dyskusji, o którym nie miałem pojęcia. Jak wyczytałem w dalszej (częściowo prywatnej dyskusji), częściowo przy innych okazjach - chyba udało mi się kogoś niechcący obrazić czy zdenerwować, na co odpowiedzi były także niezbyt zachęcające.
Wróćmy do tematu. Serio, proszę, nie mam żadnej urazy do nikogo, proszę też, żeby wszyscy zainteresowani wybaczyli mi wszelkie upierdliwości z mojej strony. Interesują mnie dwie rzeczy - zrobienie czegoś, co się przyda, oraz nauka (czysto techniczna) wyniesiona przy okazji. Nie wspomnę o dobrej zabawie podczas tworzenia i komponentach, które przydadzą mi się do innych rzeczy. Denerwuje mnie zmienianie tematu i "kręcenie afer". Utnijmy to, bo jak to ładnie mówi administracja "nic nie wnosi do tematu". Dostałem kilka merytorycznych propozycji na funkcje programu, bardzo za nie dziękuję, bo właśnie takie propozycje miałem na myśli zakładając ten wątek. Na dniach zabiorę się za realizację. Wracam właśnie z dłuższego odwyku od komputera :)
Kończąc wątek wymagań sprzętowych i programowych: zawsze jest pewien kompromis pomiędzy kosztem sprzętu i oprogramowania. Redukowanie wymagań sprzętowych podnosi znacznie koszt oprogramowania. Lub patrząc z drugiej strony - nowszy (i droższy) sprzęt obniża koszty oprogramowania. Biorąc pod uwagę, że w tym kraju koszty są bardzo ważne - łatwo się o nie posprzeczać, każdy chciałby je mieć jak najniższe. Dla mnie, jako twórcy oprogramowania największym kosztem jest czas. Dla użytkownika tego oprogramowania oczywiście największym kosztem będzie sprzęt, na którym go uruchomi. Niestety, MaSzyna za bardzo nie ma finansowania. Wszystkim brakuje kasy i czasu. Mi też, dlatego używam .NET, bo mi oszczędza czas. Dla programistów sprawa jest oczywista, że sprzęt jest tańszy od programowania. W firmach często zamiast optymalizować programy czy procesy po prostu dokupuje (unowocześnia) się sprzęt - bo tak jest po prostu taniej i szybciej, szczególnie jeśli chodzi o serwery (moja działka). Ale nie dla wszystkich jest to oczywiste, a nawet nie zawsze to jest słuszne. Czasami te decyzje są błędne, lepiej byłoby poświęcić czas na optymalizację programów. Sprawa jest kontrowersyjna, ale nie ma sensu jej wałkować. Tak krawiec kraje, jak mu materiału staje. Nie mam czasu ani pieniędzy na szukanie alternatyw dla .NET, a niektórzy potencjalni użytkownicy nie mają czasu ani pieniędzy na aktualizację swojego sprzętu i oprogramowania. Niestety wszystkim nie dogodzę dokładnie z tych samych powodów, dla których MaSzyna nie jest całkowicie ukończonym super symulatorem z setkami scenerii i perfekcyjnie odwzorowanym taborem. Mamy tyle czasu ile mamy, kasy na razie na to żadnej. Byłoby fajnie, gdyby nas ktoś zasponsorował, pewnie większość z nas chciałaby, żebyśmy mogli pracować nad tak ciekawym projektem zawodowo. Póki co robimy to hobbystycznie i nie ma się co spinać, że nie wszystko jest idealne. Nie sądzę, żeby główni programiści MaSzyny, czy główni autorzy scenerii i modeli nie mieli wystarczających umiejętności. Dla mnie to bez wyjątku geniusze. Nie mają tylko czasu i funduszy. Z tego co sobie dłubiemy w czasie wolnym jest całkiem przyzwoity efekt. Nie żałujemy poświęconego czasu, wszystko się do czegoś przydaje i jest git. Zawsze oczywiście znajdą się marudy, co będą narzekać na różne rzeczy. A to za mało poly, a to za dużo, a to że słabo chodzi na tym czy innym sprzęcie, a to że tej czy innej cechy nie ma. Gość się narobi nad infrastrukturą, to skrytykują że trawki nie ma czy tekstury brzydkie, wiecie o co chodzi. Inny dopieści grafikę, to mu powiedzą, że to jest zupełnie niepotrzebne, bo "sceneria jest bez sensu". Szkoda czasu na przekomarzanie się o te wszystkie drobiazgi, lepiej po prostu robić swoje, względnie zastanowić się, jak sobie wzajemnie pomóc dla lepszego efektu. Nikt tu nie jest konkurencją dla nikogo. Ludzie dokładają swoje cegiełki. I tak to się kręci. Dla każdego coś innego jest "najważniejsze / najpotrzebniejsze" (vide ankieta) i wszystko komuś się do czegoś przyda. Albo i nie, ale to też nie jest powód do zmartwień.
Nie kontynuujmy już tej (i podobnych) dyskusji w tym czy innych wątkach. Dajmy sobie spokój z emocjami. Skupmy się na tym, co może się przydać. Najlepsze emocje są przy robocie. Pozdrawiam z urlopu. Wkrótce trochę roboty do testów wrzucę.
-
Potrzebne by było takie coś(...)
To już chyba lepiej zrobić z nich jeden plik, a następnie skorzystać z narzędzia do usuwania duplikatów.
-
Jakoś sobie tego nie wyobrażam. Np. jest tak, że w jednym z klonów semafory nazwane są inaczej niż w pozostałych, a być może są również przesunięte.
-
Jeśli są przesunięte na scenerii to skąd jakieś narzędzie ma wiedzieć, że przykładowy wpis semafora SBL3.inc odpowiada semaforowi SBL3.inc z kolejnego pliku? Takich semaforów w pliku zapewne będzie więcej, a każdy miałby inne współrzędne i nazwę.
-
Dlatego ja bym chciał w pierwszej kolejności wydzielić do osobnego pliku te elementy, które są identyczne we wszystkich klonach. A potem zobaczyć, co zostało i zastanowić się, co się da z tym zrobić.
-
OK, wracam po dłuższej przerwie. Kolejka prac: mapa (w trakcie - optymalizacje wydajności), usuwanie duplikatów, znajdowanie tras, obliczanie rozkładów. Aktualizacja planowana na niedzielę wieczór. Prawdopodobnie uda się skończyć 2 pierwsze punkty, czyli mapę (taki lepszy STV) i usuwanie duplikatów. Znajdowanie tras to ciekawszy problem, więc pewnie pójdzie za tydzień.
-
Czym jest znajdowanie tras? Na podstawie mapy edytor sam będzie układał torowisko?
-
Docelowo obliczanie czasów przejazdu na podstawie podanych punktów pośrednich.
-
Znajdowanie tras polega na wyciągnięciu z plików scenerii tras przejazdu poszczególnych składów. Będzie to potrzebne, żeby zaznaczyć trasy przejazdu składów na mapie. No i obliczyć im rozkłady jazdy automatycznie. Zrobione to będzie tak, że zostaną "uruchomione" wszystkie eventy dla składu przestawiające zwrotnice, na zasadzie następującej:
- weź tor startowy dla składu
- uruchom eventy dla toru (czyli przestaw zwrotnice, jeśli trzeba)
- weź kolejny tor, powtórz uruchamianie eventów, jak nie ma kolejnego, zaznacz koniec
Tory, które zostaną odwiedzone w tej pętli utworzą trasę przejazdu składu.
Dość naiwny algorytm, ale zadziała dla części scenerii. Kiedy może nie zadziałać? Kiedy inny skład powinien wyzwolić eventy, które przepuszczą dany skład. Wtedy trzeba wymyślić coś lepszego, albo zaznaczyć trasę ręcznie na mapie.
To "coś lepszego" to w zasadzie osobna symulacja - puszczamy wszystkie składy na mapie i w rezultacie dostajemy ustawienia wszystkich zwrotnic dla składu. No chyba, że ktoś ma lepszy pomysł.
-
No i nie zadziała w sytuacji wyzwalaczy czasowych, przebiegów warunkowych zależnych od składu wyzwalającego i innych cudaków. ;)
-
Wyzwalacze czasowe akurat da się przejść. Gorzej z ustawianiem przebiegów wyzwalanych przez inne składy. Prawdopodobniej łatwiej będzie zaznaczanie przez twórcę poszczególnych punktów przelotowych na mapie i ewentualne podanie czasów postoju.
-
Ale wyzwalacze czasowe powiazane z eventami warunkowymi lub losowymi zmieniajace przebieg misji+ ograniczenia predkosci gdzies na szlaku + charakterystyki pojazdow. Okazac sie moze na koncu, ze w zasadzie trzeba bedzie odwzorowac symulator w wersji 2D. No ale, szczerze zycze powodzenia. Poniewaz, ja nie uruchmie tej aplikacji na swoim sprzecie, chetnie obejrzalbym film na yt, prezentujacy mozliwosci programu.
Natomiast jesli chodzi o duplikaty, to jakiego rodzaju beda usuwane (tak z ciekawosci pytam)?
To o czym pisal Ra?
-
@HTD: Nie przejmuj sie narzekaniami - poswiecasz swoj prywatny czas na ten projekt i to Ty wybierasz te narzedzia ktore Ci pozwola go zrealizowac w najkrotszym czasie.
Wymaganie .NET 4.5 nie jest kosmiczne - XP to obecnie okolo 20% komputerow, ze spadkiem rzedu 1% miesiecznie. Podobnie z 64 bitowymi maszynami.
-
otóż to... pamiętam jak kiedyś żeby odpalić DEMO DungeonKeeper'a musiałem zainstalować chyba DirectX. Wcześniej nie było to potrzebne - a tu dla jakiegoś durnego demka muszę instalować jakiś krowiasty pakiet niewiadomoczego. Bez sensu!
A teraz? DirectX jest już standardowo dorzucany do systemu, i nikt z tego powodu nie płacze... Zresztą - .net (w jakiej by niebył wersji) przecież nie powinien być traktowany jako element tego edytora. Przecież to jest platforma (pakiet), której wymagają też (lub będą wymagać) inne programy które mamy/możemy mieć na komputerze...
-
Niestety, release nowej wersji będzie przesunięty na przyszły tydzień - trafiłem na problem z optymalizacją grafiki, problem rozwiązany, ale robota trochę w polu jeszcze. Do tego jeszcze pochorowałem się i przeleżałem większość weekendu.
Co udało się zrobić - wyświetlanie i skalowanie pełnej mapy Drawinowa w czasie rzeczywistym (60FPS) - jak na pierwsze podejście z ponad 10000 odcinków jednocześnie na ekranie - nie jest źle. BTW, skalowanie w opcji rysowania CAŁEJ mapy na ekranie to najwolniejszy przypadek - każde powiększenie zmniejsza ilość rysowanych odcinków i krzywych (przyśpieszając rysowanie mapy).
Przy okazji przetestowałem wydajność przetwarzania wektorów - dla interpolacji każdego toru (łącznie z prostymi) 4 punktami pośrednimi - przejście po 10000 torów (tyle pi razy oko ma Drawinowo) zajmuje średnio 2ms. Czyli jest zapas i powinno banglać nawet na wolniejszym sprzęcie. Przy okazji te interpolacje są i tak keszowane, więc te 2ms to tylko przy przeskalowaniu okna mijają. Nie, żebym się chwalił, ale moja mapka bangla na oko kilkaset razy szybciej od STV ;) Z Rainsted nie porównuję, bo Rainsted wyświetla o wiele więcej rzeczy niż same tory. Planuję dodać też sygnalizację, ale to będą zwykłe kropy, więc nie wpłyną na wydajność. Najwolniejsze jest parsowanie, niestety - tego się raczej nie da specjalnie przyśpieszyć - to już wyłącznie kwestia samego formatu plików scenerii.
Mimo tego, że wygląda i działa obiecująco - nie wstawiam na GIT-a dopóki nie dołożę wszystkich kontrolek od nawigacji i sterowania. Czyli do weekendu pewnie, chyba, że w tygodniu uda mi się podłubać.
-
Zamiast kropek przy sygnalizacji, sugeruje jakis inny element graficzny, ktory umozliwi wizualna indentyfikacje w ktorym kierunku postawiony jest semafor. Ja zastosowalem takie palaczki (polokregi).
-
Dzięki, dobry pomysł. Może być ostatecznie nawet trójkąt. W końcu wykombinowałem jak zaznaczyć trasę składu na mapie bez pisania symulatora i ręcznego przestawiania zwrotnic. Wystarczy przejechać trasę i zapisać plik haslera. Z mijanych punktów można prosto ustalić położenie zwrotnic i wszystkie odwiedzone tory. Żeby zrobić to samo dla składu AI wystarczy tylko się do niego przesiąść i poprowadzić go ręcznie. Trasy przejazdów da się zrzucić do plików, żeby nie trzeba ich było za każdym razem ustalać. To i prawidłowo przypisana sygnalizacja umożliwi praktycznie automatyczne generowanie rozkładów.
-
Na najnowszej wersji z repo podczas ładowania scenerii pojawia się błąd ObjectDisposedException, plik EditorSyntax, linia 194.
Jest problem wydajnościowy podczas ładowania mapy. Sprawdzałem na Kaliskiej i ładuje się wieki.
-
To daj linka do tej scenerii, przetestuję co jest nie tak. Testowałem tylko na tych sceneriach co mam.
-
Jeśli chodzi o Kaliską, sceneria nie została wydana. Ładuje się ponad 10 minut przy normalnym odpaleniu do jazdy i około 2 minut w STV. Zawiera ponad 300 km toru. Jest to największy, plik jaki miałem okazję poznać. Sceneria nie jest gotowa do publikacji. Nie ma poprawnej wersji struktury katalogów i plików, (ale nie tylko to).
-
Hm, jeśli tak będą wyglądać nowe scenerie do MaSzyny (a w sumie czemu nie?), to w końcu będzie trzeba pomyśleć o binarnym formacie danych. Wg ankiety to nie był ważny aspekt, bo na obecnie wydanych sceneriach czas ładowania chociaż trochę przydługi, jest jeszcze akceptowalny i faktycznie nie ma potrzeby tego poprawiać. Co innego, jak scenerie będą się ładować ponad 10 minut. Wtedy to będzie konieczność już.
Jeśli chodzi o mój edytor, to 99% czasu trwa parsowanie pliku. Mogę to zoptymalizować, pytanie, czy to priorytetowa sprawa, czy nie za bardzo? Zamiast parsowania regexami, odpaliłbym na plikach lexer FSM, powinno być teoretycznie szybsze. O ile? Nie wiem, musiałbym najpierw napisać taki lexer i porównać osiągi. Tymczasem sama obsługa mapy jest jeszcze niedokończona, muszę poprawić na początek siatkę (przesuwa się przy powiększaniu - bug), dodać zaznaczanie obiektów i dołożyć sygnalizację. Wtedy poprawię parser.
-
A ja bede konserwa, wole, aby format tektstowy pozostal. Widze wiecej korzysci z formatu tekstowego (mozna latwo edytowac, poprawiac, zmieniac cos), niz zysk na czasie przy wczytywaniu scenerii, zwlaszcza w wyswietlaniu map w jakis edytorach.
-
Mariusz, razem jesteśmy konserwa, ale jeśli idzie w tym kierunku, widzę to tak, jak zrobiono z modelami i teksturami. Praca i składanie na txt (pliki scn, scm, crt i t.p.), tga i t3d. Natomiast wydawanie paczki to e3d, dds i jak ktoś chce niech zrobi binarkę do pozostałych wpisów. Tak jak obecnie pliki źródłowe powinny być dostępne.
-
Binarny format zapisu danych już istnieje - nazywa się RSF i jest wykorzystywany przez edytor Rainsted. Opracowywanie nowego raczej nie ma sensu, a widocznie jest jakiś powód, dla którego Ra nie wykorzystuje go w EU07.EXE.
Poza tym, błędy na sceneriach są stare jak świat. Obecnie można je w łatwy sposób naprawić lub przynajmniej namierzyć problem. Zaś analogia do modeli nie ma sensu, bo T3D modyfikowało się zawsze w bardzo nieznacznym stopniu.
-
Gdyby nie to ze T3D jest formatem tekstowym to masabpoprawek na repo nie zostalaby wprowadzona. To naprawde przystepny format, tylko trzeba go poznac.
-
Błąd występuje też na TD.
Plik: EditorSyntax.cs w linii 194.
-
Binarny format zapisu danych już istnieje - nazywa się RSF i jest wykorzystywany przez edytor Rainsted. Opracowywanie nowego raczej nie ma sensu, a widocznie jest jakiś powód, dla którego Ra nie wykorzystuje go w EU07.EXE.
RSF został zaprojektowany tak, że zawiera wiele informacji, które nie są nijak potrzebne przy wykonywaniu scenerii (symek), a umożliwiają na zupełnie inną jakość pracy w edytorze. Dlatego nie jestem pewien, czy to jest najbardziej optymalne rozwiązanie. A zmiana formatu zapisu scenerii nie zrobiona najlepiej jak się da nie jest rozsądnym posunięciem, biorąc pod uwagę jak często zmienia się w MaSzynie format zapisu scenerii. ;-)
Co do formatu binarnego ogólnie, to problemem jest brak odpowiednich narzędzi. Czy ktoś narzeka, że format z 3dsa jest binarny? Nie, bo razem z formatem jest cały edytor. W przypadku E3D oraz ew. binarnego formatu scenerii, czy nawet jakichś danych przechowywanych w pliku TGA (nie wiem, czy takie są?), nie ma łatwiej możliwości edycji, ale jest to wina braku skryptów do importu/exportu (E3D) oraz jakiegoś prostego narzędzia, niech to będzie choćby nakładka na notepada++, czy program zewnętrzny, pozwalający na wczytanie pliku binarnego, rozpoznanie jego struktury i wyświetlenie zawartości. Nie powiesz mi chyba, @Banita-m, że używasz notatnika dlatego, że jest to Twój ulubiony program służący do edycji. Trudno też oczekiwać, że ktoś będzie współcześnie pisał scenerię wyłącznie w notatniku.
-
Nie powiem. Ogolnie wyrazilem swoje zdanie. Jesli masz przeciwne, to sie nie porozumiemy. Kazda opcja ma swoje wady i zalety. Ja widze wiecej zalet jak na razie w formacie tekstowym. Jesli format binarny przyspieszalby znacznie symulacje a nie samo wczytywanie, to wtedy, przejde na twoja strone, nawet pomimo braku narzedzi.
-
Błąd występuje też na TD.
Plik: EditorSyntax.cs w linii 194.
Wypada zacytować tę linijkę 194. Trzeba pamiętać, że plik ulega ciągłej modyfikacji i treść linijki 194 może nie być jednakowa u wszystkich. Binarny format zapisu danych już istnieje - nazywa się RSF i jest wykorzystywany przez edytor Rainsted. Opracowywanie nowego raczej nie ma sensu, a widocznie jest jakiś powód, dla którego Ra nie wykorzystuje go w EU07.EXE.
To tak, jakby nie było binarki.
-
Tu nie ma stron, nie walczymy o zwycięstwo, co najwyżej o przegarną, powiem więcej, jeśli nie uda nam się wypracować konsensusu i zjednoczyć, to nic z tego nie będzie (nie mówię konkretnie o tym wątku, ale o dużo szerzej, w kontekście ogólnego rozwoju symulatora).
Dodam tylko, że ja nie lobbuje za wprowadzeniem binarnego formatu pliku scenerii, wytykam tylko luki w logice pozostałych, którzy zabrali głos.
-
No widzisz, powiadasz brak logiki. Upraszczasz caloksztalt przetwarzania danych do wygnodnych Ci przykladow. Ja podam inny przyklad, Html zostal jako metajezyk, czyli tekstowy i raczej narzekajacych nie ma. Przeciez cale forum nasze mogloby byc binarka, caly internet. Konsenus widze, tekstowo-binarny. Ogolnie nie chce proawadzic akademickiej dyskusji, jesli format opracujesz/ecie ja sie dostosuje, podobnie jak Ty teraz do formatu tekstowego w tej chwili. Ja np podam takie jedno z miliona zagrozen. Jesli powstanie konwerter teraz-binarka, to zdarzaja sie dziwne bledy w sceneriach np przesyl parametrow do plikow includowanych. Jakis parametr wymaga liczby, a podany jest string. Jesli konwerter stringa potraktuje jako zero, to juz bedzie to do niewylapania tak szybko. I w ogole format tekstowy daje szersze mozliwosci edycji/debugowania. No, ale ja sie nie upieram.
-
Ja też nie jestem całkowitym przeciwnikiem zapisu binarnego, ale wydaje mi się, że w obecnych warunkach to jest trudne do wykonania a są rzeczy ważniejsze. Poza tym, niesie to za sobą duże ryzyko, a korzyści widać niewiele. Tak, jak Tolein wspomniał, nie mamy żadnego edytora. Poza tym, ten edytor ma być tym samym co zapis w notatniku, tylko w pięknych tabelkach? Może jak już coś takiego robić, to trzeba pomyśleć o jakimś graficznym zapisie (w stylu języka G w LabView)?
Co do RSF, to Toleinie, możesz mieć rację. Ale chyba jest tylko jeden człowiek, który jednoznacznie jest w stanie stwierdzić, czy RSF można wykorzystać w MaSzynie, czy nie.
Zresztą nasze rozmowy chyba do niczego nie prowadzą, bo jeśli ktoś podejmie się stworzenia zapisu binarnego plików scenerii (na przykład Ra), to raczej nie będzie się sugerował tym wątkiem. Więc możemy sobie tutaj rekreacyjnie coś popisać, to i tak do niczego nie prowadzi...
-
Aaa, jeszcze jedno dodam, ogolnie tez bylem i jestem krytycznie nastawiony do formatu e3d i dds. Spodziewalem sie balaganu po wprowadzeniu tych formatow i czesciowo sie to sprawdzilo. Gdyby dodatki byly pozbawione bledow, to ok. Teraz jest takie rozdwojenie jazni. Mamy paczke e3d/dds, a i tak wszyscy grzebacze musza pobierac t3d/tga. O bledach/nieporzumieniach szerzej o e3d, nie chce mi sie rozpisywac. EOT w temacie formatubinarnego z mojej strony.
-
Co do problemu z edycją plików binarnych - to zniknie, jak będzie komplet narzędzi obsługujących te pliki. Jedno z nich rozwijam. Tyle. Co do tego jaki binarny format - mniejsza o to. Jakikolwiek. Będę miał więcej czasu - po prostu zrobię, dam do testów i się zobaczy. Dostanę dokumentację od RSF, to zrobię obsługę RSF. Będzie ok, przyjmie się, nie będzie ok, to się nie przyjmie i tyle.
Co do TGA, nie widzę powodu, dla którego ktoś musiałby pobierać TGA. Znaczy się jak, w SCN jawne rozszerzenia? To przed wydaniem PC maszynowo wyciąć we wszystkich plikach i po krzyku. Jeśli chodzi o T3D i E3D - to już sam exe robi konwersję. T3D jest z tego co wiem jedynie dla twórców do edycji. Fajnie jak wyjdzie z tym osobna paczka, ale paczka dla użytkowników powinna mieć tylko E3D. Jeśli chodzi o TGA - to powinna być paczka opcjonalna dla użytkowników. Powinno się to nazywać jakoś w stylu "paczka HD".
Ogólnie, zamiast się spierać na temat wymagań symka, lepiej po prostu dać dwie wersje - SD i HD. Roboty z tym praktycznie nie ma żadnej - wystarczy, że jest względy porządek w plikach. Do SD idą tekstury DDS i opcjonalnie byłoby fajnie, jakby też modele miały 2 wersje (z różną ilością poly). Ale czy nie zeszliśmy za bardzo z tematu? Żeby wrócić do tematu - ScnEdit będzie docelowo porządkował pliki (i np usuwał duple), może też robić wszystkie potrzebne konwersje. Oczywiście potrzeba troszkę czasu, żeby wszystko zrobić, ale będzie. I nie ma stresu, finalna wersja pójdzie pod XP.
Ogólnie dostałem sporo dobrych pomysłów na funkcje, wszystko będzie. Zabawa na pół roku, ale cóż, takie życie, niestety cisną mnie w robocie teraz. Będzie trochę luzu czy urlop, to robota znów ruszy z kopyta. A mam trochę zaległego urlopu.
Co do zmian w exe, co by pliki binarne wciągał - jak czytam o "niedasiach" to mnie aż ponosi. Wszystko się da, wszelkie przeszkody to wymówki. No bez żartów. Chodzi tylko i wyłącznie o czas. Trzeba będzie nad tym po prostu trochę posiedzieć i podłubać. Wg mnie warto. W porównaniu z czasem powstawania jednej scenerii to robota nad resztą rzeczy idzie szybciutko i generalnie damy radę. Sam się przyłączę. Jeszcze nie, bo raz - mam co robić, dwa, odnosząc się do legendarnego posta Rewizora - nie mam na chwilę obecną wystarczającej ilości czasu. Ale tak tego nie zostawię. Zmieniam robotę i czas na MaSzynę musi się znaleźć. Bo co to za życie jak nie ma czasu na zabawę? :)
-
Aaa, jeszcze jedno dodam, ogolnie tez bylem i jestem krytycznie nastawiony do formatu e3d i dds.
Na moim dysku paczka DDS/E3D zajmuje 5 GB, repo z TGA/T3D zajmuje niespełna 22 GB. Niewątpliwie czuć tę różnicę. Zauważyłem też, że format E3D ładuje się szybciej niż T3D. W przypadku wielopłaszczyznowego terenu na scenerii MOP zauważyłem znaczny wzrost FPS po eksporcie terenu do E3D. Z drugiej strony nieraz chciałem na szybko edytować wpis w T3D w tej pierwszej paczce i był problem. Mariuszu, to że dostrzegasz pewne minusy tych formatów wynika z tego, że przyczyniają się one do opóźnień w publikacji kolejnych nakładek bądź całych paczek (trzeba dokonać konwersji). Brak jest odpowiednich narzędzi, które masowo dokonają transformacji, ale największym problemem jest to, że nie ma rąk do pracy, a ci co coś robili dają sobie spokój, bo koncepcja rozwoju, o ile słuszna, zaczyna być uciążliwa nawet dla deweloperów ze względu na duży stopień skomplikowania. Świetnym przykładem są niekończące się poprawki kiepskich scenerii z paczki głównej.
-
Banita, porównanie do htmla średnio trafione, tak mi się wydaje. Bo jeśli Ty chcesz grać w grę "przytaczanie w dyskursie argumentów ad absurdum", to ja również mogę w tę grę grać, także służę uprzejmie i odpowiadam pytaniem: tekstury też powinniśmy mieć zapisywane w formacie tekstowym, bo chcesz mieć możliwość ich edycji w notatniku? Czy może jednak potrafisz pogodzić się z formatem bitowym i edycją przy pomocy dedykowanych programów?
Nie wiem dlaczego traktujesz mnie z marszu jako wroga. Jak już wspomniałem, nie lobbuję na tym etapie za żadną z opcji, próbuję wprowadzić normalizatorski głos w dyskursie. Masz z tym problem? get real.
A E3D będę bronił, bo format nie jest głupi, stał się natomiast ofiarą tego, że nie ma ŻADNYCH narzędzi do edycji, importu czy eksportu jego plików. Czyja to jest wina? Ry, że nie zrobił wszystkiego (idąc tym tropem, dawno powinien zrobić scenerię CAŁA_POLSKA, skoro już się zabrał za edytor).
-
Ja Cie nie traktuje jak wroga. Jesli odniosles takie wrazenie, to sorry. Porownanie z html, nietrafione, zgadza sie, bo tu chodzi o maszyne, a tam o internet. Kazde porownanie jest nietrafione np maszyna quiek. Ogolnie tez mnie denerwuje ten html, bo strony by sie szybiej wczytywaly. No ale kurcze, mial byc EOT :) Zrobicie sobie, co tam bedziecie chcieli. Jesli chodzi o e3d, to nie da sie nich edytowac ponoc, tzn, tam juz jest cos policzone, czego nie da sie odtworzyc stanu pierwotnego. Wziales to pod uwage?A czy wiedziales o tym? A czy ja mam problem, raczej nie, moze Ty masz? Ja tylko odpowiedzialem Tobie, bo sie do mnie imiennie zwrociles.
-
A czy Ty czytałeś specyfikację formatu E3D? Czy opierasz się na domysłach, pogłoskach, plotkach, etc.? Jeśli to drugie, to polecam lekturę.
Podstawowa różnica między T3D i E3D jest prosta: w E3D nie trzeba parsować (wczytujemy bit po bicie i mamy pełną kontrolę nad tym, co w którym bicie jest), a współrzędne wierzchołków zajmują 32 bajty, podczas kiedy jeden znak w T3D zajmuje jeden bajt, także jedna współrzędna zajmuje 1-8 bajtów, a jeden wierzchołek, odpowiednio, 8-64. ;-)
-
Sluchaj, skad wiesz od kogo to wiem? Jesli osoba developer mi mowi, ze sa tam juz policzone wektory i nie da sie w pelni odtworzyc stanu pierwotnego t3d (nie wszystkie parametry), to ja mu wierze. Czyli edycja jest mozliwa, ale niepelna. Mowila to soba, ktora zrobila kiedys edytor do e3d.
-
Proszę, nie rozśmieszaj mnie. Po pierwsze, nie patrzysz na sprawę obiektywnie, tylko z punktu widzenia formatu T3D, jakby był on jakimś absolutnym punktem odniesienia. Po drugie, czy mam rozumieć, że chcesz wektory normalnie (cieniowania, bo zapewne o to chodzi) edytować w notatniku? Czy masz problem z ich konwersją na maski cieniowania? Bo z tego co wiem, to zarówno 3DS, jak i każdy inny edytor, przyjmie bez problemu wierzchołki z policzonymi dla nich wektorami normalnymi. A modele się edytuje właśnie w programach do edycji tego, a nie w notatniku.
-
Na pewno nie da się przeliczyć wektorów kontrolnych na grupy wygładzania?
-
To po co edytor? Jest tak format graficzny w jakims programie, t3d, e3d. Tak pozostanie pewno. A, ze format e3d ma swoje zalety, to wiem, ale patrzac na caloksztalt w maszynie, to mnie juz to nie przekonuje. Jesli uwazasz, ze jest cud malina i nie ma z caloksztaltem wprowadzenia problemu, to twoje zdanie, ktore sznuje, ale Ty tez mnie uszanuj.
-
Co do braku wczytywania RSF przez EU07.EXE, to po prostu nie jest priorytetem. Nie widziałem wielu skarg na prędkość wczytywania, co by było głównym argumentem za użyciem RSF. Druga kwestia jest taka, że RSF nie jest jeszcze "kompletnym pojemnikiem" na scenerie (np. nie da się w nim zapisać eventów). Poza tym, co zrobić z plikami INC? Wczytywać je tekstowo, czy sparsować, podstawić argumenty aktualne pod formalne i dorzucić binarnie do RSF? Jeśli INC miały by iść binarnie, to musiała by być oddzielna wersja RSF do edycji i oddzielna do wczytywania. Jeśli INC jednak tekstowo, to spowolnią wczytywanie (no i trzeba przygotować generowanie argumentów dla INC z wartości binarnych). Za dużo niewiadomych, za mała korzyść praktyczna.
Natomiast przymierzam się też do tego, żeby z EU07.EXE zrobić wizualizację do edytora. Wtedy aktualizacja RSF w edytorze była by wysyłana do symulacji, która by się wtedy uaktualniała. Być może działało by to też w drugą stronę. To też nie jest priorytet, bo ja nie mam wewnętrznej presji na edycję 3D, a do rozwiązania w edytorze pozostaje jeszcze masa problemów topologiczno-geometrycznych, jak wyginanie rozjazdów oraz łuki koszowe.
Alternatywnym formatem binarnym było by zrzucenie wewnętrznych struktur do pliku. Taki plik byłby wczytywalny tylką tą wersją EXE, która go zapisała (być może wyjątkowo by się dało wczytać jakąś poprzednią/następną). Jednak ze względu na częste modyfikacje struktur danych raczej nie będzie zgodności pomiędzy różnymi wersjami. Prędkość wczytywania scenerii była by maksymalna możliwa, jedynie tylko E3D, dźwięki i tekstury musiały by być doczytane z osobnych plików. Również wtórna edycja plików nie miała by sensu.
Przed reorganizacją wczytywania najbardziej powstrzymuje mnie brak kompletnej koncepcji obsługi komórek. Najlepiej by było, jakby każda komórka scenerii była zapisana w osobnym pliku, możliwym do wczytania w trakcie symulacji i wyrzucenia z pamięci, gdy stanie się zbędna. Komórki można by wczytywać zarówno z RSF (ze zbinaryzowaną zawartością INC), jak i z wspomnianego formatu wewnętrznego. Ale zbyt wiele jeszcze kwestii zostaje do uszczegółowienia, priorytety wydają się być inne, poza tym nadal ciągną się podstawowe braki w podstawowych elementach (podsypki rozjazdów, wysięgniki z przesuwalnym uchwytem drutu, sposób teksturowania pól i zapełniania zabudowań, żeby wyglądały realistycznie).
-
To po co edytor?
Rozdzielmy dwie rzeczy. Zaletą T3D jest to, że można otworzyć go w notatniku, zmienić jakąś jedną rzecz (choćby parametry odległości wyświetlania submodeli), zapisać i gotowe. Jeśli natomiast chcemy coś zmieniać w samej geometrii modelu, to odpalamy edytor 3DSMax, wczytujemy model z T3D, ewentualnie eksportujemy go do innego edytora, w którym działamy (np. Blender).
Teraz dla E3D nie mamy ani jednej możliwości, ani drugiej. Skrypty dla importu/exportu modelu do 3DSa (czy np. Blendera), dają nam co najmniej taką samą funkcjonalność. Natomiast mogą dawać nam dużo większą funkcjonalność (mogą, bo funkcjonalność trzeba oczywiście uwzględnić w skryptach), taką jak np. indeksowanie submodeli (mniejszy rozmiar pliku), czy inne fajne rzeczy. Same wierzchołki normalnie też można eksportować (jest to w dużym skrócie daleko bardziej rozwinięta forma opisywania cieniowania bryły, niż maski cieniowania (lub, jak to ładnie Zając nazwał, grupy wygładzania). Dodatkowy edytor plików binarnych, o którym pisałem, miałby dawać tę samą funkcjonalność co notatnik w przypadku T3D, tzn. otwieramy plik, zmieniamy jakąś jedną rzecz (choćby parametry odległości wyświetlania submodeli), zapisujemy i gotowe. Mam nadzieję, że tym razem wyraziłem się jasno.
Na pewno nie da się przeliczyć wektorów kontrolnych na grupy wygładzania?
Należałoby chyba sprawdzić, czy wektory w wierzchołkach wspólnych dla dwóch trójkątów są identyczne, jeśli tak, to stosujemy tę samą maskę.
Jeszcze słowo do @Benka:
[...] największym problemem jest to, że nie ma rąk do pracy, a ci co coś robili dają sobie spokój, bo koncepcja rozwoju, o ile słuszna, zaczyna być uciążliwa nawet dla deweloperów ze względu na duży stopień skomplikowania.
@Benku, może należy pogodzić się z tym, że renesans przeminął, czas Leonardów da Vincich też się skończył i czas działać w bardziej zorganizowanych grupach, ze wskazaniem na specjalizację i zawężeniem pola kompetencji pojedynczego użytkownika? Symulator robi się coraz bardziej skomplikowany, jest to fakt, trudno się z nim nie zgodzić, ale wg mnie jest to zmiana pozytywna. Teraz trzeba podjąć próbę adaptacji społeczności twórców, odnalezienia się w nowej sytuacji. Trzeba znaleźć ludzi zdeterminowanych, chętnych do współpracy, nauczyć ich małego kawałka roboty i być może uda się to wszystko pchnąć do przodu.
-
Dodatkowy edytor plików binarnych, o którym pisałem, miałby dawać tę samą funkcjonalność co notatnik w przypadku T3D, tzn. otwieramy plik, zmieniamy jakąś jedną rzecz (choćby parametry odległości wyświetlania submodeli), zapisujemy i gotowe.
Od wielu lat noszę się z pomysłem stworzenia edytora plików binarnych, w którym za pomocą plików tekstowych (np. YAML) można by definiować znaczenie poszczególnych pól oraz zależności (np. że liczbę trzeba potraktować jako długość pola danych). Ale jakoś dotychczas nie było wyraźnego impulsu, by to zrobić. Być może takie edytory już istnieją. Ja potrzebuję takiego edytora również do edycji plików DBF (w celach nie związanych z MaSzyną), bo nagłówki DBF nie zawsze określają typ danych prawidłowo, a do tego potrzebowałbym sobie opisać poszczególne pola bazy danych i skonfigurować zależności.
Co do wygładzania, to obecnie istnieje już możliwość wczytywania T3D, który zamiast grup wygładzania będzie miał jawnie podane wektory normalne. Jest też możliwość zapisywania w E3D masek wygładzania poszczególnych wierzchołków, co zwiększy rozmiar pliku o ok. 3% — dotychczas chyba nikt nie sugerował takiej potrzeby.
-
Znalem fachowcow, ktorzy w notatniku robili dosyc zaawansowane modyfikacje modeli, ale to dygresja. Ja mysle, ze raczej akcent stawialbym, nie na to, ze jest brak edytora dla e3d, tylko, na czesta potrzebe modyfikowania czegos w maszynie. Same czeste modyfikacje rodza w sobie problemy, nawet import, ekport z/do maszyny. Dodatkowe zrodla problemow, to generowanie e3d z parametrami przez rozne osoby, niekoniecznie prawidlowo. Pozniej sa problemy typu, scignij dany plik t3d, usun e3d i ponownie wygeneruj e3d. W Kazdym razie, jako, ze dodatki sa w znacznej mierze zabugowane (wymysl temat, a znajde bledy), to potrzeba jest ich nieustannna likwidacja. Na ogol najlatwiej, modyfikuje sie tekstowo i zrodlo i koncowy efekt jest w jednym. No ale, sam juz nie wiem, moze przeadzam z problemami z e3d. Jesli wiekszosc z nas na forum jest grzebaczami, to i tak posluguja sie t3d (a moze sie myle)
-
Co do wygładzania, to obecnie istnieje już możliwość wczytywania T3D, który zamiast grup wygładzania będzie miał jawnie podane wektory normalne. Jest też możliwość zapisywania w E3D masek wygładzania poszczególnych wierzchołków, co zwiększy rozmiar pliku o ok. 3% — dotychczas chyba nikt nie sugerował takiej potrzeby.
Na dobrą sprawę, @Banita nie potwierdził nawet, czy moje przypuszczenie było słuszne i czy dobrze zidentyfikowałem problem, do którego się odnosił. Cieniowanie nie wydaje mi się wielkim (popularnym) problemem. Nie wiem, czy mamy aktywnych modelarzy, którzy świadomie zmieniają te wektory, próbując osiągnąć określony efekt, ale zakładam, że raczej nie. Bardziej martwi mnie fakt, że E3D oferuje pewne formy optymalizacji modelu już na etapie jego tworzenia, których nikt nie wykorzystuje (zakładam, że moduł konwersji T3D -> E3D zaimplementowany w "exe" takich funkcjonalności nie oferuje), bo (a) nie wiedzą, że można (b) nie wiedzą jak (c) nie ma narzędzia, więc wszystko i tak leci przez T3D, gdzie taka optymalizacja idzie w diabły.
Przy czym jest to kolejny przykład na to, że symulator się rozwija i (gdybyśmy mieli takie narzędzia to) potrzebna jest (by była) jedna osoba, która opanowałaby temat na wystarczającym poziomie i umiała go przekazać innym modelarzom (na zasadzie jakiegoś wykładu, prezentacji, szkolenia).
-
Ja sie wypowiedzialem, co slyszalem pare lat temu. Jesli piszesz mi o narzedziach/edytorach do e3d, ze jest ich brak, to nie wnikalem jak czesto i komu i co bedzie potrzeba zmieniac, czego zmienic sie ponoc nie dalo i o tym napisalem. Ponadto, nie pamietalem dokladnie o co chodzi, tzn, czego sie nie dalo wykonac. Moze z tym e3d za daleko zabrnalem, ale to nie oznacza, ze nie dostrzegam wad i ze stalem sie zwolennikiem formatu bianarnego do scenerii :) No i mozesz miec racje z tymi optymalizacjami.
-
Format E3D jest obecnie problematyczny o tyle, że mało kto potrafi coś z nim zrobić (np. poprawić maksymalną widoczność submodeli). Drugim problemem są błędy w T3D, z których E3D powstał. Np. jeśli w T3D nie jest zaznaczona animacja submodelu, to podczas zapisu do E3D zostanie wykonana optymalizacja, która uniemożliwi łatwe przywrócenie animacji (bo zostaną przeliczone wierzchołki). Dzięki optymalizacji mamy trochę lepszy FPS. Problemu tego by nie było, gdyby w T3D były prawidłowo oznaczone animacje oraz zresetowane transformy tam, gdzie animacje potrzebne nie są. Ale tak nie jest, a oczekiwanie od twórców, że będą robić optymalny T3D, jest zbyt dużym wymaganiem. W związku z tym po każdej takiej poprawce w T3D trzeba wygenerować E3D.
Innym problemem z E3D jest to, że zawiera on dodatkowe informacje, nieobecne w T3D. Jest to np. rozdzielenie submodeli na fazy przezroczystych i nieprzezroczystych, które zależne jest od przezroczystości w użytych teksturach. Również animacje są oznaczane na podstawie MMD i rozpoznanych nazw submodeli, aby zachować zgodność ze starymi T3D, które wszędzie miały brak animacji. Konwertując E3D na T3D gubimy część tych informacji, a z kolei E3D nie zrobi się prawidłowo bez dostępu do nich.
Pytanie moje jest, czy coś by to ułatwiło, gdyby istniał konwerter formatu E3D na odpowiadający mu w pełni format tekstowy?
-
Byloby to spore ulatwienie. Teraz zdarza sie ze model nie chce sie wczytac z e3d. Poszukwanie bledu w zrodlowym t3d jest chyba prawie niemozliwe.
-
Dostanę dokumentację od RSF, to zrobię obsługę RSF.
Nie wiem czy takowa istnieje w formie jakiej byś oczekiwał - ale popaczaj tutaj: http://rainsted.com/wiki/index.php?title=Specjalna:Szukaj&search=rsf
-
To się jeszcze dogadamy odnośnie tego. Może wspólnie coś zrobimy, ale póki co odkładam to na później, jak skończę podstawową funkcjonalność, czyli pełne wyszukiwanie obiektów na mapie i automatyczne przypisywanie. To będzie można nazwać wersją 1.0, po ukończeniu pomyślimy, czy dodawać kolejne funkcje, czy może dodać obsługę RSF najpierw.
Nie mam tylko pewności, czy zmiana parsera plików tekstowych nie powinna pójść jako priorytetowa, jeśli na niektórych sceneriach to się sypie teraz, albo działa zbyt wolno. Tym bardziej, że na razie mam tylko parser torów zrobiony, a będzie potrzebny jeszcze od trakcji i sygnalizacji. Jak implementacja lexera FSM będzie dużo szybsza i pewniejsza (a zgaduję, że będzie) - to może szkoda czasu robić 2 razy to samo i od razu zrobić ten lexer. Pliki tekstowe nie zostaną pewnie szybko zastąpione innym formatem, a nawet gdyby miały być, to i tak będzie potrzebny konwerter z obecnego formatu.
-
Przy czym jest to kolejny przykład na to, że symulator się rozwija i (gdybyśmy mieli takie narzędzia to) potrzebna jest (by była) jedna osoba, która opanowałaby temat na wystarczającym poziomie i umiała go przekazać innym modelarzom (na zasadzie jakiegoś wykładu, prezentacji, szkolenia).
Oceniam to teraz, jako najważniejsze zadanie. Może nie jestem dość pilny w nauce, ale teraz trudno o naukę w tak zorganizowanym forum. Widzę też pewien dystans do lamerskich pytań, co nie ułatwia współpracy. Z drugiej strony wyobrażałem sobie, że projekt symulatora, będzie do ogarnięcia dla każdego, kto zechce stworzyć dodatki, mapy i tym podobne rzeczy. Być może problem tkwi w niechęci do nieznanego, a możliwości poznawcze są z różnych względów ograniczone. Takie jest moje zdanie, może nie odosobnione.
-
(...) Z drugiej strony wyobrażałem sobie, że projekt symulatora, będzie do ogarnięcia dla każdego, kto zechce stworzyć dodatki, mapy i tym podobne rzeczy.
Ja widzę inny problem - symulator się zmienia. Trudno to opisać i udokumentować. To jakby 2 osobne rzeczy - obecna forma, i to co jest planowane i w tej chwili powstaje. Można to rozbić ten problem na 2 części:
1. Pełna, wyczerpująca dokumentacja struktur danych symulatora (wydana wersja bieżąca)
2. Pełna, wyczerpująca dokumentacja planowanej nowej wersji, włącznie z rzeczami do zrobienia, których jeszcze nie ma, z rozpisaniem zadań i zależności
Co do punktu 1 - pewnie zdania będą podzielone, czy jest potrzeba zrobienia tego i kto miałby to zrobić.
Co do punktu 2 - warto o tym pomyśleć chociaż i zastanowić się. Zamiast rozwijać nowe rzeczy "na żywioł" można by wprowadzić jakąś organizację. Żeby nie męczyć się później z formatami, w których coś brakuje, coś łamie kompatybilność itd. Można wziąć pod uwagę wszystkie rzeczy, które wyniknęły podczas rozwoju dotychczasowych wersji. Można zaprojektować przyszłą wersję tak, żeby była bardziej odporna na przyszłe zmiany i nowości. Właściwy projekt (a właściwie metody tworzenia projektu) mógłby zaoszczędzić mnóstwo czasu i umożliwić łatwiejszą współpracę większego zespołu ludzi. API i modularna konstrukcja pozwoliłyby pracować nad różnymi rzeczami równolegle. Mało tego, szkicowa dokumentacja projektu, zanim jeszcze zacznie być realizowany pozwoliłaby wszystkim zainteresowanym zgłaszać swoje uwagi, może byłby doskonalszy i bardziej kompletny. Z doświadczenia wiem też, że tworzenie rzeczy zgodnie z dokumentacją jest bez porównania szybsze i prostsze. Tu nawet nie trzeba nauki, po prostu bierzesz dokumentację i zaczynasz tworzyć. Nie musisz się co chwila pytać jak działa to czy tamto, bo masz to opisane. Osoba, która stworzyła jakąś funkcjonalność też nie musi tego co chwila komuś tłumaczyć - robi dokumentację i cześć.
-
a może by Ci chłopaki wystawili kawałek źródeł, który w obecnym exe odpowiada za parsowanie plików scenerii? W sumie to chyba najlepiej by było zrobić z tego jakąś bibliotekę - której mogłyby używać zarówno exe symulatora, jak i wszelkiej maści edytory itp.
-
Nie widzę problemu z używaniem plików tekstowych i binarnych. W paczce całościowej powinny być binarki, żeby symulator lepiej działał, a pliki do modyfikacji powinny być dostępne jako osobne paczki. Programiści zwykle pracują z plikami tekstowymi, a użytkownicy aplikacji z gotowymi plikami wykonywalnymi, więc może być analogicznie w przypadku scenerii, modeli i tak dalej. Na pewno w takim przypadku ułatwieniem byłby program z przyciskiem "kompiluj", żeby wyprodukować plik binarny. I tu mechanizm aktualizacji stworzony przez Ra miałby co robić, a mianowicie do repo wrzucałoby się opisaną paczkę (obiekt + nr wersji obiektu + na której wersji EXE działa), klik "aktualizuj" i działa. Potrzebny jest imperatyw, który to ruszy. Nie trzeba od razu porzucać jednego formatu pliku i używać drugiego, tylko wydzielić środowisko deweloperskie (tworzenie obiektów) od produkcyjnego (gotowa MaSzyna do symulowania).
-
Wracam po dłuższej przerwie spowodowanej złym stanem zdrowia, mam nadzieję, że na dobre. Wrzuciłem na GIT-a nową wersję z użyciem lexera FSM.
Co to daje?
Ano jest ze 100x szybsze i pewniejsze od przetwarzania plików scenerii za pomocą wyrażeń regularnych. Lexer (od Lexical Analyser) FSM (od Finite State Machine) to komponent używany przez wszystkie profesjonalne narzędzia korzystające z plików tekstowych napisanych wg składni jakiegoś języka.
Na wejściu przyjmuje plik tekstowy, na wyjściu zbiór binarnych tokenów, które jednoznacznie odwzorowują dane zawarte w pliku.
Gdyby MaSzyna używała podobnie zbudowanego lexera FSM, scenerie ładowałyby się kilka sekund, zamiast kilku minut ;)
Oczywiście ScnEdit nie ładuje scenerii w całości, ani nie optymalizuje procesu ładowania i przetwarzania do końca. Pozostawiłem pewien kompromis pomiędzy wydajnością programu a czytelnością kodu. Wewnątrz struktury są przetwarzane do różnych postaci, co można by ewentualnie skrócić dla jeszcze większego przyśpieszenia, ale przy czasach ładowania danych rzędu pojedynczych sekund nie jest to krytyczne.
Przetestowane na wszystkich mapach z najnowszej paczki developerskiej ;) Wszystkie mapy ładują się poprawnie i szybko.
UWAGA: Nazywanie i sortowanie torów NIE BĘDZIE DZIAŁAĆ W TEJ WERSJI! Proszę nie używać tej funkcji, bo może ona uszkodzić pliki scenerii! Problem zostanie rozwiązany razem z następną wersją.
Do poprawienia zostały jeszcze 2 pomniejsze bugi: skrzyżowania na mapie wyświetlane są innym kolorem niż drogi (nie mam pojęcia czemu), siatka mapy ma niewłaściwe przesunięcie.
Do zrobienia zostało zaznaczanie torów na mapie i wyświetlanie wskaźników.
Niestety popsuł mi się komp, więc siłą rzeczy prace pójdą opornie, bo w między czasie będę musiał oddać do do serwisu i skonfigurować nowe środowisko do pracy na starym kompie.
-
Ja również zetknąłem się ostatnio z problemem wydajności wczytywania scenerii. Na potrzeby modernizacji Krewetkowa piszę niewielki program, pomagający mi w wielu sprawach podczas edycji scenerii. Podczas uruchamiania program wczytuje do tablicy obiektów prawie całą zawartość plików scn i scm (oprócz pociągów). Jakoś nie zauważyłem, żeby ten program uruchamiał się znacznie wolniej niż inne moje aplikacje, niewczytujące żadnych plików. Rozumiem, że symulator musi jeszcze wczytać modele, tekstury itd., ale bez przesady. Symulator Krewetkowo wczytuje w pół minuty. Najbardziej niezrozumiałe jest dla mnie kilkusekundowe zawieszenie się Maszyny po wypisaniu "Loading - texture: textures/grassgreen1". Ile może zajmować wczytanie wierzchołków trójkątów z pliku tekstowego... Jak dla mnie, nie trzeba wprowadzać binarnego formatu scenerii, wystarczy zoptymalizować wczytywanie plików tekstowych. Dodam, że nie korzystam z żadnych nowoczesnych technologii. Pliki wczytuję w pętli, Double.Parse [metoda z. NET] konwertuję na liczbę, za pomocą switch sprawdzam z jakim typem obiektu mam do czynienia (tor, trójkąt itd). Proste i szybkie.
-
Ja również zetknąłem się ostatnio z problemem wydajności wczytywania scenerii.
Używasz paczki DDS (08.13 + ewentualne patche) czy najnowszej, tj. 15.02, która jest w wersji TGA? Wersja TGA wczytuje się dłużej, a na niektórych sceneriach długość ładowania pliku jest o wiele większa w porównaniu do tekstur w formacie DDS. Tekstury TGA ważą więcej od DDSów, więc czas ich ładowania wzrasta.
Symulator Krewetkowo wczytuje w pół minuty. Najbardziej niezrozumiałe jest dla mnie kilkusekundowe zawieszenie się Maszyny po wypisaniu "Loading - texture: textures/grassgreen1".
Pytanie, ile na tej scenerii jest elementów czy obiektów i jaka ta sceneria jest duża? Ja przykładowo kiedyś zacząłem coś grzebać przy jakiejś starej scenerii, która ładowała się dosłownie w 10 sekund. Tylko, że na tej scenerii nic nie było, a poza tym była bardzo krótka i dlatego tak szybko się ładowała. A co do tekstury trawy - wczytuje się dłużej, bo zajmuje większość (albo nawet całość) terenu, więc siłą rzeczy musi się dłużej ładować. To nie jest np. model, który jest ustawiony tylko w niektórych punktach na scenerii.
-
Paczka DDS 8.13. Sceneria jest niewielka, jest na niej kilkanaście rodzajów budynków, 3 tekstury drzewek, ściany lasu oraz teren [trawa]. Tory są zelektryfikowane. Rozumiem, że TGA zajmuje więcej miejsca. Jeśli jednak Maszyna wczytuje plik,w którym są tylko i wyłącznie trójkąty i tylko z jedną teksturą, gdzie nie trzeba tracić czasu na wczytywanie innych plików i jedyne, co trzeba zrobić to konwersja liczb ze String na Double oraz zapisanie tych liczb w pamięci, i to zajmuje kilka sekund, to z optymalizacją jest chyba coś nie tak. 10 sekund na scenerię, na której nic nie ma - trochę długo...
-
Prędkość ładowania plików (dysku) nie ma nawet nic do rzeczy. Scenerie ładują się dokładnie identycznie wolno ze starego i wolnego dysku talerzowego jak i SSD.
Co ciekawe jeśli chodzi o FPS - to też paradoksalnie nie zależy od karty graficznej. Testowałem na 3 kartach graficznych. W miejscach gdzie jest 60FPS - jest na wszystkich kartach, nawet na najwolniejszym zintegrowanym Intelu, tam gdzie przycina do 30 tam przycina też na wszystkich 3 kartach, jakby to nie była w ogóle kwestia wydajności karty graficznej. MaSzyna ma problemy wydajnościowe, które wydają się w pewnych miejscach prawie niezależne od wydajności sprzętu. Dziwne to trochę. Poprzednia paczka chodziła dużo szybciej. Nie wiem czy to tylko kwestia TGA. Podgrałem sobie DDS-y ze starej paczki i przełączyłem w Rainsted. Nie ma większej różnicy. Może troszkę mniej tnie w krytycznych miejscach, ale tylko odrobinę.
-
Nie podałeś nazw, nie zrobiłeś porównania FPS w tabelce w zależności od użytej karty i konkretnej scenerii. Twoje wnioski są niereprezentatywne.
Sceneria TD na karcie zintegrowanej intel ma prawo mieć tyle samo FPS co na GF9600. Ale L61 już nie. To samo z podmianą TGA na DDS, przyrost będzie znakomicie różny w zależności od typu karty i wielkości scenerii.
-
A możemy wrócić do meritum sprawy zamiast czepiać się wydajności exe?
-
Przepraszam za offtop, ale nie mogłem się zgodzić z HTD z tym co napisał. Wracajcie do meritum, ale bez takich nie udokumentowanych wywodów, na temat wydajności.
-
TGA beda przycinaly wiecej, bo zajmuja wiecej miejsca w VRAM przez co sterownik musi je przerzucac miedzy RAMem a VRAMem w kolko.
-
No jak masz mniej pamięci na karcie graficznej niż 2GB, to będzie wtedy różnica. Chociaż ja nie wiem, czy w pamięci VRAM przypadkiem nie siedzi grafika rozpakowana? Tak czy inaczej, na moim archaicznym Radeonie HD5870 nie ma różnicy czy DDS czy TGA. Za to jest różnica jak jest dużo modeli widocznych. W gęstym lesie czy gęstej zabudowie FPS potrafi mi spaść nawet do 30FPS, ale dokładnie tak samo na TGA i DDS.
Podsumowując ten offtopic - tekstury mają znacznie na bardzo przestarzałych kartach graficznych z małą ilością pamięci i/lub bardzo wolną pamięcią. Na współczesnych kartach raczej kiepska optymalizacja silnika graficznego ma znaczenie.
Ciekawostka - na moim Radeonie jak włączę w symku multisampling wysypuje się sygnalizacja. Rozwala się grafika wszystkich znaków i ogólnie wszystko wygląda paskudnie i migocze. Za to jak włączę maksymalny antyaliasing i multisampling w sterowniku od karty graficznej ("override application settings") - wtedy grafika wygląda ślicznie i nic się nie pierdaczy. W MaSzynie mam ustawiony multisampling na 1 (czyli wyłączony). Ogólnie MaSzyna bardzo nie chce współpracować z moją obecną konfiguracją. Dema i benchmarki nie mają żadnego problemu, problem jest tylko z MaSzyną. Problem taki, że muszę tworzyć dla niej specjalny profil w Catalyst, inaczej raz, że ignoruje ustawienia sterownika, dwa - okropnie wygląda, trzy - niemożliwie zacina. Za to w profilu ustawiam wszystkie opcje na maksymalną jakość - i wtedy paradoksalnie chodzi dużo płynniej ;) Ewidentnie silnik graficzny wymagałby lekkiego odświeżenia, bo chyba nie za bardzo nadąża nawet za kartami graficznymi sprzed kilku lat. Tylko błagam, nie zaczynajmy kolejnego flejma - jakoś działa (po długich bojach) i są pilniejsze rzeczy do poprawienia. Np ostatni zgłaszany przeze mnie bug z zasilaniem na Drawinowie. Tylko pewnie zaraz się zacznie, że Drawinowo jest be, nie ma sensu poprawiać i trzeba napisać od nowa :P
Co do dokładnych testów porównawczych - jaki to ma sens? Nie chcecie wierzyć, że tak to działa na mojej konfiguracji to nie wierzcie. Nie chce mi się dla udowodnienia, że nie kłamię tego testować. Myślę, że już powstał consensus co do tych tekstur - będą 2 wersje, DDS i TGA, do wyboru dla każdego. Co do optymalizacji silnika - to może zrobić tylko ktoś, kto ma współczesny komputer, a nawet 3 (mogą być 3 osoby) dla przetestowania zmian na kartach graficznych 3 głównych producentów, czyli Intela, AMD i NVidii.
Ja tam strzelę, że wąskim gardłem nie będzie wcale GPU tylko CPU. A raczej to, że silnik za dużo robi na CPU, za mało na GPU. Niedawno popsuł mi się laptop z szybkim prockiem i7 - jak był sprawny, MaSzyna nie schodziła poniżej 60FPS-ów, pomimo tego, że grafika mobilna w tym lapku była słabsza od Radeona HD5870. Na starym kompie mam 2 rdzeniowy i5 i MaSzyna częściej daje radę 30FPS wyświetlić, niż 60. To by też pasowało do "rysu historycznego". Dawno dawno temu karty graficzne niewiele potrafiły, dlatego więcej rzeczy robiło się na CPU. Aha, rzeczony Radek ma 2GB RAM-u, więc widocznie to wystarcza MaSzynie z teksturami TGA (o ile w ogóle skompresowane tekstury są trzymane w VRAM, bo może wcale nie - nie znam się na tym).
Co do meritum - weekend już jutro i pojutrze - może uda mi się wypuścić nową wersję edytorka ze znaczącymi zmianami.
-
@HTD: DDS jest skompresowanym formatem obslugiwanym przez GPU, wiec poza starymi Intelami wszystko trafia skompresowane do VRAM.
-
Ja jestem wyjatkiem w sensie takim, ze moze na DDS mam wyzszy fps, ale mam przyciecia symka co pare sekund. Na TGA przyciec brak.