Kurs SFML 3.0

Jeśli szukasz kursu SFML 3.0 to zapraszam. :-)
Właśnie piszę takowy kurs i napisałem pierwsze rozdziały.
Obecnie z kursu dowiesz się jak zainstalować oraz skonfigurować bibliotekę SFML w Visual Studio,
a także jak renderować kształty i obsługiwać eventy w programie.
Zapraszam :-)

https://github.com/tBane-Dev/Kurs-SFML-3.0

A czemu taka dyskryminacja?
Nie lepiej używać "przemysłowego standardu" jakim jest cmake ?
A IDE i kompilator wybierz sobie taki jak lubisz ;)

Szczerze to nie umiem inaczej jak w Visual Studio konfigurować projekt. Ale jak się nauczę to opublikuje. :-)
Poza tym VS jest najpopularniejszym IDE chyba :-)
Ale nic nie stoi na przeszkodzie, by samodzielnie skonfigurować projekt i przejść do dalszych rozdziałów kursu :-)

Marius.Maximus napisał(a):

Nie lepiej używać "przemysłowego standardu" jakim jest cmake ?

Gdyby kurs był o "przemysłowym standardzie", to nie byłby o SFML :P

Spine napisał(a):

Marius.Maximus napisał(a):

Nie lepiej używać "przemysłowego standardu" jakim jest cmake ?

Gdyby kurs był o "przemysłowym standardzie", to nie byłby o SFML :P

A co jest standardem w takim razie? :-)

tBane napisał(a):

A co jest standardem w takim razie? :-)

To w czym powstaje większość gier wydawanych przez przedstawicieli przemysłu?

Spine napisał(a):

tBane napisał(a):

A co jest standardem w takim razie? :-)

To w czym powstaje większość gier wydawanych przez przedstawicieli przemysłu?

Teraz już wiem.
Mimo wszystko kurs powstanie :-)

@tBane walcz dalej !
Jak będzie jakiś postęp dawaj znaki !
Dobrym pomysłem było by aby kompletny kod przykładów znajdował się w repo a nie tylko w treści strony
Nie wiem też czy warto iść w dwa języki

Jedno co rzuciło mi się w oczy to, że jest na GitHub, nawet nie GitHub Pages. Dlaczego?
Dwóm wersjom językowym się nie dziwię. Sam o tym myślałem, ale zrezygnowałem.
Nie mniej uważam że lepiej by było gdyby były samodzielne tj. nie pod sobą tylko np. u góry odnośniki, opisowe lub flagowe.

Tekstu, nie czytałem. VS, nie używam. Choć zauważyłem jeszcze dwie rzeczy.

wyczyść ekran czarnym kolorem? Wiem że komenda to clear ale może wypełnij ekran czarnym kolorem albo wyczyść ekran i wypełnij czarnym kolorem ?

A druga sprawa ... dlaczego tak:

-Red (czerwony)
-Green (zielony)
-Blue (niebieski)

a nie tak:

• Red (czerwony)
• Green (zielony)
• Blue (niebieski)

Jeszcze jedno: dlaczego w Primitives kod nie ma komentarzy?

@Marius.Maximus chętnie był dodał kod w wydzielonych plikach ale markdown nie pozwala includować plików więc kod jest w plikach md :-/

@brokenelevator dzięki za rady. Faktycznie, to z kolorami trzeba poprawić - ciągle uczę się markdown. :-)

Jeśli chodzi o komentarze w Primitives to uwazam, że są zbędne - kod jest wystarczająco czytelny bez nich :-)

GitHub chyba nie pozwala na proste dodawanie kodu z pliku. Jest to możliwe za pomocą GitHub Actions ale bardziej skomplikowane niż chciałbym tłumaczyć. Szczególnie że to nie moja, i nie testowana wiedza.

Problem wyczyść ekran i wypełnij czarnym kolorem jest też w angielskiej wersji.
W takim razie rozumiem że komentarze w Prymitywy są tylko dlatego bo angielski? bo kod zakładam, jest ten sam.

Jeszcze jedna sprawa. Dlaczego masz zawsze tylko jeden commit? Robisz squash i force push za każdym razem? to chyba nie tak powinno wyglądać... aczkolwiek nie wiem bo każdy korzysta z narzędzia jak chce.

@brokenelevator Dzięki za pomoc :-)

robię git commit --amend i potem git push --force.
Nie mam pomysłu na nazwy commitów, poza tym trochę chaotycznie piszę ten kurs - ciągle poprawiam i w ogóle, więc tragicznie by to wyglądało chyba w historii commitów - a tak mam jeden główny init commit i jest git :D

Marius.Maximus napisał(a):

A czemu taka dyskryminacja?
Nie lepiej używać "przemysłowego standardu" jakim jest cmake ?
A IDE i kompilator wybierz sobie taki jak lubisz ;)

Jak to ma być kurs dla początkujących w pisaniu programów z grafiką, którzy dopiero nauczyli się C++ na poziomie do prostych programów konsolowych, na poziomie np. końca 1. klasy technika programisty, to CMake mogłoby stać się najtrudniejszą częścią i kurs SFML zamieniłby się w kurs CMake. Lepiej zamiast tego wskazać IDE i napisać dokładnie, jak je poustawiać. Ja jedynie wybrałbym jakieś mniej wymagające sprzętowo IDE, np. CodeBlocks, zamiast VS, żeby jeszcze zwiększyć grupę docelową. Zamiennie można by było przedstawiać kompilowanie i konsolidowanie programów z SFML z konsoli, co byłoby niezależne od IDE oraz dobre edukacyjnie. No ewentualnie wprowadzić na dalszym etapie kursu zwykłe MAKE, ponieważ to da się łatwo odnieść do poleceń konsolowych.

Zastosowanie w kursie CMake sprowadza się do dwóch możliwości:

1. Zrobienie z tego jednocześnie kursu SFML i CMake, co będzie utrudniało naukę. Trochę jakby uczyć podstaw chemii i jednocześnie wypełniania formularzy-sprawozdań doświadczeń zgodnie z procedurami jakiegoś laboratorium, żeby udokumentować doświadczenie mieszania oleju z wodą.
2. Ograniczenie grupy docelowej do rozumiejących CMake, ale wtedy odcinasz się od wielu potencjalnych czytelników. Ci, którzy rozumieją CMake być może będą woleli uczyć się jakiejś tam biblioteki graficznej bezpośrednio z dokumentacji lub będą mieli wygórowane wymagania co do takiego kursu, a jeśli zaczynasz pisanie takich kursów, to moim zdaniem lepiej zacząć od pisania kursów dla początkujących.

Także jak najbardziej popieram, że @tBane nie wprowadził tam CMake.

tBane napisał(a):

Nie mam pomysłu na nazwy commitów, poza tym trochę chaotycznie piszę ten kurs - ciągle poprawiam i w ogóle, więc tragicznie by to wyglądało chyba w historii commitów - a tak mam jeden główny init commit i jest git :D

O rany...
To może zrób sobie developerskie prywatne repo kursu, a publicznie zrób repo tylko do release'ów?
Ty będziesz miał podgląd na wszystkie zmiany, a inni tylko na finalne.

Cześć!
Napisałem kolejne rozdziały.
Teraz kurs zawiera następujące wpisy.

Spis Treści
01 - Wstęp
02 - Instalacja
03 - Konfiguracja
04 - Prymitywy
05 - Zdarzenia
06 - Bezpośredni Dostęp do Klawiatury i Myszy
07 - Tekstury i Sprajty
08 - Czcionki i Teksty
09 - Zegar i Odmierzanie Czasu
10 - Sprite Sheet i Animacja

Contents
01 - Introduction
02 - Installation
03 - Configuration
04 - Primitives
05 - Events
06 - Direct Keyboard and Mouse Input
07 - Textures and Sprites
08 - Fonts and Texts
09 - Clock and Elapsed Time
10 - Sprite Sheet and Animation

Simple Programs
01 - Button
02 - Button With Sprite

Zapraszam

https://github.com/tBane-Dev/Kurs-SFML-3.0

Może głupie pytanie, ale po co w dobie AI tworzyć i czytać takie treści?

a po to, żeby mieć jakiś ogląd jak działa dana biblioteka. Po przeczytaniu kursu o wiele prościej się programuje i rozumie kod, który podaje AI :-)
Sam osobiście lubię czytać tutoriale, przed rozpoczęciem prac nad projektem w danej technologii.
Jako, że dobrego polskiego tutorialu z SFML 3.0 nie ma w necie, to postanowiłem go napisać, bo trochę w tym już siedzę :-)

bustard2 napisał(a):

Może głupie pytanie, ale po co w dobie AI tworzyć i czytać takie treści?

Dlaczego? powodów jest wiele — mniej lub bardziej sensownych

• Niektórzy po prostu wolą uczyć się z tradycyjnych poradników
• Pisanie poradnika pomaga uporządkować i utrwalić własną wiedzę.
• To świetne ćwiczenie umiejętności pisania i tłumaczenia zagadnień technicznych.
• Dla własnej satysfakcji — nie wszystko musi mieć wymiar praktyczny
• Przy okazji można nauczyć się innych rzeczy, np. Markdown'a, tworzenia stron internetowych, robienia czytelnych zrzutów ekranu czy organizowania materiałów
• Poradnik ma strukturę a AI trzeba umieć zadawać pytania
• Łatwiej wrócić do konkretnego rozdziału niż odtwarzać starą rozmowę z AI
• Może pokazywać nasze dobre (lub złe) praktyki (w sensie żeby się ludzie poznali na nas)
• Pisząc dla innych, szybko odkrywa się własne luki w wiedzy (trochę się pokrywa z innym punktem)
• Ktoś może przypadkiem na niego wpaść i się zainspirować (ciężko chyba przypadkiem zapytać AI)

Oczywiście pewnie można by znaleźć jakieś negatywy ale szukać nie planuje.

Podobno: Najlepszym sposobem, żeby czegoś się nauczyć, jest spróbować tego nauczyć innych.
Pisanie poradnika jest właśnie realizacją tej zasady. Nawet jeśli pierwszy poradnik nie jest idealny, autor zwykle wynosi z jego napisania ogromną korzyść. A kolejny zazwyczaj jest znacznie lepszy. Dlatego osoby podejmujące takie inicjatywy warto raczej zachęcać do rozwoju niż zniechęcać pytaniem "po co?".

@tBane A tak nawiasem mówiąć zauważyłem kilka drobiazgów, które moim zdaniem warto poprawić. Miałem to napisać wcześniej ale nie chciałem za często się czepiać może nie tak ważnych rzeczy. Niektórych to męczy. Skoro już jednak zacząłem to kilka rzeczy wskażę:

• Mieszasz języki np. w Tekstury-i-Sprajty jest tytuł Textures and Sprites
• W tym tym samym miejscu masz np. sf::Texture nie wyróżnione mimo że generalnie wyróżniasz
• Od pewnego momentu nazywasz okna tytułem sekcji ale w Textures and Sprites masz Texture and Sprite
• Zresztą w Tekstury-i-Sprajty masz tytuł Texture and Sprite a nie Tekstury i Sprajty
• Dlaczego wersje językowe nie mają swoich drzewek (albo gałęzi)
• W obu wersjach językowych sekcja/rozdział 9 ma inny tytuł wewnątrz
• Simple programs (nagłówek nie ma tłumaczenia) mogłyby być kodem a przykład obrazkiem obok

Nie wiem czy to wszystko ale wystarczy. Może część z tego jest celowa. Zrób z tym co chcesz :)

bustard2 napisał(a):

Może głupie pytanie, ale po co w dobie AI tworzyć i czytać takie treści?

Szkoliłem kiedyś grupy 10 osobowe z Excela i Worda i uważam, że najlepszą nauką jest nauczanie i tłumaczenie komuś dokładnie i szczegółowo.

tBane napisał(a):

Spine napisał(a):

Marius.Maximus napisał(a):

Nie lepiej używać "przemysłowego standardu" jakim jest cmake ?

Gdyby kurs był o "przemysłowym standardzie", to nie byłby o SFML :P

A co jest standardem w takim razie? :-)

Spine napisał(a):

tBane napisał(a):

A co jest standardem w takim razie? :-)

To w czym powstaje większość gier wydawanych przez przedstawicieli przemysłu?

Standard w informatyce to uzgodniony, formalny zbiór zasad, specyfikacji lub norm, który określa, jak coś powinno być zrobione, aby zapewnić kompatybilność, interoperacyjność i powtarzalność.

Przykłady:

• HTML, CSS, HTTP – standardy sieciowe (W3C)
• ISO 27001 – standard bezpieczeństwa informacji
• USB, Wi-Fi (IEEE 802.11), TCP/IP – standardy sprzętowe i protokołowe

Standardy mogą być otwarte (np. RFC) lub zamknięte (proprietary), ale ich celem jest ujednolicenie rozwiązań, żeby różne systemy mogły ze sobą współpracować.

Czyli standard, specyfikacja, norma to nie jest to ilość występowania danego rozwiazania.

@tBane Brawo za fakt, że robisz coś od siebie dla innych. Tak trzymać. I nie daj się zniechęcić wypowiedziami, że AI udzieli lepszych informacji - bo nie udzieli. AI co ponajwyżej użyje cudzej pracy do budowania merytoryki swoich wiadomości.

Obecnie nie programuje już z użyciem SFML ale swego czasu być może kurs był by dla mnie przypdatny.

Linki do stworzonych przez siebie kursów, artykułów, referatów możesz wstawiać na profilu GitHub.

Mam kilka uwag co do repozytorium Kurs-SFML-3.00 - tym bardziej, że ktoś tu wcześniej wspominał coś o standardach / normach / konwencjach. A te konwencje również występują na GitHub.

1 . Nazwa repozytorium. Wydaje mi się, że lepsze nazwy to: kurs-sfml-3.0, sfml-kurs-polski, learn-sfml-3.0-pl.
Krótko, zwięźle i w temat. Nazwa pisana tylko małymi literami.

2 . Description:

Kurs SFML 3.0 w języku polskim – od podstaw do tworzenia gier 2D.
Zawiera przykłady kodu, wyjaśnienia i projekty praktyczne.

3 . Tagi: sfml, sfml-3.0, c++, cpp, kurs, tutorial, polish, polski,
game-development, gamedev, 2d-game, game-programming.

4 . Skoro zdecydowałeś się, że kurs jest tworzony w języku polskim to bądź konsekwentny. Nie może być sytuacji już samym README.md używasz dwóch języków. Jeżeli chesz tworzyć kurs w obu tych językach to tworzy się dwa różne pliki README.md.

A jak już tworzysz wielojęzykowo to nazwa repozytorium w języku angielskim.

5 . Release.
Pierwszy Release
Po ukończeniu minimum 60-70% materiału.
v0.8 lub v1.0-beta

Główna wersja
Po ukończeniu całego kursu.
v1.0

Aktualizacje
Po dodaniu dużego działu lub wielu poprawek.
v1.1, v1.2

6 . Informacje które umieszczasz podczas tworzenia release'a również są istotne, warto je uzupełnić i zrobić to według konwencji.

7 . Rekomendowana nazwa pliku dla release

kurs-sfml-3.0-v1.0.zip
kurs-sfml-3.0-v1.0-source.zip

Zasady nazewnictwa:

• Używaj kebab-case lub snake_case.
• Zawsze dodawaj pełny numer wersji v1.0, v1.1. Ale nie wstawiaj wersji jako 3.X - bo to nie jest numer wersji. Relase to jest konkretna, wypuszczona wersja projektu bez późniejszych modyfikacji tego konkretnego release. Jeżeli zmodyfikujesz projekt to wypuszczasz kolejny release. [1]
• Małe litery są preferowane na GitHubie.
• Nazwa powinna zawierać kurs-sfml-3.0

[1] Tak się rozkręciłem, że teraz dopiero do mnie dotarło, że u ciebie ciąg 3.X miał się tyczyć wersji biblioteki SFML. Ale też nie wiadomo konkretnie jakiej wersji - no chyba, że SFML zostało wypuszczone w numerze której występuje znak X. No może taki psikus zrobili... he he.
Ale poważnie mówiąc to ewentualna litera w konwencji Semantic Versioning ma swoje znaczenie.

dawciobiel napisał(a):

Czyli standard, specyfikacja, norma to nie jest to ilość występowania danego rozwiazania.

Industry standard.

Standard branżowy to zestaw wytycznych, technologii lub procedur, które zostały powszechnie zaakceptowane przez firmy z danej dziedziny.

SFML nigdy nie został powszechnie przyjęty jako standard w firmach tworzących gry.
Powszechność to właśnie ilość występowania.

@tBane W przykładach masz zawarty kod wraz z komentarzami. Na przykład:

    // stwórz obiekt type Text z czionką z określoną wielkością
    sf::Text text(font, "Hello SFML 3.0", characterSize);
    text.setFillColor(sf::Color::Red); // wypełnij tekst czerwonym kolorem
    text.setOutlineThickness(6.f); // dodaj obrys o grubości 6 pikseli
    text.setOutlineColor(sf::Color(127, 0, 0)); // wypełnij obrys ciemno czerwonym kolorem
    text.setRotation(sf::degrees(5.f)); // obróć tekst względem lewego górnego rogu o 5 stopnii

Dawno dawno temu programowałem hobbystycznie w assemblerze. W tym języku warto umieszczać krótkie i zwięzłe komentarze. Nauczyłem się tam pewnych konwencji co do tworzenia komentarza. Więc podziele się dobrą radą:

• Komentarz ma być krótki, zwięzły i na temat. Bez opisowych wypracowań. Zazwyczaj im mniej tym lepiej.
• Komentarz rozpoczynasz wielką literą - jest to dodatkowa informacja, że w tym miejscu jest początek spójnej treści, która nie jest powiazana z wcześniejszymi komentarzami.
• Można komentarz znakiem kropki. Informuje ona, że komentarz jako całość jest tu zakończony. Ale jeżeli tak się zrobi to trzeba trzymać się tej zasady w całym pliku. Ja staram się unikać dodawania kropek.

Nazwy katalogów
XX-nazwa-tematu-w-kebab-case

• Numer porządkowy.
• kebab-case (małe litery, myślniki).
• Angielskie nazwy.

Nazwy plików Markdown

• Główny plik: README.md lub index.md
• Pozostałe pliki kebab-case image-and-drawing-pixels.md.

Obrazy

• kebab-case (małe litery, myślniki)

Kod źródłowy

• Format nazwy pliku jest zależny od języka programowania.

@tBane Odpisuję tutaj, a nie w komentarzu bo tutaj brak ograniczenia na ilość znaków.. i wygodniej.

1 . przecież nazwa to Kurs-SFML-3.0 a nie 3.00 :-)

Nie wiem skąd to 3.00 tam wpisałem, nie pamiętam, nie przyznam się do niczego bez adwokata - więc zostawmy to.

W każdym razie jeżeli chodzi o nazwę "projektu" to znalazłem takie określenia:
GitHub URL: https://github.com/tBane-Dev/Kurs-SFML-3.0
Nazwa wyświetlana na górze strony: Kurs-SFML-3.0
Nazwa wyświetlana jako nagłówek README.md: SFML 3.0 - Kurs / Course
aaaa zajrzę jeszcze złośliwie do dokumentu "Wstęp" bo na pewno tam jest jeszcze inaczej: "Witaj w poradniku poświęconym bibliotece SFML 3.0.".

Czyli trzeba się zdecydować i trzymać jednej nazwy.
kurs-sfml-3.0 / learn-sfml-3.0 - czyli całość jako nazwa repozytorium pisana małymi literami kebab-case.
W README.md, README.pl.md w tytule wpiszsz sobie odpowiednio od wersj językowej:
Kurs SFML 3.0 / Learn SFML 3.0. W tytule można już używać dowolnego ciągu znaków oraz dowolnej wielkości liter.

2 . No opis można poprawić - zaraz się za to wezmę
3 . nie wiem jak dodawać tagi, wyjaśnisz mi jak to zrobić?

W projektu sekcji About dodaje się topics:

Każdy wyraz odzielony znakiem , staje się oddzielnym topikiem.

Można tego dokonać również z konsoli:

gh auth login

gh repo edit tBane-Dev/Kurs-SFML-3.0 \
--add-topic "sfml,sfml-3.0,c++,cpp,kurs,tutorial,polish,polski,game-development,gamedev,2d-game,game-programming" \
--description "Twój krótki opis projektu"

gh repo edit --help

4 . kurs jest w dwóch językach, ale chciałem mieć główny spis treści, żeby wyszukiwanie było proste

Wydaje mi się, że na chwile obecną twórz ten kurs w jednej wersji językowej. Ustalisz styl, formatowanie, nazewnictwo plików itp. A na koniec przetłumaczysz to do kolejnej wersji językowej. W ten sposób nie będziesz musiał wykonywać każdej zmiany i poprawki podwójnie podczas tworzenia.
Być może istnieją narzędzia do tworzenia projektu w formie plików dokumentacji Mardown:

• JetBrains writerside

5 . 6 . 7 . Release już usunąłęm, służyło tylko do tego, żeby przekopiować kurs na inną stronę :-)

Też mnie zawsze korci aby tworzyć release w celu łatwego udostępnienia skompresowanego projektu znajomym.

@dawciobiel: Tagi dodane. Dzięki za radę :-) Ogólnie chciałem, by były dwa języki kursu. Ale README w Github za bardzo na to nie pozwala - więc trochę kombinowane.
Ogólnie planuję postawić jakąś stronę i na niej umieścić ten kurs, po to żeby można było przełączać wersję językową. Ale najpierw muszę bardziej rozbudować kurs.