[WVL_KsZeN(~werner@132.229.39.12)] better not, i still have to fix a small couple of things..
[WVL_KsZeN(~werner@132.229.39.12)] w8
ωνω darkduke [darkduke@p548935C4.dip0.t-ipconnect.de] has joined #c-64
[msg(wvl_kszen)] nono
[msg(wvl_kszen)] i just want somewhat correct input
[WVL_KsZeN(~werner@132.229.39.12)] did you grab the latest devpack?
[WVL_KsZeN(~werner@132.229.39.12)] it's there in the /source dir.. named empty2.txt
[WVL_KsZeN(~werner@132.229.39.12)] that should be what you want as input.
[WVL_KsZeN(~werner@132.229.39.12)] then there's also empty.txt, the big version of it, which you shouldnt really care about :)
[WVL_KsZeN(~werner@132.229.39.12)] 22,1
[WVL_KsZeN(~werner@132.229.39.12)] 21,1
[WVL_KsZeN(~werner@132.229.39.12)] 15,2
[WVL_KsZeN(~werner@132.229.39.12)] 13,2
[WVL_KsZeN(~werner@132.229.39.12)] 11,1
[WVL_KsZeN(~werner@132.229.39.12)] 9,1
[WVL_KsZeN(~werner@132.229.39.12)] 8,3
[WVL_KsZeN(~werner@132.229.39.12)] 7,1
[WVL_KsZeN(~werner@132.229.39.12)] 6,5
[WVL_KsZeN(~werner@132.229.39.12)] 5,3
[WVL_KsZeN(~werner@132.229.39.12)] 4,3
[WVL_KsZeN(~werner@132.229.39.12)] 3,6
[WVL_KsZeN(~werner@132.229.39.12)] 2,13
[WVL_KsZeN(~werner@132.229.39.12)] 1,77
[WVL_KsZeN(~werner@132.229.39.12)] 22,1 -> there's 1 empty hole of 22*8 bytes
[WVL_KsZeN(~werner@132.229.39.12)] 21,1 -> there's 1 empty hole of 21*8 bytes..
[msg(wvl_kszen)] yeps
[WVL_KsZeN(~werner@132.229.39.12)] 1,77 -> there's 77 empty holes of 1*8 bytes
[msg(wvl_kszen)] and then the labels and layer thing, what was that again
[WVL_KsZeN(~werner@132.229.39.12)] ah
[WVL_KsZeN(~werner@132.229.39.12)] -> you allow some file to be read as empty-hole data, in this case empty2.txt
[WVL_KsZeN(~werner@132.229.39.12)] now, if things fit inside holes, you put
[WVL_KsZeN(~werner@132.229.39.12)] *=empty8bytes0 infront
[WVL_KsZeN(~werner@132.229.39.12)] BUT
[WVL_KsZeN(~werner@132.229.39.12)] to be smart and handle BOTH layers, you start counting from the top instead.
[WVL_KsZeN(~werner@132.229.39.12)] so the FIRST thing you want in an 8 byte hole, you label :
[WVL_KsZeN(~werner@132.229.39.12)] *=empty8bytes76  (there are 77 holes)
[WVL_KsZeN(~werner@132.229.39.12)] next one is labelled *=empty8bytes75
[WVL_KsZeN(~werner@132.229.39.12)] etc
[msg(wvl_kszen)] but the file says 8,3... i.e. 3 empty holes of 8 bytes
[WVL_KsZeN(~werner@132.229.39.12)] after all is done, you simply output to a new file how many holes are left in the same manner as the
                                   input file
[msg(wvl_kszen)] yes
[WVL_KsZeN(~werner@132.229.39.12)] 8,3 == 3 holes of 8*8 bytes
[msg(wvl_kszen)] ahh 77 holes in total u mean!
[WVL_KsZeN(~werner@132.229.39.12)] 22,1 == there's 1 hole of 22*8 bytes :)
[WVL_KsZeN(~werner@132.229.39.12)] 1,77 == there's 77 holes of 8 bytes
[WVL_KsZeN(~werner@132.229.39.12)] these are never overlapping
[msg(wvl_kszen)] oh! haha ok. x,y x=bytes/8, y=number of such holes
[WVL_KsZeN(~werner@132.229.39.12)] so a hole of 8 bytes NEVER is inside a hole of 16 bytes
[msg(wvl_kszen)] yep ok, was just going to ask
[WVL_KsZeN(~werner@132.229.39.12)] yes
[msg(wvl_kszen)] gr8
[msg(wvl_kszen)] ok
[WVL_KsZeN(~werner@132.229.39.12)] and by counting down instead of up, you fix the double layer problem
[msg(wvl_kszen)] and should I stuff multiple rows in a hole?
[msg(wvl_kszen)] yeps
[WVL_KsZeN(~werner@132.229.39.12)] if you CAN stuff multiple stuff in 1 hole, do it :)
[WVL_KsZeN(~werner@132.229.39.12)] you can simply do so with
[WVL_KsZeN(~werner@132.229.39.12)] *=label
[WVL_KsZeN(~werner@132.229.39.12)] row47 .byte
[WVL_KsZeN(~werner@132.229.39.12)] row 373 .byte
[WVL_KsZeN(~werner@132.229.39.12)] simple ;)
[msg(wvl_kszen)] yes
[msg(wvl_kszen)] and finally, about those ending bytes
[WVL_KsZeN(~werner@132.229.39.12)] bUT
[WVL_KsZeN(~werner@132.229.39.12)] yes, i wanted to mention that :)
[msg(wvl_kszen)] mention it
[msg(wvl_kszen)] :D
[WVL_KsZeN(~werner@132.229.39.12)] i think you have to fix ending bytes first :)
[WVL_KsZeN(~werner@132.229.39.12)] i think you have to fill the holes up BEFORE you do the ending bytes
<int3nsity> anyone want to gimme a blowjob?
[WVL_KsZeN(~werner@132.229.39.12)] if finished, you can do ending-bytes with the data that's not ending up stuffin a hole
[WVL_KsZeN(~werner@132.229.39.12)] and you can try to sort the datarows there, to get rid of a bit more ending bytes
<_CBA_> Scout, time to give a blowjob again!
[WVL_KsZeN(~werner@132.229.39.12)] main idea ( i think)
[WVL_KsZeN(~werner@132.229.39.12)] sort rows on last byte
[WVL_KsZeN(~werner@132.229.39.12)] sort rows on first byte
[WVL_KsZeN(~werner@132.229.39.12)] erh.. no, only sorting on first byte i think.. or whatever
[WVL_KsZeN(~werner@132.229.39.12)] -> get first row
<int3nsity> what about you CBA? :)
<_CBA_> Sorry dude, I already have my mouth full :)
[WVL_KsZeN(~werner@132.229.39.12)] select a row with first byte equal to current row's endbyte, or bigger, but as small as possible
[WVL_KsZeN(~werner@132.229.39.12)] etc
<int3nsity> don't you have place for a second dick in your mouth? :)
[WVL_KsZeN(~werner@132.229.39.12)] so i think you only have to sort on first byte :)
<_CBA_> I am sure that small weeny penis will fit in (:
ωνω Jeff_VRZ [jeff@0x50a170e9.vjnxx1.adsl-dhcp.tele.dk] has joined #c-64
<_CBA_> Jeff
<Jeff_VRZ> hi CBA
ωνω mode/#c-64 [+o Jeff_VRZ] by Commodore
ωνω acidchild [bla@pD9F63248.dip.t-dialin.net] has joined #c-64
<acidchild> hola
<int3nsity> CBA, ok, so you wanted it this way... Now OPEN you mouth wide!
<int3nsity> Jeffioso
<_SCouT_> huh? what?
<_SCouT_> cba's wants a blowjob from me?
<_CBA_> Jeff, int3nsity wants a blowjob, are you available
<_CBA_> ?
<Jeff_VRZ> int3nsity, wolfram, Scout
<_CBA_> Scout, no, it's int3nsity, his little joystick is waiting for you
<_SCouT_> chef!
<Jeff_VRZ> CBA: always!
<acidchild> hi soeren
<acidchild> niels, roland
<_CBA_> acid
<_SCouT_> wolfram
<_CBA_> Nasty sexy talk here always :)
π _SCouT_/#c-64 only eats pussy... remember that!
<_SCouT_> the purring furry ones!
<_SCouT_> =)
<_SCouT_> meow!
[WVL_KsZeN(~werner@132.229.39.12)] erh.. easy algorithm.. shouldnt do 100% optimizing, but hey :) NP-complete problem, whaddayawant? :D
<int3nsity> so CBA, Scout, and all others who want to participate: now open your mouth wide open, as i am cumming...
<_CBA_> Time to leave this channel
ωνω _CBA_ [cba@xs2.xs4all.nl] has left #c-64 []
<_SCouT_> hehe
ωνω _CBA_ [cba@xs2.xs4all.nl] has joined #c-64
<_CBA_> ;)
<_SCouT_> hmm! yoghurt
ωνω mode/#c-64 [+o _CBA_] by _SCouT_
[msg(wvl_kszen)] ok, still i'm kinda lost, i've forgot how those end byte worked
<int3nsity> Scout, yeah, taste of the peach
[WVL_KsZeN(~werner@132.229.39.12)] ok :)
[WVL_KsZeN(~werner@132.229.39.12)] data in row is like :
[WVL_KsZeN(~werner@132.229.39.12)] a=angle
[WVL_KsZeN(~werner@132.229.39.12)] b=ABSOLUTE coord
ωνω bidsk [-peter@cpe.atm2-0-52177.0x5359a852.boanxx13.customer.tele.dk] has joined #c-64
[WVL_KsZeN(~werner@132.229.39.12)] c=relative coord
[WVL_KsZeN(~werner@132.229.39.12)] .byte a,b, a,b, a,c, a,c, ad infinitum
[msg(wvl_kszen)] yep ok
[WVL_KsZeN(~werner@132.229.39.12)] now you can get rid of the last byte, IF the first byte after that is => than that  byte
[WVL_KsZeN(~werner@132.229.39.12)] so if data is .byte $00,$a0
<int3nsity> Scout, now swallow it
<int3nsity> :)
[WVL_KsZeN(~werner@132.229.39.12)] you can drop $a0, if next datarow is like .byte $c0,$.,,,,,
<int3nsity> CBA u 2
<Krill> int3nsity
<int3nsity> Gunnar
[WVL_KsZeN(~werner@132.229.39.12)] so
<Jeff_VRZ> Krillerille
[WVL_KsZeN(~werner@132.229.39.12)] .byte $00,$a0
<int3nsity> have to leave. l8rs
[WVL_KsZeN(~werner@132.229.39.12)] .byte $c0,i dontcare
[WVL_KsZeN(~werner@132.229.39.12)] becomes
ωνω SignOff int3nsity: #c-64 ("")
[WVL_KsZeN(~werner@132.229.39.12)] .byte $00, ;$a0
[WVL_KsZeN(~werner@132.229.39.12)] .byte $c0, i dontcare
[msg(wvl_kszen)] why is that possible to drop?
[WVL_KsZeN(~werner@132.229.39.12)] because the code compares
[WVL_KsZeN(~werner@132.229.39.12)] you have x position in a
<bidsk> http://fractured.frac.dk/sexonaughty.jpg      weee :)
<_SCouT_> *gulp*
[WVL_KsZeN(~werner@132.229.39.12)] and it compares to those values
[WVL_KsZeN(~werner@132.229.39.12)] ,byte a,b, a,b, a,c, a,c
[WVL_KsZeN(~werner@132.229.39.12)] is like, you have angle a UP TO position b
[WVL_KsZeN(~werner@132.229.39.12)] then from there to next b, you have angle a
[WVL_KsZeN(~werner@132.229.39.12)] then from there for C pixels, you have angle a
[WVL_KsZeN(~werner@132.229.39.12)] bla bla
[msg(wvl_kszen)] hmm ok
<Jeff_VRZ> Peter: drengen ligner dig lidt :)
[WVL_KsZeN(~werner@132.229.39.12)] if it's the last byte, it's always pixel #319
[WVL_KsZeN(~werner@132.229.39.12)] but it's always UP TO & including
[WVL_KsZeN(~werner@132.229.39.12)] so it doesnt matter if it's 319,320.. 400
[msg(wvl_kszen)] i c
[WVL_KsZeN(~werner@132.229.39.12)] ofcourse pixels are multicolor, so 319 == 159
[msg(wvl_kszen)] oh well then
[WVL_KsZeN(~werner@132.229.39.12)] etc
[WVL_KsZeN(~werner@132.229.39.12)] :)
[msg(wvl_kszen)] then I get started. :D
[msg(wvl_kszen)] got the elvis part, looks good
<bidsk> hahaha
