DKMapa 1.0

[DeletedUser3752]

Nová verze, nový thread...

Kdo má zájem, může si vyzkoušet, jak vypadá první veřejná alpha (tj. zatím nedokončená) verze 1.0:

<nadále neplatný odkaz>

V porovnání s předchozí verzí jsem udělal tyto změny:

• přibylo grafické rozhraní pro aktualizace a výběr světa
• jde měnit velikost okna (tím pádem funguje i fullscreen)
• přibyl zoom mapy ovládáný kolečkem myši
• v menu lze přepnout na zobrazování vesnic podle počtu bodů (v tomto režimu se vesnice neoznačují, ale jas žluté barvy určuje počet bodů)
• informace o vesnici se nyní ukazují jako tooltip (malé okénko u ukazatele myši)
• kliknutím na vesnici se vesnice "vybere" a údaje o ní naskočí vlevo
• pokud je vybrána nějaká vesnice, v tooltipu se navíc ukazují doby přesunu jednotek

Zatím ovšem ještě není doprogramováno:

• přidávání a ubírání světů z grafického rozhraní
• ovládání a zobrazování seznamů vybraných kmenů, hráčů a vesnic (tj. podstatná část ovládání vpravo)
• přímé odkazy na WWW stránk hráčů, kmenů a vesnic

Další poznámky:
V předchozí verzi jsem si stěžoval, že kód pro vykreslování je poněkud nešťastný. Teď jsem ho přepsal čistě Javovsky a byl jsem překvapen, jak je to svižné. Ovšem dokud jsem to nespustil pod Windows. Zvláště při větších velikostech výřezu a nízkém zoomu je rychlost překreslování dost zoufalá. :-( Nevypadá to ale, že bych s tím chtěl něco dělat...
Ověřte prosím udávané časy přesunů jednotek na jednotlivých světech. Počítám to tak, jak myslím, že by to mělo být, ale to neznamená, že je to dobře. A hlásit se jen kvůli tomuto do všech světů nehodlám...
Výběry v této verzi jsou zatím natvrdo zadané v kódu a jde o výběry týkající se Světa 1.


- Jirka

 

[DeletedUser237]

tak co ja vim tak by doby presunu jednotek mely byt spravne uvedeny v napovede pro kazdy svet (kazdy svet ma svou zalozku)

 

[DeletedUser2029]

Vypadá to perfektně.

Pomalé překreslení, s tím asi nic nenaděláme. (Nevím jak to děláš, ale používáš-li pro zoom "StretchBlt", tak si zkus pohrát s "SetStretchBltMode". Defaultně je u win řady NT (NT a výše) nastaven na "HALFTONE" a ten je dost pomalý, někdy i v případě zvětšování/zmenšování o celé násobky.)

----

A mám drze pár poznámek k už funkčnímu ovládání. Tooltip mi zůstává moc krátkou dobu. A zoom kolečkem mi přijde na opačnou stranu (- i mým subjektivním podvědomým chováním, i třeba obráceně, než to má google earth v default nastavení)

---

Vypadá to nádherně. Skvělá práce. I ta síla barev pro vesnici (Mimochodem, neuvažuješ barvu od určité bodové hranice zase zeslabovat? Určitě nad deset a půl to akorát jen žere lidi ze selského dvora). Chtěl jsem si něco takového udělat (mám jednorázové mapy) i pro hráče a udělat relativní barevné váhy vůči hráčům v okolí a prolínání do dálky, ale je to šíleně počtů a nenašel jsem optimální algoritmus nastavení maximální hodnoty. A tak jsem se tím dál nezabýval a na mých jednorázovkách se tak nedostal ani k té jednoduché síle vesnic - teď ji vidím poprvé, díky. Paráda.

 

[DeletedUser3752]

Vypadá to perfektně.

Pomalé překreslení, s tím asi nic nenaděláme. (Nevím jak to děláš, ale používáš-li pro zoom "StretchBlt", tak si zkus pohrát s "SetStretchBltMode". Defaultně je u win řady NT (NT a výše) nastaven na "HALFTONE" a ten je dost pomalý, někdy i v případě zvětšování/zmenšování o celé násobky.)

"StretchBlt" ani nic jiného použít nemůžu, protože by se zesilovaly i linie hranic, což nechci. Takže trošku pod pokličku...

V 0.5.x i v 1.0alpha mám v paměti pole byte[1000*1000] (tedy Céčkově char[1000*1000] ), které je znovu naplněno po importu dat a nebo při změně označovaných vesnic. V něm jsou indexy do tabulky barev. V obou verzích probíha vykreslování podle obsahu tohoto pole.

Ve verzi 0.5.x jsem to dělal tak, jak bych to dělal na nízké úrovni v C. V dalším poli, tentokrát reprezentujícím bitmapu o velikosti výřezu na mapě a hloubce 32 bitů (tedy 600x600x4) jsem přímým zápisem pár cykly vykreslil hranice, vesnice, všechno. Na závěr jsem z toho ale musel šílenou konstrukcí s pomocí createImage vyrobit "obrázek" a ten strčit na obrazovku. Nesympatické mi na tom bylo hlavně to, že se při každém překreslení volal "new" a garbage collector se asi nezastavil (výhodou zase bylo, že o repaint se to postaralo samo). A v okamžiku, kdy by se do toho měl dodělat resize a zoom, tak by se to celé ještě trošku zkomplikovalo...

Ve verzi 1.0alpha maluji výřez mapy do poděděného objektu JPanel, ve kterém mám modifikovanou metodu repaint. V ní maluji hranice pomocí drawLine() a "čtverečky" pomocí fillRect(). A to je asi tajemství pomalosti, používat např. na objekt 2x2 pixely fillRect(), když je těch objektů na obrazovce třeba i čtvrt milionu. Ano, čekal jsem, že to bude pomalé, ale první testy ukázaly, že se to dá. Až pak ta rána pod Windows...

Ideální by bylo nějak tyto dva postupy spojit, nejspiš pomocí třídy WritableRaster, ale při prvotním náhledu mi to nepřišlo o moc lepší...

Pokud má někdo nějaký nápad, tak sem s ním...

A mám drze pár poznámek k už funkčnímu ovládání. Tooltip mi zůstává moc krátkou dobu. A zoom kolečkem mi přijde na opačnou stranu (- i mým subjektivním podvědomým chováním, i třeba obráceně, než to má google earth v default nastavení)

Zkusím se podívat, jestli by šla ještě nějak nastavit i doba zobrazení tooltipu. S tooltipem jsem si totiž už užil své, když jsem se pokoušel ho vyrobit jako multiline...
Zoom nevím. Prostě jsem vycházel z toho, že točím k sobě, tedy chci mapu k sobě, tedy přizoomovat. Pokud je zde ale zavedený standard opačně, není problém to přehodit.

Vypadá to nádherně. Skvělá práce.

Rochni, rochni

I ta síla barev pro vesnici (Mimochodem, neuvažuješ barvu od určité bodové hranice zase zeslabovat? Určitě nad deset a půl to akorát jen žere lidi ze selského dvora).

No, je to jen první pokus, implementace nápadu, který padl ve fóru. Vlastně nevím, co od toho přesně chtít. Určitě by to chtělo spíš zaměřit na hráče než na vesnice. Zatím to nechám tak a soustředím se na klíčové části programu.

Chtěl jsem si něco takového udělat (mám jednorázové mapy) i pro hráče a udělat relativní barevné váhy vůči hráčům v okolí a prolínání do dálky, ale je to šíleně počtů a nenašel jsem optimální algoritmus nastavení maximální hodnoty.

Tak tohle by bylo pěkný...


A ještě pár poznámek...

• Data už ukládám do Hashtable a zdá se, že v tomto případě je to opravdu to pravé. Původně jsem ukládal do tří Hashtables (kmeny, hráči, vesnice), nakonec jsem to spojil do jedné a teď docházím k tomu, že to asi zase rozdělím.
• Zjišťuju, že jak je pro mne objektový přístup nový, tak s tím zatím neumím zacházet. Občas se snažím nacpat do objektu něco, co se tam nehodí, občas mám objekt nabubřelý metodami, které by měly být jinde. Málo dědím. Vždy kus udělám a pak přijdu na to, že hierarchii objektů jsem zvolil nevhodně a předělávám. Holt se furt učím. Teď je to zrovna ve stavu, že se chytám na další revizi...
• DKMapa-1.0alpha má momentálně asi 2000 řádků kódu.

 

[DeletedUser1327]

Pěkný!

Zatím ovšem ještě není doprogramováno:

• přidávání a ubírání světů z grafického rozhraní
• ovládání a zobrazování seznamů vybraných kmenů, hráčů a vesnic (tj. podstatná část ovládání vpravo)
• přímé odkazy na WWW stránk hráčů, kmenů a vesnic

Aha...tady je kámen úrazu. SpiderDES ty si ale vůl. xDDD ( ale byl jsem vytrvalej)

 

[DeletedUser2029]

Ve verzi 0.5.x jsem to dělal tak, jak bych to dělal na nízké úrovni v C. V dalším poli, tentokrát reprezentujícím bitmapu o velikosti výřezu na mapě a hloubce 32 bitů (tedy 600x600x4) jsem přímým zápisem pár cykly vykreslil hranice, vesnice, všechno. Na závěr jsem z toho ale musel šílenou konstrukcí s pomocí createImage vyrobit "obrázek" a ten strčit na obrazovku. Nesympatické mi na tom bylo hlavně to, že se při každém překreslení volal "new" a garbage collector se asi nezastavil (výhodou zase bylo, že o repaint se to postaralo samo). A v okamžiku, kdy by se do toho měl dodělat resize a zoom, tak by se to celé ještě trošku zkomplikovalo...

To je tuším nejrychlejší způsob, jak pod win v GUI nakreslit nepravidelný obrázek.

"čtverečky" pomocí fillRect(). A to je asi tajemství pomalosti, používat např. na objekt 2x2 pixely fillRect(), když je těch objektů na obrazovce třeba i čtvrt milionu. Ano, čekal jsem, že to bude pomalé, ale první testy ukázaly, že se to dá. Až pak ta rána pod Windows...
...
Pokud má někdo nějaký nápad, tak sem s ním...

Zkus pro 2x2 a možná i 3x3 použít SetPixel (ve smyčce, 4x, resp. 9x). Nevím jak pod jinými systémy, ale fillRect pod win vykresluje pomocí brush. A zřejmě i když je zadán solidbrush, tak to interně vykresluje pomocí nějaké bitblt/stretchblt a rastrových operací s plochou (kde zdrojem je brush a současný obrázek).

Kdežto SetPixel tam prostě natvrdo nastaví konkrétní barvu.

Zkusím se podívat, jestli by šla ještě nějak nastavit i doba zobrazení tooltipu.

Low level pod win je to TTM_SETDELAYTIME. Pokud se v Java dostaneš k HWND tooltipu, tak je to jedno sendmessage (kdyby to bylo platformě závislé a nabyla na to standardní fce).

S tooltipem jsem si totiž už užil své, když jsem se pokoušel ho vyrobit jako multiline...

Zoom nevím. Prostě jsem vycházel z toho, že točím k sobě, tedy chci mapu k sobě, tedy přizoomovat. Pokud je zde ale zavedený standard opačně, není problém to přehodit.

Pořádný zavedený standard asi není. Proto tam i google earth má možnost to otočit. Ani u obyčejného zoom obrázků se neshodli (nejen mapy) - viewery to často dělají opačně než grafické editory jako takové a podobně. A pak záleži, jak si kdo zvykl, s čím pracuje více.

Re: váha hráčů
Tak tohle by bylo pěkný...

Možná se k tomu vrátím a pokud to vymyslím nějak rozumně, tak zveřejním algoritmus. Problém byl, že jsem chtěl vidět místně silné hráče. Ale jakmile jsem do toho zavedl nějakou váhu okolí, tak jak jsou silnější hráči rozlehlí, tak to skoro vždy vedlo ke spojnici ke středu (k nejsilnějším) - silný se dotýká (v delším okolí) s ještě silnějším, či srovnatelným (jen o trochu slabím), a tak to postupovalo. Takže nešla přiřadit jedna intenzita barvy na hráče. Protože všichni kromě prvních 20 (50,100,200,500, ...) by už byli beznadějně černí, přestože ve svém okolí jsou to špičky.

[*]Zjišťuju, že jak je pro mne objektový přístup nový, tak s tím zatím neumím zacházet. Občas se snažím nacpat do objektu něco, co se tam nehodí, občas mám objekt nabubřelý metodami, které by měly být jinde. Málo dědím. Vždy kus udělám a pak přijdu na to, že hierarchii objektů jsem zvolil nevhodně a předělávám. Holt se furt učím. Teď je to zrovna ve stavu, že se chytám na další revizi...

Já objekty používám často (v C++), prakticky stále, ale v C++ jsou statické. I dědění je statické. Nemůže se např. v runtime přidat nová funkce. Prakticky je to další úroveň makroassembleru, automaticky v prvním parametru volání přidává pointer (plus automatické volání destrukce, pro instanci jako lokální proměnná). Je-li to napsáno dobře, tak velmi zpřehlední kód, urychlí jeho psaní a často vede i k urychlení runtime (ačkoli dnešní optimalizace překladu už jsou tak mocné, že "berličky" pospojování co k čemu logicky patří skoro nepotřebují).

Jak je to ale s dynamickými objekty a jejich urychlením/zpomalením v runtime, to netuším.

------
EDIT pro jistotu:
#define WM_USER 0x0400
#define TTM_SETDELAYTIME (WM_USER + 3)
#define TTDT_AUTOMATIC 0
#define TTDT_RESHOW 1
#define TTDT_AUTOPOP 2
#define TTDT_INITIAL 3

 

[DeletedUser3752]

Release early, release often...
(i když je to původně míněno na zdrojáky, což v tomto případě zatím neplatí)


Po víc jak týdnu další alpha:
<nadále neplatný odkaz>


Co bylo upraveno a stojí za to zmínit:

• zcela překopán objektový model (byla to práce pro vraha, která navíc zvenku není vidět, ale stálo to za to)
• doplněno ovládání v angličtině
• drobná a přesto výrazná optimalizace ve vykreslování
• tooltip se ukazuje hned a zůstává navěky, části tooltipu jsou teď tučně
• otočeno ovládání zoomu
• při probíhajícím přepočtu se ukazuje průběh
• funguje zobrazování seznamů pro označování
• nový About dialog (určitě ne definitivní, navíc jsem teď zjistil, že z něj vypadl obrázek)

Ovládání seznamů k označování stále ještě nefunguje! V zipu je přiložen soubor se seznamy některých objektů ze Světa 1, takže pokud budete zkoušet Svět 1, něco označené uvidíte.
Jazyk se automaticky volí při startu podle jazyka operačního systému. Zde bych prosil někoho ze Slovenska, ať zkusí, jak to na něj mluví. Mělo by česky, ale nemám tu nikde slovenská Windows, takže je možné, že tam mám botu a naběhne to v angličtině.

- Jirka

 

[DeletedUser4584]

Jo hele, asi jsem blbej, ale poradí mi někdo, v čem otevřu javu na Windowsech???:confused::confused: Mě se to vždycky rozzipovává

 

[DeletedUser2029]

Po víc jak týdnu další alpha

Jako obvykle, nádhera. Práce pěkně postupují. Díky moc za zapracování nápadů.

Potvrzuji citelně rychlejší vykreslování. Byť při malém zoomu i nadále trhané, nyní už to není rušivé. Takto to dostačuje.

------
Nápady a komentáře:

1) Pouvažuj o možnosti vypnutí vykreslování šedivek a případně červených nezvýrazněných vesnic (stačí v menu "funkce" zaškrtávací menuitem) - při malém zoomu (vesnice 1 pixel, ale někdy i více) tam šedivky někdy překáží.

1a) Časem, jako úplný luxux, možnost volby barvy pro šedivky/červené. (Ale pravda, to nepotřebuji - jen mne to napadlo jako možná feature, třešinka na dortu).

2) Visuální drobnost. Při maximize/resize okna z nějakého menšího zachováváš střed. To je dobře. Ale pokud jsme už při zmenšeném okně na kraji mapy, tak po zvětšení mapa "přeteče" kolem dokola. Nepadne to, ale začnou se vykreslovat data modulo 1000, takže jsou vidět dvě polokoule (plus není černá mřížka a při dragu hned poskočí na viditelnou oblast). Ohlídej i při maximize/resize limity (stejně jako to děláš při dragu) a chtě nechtě posuň střed.

EDIT: re: 2) Tak nezachováváš střed, ale levý okraj (dolní/horní?). Pohoda. Vyhovující. Ale tím pádem problém se projevuje jen na pravé části mapy, při pravém okraji.

 

[DeletedUser3752]

Jo hele, asi jsem blbej, ale poradí mi někdo, v čem otevřu javu na Windowsech???:confused::confused: Mě se to vždycky rozzipovává

Nevím přesně, co se ti rozzipovává.

Z webu stáhneš .zip soubor. Ten opravdu musíš rozzipovat. Vevnitř je mj. soubor DKMapa.jar, což je vlastní program. .jar soubory jsou jakoby přejmenované .zip soubory, tudíž je možné je rozzipovat, ale k ničemu to není.

Soubor .jar by měl jít spustit běžným poklepáním (tedy pokud máš nainstalovanou Javu). Může ale třeba hned skončit, když nedostane k běhu potřebné parametry, což je případ DKMapa 0.5.x (ta má proto u sebe ještě .cmd soubory). DKMapa 1.0 už to nepotřebuje, soubor .cmd k ní přibaluji "navíc".


- Jirka