Autor Wątek: Obiektowosc - co bedzie obiektem itp...  (Przeczytany 10177 razy)

truman

  • Gość
# Styczeń 11, 2007, 23:16:30
Witam.

Po raz kolejny w bardzo krotkim czasie zabieram sie za kolejny projekt. Dlugo zastanawialem czemu tak sie dzieje. Doszedlem do wniosku, ze powoduja to za duze ambicje (da sie ominac :P ) i "pisanie na zywca". Gdy tylko wpada mi jakis pomysl do glowy siadam i zaczynam pisac. Konczy sie to tym, ze gdy troche juz napisze zaczynam sie gubic w wlasnym kodzie. Po dodaniu komentarzy wszystko sie rozjasnia, ale pozostaje jeszcze jeden bardzo wazny problem. Gdy chce cos zmienic bo np okazuje sie, ze aby wprowadzic nowa rzecz musze dodac poprawki okazuje sie, ze zmiana czego kolwiek jest bardzo trudna. Przeczytalem kilka artykulow i stwierdzilem, ze nie docenie fazy projektowania to naprawde zly pomysl w przypadku czegos bardziej zlozonego od ponga. Pierwsze proby "planowania" okazaly zakonczyly sie zle... Po wielu udrekach skonczylem z jedym obiektem do przetrzymywania wszystkich innych, wyswietlania,  kontrolowania oraz wczytywania ich grafiki... Krotko mowiac okazalo sie, ze nie za bardzo wiem jak to robic, aby nie spalic kolejnego projektu juz na wstepie mam kilka pytan odnosnie moich pomyslow.

Teraz wymyslilem tak standardowy (mam nadzieje podzial zadan dla obiektow ):
a)grafika:
   -wczytywanie grafiki ( zapisywanie do wektora )
   -wyswietlanie grafiki

b)fabryka:
   -tworzenie obiektow ( zapisywane w wektorze )
   -usuwanie obiektow

c)glowny:
   -odpowiednie "kontrolowanie" grafiki (wlacz/wylacz :P )
   -"nadzorowanie" fabryki ( co i kiedy stworzyc/usunac )

Grafike (wskazniki na bitmapy) zapisuje do wektora, aby potem poprzez indeks odwolywac sie do odpowiedniego sprita.  Przy tworzeniu obiektu w fabryce podaje sie ind. pod ktorym znajduje mu sie jego sprite. Np.:
Dodaje obrazek glownego bohatera, udalo sie otrzymalem indeks (zalozmy, ze wynosi 5). Teraz przy tworzeniu obiektu ustawiam jego pole (np. sprind ) na 5. W takim wypadku rysownie jest bardzo proste. Skoro wszystkie obiekty sa w wektorze wystarczy, ze zrobie tak:
//pseudo kod
for ( i = 0; i < wektor_z_obiektami.rozmiar(); i++ )
rysuj_sprite( wektor_z_obiektami[i].x, wektor_z_obiektami[i].y, wektor_z_sprite[ wektor_z_obiektami[i].get_sind() ] );
   

No i swietnie tylko jak tu podczepic teraz animacje? Bardzo uciazliwe jest takze to, ze ciagle musze sie odwolywac do kartki z spianymi ind. spritow, aby wiedziec, czy juz taki wczytalem, czy nie i jestli tak to pod jakim jest ind..  Jak inaczej mozna to rozwiazac? Po za tym taki zapis wydaje mi sie strasznie dlugi. Moze lepiej dac kazdemu obiektowy wskaznik na sprita? Jak powinno wygladac wyswietlanie grafiki w 2D. Czy przechowywanie obiektow i spritow w wektorze to dobry pomysl?

Po prostu nie wiem jak wygladac co kolwiek. Gdzie trzymac obiekty i sprity? Jak je rozpoznawac i rysowac?
Czy obiekt powinie miec w sobie metody do poruszania sie, czy powinno sie robic jakis ogolny obj., ktory kontrolowalby polozenie innych?

Tu chodzi o podstawy w stylu: "co kontroluje co", "co ma co", "co jest zalezne od czego". Jak to ma wygladac, aby sie nie pogubic i wszystko bylo elastyczne.

Przepraszam... Post jest napisany bardzo chaotycznie i moze byc trudny w zrozumieniu. Wynika to z faktu, ze w ogole nie mam pojecia na ten temat i staralem sie zawrzec tu jak najwiecej pytan i moich watpliwosci. Jezeli czegos nie da sie zrozumiec przepraszam jeszcze raz i postaram sie to napisac jasniej.

PS.: Prosilbym o tytuly jakis Open Source 2D gier pisanych w c++. Szukalem sam, ale cos nie moglem znalec w odpowiednim jezyku. Znalazlem tylko cos w Pythonie i Javie, a chcialbym zobaczyc jak to rozwiazuja ludzie w ich projektach.

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

truman

  • Gość
# Styczeń 12, 2007, 00:05:29
o obiektach najbardziej bazowych mozesz myśleć jak o czasownikach np. chodzi, gryzie. potem zbuduj z tych klocków  rzeczowniki np kot będzie składał się z chodzi, gryzie, wygląda itd.

co do gier otwartych 2d hmm może www.allegro.cc gdzies w dziale projekty

Offline Ghoel

  • Użytkownik

# Styczeń 12, 2007, 00:42:48
Witam, z tego co widzę brakuje ci menadżera. Menadżer jest to specjalna klasa która zarządza danym typem zasobów (tekstury, dźwięki, efekty, czcionki, itp.) - tzn. tworzy je , udostępnia i zwalnia. Aby jakoś to naświetlić powiem ci jak to u mnie wygląda z zarządzaniem teksturami.
Po pierwsze menadżer jest singletonem którego kluczową metodą jest zwracanie wskaźników na żądane tekstury. Aby nimi lepiej zarządzać ma własną strukturę TextureHolder, która to składa się z 2 pól  - nazwy(lub innego identyfikatora) oraz samego obiektu tekstury. Obiekty typu TextureHolder trzymane są w wektorze mojego singletonu. Kiedy jakaś klasa potrzebuje tekstury to zwraca się o nią po nazwie do mojego menadżera. Wtedy on sprawdza cały wektor czy ma już takową załadowaną. Jeśli tak to przekazuje wskaźnik na teksturę, jeśli nie to tworzy ją, ładuje do TextureHolder'a, wrzuca go do TextureHolder'a wektora i dopiero wtedy zwraca wskaźnik.

Obiekt który potrzebuje tekstury musi znać jej nazwę, a przy tworzeniu (lub inicjowaniu) zgłosić się do menadżera tekstur o wskaźnik.

Gdyby coś było niejasne podaję plik nagłówkowy:

 

#pragma once

#include <vector>
#include <d3dx9.h>

using namespace std;

struct TextureHolder
{
char* m_cName;
LPDIRECT3DTEXTURE9 m_Texture;
TextureHolder( char* name, LPDIRECT3DTEXTURE9 texture);
~TextureHolder();
};

class TextureManager{
private:
static TextureManager m_instance;
vector<TextureHolder*> m_pTextures;
LPDIRECT3DDEVICE9 m_pd3dDevice;
TextureManager();
~TextureManager();
public:
void Init(LPDIRECT3DDEVICE9 pd3dDevice);
static TextureManager* GetInstance();
LPDIRECT3DTEXTURE9 getTexture(char* name);
void ReleaseAll();
};

Offline Reg

  • Administrator
    • Adam Sawicki - Home Page

# Styczeń 12, 2007, 12:38:07
Po pierwsze, zabieranie się za kolejny projekt i niekończenie swoich projektów jest czymś normalnym. Można tego nie akceptować, próbować z tym walczyć, ale do końca się tego nie wyeliminuje. Wszyscy tak mają :)

Cytuj
Po dodaniu komentarzy wszystko sie rozjasnia
Komentarzy się nie dodaje, tylko się je pisze w czasie pisania kodu.

Cytuj
Gdy chce cos zmienic bo np okazuje sie, ze aby wprowadzic nowa rzecz musze dodac poprawki okazuje sie, ze zmiana czego kolwiek jest bardzo trudna.
Z tym można walczyć i próbować to minimalizować za pomocą dobrej, przejrzystej, prostej struktury programu, szczególnie z użyciem programowania obiektowego, ale też do końca nie da się tego wyeliminować. Poza tym jest tutaj taka pułapka, że im bardziej będziesz się starał wszystko pisać ogólnie i uniewersalnie, tak żeby było łatwe do rozszerzania i modyfikowania, tym trudniejsze i dłuższe będzie pisanie wszystkiego, a tym samym mniejsze szanse, że cokolwiek skończysz.

Z projektowaniem i z wykorzystywaniem programowania obiektowego dobrze kombinujesz. Nie przeszadzaj tylko z tymi abstrakcjami takimi jak fabryka. W programowaniu obiektowym, szczególnie na początku jego nauki, chodzi o to żeby klasy i obiekty reprezentowały coś co ma sens i faktycznie istnieje - np. mapę, potworka, wczytaną do pamięci teksturę.

Rozwiązaniem konkretnego problemu o którym piszesz jest napisanie managera - o tym wspomniał już kolega powyżej. Manager ma być 1. Szybki 2. Wygodny. To jest mechanizm który wczytuje, zwalnia, ogólnie przechowuje, zarządza i udostępnia wszystkim zasoby takie jak wczytane do pamięci tekstury czy dźwięki. Może być jeden dla wszelkich zasobów w grze albo po jednym dla każdego rodzaju zasobów. Mówiąc abstrakcyjnie, zasoby można identyfikować przez:
- Nazwę pliku czy inny łańcuch który może posłużyć do jego wczytania
- Jakiś uchwyt, czyli identyfikator liczbowy (niekoniecznie indeks w tablicy, ale może być)
- Bezpośrednio wskaźnik do obiektu danego zasobu (bo zakładam że masz do tego własną klasę, która dopiero przechowuje coś takiego jak IDirect3DTexture9* albo FMOD_Sample*).
Kwestią do przemyślenia jest, którą z tych rzeczy ma przechowywać np. obiekt potworka celem zidentyfikowania tekstutry z użyciem której ma się rysować.

Dodam, że takich rezczy nie da się za bardzo opisać w sensie pytania: "chcę to i to, gubię się w tym, nie wiem jak to wszystko zorganizować" i odpowiedzi w stylu "napisz klasę taką, taką i taką", bo nikt nie nie będzie myślał za kogoś, a odpowiedź ściśle zależy od konkretnej sytuacji i nie ma tu aż tak bardzo gotowych wzorców (choć pewne ogólne są - np. ten manager). Jednym słowem - musisz samemu pomyśleć (pomyśleć przed napisaniem! - czyli zaprojektować, przynajmniej w głowie), zrobić tak jak uważasz że będzie dobrze, a jak tylko zaczyna się coś gmatwać to przemyśleć od nowa i przerobić (natychmiast! nie czekać z tym i nie robić tymczasowych obejść! od tego właśnie powstaje kod spagetti!).

Nie wiem też czy dobrym pomysłem na naukę organizacji różnych rzeczy jest prezglądanie gotowych kodów. Może... Każdy uczy się inaczej. Tak czy owak, ja potem własne myślenie, ćwiczenie itd. Każdy następny projekt jest lepszy od poprzedniego :)

Cytuj
o obiektach najbardziej bazowych mozesz myśleć jak o czasownikach np. chodzi, gryzie. potem zbuduj z tych klocków  rzeczowniki np kot będzie składał się z chodzi, gryzie, wygląda itd.
Eeee, coś mi tu nie gra. Klasa/obiekt to rzeczownik i w takiej postaci powinna być wyrażona jego nazwa, np. Potworek, Mapa, Tekstura. Czasowniki to metody klas i funkcje (np. Atakuj, Jedz, Idź), a pola/atrybuty i zmienne to przymiotniki (wielkość mówi czy duży czy mały, siła mówi czy silny czy słaby).

Jeżeli chcesz do tematu o który pytasz podejść bardzo poważnie (choć żeby pisać to nie musisz aż tak), poszukaj czegoś (materiały w Sieci, książki) na temat projektowania i/lub programowania obiektowego, na temat wzorców projetkowych, na temat notacji UML. Oczywiście zakładam, że przed tym doskonale znasz programowanie obiektowe w sensie mechanizmów jakie zapewnia w tym zakresie język programowania, którego używasz - czyli jak się pisze klasy, jak się używa dziedziczenia, metod wirtualnych itd.

Offline pawelad

  • Użytkownik
    • strona domowa

# Styczeń 12, 2007, 14:12:24
Postaraj się poszerzac swój projekt o kolejne klasy, zamiast projektowac wszystko od od poczatku do konca, bo wielu rzeczy nie da sie przewidziec. Zrob jedna klase w miare dobrze i dopiero bierz sie za kolejną.
Dobre są luzne wiązania miedzy klasami, te sie robi robiac pola jako wskazniki do interfejsów klas. Jak napaprzesz cos w jednej( implementacji interfejsu) to nie ma to wplywu na drugą i masz przy okazji krotki czas rekompilacji.
Głowny kręgosłup na dziedziczeniu, czyli basowa rysowanych to interfejs, a po nim jednodziedziczenie juz wlasciwych obiektow rysowanych lub dalszych interfejsow. U mnie na tym dziedziczenie sie konczy, potem juz tylko skladanie klas z interfejsow.
Gdzie sie da singleton, zebys sie latwo dostal do obiektow z dowolnego miejsca kodu.
Lepiej wszystko robic po swojemu i uczyc sie na błędach.
Optymalizacja na koncu.
Najwazniejsze to chyba trzymac sie interfejsów i kompozycji. Co do UML i wzorcow, to nie jestem zwollenikiem, niech ci to nie przesłoni prawdziwego celu projektu, ja projektuje na A4 tak jest najszybciej.

PS. Swojego projektu jeszcze nie skonczyłem a tłukę go już 7month, tak że nie wiem czy moje uwagi są dobre.

Offline zarius

  • Użytkownik

# Styczeń 13, 2007, 14:44:18
Ja robilem tak jak kolega (czytaj postawielm szkielet a potem dopisywalem wszystko co mi bylo potrzebne) i zdecydowanie odradzam takie podejscie.

Pol roku minelo od kiedy zaczalem tworzyc swoj projekt i w pewnym momencie mowiac brzydko zakopalem sie w powiazaniach pomiedzy klasami. Przez to zmiana czegokolwiek bez narazenia sie na przepisywanie 1/4 kodu jest niemozliwa.

Od jakiegos czasu jestem zmuszony pisac wszytko na nowo (duzo kodu kopiuje ale rozbijam to inaczej). Ogolnie poki co zapanowal nowy porzadek.

Teraz zrobilem to tak:

- Rozpisalem jak najbardziej ogolna hierarchie klas ktore mi sa potrzebne na danych etapie
- Zchodze nizej w hierarchii do danego podsystemu ktory aktualnie tworze i najpierw definiuje wszystkie klasy jakie bede uzywal i powiazania miedzy nimi
- Zaczynam kodzic dany "sektor" czy "modul" no i wiadomo ze w praniu wychodzi cos czego potrzebuje wiec to dopisuje odpowiednio dolaczajac do schematu.

Dzieki temu mam przynajmniej porzadek w powiazaniach miedyz klasowych - ot taka fasada dobra rzecz ;d

truman

  • Gość
# Styczeń 13, 2007, 16:09:21
nie rób żadnych powiązań albo tak mało jak tylko się da, nie ma nic gorszego, zamiast tego komunikator międzyobiektowy (kazdy obiekt implementuje końcówkę do przesyłania i odbierania) i jeden obiekt który jest 'routerem' i tym wszystkim zarządza. message to hashtabla stringów.

truman

  • Gość
# Styczeń 13, 2007, 16:51:17
trochę rozwinę bo znalazłem chwilkę.
końcowe obiekty gry (jak. np żołnierze) powinni się komunikować z resztą obiektów na podobnej do sieci zasadzie opisanej powyżej. Program nie powinien znać z góry obiektów gry ich typów, co one potrafią itd. jest to rzecz nieprzewidywalna.
Natomiast co do głębszego kodu wymagającego większej prędkości polecam mechanizm COM/Corba lub podobny swój gdzie jest centralny rejestr obiektów z którego można wyciągać obiekty po nazwie interfejsu naprzykład.
Pozatym najwazniejsza jest maniera myślenia obiektowego. Z reguły lepiej jest zrobić dzidziczenie niż jakieś sztywne dowiazania do innych obiektów. Jeśli tak nie jest to najczęsciej po prostu jest to źle zaprojektowane. W takim projektowaniu może pomóc taka zasada:
Jeśli masz naprzykład obiekty start->menu->level i teraz chcesz wyciągnąć z tego menu bo podczas testowania nuży Cię jego częste oglądanie i jeśli start->level ruszy poprawnie to znaczy że zrobiłeś swoją gre poprawnie pod względem obiektowym.

Offline Reg

  • Administrator
    • Adam Sawicki - Home Page

# Styczeń 14, 2007, 11:21:28
nie rób żadnych powiązań albo tak mało jak tylko się da, nie ma nic gorszego, zamiast tego komunikator międzyobiektowy (kazdy obiekt implementuje końcówkę do przesyłania i odbierania) i jeden obiekt który jest 'routerem' i tym wszystkim zarządza. message to hashtabla stringów.
LOL :) Ja rozumiem że jak najmniej powiązań to jest ideał, ale nigdy nieosiągalny. W praktyce zawsze używa się wielu rzeczy, choćby takich jak klasa Wektor, Macierz, obiekty Logger, Konsola, Profiler i wiele innych. Kod układa się wtedy w takie warstwy z których te niższe (jak moduły bazowe) nie mają pojęcia o tych wyższych (jak silnik, nad nim gra), ale wielu powiązań między tymi warstwami i wewnątrz niech nie da się uniknąć. W samej grze faktycznie często robi się spagetii i wszystko musi używać wszystkich, należy z tym walczyć, ale wątpię czy przesyłanie sobie komunikatów między obiektami, w dodatku przez każdorazowe zamienianie ich na łańcuchy z parsowanie z powrotem na dane, jest dobrym pomysłem. Szczególnie, że taki (jakże powolny!) protokół komunikacji musi być znany wszystkim obiektom i ilekroć o coś go wzbogacamy, inni też muszą o tym wiedzieć - na jedno wychodzi :P

Offline pawelad

  • Użytkownik
    • strona domowa

# Styczeń 14, 2007, 13:15:22
No ja juz prawie skonczylem swoj projekt. Na samym koncu wszystko przebudowałem żeby oddzielic abstrakcje od implementacji i zrobilem wszystko zeby zablokowac userowi narobienie bigosu. Nie wyglada to najlepiej, duzo przyjazni, powiazan w cholere. Zaprzyjazniałem klasy rzeczywiste z fabryka, zeby ta miala swobodny dostep do obiektu bo walenie akcesorow nie mialo sensu, obiekty maja wszystko prywatne zeby user nic nie mogl zrobic tylko fabryka.
No i user ma przestrzenie nazw przez które dostanie sie do kazdej nazwy i podejrzy mi pola, ale przebudowywac przestrzenie nazw mi sie nie usmiecha, nie przewidzialem tego. Ku..a programuje juz kilka lat i nie potrafie wypracowac sobie idealnej metodologii projektowania w c++, pie..rze wracam na pole uprawiac ojcowizne :).

Offline Steel_Eagle

  • Użytkownik

# Styczeń 14, 2007, 13:25:57
Cytuj
końcowe obiekty gry (jak. np żołnierze) powinni się komunikować z resztą obiektów na podobnej do sieci zasadzie opisanej powyżej. Program nie powinien znać z góry obiektów gry ich typów, co one potrafią itd. jest to rzecz nieprzewidywalna.
I do tego sluzy polimorfizm, najszybsze i najbardziej obiektowe rozwiazanie. Rozsylania komunikatow powinno uzywac sie tam, gdzie polimorfizm nie daje rady  ;)

Cytuj
Natomiast co do głębszego kodu wymagającego większej prędkości polecam mechanizm COM/Corba lub podobny swój gdzie jest centralny rejestr obiektów z którego można wyciągać obiekty po nazwie interfejsu naprzykład.
Nie do konca rozumiem co chciales powiedziec, ale w dobrze napisanym silniku nie powinno sie uzywac rzutowania w dol zbyt czesto (najlepiej wcale).

Cytuj
Pozatym najwazniejsza jest maniera myślenia obiektowego. Z reguły lepiej jest zrobić dzidziczenie niż jakieś sztywne dowiazania do innych obiektów. Jeśli tak nie jest to najczęsciej po prostu jest to źle zaprojektowane.
Nie. Obiektowosc faworyzuje skladanie obiektow (kompozycje) niz dziedziczenie. Kompozyty zawieraja wskazniki na interfejsy wiec o sztywnosci nie ma mowy. Tak jest dobrze zaprojektowane  ;)

Cytuj
Jeśli masz naprzykład obiekty start->menu->level i teraz chcesz wyciągnąć z tego menu bo podczas testowania nuży Cię jego częste oglądanie i jeśli start->level ruszy poprawnie to znaczy że zrobiłeś swoją gre poprawnie pod względem obiektowym.
Niebardzo  :P  Mozna zrobic to co opisales, ale obiektowosc nie polega na wyjmowaniu klas posredniczacych  ;)

Polecam ksiazki z serii Inzynieria Oprogramowania WNT :)

truman

  • Gość
# Styczeń 14, 2007, 14:43:12
Cytuj
Natomiast co do głębszego kodu wymagającego większej prędkości polecam mechanizm COM/Corba lub podobny swój gdzie jest centralny rejestr obiektów z którego można wyciągać obiekty po nazwie interfejsu naprzykład.
Nie do konca rozumiem co chciales powiedziec, ale w dobrze napisanym silniku nie powinno sie uzywac rzutowania w dol zbyt czesto (najlepiej wcale).
Bo zbyt ogólnie się wyraziłem. Polecam materiały dotyczące technologii Com i Corba. To wychodzi poza ramy tematu i moje chęci klawiaturowe ;)

Cytat: Regedit
LOL Smiley Ja rozumiem że jak najmniej powiązań to jest ideał, ale nigdy nieosiągalny.
Napisałem że warto do niego dążyć.

Podsumowując techniki przezemnie wspomniane mogą się podobać lub nie. Zerlo zapytał się w jaki sposób zminimalizowaliśmy w przeszłości przepisywanie 20 raz kody od nowa więc mu o tym opowiedziałem co ja stosuję. Życzę panom Regedit i Steel_eagle w przyszłości więcej ukończonych projektów w praktyce, mniej książkowych dogmatów.

Offline Xion

  • Redaktor
    • xion.log

# Styczeń 14, 2007, 18:41:57
No proszę, wywiązała się całkiem ciekawa dyskusja... W istocie o projektowaniu z użyciem technik obiektowych napisano już sporo kilobajtów i w dużej części wiedza ta jest bardzo przydatna. Osobiście uważam jednak, że w tej dziedzinie tworzenia programów doświadczenie jest niezwykle ważne, a co za tym idzie - także pewna doza intuicji. Po prostu trzeba popełnić parę złych projektów, przepisać je w dużej części od nowa, poprawiać, porzucać, itd., żeby, po pierwsze, zdobyć doświadczenie w samym stosowaniu technik obiektowych, a po drugie, znaleźć swój własny sposób "dochodzenia" do właściwej struktury projektów.
Naturalnie znajomość choćby wzorców projektowych czy (koniecznie) ogólnych założeń OOPu (bardziej w oderwaniu od konkretnego języka programowania) może być przydatna. Jednak ortodoksyjne ich stosowanie wcale nie musi, przynajmniej na początku, przynosić większych pożytków. Jeżeli bowiem nie potrafimy ogarnąć własnego projektu, albo co gorsza, nie wiemy dokładnie, jak do niego doszliśmy, to nic dobrego z tego nie wyniknie :)

Dodatkowo w przypadku gier dochodzi jeszcze czynnik efektywności kodu. Na przykład generalnie chwalebna idea, aby obiekty miały jak najmniej powiązań i były jak najbardziej niezależne, może nadwątlać tę efektywność; nawet niekoniecznie wtedy, gdy stosuje się takie ciekawe pomysły jak proponuje Regedit (czyli przesyłanie tekstowych komunikatów - no ładnie, a o metodach wirtualnych i wzorcu Polecenie to już nie słyszeliśmy? ;)) Tym niemniej nie należy z góry zakładać, że trzeba elegancję obiektowego projektu składać na ołtarzu szybkości - pamiętajmy, że wszystkie optymalizacje są winne dopóki nie udowodnią swojej niewinności, a ważne jest to 20% kodu, które wykonuje się przez 90% czasu.

Offline Steel_Eagle

  • Użytkownik

# Styczeń 14, 2007, 19:11:04
Xion masz punkt ;) Dorzuce jeszcze tylko, ze obiektowosc moze spowolnic kod, ale dobry kod obiektowy mozna lepiej i szybciej optymalizowac.

Cytuj
Podsumowując techniki przezemnie wspomniane mogą się podobać lub nie. Zerlo zapytał się w jaki sposób zminimalizowaliśmy w przeszłości przepisywanie 20 raz kody od nowa więc mu o tym opowiedziałem co ja stosuję. Życzę panom Regedit i Steel_eagle w przyszłości więcej ukończonych projektów w praktyce, mniej książkowych dogmatów.

@Truman: Poprostu mowisz troszke od rzeczy ;) Zweryfikuj swoja wiedze i nie denerwuj sie za bardzo  :)

truman

  • Gość
# Styczeń 14, 2007, 20:56:59
Proponuję czytać ze zrozumieniem. Naprzykład kilka razy. Cieńko będzie w takim razie panowie. No ale życzę powodzenia.