On 25 Feb 98 at 14:14,   > wrote:
Bocs, hogy csak most valaszolok, elegge el vagyok itt most asva.
> A megoldas a kovetkezo:
> v&((v-1)^0xff)
Aranyos :) Bar ez kicsit mas jellegu, nem atmenetet keres, hanem 1-es
pixelt, es mint kesobb irtad, "alulrol".
> Megjegyzem ezzel a megoldassal mehetsz gyorsabban is mint 8 pixel,
> csak a 0xff-et kell nagyobbra venni, na meg a regiszter meretet. :-)
Persze, mint kesobb irod, ha olyan sorrendben lennenek a pixelek.
(Errol eleg hosszan meseltem en is korabban.) Szoval meg egyszer: Ez
a bitsorrend little endian gepen nagyon rossz, de ha nem tartjuk
magunkat ahhoz, ahogy masok is megszoktak, abbol esetleg kesobb
bonyodalmak es nehezen keresheto bug-ok lesznek. Annyit valoszinu nem
er meg a dolog, hogy csak a feher-fekete atmenet kereses miatt
atforgassa az ember a kepet.
[ugyanez neg-gel]
> Na szoval valahogy igy nezne ki: (AL-ben a vizsgalt byte)
> MOV BL,AL
> NEG BL
> AND BL,AL
[...]
> hosszuak, ugyhogy ez az egesz itt 6 orajel alatt lefut elmeletileg
> 386-on, pentiumon pedig ugy saccolom, hogy olyan 3 orajel lehet.
> Ez mar eleg jo nem? :-)
:)
Most hirtelen en sem tudom, hogy a neg az parba allithato-e a
pentiumon, de ha igen, akkor erdemesebb igy csinalni:
mov bl,al
neg al
and al,bl
Ez 2 orajel lenne csak, mert a mov es a neg parhuzamosan 1 orajel
alatt megvan.
> Ezzel kapcsolatban jut eszembe, van egy hasonlo feladat, es a megoldas
> is hasonlo:
> hogyan lehet eldonteni gyorsan egy szamrol, hogy 2 hatvanya-e vagy sem.
> Megoldast most nem irok, kivancsian varom hogy ismeritek-e.
Igen, ilyen mar kellett nekem is :)
(X-1) & X == 0
--------------------
No, a ket napos feladatra nem jott valasz, ughogy elarulom:
Szoval a feladat az volt, hogy csak azokat az atmeneteket kellene
megtalalni, amiket eddig meg nem jartunk be, es a bejarast egy
parhuzamos bitmapben tartjuk nyilvan.
eleje:
mov ah,dl ; dl-ben volt az elozo byte, a legalso pixelje erdekes
mov al,bitmap[esi]
mov dl,al
shr ax,1 ; minden pixel alatt ott lesz a tole balra allo
not al
and al,dl ; ha 0 pixel van 1 elott, akkor ott 1-es bit lesz
xor al,konturmap[esi] ; es ha meg nincs bejarva, ugy is marad
jnz atmenetvan
inc esi
jmp eleje
Ez a lenyege a dolognak. Ha mar atmenet van, akkor meg kulon ki kell
talalni, hogy melyik azok kozul a legbaloldali (mert elvileg egy
byte-on belul tobb is lehet), de az mar szinte mindegy, hogy milyen
lassan tortenik, mert ebbol csak laponta nehany ezer lesz, mig bejart
atmenetbol (ahol a konturmap nem 0) tobb szazezer.
A fenti ciklus jol mukodik a byte-ok kozott is, ettol kicsit
hosszabb, mint a lenyege. Viszont a valosagben ennel kicsit meg
hosszabbat erdemes csinalni, mert erdemes figyelni azt is, hogy hatha
csupa 0 byte-ba akadunk, mert akkor azt (es a rakovetkezo csupa
0-akat) kulon sokkal gyorsabban at lehet lepni. Olyanbol nagyon sok
lesz (ket betusor koztt peldaul), ugyhogy erdemes ra figyelni.
Egyebkent bocs, fiuk, lehet, hogy kicsit felrevezeto volt a kerdes,
mert mint latszik, nem arra megy ki az algoritmus, hogy az ELSO
atmenetet talalja meg gyorsan, hanem, hogy a be NEM jart atmeneteket
talalja meg gyorsan. Kicsit probaltam a kerdesben erre utalni, de
lehet, hogy nem sikerult elegge.
István
-- Istvan Marosi -- http://www.sch.bme.hu/~marosi --
-- Recosoft Ltd. -- mailto: --
|
Hi!
>On 6 Feb 98 at 9:26,  wrote:
> Szoval varok otleteket, hogy nehany logikai muvelettel (and, or, xor,
>shift) hogyan lehet eldonteni azt, hogy van-e feher-fekete atmenet (ahol
>a bal oldali feher pixelt egy fekete pixel koveti jobbrol) az adott
wrote:
Sajnos nem olvastam a teljes levelet, mostanaban kezdtem nezegetni a
listat.
En annak idejen mas jellegu problemaval foglalkoztam, de asszem eleg
jo megoldas volt egy 256 byte-os tabla. Egy index registerhez
hozzaadod a kiolvasott erteket es a tablabol indexelve kiszeded a
megfelelo valaszt.
Bar ez nem oldja meg a byte also bitje es a kovetkezo byte felso
bitjenek vizsgalatat, de azt is +2 AND utasitassal elerheted.
00: 0 8 7 7 6 6 6 6 5 ... <- itt ertendo, melyik biten van valtas
; 0 nincs
byte, kov
|
