|
|
Spravuje: Mr.Spock
Počet příspěvků: 3834
|
Bývalá veřejná diskuse členů vývojářského týmu WDK Games, do které se mohl zapojit opravdu ka?dý, dnes "jen" nejnav?těvovaněj?í fórum s řadou hybridních bytostí bez mozku...
|
|
|
| | | naku: hele, prihlas se do maillistu na sourceforge, a poradne probereme GUI - mel bych par pripominek, a list mi prijde jako nejvhodnejsi. |
|
|
|
| | | Jirka006: no vidis,to jsme nejak neprobrali... No, ja muzu skoro vzdy, krome ctvrtka a patka, a obcasnych vychylek, na ktere stejne netreba brat zretel. |
|
|
|
| | Pěkná diskuse, pánové :-)
Bude tedy nějaká schůzka ? |
|
|
|
| | | Samozrejme, predchudci a nasledovnici jsou v souboru uvedeni pod nejakym jmenem nebo cislem (ID ? :) a jejich patricna struktura se najde az v pameti. Asi to bude chtit dvoucestny, aby se nemusely technologie nejdive definovat, nez na ne nekdo odkaze. |
|
|
|
| | | Jo, a ten strom se v pameti vytvari pri startu - je cely v pameti. Naplni se udaji ze souboru - nazev technologie, pocet bodu pro vynalezeni, nasledovnici, potrebni predchudci. Ten soubor by slo zapsat jako XML, aby se dobre editoval. Parser XML, zvlast pro tak jednoduchy typy dat, je docela v pohode, a po startu se klidne muze odloadovat. Nechci, aby byly ty technologie soucasti kodu, protoze pak bychom si s nim neohli poradne hrat - po kazde zmene rekompilace, a to je blbost, s prominutim. Chci dusledne oddelit data od algoritmu. |
|
|
|
| | | naku: jiste, vyvojovy strom si predstavuji jako pravy, nefalsovany strom jao dynamickou datovou strukturu. Nekde u korene vynalezas nekterou z napr. 6 prvnich technologii. Po jejim objeveni se umozni vynalezat jeji potomci - ale ne drive, nez jeji potomek ma vynalezene vechny sve predchudce - tady musi byt jeste asi i pole zpetnych pointeru. Ja bych ti to nakreslil, ale nevim... No, zkusim to. |
|
|
|
| | No uz tam je, ale....
You cannot submit news for a project unless you are an admin on that project.
|
|
|
|
| | | Deska bude na SForge muj navrh ohledne GUI... |
|
|
|
| | Takze... vysvetleni (vcera vecer mi spadlo pripojeni, tak sem nestinul odpovedet)
Problem: Requiments __u16 nebo * ?
Takze, pouzijeme-li __u16, tak budeme muset mit jakesi pole, kam vsechny jiz vynalezene vynalezy (resp. jejich ID)ulozime. Oproti tomu, kdyz tam bude pointer, staci do kazedo prvku pridat neco jako boolean (no...v C int :) - "vynalezen".
Problem je v tom, ze kdybychom chteli nacitat informace o vybaveni z souboru (snadna rozsiritelnost; mozna by sli cist ze souboru i vyalezy), tak bychom pointery ukladat do souboru nemohli (no... mohli) resp. bychom museli vymyslet nejakej relativne kumstovej algoritmus...
BTW. Pokud by nas software byl GNU (tzn. ze se nebudem stydet za nas kod ;), tak se na __u16 muzem vykaslat, kazdej muze upravit primo zdrojak...
BTW2. Tak me napada, ze do stromu by to chtelo ke kazdymu vynalezu pridat krom nazvu i nejakej "hlod" (popis :)
Stejne si ale praci s * neumim zatim ( v pripade stromu) moc dobre predstavit... Jasne ! Uz sem to pochopil ! Ty myslis, jako ze se bude vyhodnocovat od koruny ke korenum.... genialni.... |
|
|
|
| | A este detail - samozrejme ze ne *PRVEK ale *prvek :)))
PS. 2 verze vyvojoveho stromu (az to tady vyjasnime) bude
a) snad posledni vec co tady budem resit - presunul bych se do coders
b) napsana dle happzova standartu se kterym plne souhlasim !!! |
|
|
|
| | | Naku: ted jsem te nepochopil, jak to presne myslis. Muzes to rozvest? Chapu, ze se ti jedna o neco kolem predmetu, umoznenych urcitou technologii. A dal? |
|
|
|
| | Souhlas... takze C (sice se uz ted desim dialogovejch oken... ale budiz :) - podporou nam budiz nize, vyse, vsude zminovane Allegro, ktere si bez ++ vystacilo......... obavam se ale, ze prave standartni Allegro GUI je dost zastrasujici priklad :((
Ad ID - Kdybyste me videli !!!! Prave jsem popsal 3 stranky textu uplne zbytecne - ujasnoval sem si nazor. Takze - jelikoz veci budou muset mit taky neco jako odkazy na ID vynalezu sou 2 moznosti.
int (resp. __u16)
Komplikace je ze bude potreba udelat neco jako mnozinu uz vynalezenych IDu - C++ ma na to template, ale ani v C neni problem - dynamicky pole, ktary se bude prohledavat - vzhledem k tomu, ze pocet vynalezu bude asi tak pod 500 (no... Uni, nechci te podcenit... :) tak by to nemelo bejt uplne pomaly...
A co ty vjeci ? To bych videl jako zakladni argument "pro". Udelal bych je formou plug-inu (ext. souboru), aby sli lehce editovat (viz. dale)
pointer (resp. *PRVEK)
Nadherne ulehci manipulaci, odpadne potreba delat neco jako buffer na vynalezene vynalezy, ale zbrane by se museli definovat ve zdrojaku (resp. nejakej algoritmus co prevede ID na pointer uz pri nacitani... slo by....) |
|
|
|
| | Aha... takze bysme klidne zvladli i C :) Abych pravdu rekl, tak ted se mi moc nechce propatravat C++ opravdu do hloubky, zvlast, kdyz mi v C nic moc nechybi. Pravda, objekty to nejsou, ale i tak si umim poradit. A navic, je mi blizsi tim, ze je o fousek niz nez C++, a to se mi libi :)
Ad ID: ne, ID by melo zustat int, ale pak tam pouzivas int[5], kde ukryvas ID potrebnych predchudcu - misto toho bych dal prave PRVEK *[5] na predchudce. |
|
|
|
| | | Omlouvam se, ze neomluvitelne pretezuju forum, ale vzpomel jsem si na jednu vec, co by mohla zajimat vsechny - na 85% mame dalsiho MAX grafika.... |
|
|
|
| | Na druhou stranu, momentalne si nejsem jistej, jestli sem schopnej psat fakt pure C... to C++ dost mate (napr. deklarace counteru for cyklu v jeho hlavice nebo luxus v podobe pretezovani operatoru, new na misto mallocu...
Ciste C++ - no... zajimava myslenka a moc pohodlna (vektory, objekty...) - cely Allegro je v relativne cistym Cecku. Relativne znamena, ze v zajmu rychlosti vyuziva direktivu asm, ktera je sice nad normu v C, ale vsechny kompilatory co znam ji podporujou. (Samozrejme je i volba kompilace v skutecne cistem C, ale ta je IMHO dost bezpredmetna...)
C/C++ hybrid - nejni to zas tak neuskutecnitelna predstava - pokud se budem drzet normy a podstive psat extern "C" { } ... ale na druhou stranu - kdyz uz objekty, tak proc jen v GUI....
Shrnuto a podtrzeno - momentalne sem programator na prd ;) Ac sem kdysi sqele (no... ale jo) umel Ccko, zmaten puvaby (a nesvary) C++ (jazyka, jehoz dve + nejsem - zatim - schopen na 100% vyuzit) sem se skutcne ciste C psat odnaucil.... |
|
|
|
| | | (Jen pro informaci - C++ se rel. intenzivne ucim od zari (presneji - prechod z C) a z cely STL si tykam asi s 5-8 sablonama... z 30 - je sice pravda, ze nektery sou nevyuzitelny, ale....) |
|
|
|
| | Dobra tedy - upravim svoji "teorii stromu" na tu dvoj-podtrzitkovou formu.
Ad C++ no - nerekl jsem, ze je nezbytne nutne uzit C++, ale ze to je vhodne - usetri to IMHO spoustu prace. Zase na druhou stranu nejni prechod z C zas tak jednoduchej - pokud chces proniknout fakt pod povrch a alespon malinko pochopit templaty,interatory etc. a proniknout do STL, muze to bejt zalezitost mesicu :(
Ad vyvojovej strom: Proc myslis, ze by v ID mel misto intu bejt pointer ? Me se zda cislo praktictejsi (na manipulaci), ale.... ? |
|
|
|
| | | Nu, ohledne formy jsem pro __, jazyk bych bral C, ale kdyz tvrdis, ze C++ je pro GUI lepsi, tak dobra, C++ tedy. Jenom se budu muset kouknout na nejake ty zaludnosti, aby me pak nekde jazyk neneachytal :() |
|
|
|
| | Tak co ? Jakou formu zvolime definitivne ???
__ nebo OpenGL ? Me je to jedno, ale jestli se ma zacit neco psat...
Ad jazyk ????? |
|
|
|
| | | (PS. Du domu.... tak zasz wecer....) |
|
|
|
|
HLAVNÍ STRÁNKA
UŽIVATELÉ
DISKUZNÍ FÓRA
VYHLEDÁVÁNÍ
STATISTIKY
AKCE
NASTAVENÍ
FAQ
[ ARCHÍV ]
|
