Programy napisane w WinaAPI a nowe Windowsy

Witam,
czy programy napisane w czystym C (nie C++, nie C#) w WinaAPI będą działać na Windowsach 8 - 10?

Nie rozumiem po co ten masochizm z WinAPI.
MS dba o wsteczną kompatybilność i w 99% przypadkach wszystko będzie działać na nowych systemach Windows-a.

Nie rozwodząc się za bardzo - będę musiał w programie wejść w niskopoziomowe działania na dźwięku i obrazie bez używania opengl, directX itp...
Nie jest tak, że i tak zejdę na poziom winaAPI?

Tego ci nie powiemy póki nie doprecyzujesz konkretnie jakie operacje chcesz robić. Ale wielce niewykluczone, że np. do operacji na obrazie to jakieś API Nvidii i AMD będzie wystarczające.

A po co zakładasz drugi, bardzo podobny temat?
O kompatybilności WinAPI pisaliśmy w innym wątku - https://4programmers.net/Forum/1539408

Poza tym, skoro zadajesz więcej pytań i tworzysz kolejne wątki, może załóż konto, a nie pisz z anonima? :P

Spokojnie. Wątek nie jest dokładnie o tym samym a co do zbieżności, to popatrz na godziny (w tym przypadku minuty).
A dwa - przecież cały czas się podpisuję.

darek darek napisał(a):

Witam,
czy programy napisane w czystym C (nie C++, nie C#) w WinaAPI będą działać na Windowsach 8 - 10?

Tak.

WinApi to masochizm i trudno sobie wyobrazić, że chciałbyś tego użyć. Co to za czary chcesz zrobić, że nie wystarczy np. SDL czy Allegro, skoro nie chcesz OpenGL ani DirectX. Nikomu nie życzę programować w WinApi, to chyba jeszcze gorsze niż XLib. :p Nie mniej jednak WinApi powinno działać.

Będą działać – w końcu używasz API systemu, które jest po części ”dziedziczone” z wersji na wersję. Stare funkcje pozostają, a nowe są dodawane. Ale to wcale nie oznacza, że nie będziesz mieć żadnych problemów.

Jeśli Twoja aplikacja ma wspierać wszystkie wersje Windows np. od NT wzwyż, to musisz korzystać z takich funkcji, które są zawarte w bibliotekach we wszystkich wspieranych wersjach systemu. Jeżeli na taki problem natrafisz to należy skorzystać ze starszego odpowiednika, a jeśli nie ma odpowiednika (bo stary system w ogóle nie posiadał danej funkcjonalności), to cóż… trzeba wykryć wersję systemu i udostępnić daną funkcjonalność tylko wtedy, gdy faktycznie jest dostępna.

elwis napisał(a):

WinApi to masochizm i trudno sobie wyobrazić, że chciałbyś tego użyć. Co to za czary chcesz zrobić, że nie wystarczy np. SDL czy Allegro, skoro nie chcesz OpenGL ani DirectX.

Właśnie żadne czary. Muszę hurtowo bitmapy przelecieć dosłownie piksel po pikselu i na podstawie jakichś tam obliczeń zmienić jego kolor. OpenGL i DX uznałem za coś bardziej do grafiki 3d (nie słyszałem o ich funkcjach operujących na poziomie pojedynczych pikseli) a z kolei Allegro, SDL itp. i tak korzystają z winAPI i nie wiem, czy specjalnie tu pomogą. Bardziej zaciekawiła mnie inna sugestia kolegi z tego wątku, że być może natywne API NVidia czy ATI - przyznam, że tego w ogóle nie brałem pod uwagę, bo nie wiedziałem, że takie coś jest udostępniane.

Nikomu nie życzę programować w WinApi, to chyba jeszcze gorsze niż XLib. :p Nie mniej jednak WinApi powinno działać.

Dopiero będę próbował. Aż tak źle?

darekdarek napisał(a):

Muszę hurtowo bitmapy przelecieć dosłownie piksel po pikselu i na podstawie jakichś tam obliczeń zmienić jego kolor.

Takie rzeczy można robić bez WinAPI i wcale nie jest powiedziane, że będzie to wybitnie powolne.

Bardziej zaciekawiła mnie inna sugestia kolegi z tego wątku, że być może natywne API NVidia czy ATI - przyznam, że tego w ogóle nie brałem pod uwagę, bo nie wiedziałem, że takie coś jest udostępniane.

Do dyspozycji jest wiele różnych bibliotek, mających przyjazny interfejs i wysoką wydajność swoich rozwiązań. To jednak w dalszym ciągu nie powinno decydować o doborze języka i sposobu pisania kodu.

Dopiero będę próbował. Aż tak źle?

Pisanie kodu aplikacji strukturalnie i z wykorzystaniem funkcji z API systemowego nie jest ani łatwe, ani szybkie, ani też bezpieczne. Po to wymyślono różne biblioteki do UI, aby nie tracić czasu na mozolne rzeźbienie kodu i ślęczenie w dokumentacji Windowsa.

@darekdarek:
To do takich zastosowań powinno dać radę DirectX - na szybko gógle znalazły mi takie coś

furious programming napisał(a):

darekdarek napisał(a):

Muszę hurtowo bitmapy przelecieć dosłownie piksel po pikselu i na podstawie jakichś tam obliczeń zmienić jego kolor.

Takie rzeczy można robić bez WinAPI i wcale nie jest powiedziane, że będzie to wybitnie powolne.

W sumie... to to winAPI potrzebne mi tylko do wyświetlania widoku tych zmian w jakimś oknie. Po prostu (być może mylnie) odrzucając OpenGL czy DX sądziłem, że zostaje mi tylko winAPI.
Co innego do wydajnego hurtowego grzebania po pikselach w 2d mogłoby być sensowne (w C i pod WIN)?

darekdarek napisał(a):

W sumie... to to winAPI potrzebne mi tylko do wyświetlania widoku tych zmian w jakimś oknie.

Do tego też nie potrzebujesz WinAPI, chyba że pisanie kodu w czystym C jest sztywnym wymogiem. A jest?

Co do "C" - tak, to jest wymóg.
A co do winapi - no chwila, a jak utworzę windowsowe okno? Jak wyświetlę w nim cokolwiek, czy zaprogramuję podstawową jego obsługę bez korzystania z Api Windowsa?

darekdarek napisał(a):

elwis napisał(a):

WinApi to masochizm i trudno sobie wyobrazić, że chciałbyś tego użyć. Co to za czary chcesz zrobić, że nie wystarczy np. SDL czy Allegro, skoro nie chcesz OpenGL ani DirectX.

Właśnie żadne czary. Muszę hurtowo bitmapy przelecieć dosłownie piksel po pikselu i na podstawie jakichś tam obliczeń zmienić jego kolor. OpenGL i DX uznałem za coś bardziej do grafiki 3d (nie słyszałem o ich funkcjach operujących na poziomie pojedynczych pikseli) a z kolei Allegro, SDL itp. i tak korzystają z winAPI i nie wiem, czy specjalnie tu pomogą. Bardziej zaciekawiła mnie inna sugestia kolegi z tego wątku, że być może natywne API NVidia czy ATI - przyznam, że tego w ogóle nie brałem pod uwagę, bo nie wiedziałem, że takie coś jest udostępniane.

To z tego wynika, że wcale nie musisz schodzić na niskopoziomowe API. Nie widzę przeszkód żeby zmodyfikować bitmapę w pamięci przed wyświetleniem. Możesz to również zrobić w SDL, a powodów jest kilka. Przede wszystkim SDL jest przenośne, zadziała również na Linuksie, Macu i czymkolwiek tylko będziesz chciał. Dodatkowo ma całkiem przyjemne API (tak, WinApi jest BARDZO ZŁE i toporne) i na dodatek wspiera wsparcie sprzętowe dla grafiki 2D, więc może się załapiesz (WinApi chyba nie ma). Poza tym w SDL z łatwością zaimpotujesz obraz w jakimś normalnym formacie (np. png). BTW. w DirectX też pewnie to możesz zrobić (choć nie wiem czy wspiera język C, możliwe że tylko C++, MS za bardzo nie lubi C), bo to też ma wsparcie dla grafiki 2D.

Nikomu nie życzę programować w WinApi, to chyba jeszcze gorsze niż XLib. :p Nie mniej jednak WinApi powinno działać.

Dopiero będę próbował. Aż tak źle?

http://zetcode.com/gui/winapi/gdi/ -- tu jest coś o graficznym API, GDI.

Popatrz na przypadkowy kod w sieci, szybko zobaczysz, tysiące funkcji i mało która ma mniej niż 5 parametrów. ;( Bardzo dużo haczyków, itd. Do tego jest bardzo niskopoziomowe, nie warto. SDL ma ładny obiektowy styl w którym da się ładnie i wydajnie programować, może kiedyś ci się przyda jak zechcesz kodować coś multimedialnego. To bardzo przydatna, przyjemna w użyciu biblioteka.

darekdarek napisał(a):

Co do "C" - tak, to jest wymóg.

W takim razie jesteś raczej skazany na rzeźbienie kodu strukturalnego. Chyba że możesz skorzystać z jakiejś gotowej biblioteki, która ułatwi stworzenie aplikacji okienkowej (zobacz).

WinApi to masochizm i trudno sobie wyobrazić, że chciałbyś tego użyć.

Mocna przesada. WinAPI nie jest takie straszne jak je malują.

Powstaje jednak pytanie: czy ten program w ogóle ma coś wyświetlać? Bo jeśli tylko wczytywać pliki graficzne coś tam w nich manipulować i zapisać wynik, to to może być po prostu program konsolowy. Potrzebna jest tylko jakaś biblioteka do obsługi potrzebnego formatu graficznego.

Ja powiedziałbym, że WinAPI z C to tak jakby używać asemblera - da się w taki sposób zrobić naprawdę bardzo wiele, ale używanie wywołań i struktur WinAPI jest po prostu bardzo żmudne.

Azarien napisał(a):

Powstaje jednak pytanie: czy ten program w ogóle ma coś wyświetlać?

Tak, oczywiście. Na bieżąco zmiany w bitmapie - a bitmapa w oknie windowsowym z podstawową obsługą (typu podstawowe menu Load/Run/Save/Exit etc.)

Radujże się. Znalazłem swój stary program z pracy dyplomowej który działa na bitmapach *.BMP przy użyciu WinAPI, i robi:

• zmiana kontrastu
• negatyw
• zmiana na skalę szarości
• zmiana jasności
• progowanie
• rozmywanie

chociaż jak patrzę na ów kod, to mam spore wątpliwości, czy takie coś godzi się ludziom pokazać...

EDIT:
No dobra @darekdarek, zrobimy tak - obacz czy to, co ów program robi jest mniej więcej tym, czego potrzebujesz, i dostaniesz kod.

poka poka ;)
tylko w całości, żebym nie zadawał miliona pytań, co jeszcze trzeba dokleić
no bo z kontekstu wynika, że innej wartości niż sentymentalna to chyba nie ma :)

i żeby nie było, to nie jest ani moja praca domowa ;) ani dokładnie to co będę próbował zrobić, ale chętnie bym przeanalizował w celu edukacyjnym

EDIT: tak - co do ogólnych ram, to to czego szukam
jako ogólne ramy rozumiem rzeczy tak podstawowe jak:

• Windows;
• C;
• WinAPI;
• Okno z menu;
• Działania na bitmapie.

Różnice takie, że to docelowo będą całe animacje obrabiane "klatka po klatce" a operacje "piksel po pikselu" będą robione na podstawie wielu plików/warstw jednocześnie.
Taki jest zamysł.

BTW: Jak np. robisz negatyw czy szarość, to rzeczywiście jest to operacja piksel po pikselu (pętla w pętli) przez cały obrazek czy jakaś inna operacja (np. po prostu na palecie kolorów)?

Zmiana na skalę szarości to o ile pamiętam jest zrobiona poprzez uśrednienie kanałów RGB. Ale jak dokładnie, to już sam sobie przeanalizuj.

O Swarogu przenajsłodszy, toć to jeszcze projekt dla Visual Studio 6.0...o.O

Spasiba

Ja tam schodziłem do czeluści WinApi jak robiłem na win ce, ale średnio bym tam wracał :-)

MasterBLB napisał(a):

Zmiana na skalę szarości to o ile pamiętam jest zrobiona poprzez uśrednienie kanałów RGB. Ale jak dokładnie, to już sam sobie przeanalizuj.

Innym sposobem jest obliczenie jasności piksela i użycie go jako odcienia szarości. Poniższego przelicznika używam w swoim projekcie:

shade = (r * 0.299) + (g * 0.587) + (b * 0.114)

r = shade
g = shade
b = shade

Łatwizna. Mam jeszcze kilka innych algorytmów, np. do rozjaśniania/przyciemniania kolorów, więc w razie czego mogę podać przeliczniki. Jeden z nich (przyciemnianie) opisałem na blogu – tam jest wersja działająca dość efektywnie.

@furious programming: Hmmm to chyba mój będzie szybszy, tylko 3 dodawania i 1 dzielenie:

z=(*(pBits+1)+*pBits+*(pBits+2))/3;//obliczenie wartości składowej skali szarości //pisownia zostawiona oryginalna, choć mi oczy krwawią...

Być może i szybszy, ale Twój wzór generuje znacznie jaśniejszy odcień. Dla przykladu posłużę się kolorem 54,111,205 – jest to odcień niebieskiego, którego używam w swoich projektach. Najpierw Twój sposób:

(54 + 111 + 205) / 3 = 123.333333

a teraz ten podany przeze mnie:

(54 * 0.299) + (111 * 0.587) + (205 * 0.114) = 104.67300

Po obcięciu części dziesiętnej mamy wartość 123 kontra 104 – to duża różnica. Sposób którego sam używam jest dość popularny, a wzór można znaleźć m.in. w tym artykule – Grayscale: Luma coding in video systems.

Jeśli wydajność jest istotna (skoro to mają być bitmapy „hurtowo”) to obróbkę grafiki bym zrobił w OpenGL-u na GPU. Będzie mega szybko.
Ale to już zadanie z gwiazdką, a nawet kilkoma.

Nie czytałem całego tematu, ale tak bardziej w odniesieniu do odpowiedzi @furious programming: i @MasterBLB

Jeżeli chcemy z koloru zdefiniowanego przez trzy składowe RGB do skali szarości, to od razu widać, że reprezentacja RGB nam w tym zadaniu nie pomoże, znacznie lepszym wyborem byłoby przedstawienie koloru w przestrzeni kolorów YCbCr.

Y to składowa luminacji, jest ona wielkością natężenia oświetlenia, Cb, Cr to dwie składowe chrominacji odpowiadające za kolor i natężenie koloru.

Jak widzimy Y będzie tą wartością, którą będzie nas interesować, warto wspomnieć, żę nie ma jednej dokładnej definicji przejścia z przestrzeni barw RGB do YCbCr, ale różnice między nimi są niewielki i często dla przyśpieszenia wykonywania obliczeń, wybieramy uproszczone wersje.

Przykładowo w zaleceniu ITU-R BT.709 zawarto: (link)
E'Y = 0.7154 E'G + 0.0721 E'B + 0.2125 E'R
E'PB = – 0.386 E'G + 0.500 E'B – 0.115 E'R
E'PR = – 0.454 E'G – 0.046 E'B + 0.500 E'R

Ten wzór może być dobrym kandydatem na uzyskanie prawidłowej luminacji.
Y = 0.2125 R + 0.7154 G + 0.0721 B

Jednak dla optymalizacji obliczeń wprowadza się pewne zaokrąglenia, lub próbuje się przybliżać wynik w inny sposób.
Przykłady znalezione w internecie:

Y = 0.33 R + 0.5 G + 0.16 B
Y = (R+R+B+G+G+G)/6
Y = (R+R+R+B+G+G+G+G)>>3

Wyniki dla (54, 111, 205)