Programiści... - Programy - VirtualBus forum

Jump to content



Programiści...


  • Please log in to reply
32 replies to this topic

#1
DevPort

DevPort
  • Użytkownicy
  • 37 Posts:
2
Te, mam pytanie do społeczeństwa tutejszego...
Jakich tu mamy programistów?
- C++
- Obj. Pascal (Delphi, FPC)

Głównie zależy mi na tym kto i w jakim stopniu rozwija VB i co wolicie: pascala czy c++.

Sam programuję w FPC na PC i C++ na ARM.

//************************************************************************************************************
Nie szukam programistów dla siebie...

Wiele razy widziałem tutaj posty użytkowników, którzy w jakimś stopniu chcieli stworzyć nowego VB.
Moim zdaniem stworzenie całkiem nowego symulatora jest nieosiągalne dla obecnych tutaj programistów.
Lepiej stworzyć nową bazę dla obecnej. Czyli pozbyć się Delphi + GLScene na rzecz FPC+OpenGL + API systemowe i dążyć do stanu obecnego czyli A6E.
Mam pewną koncepcję i postaram się ją w między czasie umieścić... by kolejne osoby mogły ją rozwijać.
Martwi mnie fakt, że mimo upływu 4 lat znajomości, VB nadal ma krytycznie małą wydajność.
Co wy na to?
Prawdziwy programista wiesza się wraz ze swoim programem.

AdBot

  • Elita
  • Posts: ∞

#2
hck

hck
  • Użytkownicy
  • 2 Posts:
0
Chętnie pomogę. Programuję we wszystkim oprócz Pascala już parę dobrych lat.
Napisałem prostego frameworka DirectX, na razie nic specjalnego (wyświetlanie modeli, tekstur, shadery), ale jakby znalazła się ekipa to można by coś z tego zrobić.

#3
fr0zi

fr0zi
  • Developerzy
  • 280 Posts:
34
Zamiana Delphi i GlScene na FPC i OpenGL? Dla mnie to brzmi jak zamiana "siekierki na kijek"... Delphi to Object Pascal a GlScene to biblioteka do obsługi OGL w Pascalu... Jest jakaś realna różnica?

Sądzę, że dopiero przepisanie kodu VBusa do C++ może dać jakąś różnicę wydajnościową.
CPU & RAM: AMD FX 8120 @ 3.1 GHz & Kingston 8 GB DDR3
GFX: Sapphire Radeon RX 480 8GB GDDR5
OS: Windows 10 Professional 64-bit

Zasilacz: OCZ CoreXStream 500W
Obudowa: Fractal Design Define R3

#4
ryba825

ryba825
  • Użytkownicy
  • 116 Posts:
1
Oczekujemy publikacji. :) Mam nadzieję, że projekt będzie rozwijany. :)

Wydajność Pascala/Delphi jest marna. Są to języki przestarzałe.

#5
Butelka

Butelka

    [PL] [EN] [ES]

  • Moderatorzy
  • 2830 Posts:
191
Każdy język da się wykorzystać i skompilować tak, by otrzymać dobrą wydajność. Wszystko w rękach IDE.

#6
fr0zi

fr0zi
  • Developerzy
  • 280 Posts:
34
No, niekoniecznie :) IDE to tak naprawdę jedynie środowisko narzędziowe i edytor kodu. Wydajność zależy od kompilatora i od sposobu w jaki tłumaczy kod źródłowy na maszynowy. Mają tu też wpływ różne mechanizmy działania języka. Pascal i Delphi nigdy nie stały się językami programowania gier, bo nie dawały tak wydajnego kodu jak np. C++.

Zastanawia mnie po prostu sens pisania drugi raz tego samego... Chociaż zawsze istnieje możliwość napisania czegoś lepiej niż poprzednio ;) Miejmy nadzieję, że tak się stanie.
CPU & RAM: AMD FX 8120 @ 3.1 GHz & Kingston 8 GB DDR3
GFX: Sapphire Radeon RX 480 8GB GDDR5
OS: Windows 10 Professional 64-bit

Zasilacz: OCZ CoreXStream 500W
Obudowa: Fractal Design Define R3

#7
ryba825

ryba825
  • Użytkownicy
  • 116 Posts:
1
Butelka, każdy język ma swoje ograniczenie, a największym z nich są zasoby ludzkie.

#8
Butelka

Butelka

    [PL] [EN] [ES]

  • Moderatorzy
  • 2830 Posts:
191

Wyświetl postUżytkownik fr0zi dnia 02 October 2012 - 18:32 napisał

Wydajność zależy od kompilatora i od sposobu w jaki tłumaczy kod źródłowy na maszynowy.

I to właśnie miałem na myśli :) Częścią IDE jest przecież kompilator.

#9
DevPort

DevPort
  • Użytkownicy
  • 37 Posts:
2
Ależ wy piep....ta, macie pojęcie w ogóle co piszecie?

Cytat

Zamiana Delphi i GlScene na FPC i OpenGL? Dla mnie to brzmi jak zamiana "siekierki na kijek"... Delphi to Object Pascal a GlScene to biblioteka do obsługi OGL w Pascalu... Jest jakaś realna różnica?

Można pisać szybkie gry w Delphi, ale nie z pomocą komponentów!!!
Pisanie w Free Pascalu w trybie Obiektowym to takie pisanie w czystym C++
Czystego Pascala porównać można co C, a Obj Pascal do C++.
Wielkich zmian po za składnią nie ma.

Szkoda kłótni zaczynać... wojny zwolenników są już od wieków.

Ryba825: C++ jest równie stary jak Obj Pascal.
Chę fr0zi zwrócić uwagę, że nie język jest problemem, a sposób kodowania gry.
Jestem zboczony na punkcie minimalizacji potrzebnego kodu. Czasami czuję się jak dodatkowy optymalizator kodu :P
Sam dla swych potrzeb piszę nagłówki do bibliotek kernel32.dll czy OpenGL32.dll przez co exe jest małe i szybkie.
Nie porównuj mnie z programistami Delphi bo to dla mnie jest obraza :)
Korzystam z Free Pascala bo programuje wyłącznie w rozbudowanym notatniku "Notepage++" i z użyciem wstawek assemblera.
Dla mnie Delphi przestało istnieć po wersji 7 Personal, na której się wychowałem.
Przesiadka na FPC dała mi dostęp natywny do Linux'a i skupienie się na wydajnym kodzie, a nie pięknych foremkach i komponentach.
Mego przekonania, że FPC jest równie dobry do gier co C++ nie zmienisz, mam choćby demo RayTracer'a pisanego w Objfpc (nie pod Delphi).
Prawdziwy programista wiesza się wraz ze swoim programem.

#10
Butelka

Butelka

    [PL] [EN] [ES]

  • Moderatorzy
  • 2830 Posts:
191
Napiszemy vBusa od nowa w Turbo Pascalu i tyle :e

Stop wojnie na wiedzę o językach programowania i notatnikach. Start dla rozmowy o konkretach odnoszących się do vBusa. Nikt się nie obrazi za użycie tego czy innego IDE albo języka, ale wszyscy się ucieszą gdy zobaczą powstający program, nawet w fazie pre-pre-pre-alpha.

#11
fr0zi

fr0zi
  • Developerzy
  • 280 Posts:
34

Wyświetl postUżytkownik Butelka dnia 02 October 2012 - 23:37 napisał

Napiszemy vBusa od nowa w Turbo Pascalu i tyle :e

Stop wojnie na wiedzę o językach programowania i notatnikach. Start dla rozmowy o konkretach odnoszących się do vBusa. Nikt się nie obrazi za użycie tego czy innego IDE albo języka, ale wszyscy się ucieszą gdy zobaczą powstający program, nawet w fazie pre-pre-pre-alpha.

Amen :)
CPU & RAM: AMD FX 8120 @ 3.1 GHz & Kingston 8 GB DDR3
GFX: Sapphire Radeon RX 480 8GB GDDR5
OS: Windows 10 Professional 64-bit

Zasilacz: OCZ CoreXStream 500W
Obudowa: Fractal Design Define R3

#12
DevPort

DevPort
  • Użytkownicy
  • 37 Posts:
2

Wyświetl postUżytkownik Butelka dnia 02 October 2012 - 23:37 napisał

Napiszemy vBusa od nowa w Turbo Pascalu i tyle :e

Stop wojnie na wiedzę o językach programowania i notatnikach. Start dla rozmowy o konkretach odnoszących się do vBusa. Nikt się nie obrazi za użycie tego czy innego IDE albo języka, ale wszyscy się ucieszą gdy zobaczą powstający program, nawet w fazie pre-pre-pre-alpha.

Czy jesteście pewni Pascala? Sonda powinna zdecydować, czy C++ czy Pascal i małe sprostowanie dla Ciebie Butelka: Nie Turbo Pascal, a Object Pascal. :)
Tak czy siak, ja koduję swoje... jeżeli to wypali to zamieszczę tu informację.
Pozdrawiam.
Prawdziwy programista wiesza się wraz ze swoim programem.

#13
ryba825

ryba825
  • Użytkownicy
  • 116 Posts:
1
Spike, na jakim jesteś etapie?

Co do języka, to zawsze można w obydwu jeden projekt pisać. ;)

#14
fr0zi

fr0zi
  • Developerzy
  • 280 Posts:
34
Spike, sam napisałeś, że nie cierpisz C++, więc o czym tu dyskutować? Skoro chcesz pisać to rób to w taki sposób, w jaki Tobie jest wygodnie.
CPU & RAM: AMD FX 8120 @ 3.1 GHz & Kingston 8 GB DDR3
GFX: Sapphire Radeon RX 480 8GB GDDR5
OS: Windows 10 Professional 64-bit

Zasilacz: OCZ CoreXStream 500W
Obudowa: Fractal Design Define R3

#15
DevPort

DevPort
  • Użytkownicy
  • 37 Posts:
2
Ryba825: prawie podstawę pod engine mam... lecz mozolnie to idzie z prostego powodu, braku czasu...
Ogólnie pisanie surowo plików nagłówkowych do bibliotek np. opengl.dll nie jest czymś prędkim. Jeszcze staram się na początku już tak pisać by kompilowało się też na Linux'ie :]
Jeżeli kogoś korci pytanie czemu nie użyję gotowego pliku opengl.pas to odpowiem: Programista opierając się o silnik używa funkcji dostępnych w silniku, reszta jest zbędna... staram się wychwycić najpotrzebniejsze funkcje i w sumie kreuję własną wersję, który jest wręcz wersją odchudzoną pliku nagłówkowego OpenGL.pas :D

fr0zi: Tyle, że jeżeli podstawę napiszę i przedstawię zasady programowania to przydałyby się  osoby wspomagające. Mało tego, projekt jest na tyle szalony, że spojrzenie na źródła daje odczucie "wynajdywania koła na nowo" co w pewnym sensie jest prawdą, bo spotkać można np. klasy obsługi strumieni (TStream pamięciowe czy plikowe) napisane na nowo. Ale lepiej wyciągnąć jedną klasę z pliku, niż ładować plik z kilkoma klasami dla tej jednej jedynej.
Prawdziwy programista wiesza się wraz ze swoim programem.

#16
Butelka

Butelka

    [PL] [EN] [ES]

  • Moderatorzy
  • 2830 Posts:
191

Wyświetl postUżytkownik spike dnia 03 October 2012 - 14:44 napisał

Czy jesteście pewni Pascala? Sonda powinna zdecydować, czy C++ czy Pascal i małe sprostowanie dla Ciebie Butelka: Nie Turbo Pascal, a Object Pascal. :)

I małe sprostowanie dla Ciebie spike: znasz słowo "ironia"? ;)
EOT.

#17
hck

hck
  • Użytkownicy
  • 2 Posts:
0
To teraz moje 3 grosze.

Zacznijmy od tego, że vbus w formie, w jakiej znaduje się teraz odrzuca. Odrzuca grafiką, odrzuca modelem jazdy, odrzuca animacjami, ....
Pomimo tego vbus istnieje, ludzie w to grają, istnieje społeczność, która chce aby przestał on odrzucać, a zaczął przyciągać.

VBus ma potencjał i warto ten potencjał wykorzystać.

Trzeba to zrobić mądrze. Trochę znam branżę game dev i jedną z rzczy, których się nauczyłem to aby nie używać półśrodków. Jeśli chcemy, aby vbus był grywalny i ładnie wyglądał, w tej sytuacji półśrodkiem będzie pisanie od zera.
Napisanie ładnego, grywalnego vbusa od zera przez 10-osobową grupę pracującą 8h dziennie szacuję na co najmniej pół roku. To nie ma sensu.

Proponuję:

1) użycie kombajnu (UnrealEngine, Unity3D itp.)
plusy:
+ Napisanie skryptów będzie banalne, praca praktycznie ograniczy się do tworzenia modeli
minusy:
- Mogą wystąpić problemy z licencjami
- Żeby pracować z takim kombajnem, trzeba ten kombajn znać. Hobbystom, którzy będą chcieli pomóc może być ciężko

2) użycie mniejszego silnika (Ogre3D, Esenthel itp.)
plusy:
+ Dostęp z niższego poziomu co może pomóc w programowaniu specyficznych dla autobusów rzeczy
minusy:
- Programowanie z niższego poziomu jest trudniejsze

3) użycie VDrift
plusy:
+ Wieloplatformowość
+ Projekt open-source, można go z góry dostosować do potrzeb autobusów

#18
Zonaimad

Zonaimad
  • Administratorzy
  • 34 Posts:
7
Panowie, moja rady są takie, by:
  • myśleć realistycznie,
  • myśleć ekonomicznie,
  • nie wynajdować od nowa koła.
:-) Poza tym nie chcę gasić niczyjego zapału, ani - co gorsza - przeszkadzać programistom w pracy. ;-)
Dołączona grafika

#19
Butelka

Butelka

    [PL] [EN] [ES]

  • Moderatorzy
  • 2830 Posts:
191
W praktyce tworzenie w oparciu o jakieś game development SDK będzie o wiele trudniejsze od pisania kodu od zera lub na bazie jakiegoś silnika. Spike słusznie zauważył, że dobrze jest zbudować własne zestawy klas, aby ograniczyć rozmiar pliku, zużycie zasobów itp. itd. Trochę czasu to zajmuje, ale przynosi efekty, a pisząc w Object Pascalu mamy ułatwienie w postaci istniejących już fragmentów kodu.

#20
fr0zi

fr0zi
  • Developerzy
  • 280 Posts:
34
A ja powiem tak: należy powaznie zastanowić się, w którą stronę VBus ma pójść. Czy nowa wersja ma bazować na obecnych modelach i mapach i jedynie ma poprawić wydajność. Czy ma wprowadzić nowe możliwości, tj. grawitację, realistyczną fizykę, lepsze i ładniejsze modele oraz trasy itd. Bo wydaje mi się, że każdego z tych celów wiedzie trochę inna droga.

Rozwiązanie, które zaproponował @spike wiedzie do celu pierwszego. Czyli wszystko będzie wyglądało tak samo, tyle że może będzie płynniej. Wynika to z prostego powodu - aby uzyskać realistyczny wygląd i ciekawe efekty graficzne (realistyczne odblaski i cienie, mapowanie wybojów itp.) potrzeba o wiele więcej tekstur i danych, a co za tym idzie zwiększa się ilość pracy oraz skomplikowanie modeli 3D. Wystarczy zajrzeć do dokumentacji choćby UDK albo CryEngine 3 i zobaczyć z ilu siatek i tekstur składa się pojedynczy model postaci bądź pojazdu. Dopiero wtedy silnik może prawidłowo oświetlić obiekt, zasymulować wyboje i rodzaj materiału... Obecne modele w VBusie mają jedynie siatkę okrytą zwykłą teksturą. Obecny silnik nawet nie odczytuje parametrów materiału zastosowanego w modelu (przezroczystość, odblask, promień odblasku itp.).

Dla przykładu - model czołgu z tutoriala do CryEngine 3 składał się z: głównej siatki 3D, siatki kolizji, siatki dla LOD, normalnej tekstury, mapy normalnych i lightmapy dla obiektów odblaskowych.
Dlatego też użycie UDK, albo Unity też pociąga za sobą sporo pracy.

Wniosek? Żeby faktycznie wnieść VBusa na nowy poziom realizmu i wyglądu, trzeba albo stworzyć nową bazę obiektów dostosowanych do wiekszych możliwości silnika albo dostosować stare modele, co w niektórych przypadkach pewnie nie byłoby łatwe.

Pomijam fakt, że niektóre stare mapy oprócz jezdni nie mają siatki gruntu, więc przy podpięciu fizyki, zjeżdżając autobusem z drogi, spadamy w otchłań... Spotkałem się z tym przy próbach Irrlicht+Bullet ;) Też trzeba by to poprawić.

Tak więc, trzeba pomysleć, czy po prostu przepisujemy od nowa kod VBusa i tyle (kompatybilność ze starymi mapami i pojazdami), czy tworzymy nowy silnik (dostosowywanie map i pojazdów ale lepszy wygląd i większe możliwości).
CPU & RAM: AMD FX 8120 @ 3.1 GHz & Kingston 8 GB DDR3
GFX: Sapphire Radeon RX 480 8GB GDDR5
OS: Windows 10 Professional 64-bit

Zasilacz: OCZ CoreXStream 500W
Obudowa: Fractal Design Define R3