<WVL_KsZeN> i changed the tool that looks through the bitmap a bit
<WVL_KsZeN> it now outputs 2 files
<WVL_KsZeN> one that is supposed to be included in the source
<WVL_KsZeN> with 
<WVL_KsZeN> empty8bytes0 = $blabla
<WVL_KsZeN> etc
<WVL_KsZeN> the other file is meant to be fed in the wall editor
<WVL_KsZeN> it has output like
<WVL_KsZeN> 1,77 -> 77 chars free in bitmap
<WVL_KsZeN> 2,40 -> 40 * 16 bytes free in bitmap
<WVL_KsZeN> etc
<WVL_KsZeN> is a file like that enough for the wall editor to cope with it?
<WVL_KsZeN> 22,1
<WVL_KsZeN> 21,1
<WVL_KsZeN> 15,2
<WVL_KsZeN> 13,2
<WVL_KsZeN> 11,1
<WVL_KsZeN> 9,1
<WVL_KsZeN> 8,3
<WVL_KsZeN> 7,1
<WVL_KsZeN> 6,5
<WVL_KsZeN> 5,3
<WVL_KsZeN> 4,3
<WVL_KsZeN> 3,6
<WVL_KsZeN> 2,13
<WVL_KsZeN> 1,77
<WVL_KsZeN> here's a total output example
<WVL_KsZeN> is a bit messy though, as this also includes the places where i'm storing the sprite data for the ball
<WVL_KsZeN> i guess i have to change order of compiling, so the sprites are put in the bitmap BEFORE this tool looks at the data
<JackAsser> i guess that's alright
<WVL_KsZeN> oh
<WVL_KsZeN> btw
<JackAsser> as I said before, we have to talk exactly how it's supposed to work
<WVL_KsZeN> some suggestions :
<WVL_KsZeN> yes
<JackAsser> i'm not fully aware right now. :D
<WVL_KsZeN> :D
<WVL_KsZeN> we'll talk l8r
<WVL_KsZeN> but this weekend i'm not online
<JackAsser> ahh ok, but talk now!
<WVL_KsZeN> talk now?
<WVL_KsZeN> :)
<WVL_KsZeN> ok
<WVL_KsZeN> the idea is that my new tool produces a list of how much memory is still available inside the bitmaps
<JackAsser> yeps
<WVL_KsZeN> the only thing the walleditor has to do is to use it as good as possible
<WVL_KsZeN> some problems i can imagine :
<WVL_KsZeN> 1 - problems with $d000-$dfff area
<JackAsser> x,y where y-bytes at x-places are free
<WVL_KsZeN> -> not sure how to handle that yet
<WVL_KsZeN> x,y == x*8 bytes free at y places
<JackAsser> yeah ok
<JackAsser> and as always, i suspect the fitting is NP-complete... :D but anyway..
<WVL_KsZeN> well
<WVL_KsZeN> doesnt matter
<WVL_KsZeN> it doesnt have to be perfect
<JackAsser> no, only good
<WVL_KsZeN> now the walleditor spits out data in rows
<WVL_KsZeN> the only thing we have to do, i guess is :
<JackAsser> why would $d000-$dfff be a problem, don't u check the collisions inside the IRQ?
<WVL_KsZeN> 1 - sort the rows to byte size
<WVL_KsZeN> no, the collisions are definately outside the irq
<WVL_KsZeN> -> there's also a lot of irq's happening during collision detection!
<WVL_KsZeN> 2 -> check how many 8 byte gaps there are
<WVL_KsZeN> and fill them up with 8 byte rows if possible
<WVL_KsZeN> if there are no 8 byte rows left
<WVL_KsZeN> fill them with 6 byte rows
<WVL_KsZeN> (YOU ALSO ALWAYS NEED TO PUT THE ENDBYTE THERE!!)
<WVL_KsZeN> so no 7/5/3 byte rows!
<WVL_KsZeN> etc
<WVL_KsZeN> if you filled all the 8 byte gaps
<WVL_KsZeN> do so with all the 16 byte gaps
<WVL_KsZeN> etc
<JackAsser> "2 -> check how many 8 byte gaps there are" exactly how do u mean?
<WVL_KsZeN> 3 - put all the not relocated 
<WVL_KsZeN> erh
<WVL_KsZeN> well, you got how many gaps there are from my tool
<WVL_KsZeN> so you see there are 77 8 byte gaps
<WVL_KsZeN> then you select as many 8 byte rows as possible
<WVL_KsZeN> if there are only 60 8 byte rows, you select 17 6 byte rows as well
<WVL_KsZeN> -> you put all these selected rows to the very bottom of the output, and put *=empty8bytes0 infront of each row, 8 and 0 changing ofcourse
<WVL_KsZeN> etc
<WVL_KsZeN> then you do 16 byte gaps
<WVL_KsZeN> etc
<WVL_KsZeN> when you're done, you have to output a file with remaining gaps!!
<WVL_KsZeN> so you can use the 2nd layer collision data to fill any gaps left over!
<JackAsser> moment..
<WVL_KsZeN> oh
<JackAsser> ok
<JackAsser> let me see
<WVL_KsZeN> that reminds me :)
<WVL_KsZeN> when there are like x gaps of 8 bytes free
<WVL_KsZeN> and you only use x-10
<WVL_KsZeN> you have to number the empty8bytesx not from 0 to x-10, but probably from 10 to x
<WVL_KsZeN> -> so the 2nd layer can start numbering from 0
<WVL_KsZeN> easier that way
<WVL_KsZeN> are you getting this? :)
<JackAsser> no, but my mind isn't 100% set on it also, i think i'll cut and paste it and read it carefully
<WVL_KsZeN> ok
<WVL_KsZeN> it's just like this :
<WVL_KsZeN> when exporting, the editor has to read a file with gap info
<WVL_KsZeN> -> has to try to fill those gaps reasonably well
<JackAsser> yeps
<JackAsser> i think i got it
<WVL_KsZeN> to do that, i say :
<JackAsser> not the numbering though
<WVL_KsZeN> start filling 8 byte gaps first
<WVL_KsZeN> then 16 byte gaps
<WVL_KsZeN> etc
<JackAsser> yeah
<JackAsser> should be easy to fix
<WVL_KsZeN> for now, let's forget about what happens when there's a 320 byte gap, and you only have a 40 byte row max..
<WVL_KsZeN> so we'll forget about putting >1 row in a gap for now, to make it easy
<WVL_KsZeN> but
<JackAsser> what do u mean exactly now
<JackAsser> >1?
<WVL_KsZeN> well, if 320 byte gap
<JackAsser> not fit more that 1 row in each gap?
<WVL_KsZeN> you could fit in 8 40-byte rows
<JackAsser> why not do that?
<WVL_KsZeN> erh.. it sounds difficult
<WVL_KsZeN> especially since you have to use
<WVL_KsZeN> *=empty320byte0+40 for the 2nd thing you put in that gap
<WVL_KsZeN> as there are no extra labels!
<WVL_KsZeN> also
<JackAsser> yeah
<WVL_KsZeN> you have to put the endbytes in there also (the last byte)
<WVL_KsZeN> not remove them!!
<JackAsser> last end byte of each row u mean?
<WVL_KsZeN> and you have to be sure the endbytes of the rows you do not relocate are not messed up
<WVL_KsZeN> yes
<WVL_KsZeN> -> so FIRST fill gaps
<WVL_KsZeN> THEN do last byte removal in the rows that are NOT relocated
<JackAsser> exactly
<JackAsser> easy peasy
<WVL_KsZeN> if you're done
<WVL_KsZeN> put out a file that has the remaining gaps in it
<JackAsser> yeah
<WVL_KsZeN> now here comes the thing :
<JackAsser> ofcoz
<WVL_KsZeN> let's say there are 2 8 byte gaps
<WVL_KsZeN> layer one manages to fill one of those :
<WVL_KsZeN> now it labels that as empty8byte0
<WVL_KsZeN> -> when doing layer 2, it fills up the last of that gap
<WVL_KsZeN> but will also name it empty8byte0
<WVL_KsZeN> !
<WVL_KsZeN> so you have to start couting from the top!
<WVL_KsZeN> if there are 2 gaps, first use label empty8byte1
<WVL_KsZeN> -> then you never get in trouble with labelling the 2nd layer
<JackAsser> problem is that i don't keep track of the layers at all.. that are 2 different levels sort of
<WVL_KsZeN> yes
<WVL_KsZeN> but you dont have to
<WVL_KsZeN> just let the exporter read a gap-info file
<WVL_KsZeN> and output the remaining
<JackAsser> yes
<JackAsser> exactly
<JackAsser> so what's the wuzz about label naming?
<WVL_KsZeN> this works fine, if you start numbering the labels from the top
<WVL_KsZeN> and not the bottom
<WVL_KsZeN> otherwise layer1 and 2 will use the same labels
<WVL_KsZeN> liek
<WVL_KsZeN> like :
<JackAsser> i c
<WVL_KsZeN> layer1 exporting, there are 2 gaps, it uses one, so one left
<JackAsser> i know what u mean
<WVL_KsZeN> -> if you start numbering from 0, you're in trouble
<JackAsser> yeps
<WVL_KsZeN> as layer 2 will also do it
<WVL_KsZeN> so start labelling from (in this case) 1
<WVL_KsZeN> then layer 2 will only see 1 gap left
<JackAsser> yeps, i know exactly what u mean
<WVL_KsZeN> and will label 0
<JackAsser> yes yes
<WVL_KsZeN> -> problem of double layers solved ;)
<JackAsser> yep
<JackAsser> nice
<WVL_KsZeN> and no hard code to make editor understand there are 2 layers
<JackAsser> yeps
<JackAsser> i'll fix, u relax.
<JackAsser> :D
<JackAsser> how many bytes to u reckon to save?
<WVL_KsZeN> just a sec..
<WVL_KsZeN> gotta run tool ;)
<WVL_KsZeN> 328 empty chars found in total
<JackAsser> in how many continious chunks
<WVL_KsZeN> but those are including the areas i'm putting sprites in (24x48 bytes)
<WVL_KsZeN> 119 chains found
<WVL_KsZeN> so in total 328*8 - 24*48 = 1472 bytes left to fill
<WVL_KsZeN> = 5.75 blocks
<WVL_KsZeN> i still have to change compilation order, so the sprites are included in the bitmap before i run the tool
<JackAsser> i c
<WVL_KsZeN> quite worth it, i think
<WVL_KsZeN> well, i guess there will be one block less, when i fill the bitmap a bit more..
<JackAsser> yeah
<WVL_KsZeN> but still!
<WVL_KsZeN> especially layer 2 has lots of 8 byte rows!
<WVL_KsZeN> 2 ducts * 4bytes/duct at most places..
<JackAsser> yeah
<WVL_KsZeN> maybe the exporter can also kinda sort the remaining rows a bit to optimize last-byte removal
<WVL_KsZeN> well, 'sort'
<WVL_KsZeN> just pick rows
<WVL_KsZeN> pick first row, check last byte
<WVL_KsZeN> then pick one of the left rows, with first byte that's as small as possible, but still > the last byte
<WVL_KsZeN> etc
<WVL_KsZeN> ofcourse, it's also an np complete problem
<WVL_KsZeN> but a simple 'picking' routine like that will also give a lot more last-bytes removed, i'd say
<JackAsser> ahh, yes
<WVL_KsZeN> very simple sorting
<WVL_KsZeN> implement in a couple of minutes, i'd say :))
<WVL_KsZeN> maybe nice to implement that first
<WVL_KsZeN> -> wouldnt cost a lot of time
<WVL_KsZeN> and you'd see clearly how many bytes are saved extra
<WVL_KsZeN> oh yeah :)
<WVL_KsZeN> while you're at it :
<WVL_KsZeN> please make it also work on 16 bit screens? :D
<WVL_KsZeN> last time you said you knew how to fix that :D
<WVL_KsZeN> ;estimated free memory :
<WVL_KsZeN> ;                    37.75 blocks free
<WVL_KsZeN> ;estimated extra memory use :
<WVL_KsZeN> ;total                        35-42 blocks?
<WVL_KsZeN> this is why..
<WVL_KsZeN> very close..
<JackAsser> hehe ok
<WVL_KsZeN> ofcourse i think i can save 4 more blocks by optimizing the collision data with the export/import tool
<WVL_KsZeN> but 4-5 more blocks free would rule..
<WVL_KsZeN> then i would be able to increase the # of flipper frames to what i want :)
<JackAsser> indeed
<WVL_KsZeN> == from 7 to 13 frames
<JackAsser> yeah
<JackAsser> before u go today, please copy the whole IRC log from me and mail me, mkay?
