Lehet olyat is, hogy nem kozvetlenul dst[x][y]=0; es hasonlo modon allitod a pixeleket, hanem mondjuk 3 inline-ositott fuggvenyen keresztul.Lehet, de az bonyolítaná az API-t. Így most csak egy függvény, oszt jóccakát. (Egyébként tényleg gondoltam erre, fontolgattam, hogy define-al lehessen-e függvényeket megadni pixelállításhoz.)
De az is teny, hogy innen mar kb. trivialis atirni a megfelelo formatumra.Jaja, a cél pont ez volt, egy olyan köztes valami, ami könnyedén kezelhető. Ebből bitmapet is könnyedén lehet csinálni, csak lecsíped a legalacsonyabb helyiértékű bitet és kész is (aztán hogy azt merre mennyivel shifteled, az meg már úgyis implementációfüggő, a hőnyomtatódon se tudom még abból, hogy a 8-as csoportból állt, hogy akkor az 1 vagy a 0x80 volt-e balra).
A sok konstans tomb gondolom a pixelek helye (kigyo forma) meg a CRC szamitas. Az kicsit nehezebben ertheto, de a formatum sajatja.Hát, ez is, az is. Az első négy a blokkcsoportok mérete és száma (két csoport van), aztán Reed Solomon ECC polinóm paraméterei (az egyik indirekten a gen_poly újabb konstans tömbből veszi ki az offszetet a még újabb konstans tömb polinóm táblából), aztán a végén az utolsó két érték az már tényleg pixelminta, ami a képre kerül (innen tudja az olvasó, hogy milyen QR verzióról van szó). A "kígyó forma", már amennyiben a bekeretezett négyzetet meg a két keresztvonalat érted ez alatt, na az pont nincs benne ezekben :-) Azok ugyanis éppenséggel verziófüggetlenek (csak a pozíciójuk változik, a mintájuk nem). Ja, jó bonyi az egész, de igazából egy-két dolgot leszámítva elég ötletes és hatékony (annak például nem látom értelmét, miért kell zig-zag sorrendben olvasni a pixeleket és minek van benne numerikus, alfanumerikus stb. adathalmaz, miért nem elég a bájt és hogy minek bitekre szétbontani a bájtokat külön két bájtra, miért ne lehetnének egy-az-egyben az üzenet bájtjai; minden más tök oké és ötletes).