the 'lineout + rg prod' putting-toghether log

15-01-2008:

seems like something like 850 kbyte is used as BSS.. i need to reduce this,
although 608+64 = 672 kbyte is required at the very least. so where is the 
remaining 180 kbyte? the DATA section is accounted for (235 kbyte), which
includes 50 kbyte for music (why so big?) and loads of pi1 and even a 1bpl small
font as a 32 kbyte pi3.. code is only 100 kbyte. 
so.. we can convert some piccies, generate some code to shared bss, and try
some other music format. but first we need to check the damn missing 180 kbyte? 
 23:20: update.. seems like i knocked off 150+ kbyte. gupta8.s used a lot of
bss. i think this was the bad guy. however, i could do with 100 k less.. don't
 know but i think i can only win 10 k more with bss optimising. the rest will
need to be done by image and music crunching. the 2x2 rotozoom code is the 
critical path.. it needs all those huge buffers. hell, off to bed. 
 tomorrow i'll mash down on the font and possibly the music (?!) and fix that
last bss optimisation.. code generation will happen shortly after.

16-01-2008:

kicked another 40 k or so by ditching the void around the font and the last bss
optimisation. i guess it's code generation time now as i have no clue about how
to squeeze down on the memory footprint of the music.
 okay, it seems wibble2.s has close to 10 k of screen clearing code. i could
generate this. dotsext2.s also has alot of code which could be generated. this 
is possible 25 k or so. just knocked 1.5 k off gupta8.s.. i think this can't be
further shortened a lot by code generation: maybe 3 k. the code is just huge,
but the aliased line rout may be replaced by the standard one in the 3d lib.
let's try that. 
 okay, did that. didn't save too much, of course. hybroto2.s already features
a lot of generated code. there's maybe 2 k to save in total. kicked some lib3d
stuff from glenz.s and last but not least kicked that silly 3 bpl clear rout.
saved 6 k. the footprint is 965 kbyte RAM now.
 next up is probably chopping some pi1's. i think i can kick at least 50 k
more. if that isn't enough i may need to go for the TOS screen RAM. but that's
nasty since on falcon a screen can actually be less than 32K.. hhhmm.. 
 okay, that worked and the footprint is reduced to 915 k. ah yeah! of course,
i forgot that the wavescroller can be used for the cracktro in a completely
separate program. that should at least guarantee some additional space.
 i still got an idea for a twister effect, so it would be nice to have at least
a few kb of space left.

18-01-2008:

i think i will make a ribbons screen with PI1 loader. maybe kev can cook up some
nice logo for the side. after that it's time to split the scroller from the
demo and equip it with some mad max music. finally, i want to write that 
twister.
 come to think of it, i guess i can use multi color sprites for the wave 
scroller. hhmm.. but that's for later.

20-01-2008:

the wave scroller is separated and has loads of events in its own big list. it
looks quite amusing, but could do with a little separate scroller, displaying
'reservoir clogs' (with some clogged up clogs on the sides :)
 i wonder if multi-color sprites would work btw. let's check if the plot rout
is 4 plane or 3 (yikes). oh dear, it is 3 planes. man, i can't be arsed to make
it 4 plane right now.. anyway, wrapping seems to work, so the thing can go on
for eternity. tomorrow i'll leech some madmax sndh and use it.
 now on with the RIBBONS2.PI1..
 actually, i actually put glens.s in the demo now.. i mean, it's actually shown
now. whereas, it was included but not shown running in the previous version.
this led me to the discovery of a bug in the new screen allocation. but that's
fixed now.
 i hope i can finally get on with RIBBONS2.S now.. okay, fixed and zipped. i'll
mail it to kev tomorrow. 
 we'll continue with some more events in the main part of the demo.

22-01-2008:

did the scroller with madmax zik.. the sndh replay is buggy like hell, dunno 
why. gwem sent me another test shell but didn't bring it with me.. blah.
kev is doing some gfx, malc some msx..

23-01-2008:

did nothing yesterday.. my left arm is killing me.. can't even sleep alright
with that thing.. i need something nice to work on instead of this design 
shit.
 i could work on a twister fx or something..

24-01-2008:

completed the first version of the twister. piss-easy but nice looking. maybe
i'll degrade some of the main part fx now to go with the sid sound..
 okay, the dot morpher is done.. 
 hhmm, that was about all, really.. strange.. all seems to be fast enough now.
guess it's ready for posting, then.
 ah, shite.. had it set to 9 MHz! let's try again at 8! the wibble cube had to
be degraded, but only a slight bit (the clear rout was lame!). the ribbons
are shortened (not too much) and i still need to fix the clipping of the far
end! but god damn, the glenz screen crashes?!? but why!? need to fix it. i want
the guys to see a preview.
 damn, that only happens when you load it off disk from tos (not from within
devpac, somehow). at least the thing runs from auto the folder on a 1 meg st.
i guess the steem debugger will come in handy tracking down that nasty bug.
more tomorrow!

25-01-2008:

yeah!! kev made loads of graphics! the guy is on fire!! can't fucking believe
pink was always "waiting for the graphics". unless, he worked even faster than
kev. i can't even imagine.. 
 i'm in the middle of a gigantic bughunt. the damn thing seems to shift places
every now and then. obviously very dependent on ram contents. a piece of ram is
badly corrupted by some cascade effect. let's try different runtimes for the
effects and see if i can reproduce.
 at least i know that it happens -before- the GLENZ.S part. sometimes the 
WIBBLE2.S part bugs as well.
 more investigation: the RIBBONS2.S part is not a suspect anymore. and the 
GUPTA8.S part is free to go as well. so is LEDPLS.S..
 alright, HYBROTO2.S is still a suspect. i removed it's events and it seemed to
work fine.. let's take this baby apart. seems that shit only happens when i
switch to the 2x2 version of the rotator? confirmed!
 wtf?! i completely hardwired the 2x2 paint rout but still the bug persists. to
me it sounds damn odd that it's just the event rout?!
 oh hell?! it's a combination of WIBBLE2.S and the 2x2 HYBROTO2.S paint rout?
this is a nominee for wierdest bug ever.
 and what was it then? some moronic screen clearing rout. of course, it was out
of bounds. what the rotator screen had to do with it i still don't know. but the
bug was fixed in the 3D screens GLENZ.S and RIBBONS2.S.
 23:14: conved and added kev's texture. it rocks! only 8x8 mode looks a bit 
shit. i was right to have chosen a graffiti type thing here, though. now i 
should try the ribbon side logo. that also looks better. kev worked out that the
overlap color should be white and reordered the palette. great! :)
 23:25: tons of stuff to do, still. could degrade GLENZ.S a little to get it 
running in 1 VBL. also noticed RIBBONS2.S and WIBBLE2.S still need slight 
degradation, too. should also test the sound of the "cracktro". but this 
download album sounds way too good to change! both grazey and gwem sent me 
replay sources..
 23:40: okay, those degradations are performed. feeling a bit tired now. 2.5 hrs
of debugging kinda rob you of your creativity. and let's not forget the last 2 
hrs of improvements to the looks of the thing..

26-01-2008:

alright! cracktro sound is working! and what was it? i didn't select a SNDH sub-
tune! wtf?! grazey's source was by far the best (best space bar check, decent
sound killing, and setting timer c -after- the init). i copied the sound 
killing. still, all those sources had ds.w 200 instead of dc.w 200, hahahaha.
 okay, now what? i guess i can copy the little clogs to the bottom of the 
cracktro screen. 
 19:30: waving reservoir clogs logo is in there.. the things runs 50 fps all the
time. well, almost. the morphing is still a painful issue. it's prolly due to
events being too close together.. but it's hard to notice.
 so wtf.. i spent the whole day on this godforsaken piece of shit cracktro 
screen. at least it has madmax s.o.s. 
 no clue what to do next. i could try to use my brain about the whole ribbon
clipping issue.. but maybe that's better left till tomorrow. i got some whisky
ready! 

27-01-2008:

01:50: fixed some festering crap in the rotator, added a decent trajectory and
dropped some scanlines to help the music. seems it does indeed take 10+ % in the
worst case. not bad. malc said it could be better, i'm eager to see. off to bed
now..
 10:50: tried to get the rotator symmetrical. but it's a bit shit. i can better
ask for a small banner graphic instead of wasting code on this. a good idea is 
to fix the ribbons.
 12:50: can't find anything wrong with the clip rout or orderding/counting. i
verified this on paper. 
 13:15: the intersection rout is free to go, but the ribbon clipping rout is 
tricky..
 13:25: seems it doesn't copy enough joints sometimes.. it was just a stupid 
counting issue, bah. it's resolved. the brain can be a good tool, sometimes.
 21:50: made an edge table. started particle table stuff.. just putting the 
stuff i assembled so far on usb stick. i'll send it to the team tomorrow.

30-01-2008:

i'll try to continue with the twister now. i want the colliding particles first.
second may be the swirling particles (words -> swirling letters). but i might
also try something else: optimising clearing areas in GLENZ.S. speeding or 
slowing the camera in the ribbons screen is also an option.
 21:00: some early bouncing stuff is done. it ain't bad but doesn't take any
nice physics into account. i'll cut it out for a little while but might come
back to it tonight.

02-02-2008:

19:30: it was a good day, today. made sprite extraction, preshifting, culling,
clipping and painting. and tested too. now used as particles. only need to 
restore the background. this can be a simple clearing rout..

03-02-2008:

wanted to paint an example font to use for the twist screen sprite-particles.
but it's 22:40 now.. underestimated the climbing today. turned out to take the
whole day. and other stuff came inbetween me and this demo. so i'm putting this
one on the todo list.

04-02-2008:

kev's new 128x128 texture looks awesome! think graffiti meets bubble bobble. 
i love it! :) using a lethal coctail of xnview and perl i managed to extract the
palette ste style and export it as 8 bpp.
 it's time for some crack art..
21:00: well fuck that idea! better try something ugly in gimp and conv to degas.
22:30: got some ugly font and trying to extract it to the pre-shifted sprite
format. i'm damn slow tonight. hating life..

05-02-2008:

after messing around alot i finally got those chars moving. with a completely
wrong palette, i might add. time to stop again.. more tomorrow, probably.

07-02-2008:

finally got that synergy demo grab for kev. i'll send it tomorrow. now i'll
continue with that char mess. didn't quite get a preview running yesterday.
 20:25: damn! it works! now i gotta set the particle state to dead when they
get culled. 
 20:40: okay, got that working.. but wtf?! seems top clipping is bugged. gotta
fix it.
 22:15: better. still crap, though.. 
 22:30: alright now. i gotta put in the right chars.. all Q's now, somehow. but
the background restoral will be the worst. i'm only doing the chars now. 

08-02-2008:
22:10: background restoral seems to be working half way. seem to have messed up
horizontal clipping in the process, yay.
 22:30: well, it's fast enough.. plenty of time left, even for sid voice crap.
clipping is still fucked up.
 22:40: horizontal clip is fixed. bottom clipping is still fucked.
 22:50: was easy to fix. simplified the paint rout in the process. btw, kev said
he'd work on something after i sent that icecream picture from the synergy demo.
let's hope he stays in 'the zone' for a while longer. meanwhile i gotta work on
some nicer movement of these chars.. it's just bloody horrible. but first, i 
gotta work on correcting the clear rout. it still seems messed up. scan line 
offset crap, ahoy.. 
 23:15: fixed. it's nasty fixing code optimised for such a code table afair.
 00:30: the sprite rout is simpler now, and correct! the screen can now load a
degas from file. time for a break. the movement can wait..

10-02-2008:

saturday got lost to the immense gravity of the couch and a massive pig-out 
session. the only thing i did was a bugfix in the particle movement.
 today i picked up the pieces and made some additional routines. the twister
can now be centered as well. i hope to make some rout to update the particles
in a spinning fashion..
 omg, the left-side clipping rout seems buggy as hell. here we go again. 
17:00: fixed that crap. let's try that spiral..
17:40: why do i always choose the hard way? the spiralling stuff should be from
top to bottom (or reverse) and shouldn't start in the center: where we are
confronted with bollocks like trying to align words horizontally and still 
morph them smoothly into a spiral movement. not worth it.

12-02-2008:

just the spiral movement.. even where the chars are going behind the twister.
that really sucks ass because the twister is copied to screen without any 
masking. this results in really lousy masking/clipping of the characters.
 i asked kev to do a 4 bpl font, but maybe a 2 bpl one would have been better.
i hope he doesn't matter. anyway, he's working again which will undoubtedly have
an enormous impact on the graphics for this demo... in the negative sense :/
 off to the stores to think this crap over.. maybe it's better to think this
with malc in the weekend. and start on the texturemapped ice cone..
 21:30: let's start that, then.
 22:10: created a new source file to hold the effect and made a first version
of the polygon-based part of the object. it's time to quit again, sadly.

14-02-2008:

today i recycled some scan conversion and texturemapping code from the rusty 
cpu-only version of my human fly engine. i completed the ice cone shape, 
basically. i should also recycle some transformation code from the 3D lib as
used in other parts of this demo. recycle re-re-recycle. there's not too much
original stuff you can try on this platform, anyway.

16-02-2008:

1:30: added transformation code.. untested. i prolly still need to initialise 
multiply and inverse tables. nap time!

17-02-2008:

2:10: here at msg's amsterdam hide-out. msg demanded to reorder all mainpart
effects, which was quickly done. some transition stuff like fading needed to be
improved. the rotozoomer now fades in with two steps. looks better. 
 the anti-alias screen has some train on the left side with (a place holder as
msg likes to call it). and the colours are true Nederlandse Spoorwegen style.
The demo already looks a bit better.
 we'll probably work more on transition stuff tomorrow. we do still need 
graphics.
 loads of transitions with faderouts done and some minor syncing shit. there are
plenty ideas to implement. some easy (fades), some quite feasible (wipes), and 
others possibly impractical (half object with the wibbly cube inside).
 it's done for to today and for the weekend. but i gotta say it was quite 
fruitful. msg gave some good hints and we tackled the sequencing and the 
splitting of parts. design and technical limitations always get in the way. 
that's the inseparable downside and charm of oldschool demo making. this wanker
is off to bed.

18-02-2008:

got a new train from kev. got to try that one..
 22:00: it's in there. now for the magnifier. 
 22:30: it's in, looks nice, terribly lame, tho. need to rip that sprite rout
from the twister. it needs to move around a little. 
 22:40: with the train in there the transition now looks like shit. more work
for later. night!

19-02-2008:

split the sprite extraction and painting from the twist effect and put it in a
separate library. i intend to use this for the NS (aaline) screen too. 
 22:30: fuck! still messing with that lib. seems to work fine now, though.
 23:10: YES! got the sprite rout included. was a bitch! but now the glass is
moving around. it's clipping-unsafe, but who needs it here. the zoom needs to
be repositioned, though. but since it's shift-register-based that won't be much
of a problem, i reckon. off to sleep!

21-02-2008:

3:00 completed a shifted zoom which is very constant in terms of performance due
to balanced or "reciprocal" shift (lsl.w #s,dn lsr.w #16-s,dm). the offset is 
messed up, so i'll fix that now. 
 3:10: done, piss easy too. think i'll do a transition effect now.. 
 4:10: got that transition (odd/even wipe) going. had to double the speed.
letting it take 4 whole seconds would be too much.
 4:40: included a fade too.. and the effect is stopped. bed time! for fuck sake.
my rhythm is disturbed. how the hell will i manage to get up early for oxy 
party on friday? 
 12:15: alright, the transition to the NS screen is done with the right 
colours. this was a bitch since yellow was supposed to be the background colour.
i could try to make a transition for the train piccy as well. but i'll prolly
wait for msg's comments.
 i'm a bit clueless what to do with the glenz part. the music keeps getting 
better and at the same time worse in the cpu usage department. the idea of using
a half or opening object.. it's nice and all but a huge amount of work and there
are obvious constraints (1 vbl-ness, clipping, etc). i'm thinking more of two
cubes drawn overlapped. with palette effects alot could be achieved.
 i'd have to move all these nice 12, 20, and 26 faces objects to the end.. a bit 
shit if you ask me. the re-cycling of the girl banner is not acceptable, though.
he's right about that. so, i'm ready to prepare for lame cube-ness.
 i could also do a title place holder, over the plasma.. 
23:10: worked on that lame cube shit for a while.. it sucks ass so much. boring
boring boring. i don't like the idea one bit. it's just too hard to realise. and
the amount of free cpu is lowered significantly.. it would be nice to have delta
polygons here. but that was not my plan. i'm clueless on how to continue. 
 msg wanted that record breaking stuff (26 faces in 1 vbl) to move to the end. 
of course, that's the only choice. i should just start with the end part. but
i'm cooked for now. screw this!

22-02-2008:

i thought the wibbling cube might have been inside out but it was ok. i still
can't figure out why that thing is so goddamn slow. testing it now and it seems
the polygons are the biggest concern. but the lines are slow too. which seems
quite unlogical to me, since they contains so few pixels. the clearing takes 
some time (thought it was faster..) and the 3d calcs are the least costly but
still i hate them. have to recheck the clearing.. seems to take 2.5 times as
long as the 3d calcs. this is about as costly as the lines. 
 i could optimise the lines, the horizontal case seems fine. but the vertical
case gives a too big loop, hard to jump with that one.. 
 23:20: i optimised the line rout.. but it's a very minor one.. in this wibble2
screen it can't be noticed at all. i just saw a change to fuck some bits and i
jumped on it. guess hacking the clearing rout would be a better choice. 
 23:40: just gained a few rasterlines by getting rid of the dull lea in the 
clearing rout.

23-02-2008:

 00:55: i should work on a place holder for the title graphics.. but first i
should benchmark that muddy plasma screen.. it's about 2.5, maybe slightly under
that figure. the problem is the music.. how the hell to keep it 3 VBL with music
and the damn sprite overlay? could freeze it at one point. 
 02:15: totally lame overlay with placeholder graphics. check! runs in 3 VBL for
the most part too. can be optimised, of course.. don't have the mask pre-
extracted yet. maybe havoc or kev can do something with that. 
 2:20: synced it in the demo.
should work on the texturemapping now.
 11:20: the demo works on a TT! only the resolution needs to be reset. TT 
detection needs to be in there. need seme h/w register listing. i don't know
the TT _VDO cookie value nor do i know the tt shifter h/w address.
 11:25: better get back to the 3D again.
 13:20: added table initialisation to the icecone screen. really useful if you
ever want to see anything at all. there are alot of 020 addressing modes that 
need downgrading to 68000 form. hell.. good thing i won't need to modify much
of the texturemapper algorithm itself, only the implementation.
 16:10: got all those *2's out.. let's hope it at least runs. hhhm, thinking of
something.. bah, i might need to improve the clipping. the S-H algorithm should
still be fine but the fucking problem is the splitting. it can much better be 
done straight to scan table by checking edge orientation. i'm writing to table
anyway, so there's no loss. and i can't see how to do it without much memory
access. you can ditch the scan table but then you're still stuck with loads of
stack access in the y loop.

24-02-2008:

 01:30: what the hell? it seems to run without crashing. after all that killing
of 020+ type instructions. don't know if it will look any good but it's a start.
 01:40: okay, i need a c2p rout as well. recycle!
 04:10: recycling done. it's slow as shit. can optimise, degrade or whatever..
but at the moment it would seem to be 4 VBL. that's shit. 3 VBL would again be
good goal. gotta sleep before i hit the road in the morning. blah.
 22:00: the c2p seems to be quite good for some generic stuff. i couldn't come
up with a better one 4 years ago and i doubt i can today. it might be possible
to inline it with the texturemapper. or at least, inline an optimised pre-
stepped version.. it's all triangles so it might work. i had an idea for a 
64x64 texture which is good for saving ram but maybe it's also faster if i use
more =)
 22:10: first i'd better continue with the looks of the thing. optimisation
can come later.

25-02-2008:

seems that only the left part of the first scan line is rendered. some offset
business gone all wrong.
 11:30: y offset problem fixed. x offset is still wrong. there's some blocky
background pattern as well. what's up with that?
 11:50: pattern stuff fixed. it's word -> byte stuff.
 14:20: there was an x translation in there.. bollocks! much better now. it
actually looks like 3D graphics! but only half of the cone polygons are visible.
i should figure out why.. 
 15:15: got a full cone now. unbelievable how much crap was wrong here. but it's
sorted and i got a full 3D engine at my disposal. 
 18:15: attempt to make a place holder texture. now it seems that the texturing
is all wrong? time to check the u,v coordinates. 
 19:10: it might be the damn coordinates. or not. i could replace them with a 
single set of 3 (u,v) coordinates. and i could replace the texture by a polar
lay-out instead of a cartesian. on second thought, the repeated set is not 
possible with the code as it is now. let's try the texture, then. 
 19:50: forget that. i just rolled up a piece of paper to make my own life-like 
model of an ice cone. that explained alot about the texture coordinates. 
 20:45: using my 'model' i concluded that the mapper is fucked. something might
have gone wrong when i got rid of the longword arithmetic. 
 21:30: taking the high level aproach. showing the object from some fixed 
angles. the mapping is definitely wrong. i need to go back to drawing a simple
triangle with a checkerboard pattern. 
 22:00: the test texture i made sucked. might have added to the effect. the cone
does look better but not nearly good enough. gonna have to test alot more with
the triangle. you got to love these fundamental tests.

26-02-2008:

mapping along x and y axes is good. but along a diagonal is totally messed up.
what the hell? let's take a closer look at what the code is doing at these 
angles.
 23:30: it's not the scan conversion. this seems completely fine. which is odd
since i changed this. and not the other parts iirc. it could be the uv slope
calculation.. because, yes, i hacked that too!
 23:45: yeah! as suspected! fixed it! the dy coefficient wasn't loaded. blah. 
it's an ice cone now! for real! i need to think about the wrapping of the 
texture, though. can probably be fixed by making independent uv coords. off to
sleep with a satisfied feeling! =)

27-02-2008:

by using an additional vertex i could get the wrapping done right. a nice 
solution. 
 23:10: preliminary z buffer ball drawing done. 100% pessimised and most likely
not free of bugs. 

28-02-2008:

just got a good idea. i don't need to sort polys mixed with balls. i think since
the cone is a convex object it means that the visible polys are always either
completely in front or behind the balls. this should be simple to test. maybe
just one z test on a single vector. 
 23:00 working on the ball precalc.. i need that fucking sqrt subrout. hope i 
didn't leave it up on the attic. yes, i did. bugger all! i only got 1/sqrt for
the anti-alias line. since the ball sprite is small it could be calculated with
procalc and put in a dc.b table.. but that's for tomorrow. too tired now. and 
got to work tomorrow. i want less work, more noise, more code, more (any) sex.
some alcohol wouldn't hurt either. one weekend won't solve that, but at least
i'll have a precalced ball? that i can do, at least.

01-03-2008:

02:00: 2 months left.. the ball is precalced by a perl script. was easiest. the
paint rout is done as well. i really wonder about the z stuff. i sincerely hope
i don't need to make the texturemapper z buffered as well. that would suck a lot
of cpu power. for the rest i can't wait to show this.
 what is still needed:
- full 3D transformation of ball center's (z coordinate is required for 
buffering)
- clipping of sprite rout
- palette hacks: cone should be brown, ice should be vanilla. 
nap time. 
 11:30: balls are on the cone! but they somehow don't seem to be in the right
triangle.. the z buffer is a bit off cos i scaled the ball values too hard. but
without scaling it doesn't seem to work either? ah fakk! seems to work better
when the z is scaled (was really huge). also, when intersecting, the damn sides
seem to overdraw and the rest doesn't?
 14:30: looking much better now. i screwed up the z test.. didn't add center 
offset! 
 15:15: tilting it a little forward helps alot. now i gotta increase the ball 
size. 
 18:00: increased ball size, hacked the palette, and sent a preview version to
to rg and lno crewmates. they haven't responded yet. seems they are all screwing
their respective girlfriends. also now smacked an endpart together. this 
contains the icecream cone and the twister. i should do some events. 

02-03-2008:

yesterday i only did some extra events and that's about it. but this morning kev
sent an icecream pic! i'll include it. it seems there is a hell of a lot to do.
even if all effects are now finally present. 
 what i can do today: 
- introduce and extroduce the ribbon, maybe speed it up a little bit in certain
parts.
- special wiping rout as transition for the train screen, using 'arrows' for 
each frame. 
- more transitions near the end..
- fade ribbons to black?
- start a delta polygon engine, to increase speed with the two cubes screen. i
really don't feel like it. but if i want to do it, i should do it now. 
- include kev's pic.
the last item i can do right now, i think.
 14:40: kev's picture has it's own effect. maybe a bit over-the-top, but in the
end it's probably best since it also needs fading and otherwise would really
make that ice cone screen source (TMAPICE.S) alot bigger. it's in the end part
now, as well. 
 14:50: adapted the background colour throughout the entire end part. best focus
on the main part again.
 17:45: the ribbons can now be ended really smoothly. put it in the demo as
well. looks better. 
 22:45: kev's font looks lovely. although the twister is all bloody red now. 
maybe i can place it on two other bitplanes.. can all be changed in good time,
of course. i got a delayed explosion in there too. additionally, i'd need some
shit like polar randomised speed vectors instead of cartesian, which just looks
silly (some particles are way too slow). i'd better be off now. 

03-03-2008:

polar speed vectors are done. looks better. now for some decent end texts. 

06-03-2008:

did very little.. some fading, noticed msg had made some faded patterns. these
are used now. also the the ribbon is shortened at the end. wasn't a bad idea. 
communicating alot with kev to get the graphics ready. my head's a mess at the
moment, so i'd better start with a list of tasks to perform in the coming weeks,
in order of descending importance:

- title overlay graphics (DONE)
- better train graphics (DONE)
- spazz cube bouncing off the sides of a 'room' (DONE)
- 'pointy' transition effect for the train screen (in) (DONE)
- fade in 8 low colours of train screen (DONE)
- fade to purple in train screen (DONE)
- glass moves over lines in train screen (DONE)
- big magnifying glass graphics (DONE)
- make zoom area circular. should be faster, even (DONE)
- center the rotozoomer (DONE)
- dots-to-cube fade? (DONE)
- twister '&' char (DONE)
- twister colours (DONE)
- icecream colour to vanilla (DONE)
- eliminate glitch in fades (DONE)
- spazz cube flash (DONE)
- dots should spin around fast (360) with some beats (DONE)
- spaz cube edges morph into '2D helix ribbons' (DONE)
- leave plasma palette inverted after logo has disappeared (fix fade-out..)
 (DONE)
- fade in rotozoomer background later (DONE)
- show bee in the center (stopped) at the beginning of the plasma, move from
 there (DONE)
- dots-to-cube with matching shape? fucked up box, or so? (DONE)
- keep the spaz ribbon close before moving it away.. (DONE)
- spaz fade out (DONE)
- introduce dots in somekind of iterative pattern (DONE)
- match 3D ice cone size with icecream pic (DONE)
- wipe twisters in and out (left and center versions) (DONE)
- slightly longer fade out or delay it a teeny time (DONE)
- magnifying glass should not jump but move to lines (DONE)
- new crazy q music in end part (DONE)
- fade out end part (DONE)
- fade-in spaz background (DONE)
- delta polygons on the cube-inside-cube screen (FAIL, can't be done in time anymore)

at the end:
- squeeze into 96K disk space! (DONE)
- squeeze into 1 MB RAM (DONE) 
- get rid of precalc times between effects (DONE)
- glitch in 3D transformation? (DONE)
- 60 Hz fixes (DONE)
- compatibility testing: 1MB STf (DONE), Falcon (DONE), TT !

just some additional ideas:
- busy bee flying on the title plasma screen, to become a bug (DONE)
- 'pointy' transition effect for the train screen (DONE)
- introduce ribbons
- wipe magnifying glass in
- twister masks, instead of chopping the sprites.. 
- many-faced objects at the end.. record shit. as reset part? 
 possibly best to make this a 4k.
- spaz background end (kick out walls one by one)
- fix "lineout" logo (no movement!) when the rotozoom starts?

i'm just talking with kev about all these ideas..

* note that loads of ideas were added to this list after 06-03-2008.

09-03-2008:

the last days have only seen a lot of graphical improvements. in terms of code,
only blit dimensions and palettes have changed. i still need to put in the '+'
sign in the twist texts.
 11:40: okay, did that. 
 15:00: working on the 'arrow' transition effect.. it's a bitch. and stuff like
clipping doesn't make things easier. sure could just use empty buffers outside
of the screens but that won't work when you don't have a hell of a lot of RAM!
fuck!! all this trouble for such gay transition. this is what i really hate 
about demo coding and ST demos are just full of it. 
 16:30: can handle south clipping now more or less. omg, this is taking way too
long. if these fucking transitions take more time it's gonna mean no more time
for delta poly routs and such, or a reset screen.. or.. wtf!!? this train screen
is turning into a goddamn bloodbath! next time i'm shunting ridiculous ideas. 
it could better have been a goddamn origami object over a nice backdrop. this is
just way too complicated and it doesn't show at all in the end result! fuck!
hating life!
 i'm pulling through this one and gonna complete it. but it's the last of its
kind. next time it's a fade or a simple wipe (pattern, vertical, etc). the
deadline is really getting to me. less than 7 weeks left! 
 23:10: sucks ass! die!!

10-03-2008:

20:50: north clipping works! jezus!!!! 
21:05: south clipping too! omg! finally! 
 22:00: the arrow wipe is in the demo now. looks sweet. still haven't got rid of
the interlace wipe. replacing with a fade might look shit. too much ideas too
much pressure too little time! 
 23:00 did a lot of fading too. looks good. even the yellow to purple. the idea 
for the transition is here at least! 
 23:15: now the glass also moves over one edge. indeed this looks nice. should
do more tomorrow. rest now!

11-03-2008:

completed the glass moving over the entire object. adjusting sync in the demo a
little. looks nice. now working on some background polys for the spaz cube. 
2 bit planes remain, so let's do something with those.. tried it. hangs. more 
tomorrow.

12-03-2008:

the poly works now, but is invisible. fuck! 
22:30: visible but still wrong? inside-out? or tri instead of quad?
22:40: ok, got it now! 

14-03-2008:

00:30: got the background for the spaz cube working.. looks like a room more or
less. and now it bounces to. and the bouncing starts with a nice flash! added
some entries to the todo list. oh boy. it's coming together at least. should do
a bit more this week and do a back-up to my old laptop. name: craptop, it's a
noisy little bitch too, either the fan or the HDD.
 off to get some sleep..

15-03-2008:

00:10: background restore on the spaz cube improved. looks without nasty shit
trails now. 
00:30: improved that damn random rout. shifting sucks ass. much better to fetch
bytes from ram, as i already knew. option to turn off the wibble done.
01:30: rounded the zoom area in the train screen. looks better. a glass might
fit around it. 

16-03-2008:

00:40: made a big fat circle around the zoom area. to give the impression of the
magnifyer.
11:00: making an SSD benchmark program. it's time i started doing things right
and take them into my own hands.
15:45: i made a sndh profiling tool and sent a graph to msg. hope he 
understands. in any case, i think 15-16% CPU worst case is a little too much. i
could try to adapt my effects. but fuck it. anyway, this tool is really 
indispensible for future coding on ST.
22:20: kev's glass and train graphics are in. man, they rock! this is a good 
day! one major downer is that checkpoint will be kicking a demo for outline and
it has been completed a month ago or so. shit!! that means we're no winners. 

17-03-2008:

22:50: worked on the sprite shit for the title screen (LEDPLS.S). once again i
find myself awestruck and mildly disappointed at the time this actually takes. 
it's a wise plan to dedicate the remainder of this month to design and perhaps
one more nice code thing. after that it's fixing, crunching, optimising to the
max. 
23:15: coded the extraction.. and it didn't work right away. big suprise!

18-03-2008:

22:10: extraction seems to work. paint rout still bugs. 
23:15: sprite rout is in there with some movement. no clipping. but i can't be
arsed. tomorrow the right movement will be done, i'll just skip the top-left
corner clip. perhaps using the fade-in i won't need clipping, anyway. i'm 
cooked!

20-03-2008:

00:20: better trajectory for the bug. still sucks ass, tho.. 
00:50: laming around checking 'hallucinations' by rg (probably mostly griff's
code). the gouraud is the only new thing going on there. but otherwise it's a
damn fine prod. the poly and line routs must be very fast for stf. it seems
like the lightsourced ball is 42 faces. i could do more than that in 2 VBL but
i wouldn't know if a 2 bitplanes version would perform the same. it'd be close,
anyway. the virtual city is solid code (shame about the non-rounded edges)
but 3 - 5 VBL. when i see this demo i'm still impressed. even if it's only 7 
screens. 
 in the greater scheme of things, this demo finished 5th: the runner-up from
last place. grimey, fantasia, and posh also competed (and that dhs demo which
failed to impress me, they did better stuff, for instance the invitro for this
year's outline). fantasia was better (the graphics, the great mapping routs,
the lovely medley by dma-sc, and oddstuff feelgoodness). and grimey was just
fucking original (hard to judge). posh.. was.. well.. amazing. yes, there were
nasty 4x4 pixels but still. an incredible achievement. 
 i think we're not in the same league as the last 3 mentioned demos. fantasia
is better with it's graphics and feelgood vibe. grimey is a milestone in design
and posh is basically the de-facto standard work for extreme st coding (it's 
still messy, though. that's one thing we can do better).
 meikever will be able to take on any decent dhs demo, or a hallucinations, or
the two st demos released at numerica, last year. but anything that defjam has
worked on for 2 years: no way. if the french guys have also invested over a year
and come with some asskicking graphics-design cutesy massacre, it's losing time
as well (although i highly doubt this now). 
 1:20: btw, it seems that SSD is a safe choice for low-cpu work. you can speed
it up when there's only a single voice (YM2149 state machine exploits). but this
is not the case with malc's tune. he said he wanted to optimise but after 
detailed sync is done. it's fine with me. but we need to hurry. enough muttering
for today. off to bed!
 10:10: back at doing the bug movememt. guess i could reverse the loop direction
to make it seem a little more chaotic. 
 17:25: movement finally looks right. the bug even sits still. 

21-03-2008:

01:10: got a 32x32 version of a busy bee.. it's now used. 
02:00: inverted palette! hurrah! now i need to fix that damn right hand side
clipping! but not tonight! i'm off!
23:44: more stuff is getting done at the party. just added a really nice triple
flashing invert to the title plasma screen. the glitch in the fading is gone.
corrected the ice cream colours. got a great idea for transition from the spazz 
cube to the ribbons.. 
 could do with simpler tasks right now. i'm a bit low on mental energy. i'll try
centering the rotozoomer.

22-03-2008:

00:15: the rotozoomer is centered. looks classy now. 
02:10: that spazz->ribbon transition is gonna be tricky. i seem to have gotten
the right edges for now. the morphing should be easy. and that's what will save
it. otherwise this shit will push it way beyond the acceptable cpu level.
03:15: seem to have gotten the unfolded shape right. 
10:00: awake for a while now. gotta continue on the morph.
10:15: checked posh/checkpoint again, and actually it gave me a huge amount of
confidence. this demo is very good but it's not really sick. only 1 screen is
3 VBL. the rest is 4,5, or even 7. and loads of 4x4 modes as well. and only 1
screen is in overscan.. it's not -that- impressive.
 but still, it has 15 solid effects and 5 good transitions going on. that's 
almost impossible to beat in this time span. i can best stick to perfecting the
transitions and continue on my usual path.
 15:45: did the morph. looks ok. should now wibble it a bit. the good old sine 
wave is a good candidate. 
 16:50: fixed to rotation to prepare for the sine wave. may need to morph if i
can't find the right rotation matrix to stop at. fuck! so much specific cases
and code.
 17:00: my demo system needs a fast-forward/search option. afternumerous runs of
experimentation i got the right point to stop at. 
 17:30: need to rethink the mesh. morphing a cube in this way leads to rubbish.
need also to stop x and y displacement and start the zoom out. 
 18:30: almost there.. only the backside of the ribbon.. oh boy! 
 20:50: omg, that took more time. i decided to skip indirect indexing (poly->
edge->vertex) and go for the more direct way (poly->vertex). that paid off. 
gotta try to move it a little more off center (if that's at all possible). it
looks, somewhat ok-ish. still not what i hoped.. 
 22:30: added some fading to compensate.. still i think the spaz thing should 
fade out as well.
 22:55: being more than just fed-up with transitions i will now add some spice
to the dots effect (360 degree spins). and then finally add those delta polygon
routines.
 23:45: okay, added that 360 spin. not bad. 
 
23-03-2008:

00:00: time for a delta polygon rout! i can't stand the fucking presentation 
code devouring the coding experience. must draw a bit in ASCII or on paper, 
first.
 cases for delta edges (horizontal):
* L-empty,  R-empty  : trivial
* L-empty , R-filled : shrink/grow cases
* L-filled, R-empty  : shrink/grow cases
* L-filled, R-filled : shrink/grow cases
 an obvious problem seems to be shrinking.. or rather, growing the opposite 
side. even if you use only 1 bitplane, you need to restore other planes too. 
also, you need to keep track of everything 'empty'. possibly, double indirect 
objects are required to know exactly which edges are shared between polygons. 
 every visible edge influences the screen contents. this is relatively easy. but
the damn occlusions and appearances of polys seem like a bitch. 
 01:10 i quit steem. who knows i may be setting up fades again. don't want that!
it seems that occlusions and such will be a huge pain in the ass. on the other
hand, when refreshing an edge. the only thing you need to do is -grow- one side.
so, maybe.. you could only draw using current and previous edge positions? 
 clipping is another issue i don't even want to think about. damn, this is an
interesting problem. can you feel your brain revitalising? probably S-H is out
of the question in this case? at least horizontally it seems like a good reason
to just introduce a special case?
 this brings us to vertical movement. partially this can be handled by the 
horizontal case stuff as i see it now. but i think you'd also need to extend it.
what's also possible is splitting up the background in polygons. this way only
normal and clipping cases remain. and not some special vertical cases.
 the more i think of it the more confusing it gets. making drawings in ASCII 
which sucks ass. i need some good drawing paper. i guess i'll have to start my
code with a single quad moving around.. 
 12:10: guess i could better make a scan table version of my polygon rout. 
 14:00: working on that rout. in itself it would be simple but i have a feeling
the scan tables would need to be re-used. i.e. first scan convert all -visible-
edges and then fill. strange that i took such an approach ages ago already. but
in this case it actually pays off. ;) 
 14:10: just writing the scan converter then and making it a bit reusable. for
visible edges i can always use the marking code from other screens.
 14:25: a nice idea is doing the edges on demand, directly in the polygon 
painting routines. 

24-03-2008:

back from breakpoint. while still there i completed a poly filler based on scan
tables. now i wonder i can extend it to use huge scan table lists. 
 22:00: an idea is to use a pointer table to index the huge left/right table.
i'll try that tomorrow. let's hope this will all help making a good edge-based
object/scene engine (a la cybercon3). at this moment i'm still not there. and
delta polys are even a step beyond this. i think the original edge indices would
also have to be stored in the pointer table. to keep track of frame-to-frame
edge displacement.. hell, it will be a really tough nut to crack. and i think
an incremental development approach is the only feasible one. thinking it all
out on paper will at least clear up some limitations or caveats. but probably
nothing more. you can't draw up all the data structures and data flow from 
scratch. i'm off. good night.

25-03-2008:

17:30: working on the vertex/edge based engine. i need all objects in vertex
and edge based format. basically doubling the data. otherwise, a combination of
backface culling and efficient finding of scan table data may be very tricky 
indeed. loads of translations and nastiness. 
 all this for a damn step up to that delta polygon business. it's nothing new
for me, though. i did zillions of poly routs and small 3D engines. the current
one even resembles an envmap screen from the alive demo (nine years ago!). i 
should get this one ready at the end of the week. 

26-03-2008:

22:10: i'm wasted. too tired. and lacking any real motivation. i'm in sort of a
post-breakpoint burn-out. but i'm getting somewhere, i think. still working up
to the delta polygon business. what i'm basically doing is adapting my old alive
routines to flatshading and n-polys. the former is piss-easy, the latter is a
bitch which involves rotating the polygon vertex array and all that tripe. 
 all-in-all, it's complex enough. and i really hope to have this done by the end
of the week. but the delta polygons.. man, they are gonna be frightful. i know
what i'm doing now is required as a basis. but exactly how much of it will be
necessary. will it turn in to twice or maybe three times the amount of work? 
for all i know it could turn out as a blood bath. but fuck it! this is what i
want. hardcore coding. i -want- to understand delta polygons. the rest, for me,
is not -that- essential. but i'm off now. too tired. 

27-03-2008:

22:10: at least i'm coding. i'm wondering whether a delta poly rout could better
do with continuous scan tables instead of the indirect ones (using pointers) i'm
trying now. this way is complex without delta functionality. i'm just wondering
how much more complex it will get. i'm going to use labels and ram access
everywhere to keep it simple and pessimised to the max. but i gotta quit now.
outline organisation stuff. 

29-03-2008:

spent last night monitoring and disassembling synergy's delta polygons. they
indeed use a separate scan table per edge. that's the way i thought it should be
done. i think i'll continue hacking for a while to gain some more insight.
 i've now removed the status register/trap messing, custom vbl count waiting and
other nastiness. i'm able to debug it comfortably at least.
 11:40: it seems the old scan tables are immediately overwritten with some 
numbers which are then used for the delta filler. i think they serve mainly as
somekind of jump condition. the delta stuff consists of two parts: 
1] some logic, fetching masks, replacing scan x values with codes
2] the delta filling, which also does some jumping based on codes
 it should be said that the delta filling is extremely efficient for the case
i'm checking now. it only does 1 (one!) word of writing.. 
 pinpointed the delta rout. need to figure out how it distinguishes between
normal (initial) and the delta case. done for now. to be continued.
 22:10: at malc's place now. just ate some upx packed seaweed. odd stuff. i got
a lot of items to add to the todo list already. doing these will hopefully make
the presentation a lot better.

30-03-2008:

part timings start (clocked by msg, not very accurate, lol :):
14,30,45,59,1:29 (dots),1:45,2.,2:29 (ribbons) 
 13:00: the plot table init is now as fast as it's gonna get. 
 15:30: optimised dots init time. really slick now. need to think of small delay
that's left-over still. should also be the same on tt or falcon.
 20:30: loads of init times are speeded up a lot! this means sub-second 
precision on syncing can now be done. but the aaline is bugged (only when linked
into the demo.. bah). have to debug! i seem to be able to reproduce some crash
when running stand-line (yes!) but with modified source (oh..). 
 20:40: this is caused by a line that of 0 length. don't know if this is our 
little piggy..
 20:50: apparently not. fixed the length 0 case. but still it messes up. let's 
if i can force the whole main part into test mode. well, i can. but the thing
just doesn't show me where the hell it bugs. i'm already sure it's in the line
routine. but that's about all. got it commented out, all is fine. i'm sure
it's the goddamn multab cos that's about the only thing i changed. it would be
a somewhat easier if the bug was reproducable when running stand-alone. 
 21:00: traced it! running the demo in test mode. and jumping to the fist frame
of paint_object. to be continued!

31-03-2008: 

squashed the bug, it was some holes in the table. damn quadrant stepping. there
is still -one- glitch in there.. damnit. 
00:25: too tired. the damn glitch can wait. postponed the background fade in for
the rotozoomer. msg said it would look better. i don't know why, actually? it's
just equalizing or flattening the event list to me. doesn't really look better.
but i can mark it as done. 
 1:00: stubborn as hell i wrote a compare tool, which is interesting. i have to
run the 'patched' algo output thru it.. there are some side cases. but i also
need to prefill the buffer with dummies to check for gaps. what a test method.
i seem to have lost the ability to prove my optimisations. must be stress 
related. do everything in a hurry and die. i'm off.
 22:30: squashed it. the miracle that is pen and paper. 

01-04-2008:

stressed out. organising work is interfering. did the centered bee, but 
realising 60 Hz compatibility will be a bitch. that's for later, though. now i
got to find either a way to leave the two top colours intact, without fucking
up the background too much. 
 22:30: that colour messing is teh fail. 
 23:00: okay, palette sorted, but somehow fucks up when linked to the demo!!
seems only to mess up when palette has fully faded in? it also happens without
the new palette messing. must be the new plasma rendering, then. arghl. 
 23:30: .. ah fixed it .. not being a retard helps. 

02-04-2008:

put the square in the dots screen. and made it morph at the last moment. 
however, the square should be smaller to really fit with the next effect. and we
probably need one of those cheap flashes too. at least the 'gfx' banner is gone
when the screen ends. solved that one. i'm off..

03-04-2008:

reduced the square size. slightly delayed the morph start. now for the flash.
 21:30: done, looks nice. but.. the spaz screen now screws up (wtf?!)
 22:00: indeed, somehow this palette stuff really messes things up. i can't
understand.
 22:10: ok.. i changed some timing in the boxglenz screen itself and now it's
okay. also when i turned off the white palette it worked. fucking wierd! there's
a damn ghost in there. gonna bust that fucker someday.
 23:10: tomorrow i'll start with some other simple presentation stuff. fading,
simple wipes. maybe some object movement too. off now.

04-04-2008:

23:15: fixed the spaz ribbons. want to fade between spaz and ribbon screens now.
there's some nasty offset bug. probably to do with the shared bss block. this
also caused yesterdays glitch. fixed.
 00:50: alright, i'm on a roll. moar fades! seems like the main part is now 
fully fledged in terms of palette stuff. but ehh.. damn, it's way past midnight.
i'm still on a roll. or at least, i think i am. don't know if doing more will
help.. 

05-04-2008:

introducing the dots. looks nice, but it crashes! after 20 minutes it got fixed,
though. looks cool. now i gotta move my ass. coming back late at night..

06-04-2008:

guess i could try to do the ice cream. maybe zoom out the pic, first. but i'll
just try to zoom the 3D cone in. 
 13:20: okay, bigger, and starts at the center. huge cohones too.
 14:00: working on a flash again. and that works now. 
 16:00: that wiping of the twist is done. now only a few presentation things are
left. and, actually, i don't think they are very important. only the sync i want
to heavily scrutinize. wiping in the magnifier glass is a thing that would be a 
bit hard. maybe i'll do the syncing later tonight. 
 21:40: looked at the music sync now, and really. there's absolutely nothing 
wrong with it. i can sync it to the start of a pattern but would anyone anywhere
really notice? the music and effects are not completely made for eachother. even
if msg did a really good job with adapting his tune. it's more like fantasia or
odd stuff in terms of sync. and not like obnoxious where you really have music
matched to every part of the demo and even every transition (great work btw,
but it does not necessarily mean a more enjoyable show). i think i can just send
this preview. let malc and kev judge it. 

10-04-2008:

working my head around delta polygons. in the mean time i have to do more 
practical stuff like writing readme's and a loader. both are done. there's a
nice crash after running the things.. bah. i don't really feel like debugging
all that. 
 the most frustrating is the delta polygon stuff. i know i need loads of time
and i just haven't got it. 

12-04-2008:

packed everything with upx yesterday.. works nicely, but the cracktro is too 
big. i have to strip loads of shit. but more important is the RAM usage of the
main part. atm it's 150 k too big.. oh fakk. bitmap mangling ahoy. i'll push
aside the brutal code for a while, then. 
 17:00: knocked off 30 k, going for more.. and just did 15 k more :) msg's new
track also saves 3 k, and a newer version is even smaller. :) 
 19:00: killed more and more. still 60 k to go, i think.
 19:30: and another 16 k. i like this job. i can save 8 more on the roto texture
and 1 more on the new ssd music. and possibly 10-15 on fade routine crap. but i
now saved 32k on the cube-in-cube. a whole unused degas was incbinned. hehe. at
this moment we're at 914 k. and i think we can lose the ~20 k mentioned above +
an additional 16 k for the spaz background degas (only 2 bitplanes used). this
will bring ram use to very safe figures. 

13-04-2008:

just killed another 16 k -> ram usage now 898 k. this makes the damn thing work
on a 1 megger, even from tos (okay, 1.2). also squeezed end part to < 900 k. put
msg's new .tri in there. i can't hear the difference. but it's slightly smaller,
though. the whole thing (including cracktro) is just 1.13 k too big.. it should
be possible to weed out some unused bits from the cracktro?
 21:00 i killed 200 bytes earlier. damnit, still 950 bytes to go!
 23:00 cut up the 'clogs' degas. now the cracktro is very very small. the whole
demo is 88 KB as a total! the goal is reached! zipped it up and sent it to the
others. tomorrow i'll get rid of the tos background inbetween the parts.

16-04-2008:

working on the delta polygons again. this time on my own routines. the edge
marking and v- and e- objects were bugged to infinity. took quite some time.
it's necessary.. i know.. but things are moving so slow. i just unplugged from
internet. fuck all that outline organising. even worse, i'd prolly go on pouet
too. 
 20:30: the marked edges are scan converted pretty nicely.. after i removed
that bug ;) i'm still thinking about rapido's delta routs. they are damn good
and may be called a masterpiece. it's not the stack abuse, the careful pairing
of instructions to gain 4 cycles more. well, yes.. also that. but that just is 
the very good realisation of a pretty sick idea. i understand the nuts and bolts
but i don't know how the engine is hanging together. maybe in a few days i will.
i'm working on both sides: making my own engine, and reverse engineering someone
else's. somewhere inbetween things should come together.
 anyway, respect to rapido. i can understand that he left after doing this 
engine. it's hard to top something like that. 
 20:50: the polygon indirection seems to work. same goes for the top/btm finder.
now for the rest.. direct-poly shifting seems to work (for this instance).
 21:00: and now for the hard part: the trapezoid loop. it's always a headfuck,
this. 
 21:15: hell, it seems like the e-poly needs reordering and not the direct one.
i mean, i already got the scan tables. makes sense, doesn't it? 
 22:30: we're getting somewhere. it now rearranges the e-poly and uses the 
direct poly (d-poly, lol) for top/btm finding. the problem now is that the edge
structures are not references directly by the e-poly. i'd need to replace the
e-indices with indices into the new table, or.. create the edge structures at
the old indices. that sounds lazy, and i've got plenty of ram, anyhow. that's up
for tomorrow.

17-04-2008:

22:00: i seem to have resolved that edge structure indexing problem. now i need
to have something like the trapezoid polygon filler loop.. there are special 
cases for horizontal edges, for instance. 
 23:15: horizontal cases work. the thing terminates too. but only tested for a
very simple case. it's pretty tight atm. quite unexpected. the hline needs a
some address registers loaded but this seems like all there's left to do. nice!
i've probably overlooked at least half a dozen issues but, hey. 

19-04-2008:

transformation code added, which seems to work. but some polys in the cube are
still reversed. need to work on that sometime. it's no biggie. passed the inv
table to the scan converter (important!). the hline should now work.. 
 13:50: damn, seems like the goddamn polys really need reordering?! fixed the
v-polys. need to reverse e-polys to match.
 14:10: okay, reversed all thos e-polys. should work better now. let's try
again.
 14:45: hell, sides are reversed. why?! let's swap em.
 15:10: swapped, fixed edge refresh conditions. fixed number of visible polys.
 15:20: yes! it works! now for the vertical offset. and there are probably some
overlooked bits. vertical offset done too, looks alright. 
 18:00: rotate a bit and the thing hangs. what do you expect? 
 19:20: damn, stop criterion is still shit. and there is a problem with painting
more than one poly.
 19:30: pointer dumped on the stack, now able to draw more than one poly. must
work on the goddamn stop criterion. which i did now, and it holds! this is 
fucking awesome! i think i actually made a better trapezoid-based poly rout
, of course ignoring the pessimisations, than the one without the scantable. 
let's test it some more.. 
 19:40: it's a spinning cube! yes! 
 20:15: it's not exactly fast. takes up at least half a vbl for a simple cube.
but the hline loop is damn silly. loads of stack shit. as i said, pessimised.
 20:40: seems unwise to optimise right now. the cube-in-cube screen looks like
it is slightly faster. but not much. prolly i'll be on a par with some 
optimising.
 21:10: i wonder if i should now try the delta stuff (use pen and paper) or try
to work on compatibility? 
 22:00: decided to ponder on delta polys once more. i got the trap/scan based
polygon engine now. this should be a decent framework. 
 23:40: been brainstorming and drawing like mad. i will stick to the edge delta
based thing. this is how it's already done. algebraic S-H is another option but
probably very different and esp hard to get pixel perfect. with edge delta there
are two main problems:
1) head/tail overlap between trapezoids. you need to figure out if you're
 dealing with an inner or outer trap. inner traps are quite deadly: in this case
 you have to use different edges in the new and old frames.. fucked up. it would
 have been so much fucking easier using a completely scanned poly.. but it's
 also (probably) less efficient. in the limit case it's 50% less scan 
 conversion.
2) 2x2 old/new combination of edges. in most cases it's old-left with new-left
but in some cases new-left has to be compared with old-right, and even new-right
in some cases. 
the combination of both sounds like a fucking nightmare. edge tables need to be
fetched from all over the place, offset, and compared like mad. keeping this
efficient is a challenge. probably a harder one than the engine i got now 
already (which came out suprisingly simple, i might add).
 might be a nice idea to check how the synergy code distinguishes between these
problems. although i have a nasty feeling i need to set up loads of test cases 
for that.

20-04-2008:

seems the synergy routs use all scan tables (all 4). that's what i expected.
otherwise you can't cover all cases. 
15:40: there are 3 cases for left and 2 for right. right is combined (followed
directly, without jump) by an administrative stage where all scan tables are
accessed. 
left cases: 
 L1] nl<nr (probably?)
 L2] nl=nr (even this is not sure?)
 L3] ln>nr (probably?)
right cases:
 R1] ??
 R2] ??
16:20: on a global tip: there are a couple of paint/wipe code tables:
 * delta (x2: zeroes, ones)
 * paint new (x2: zeroes, ones)
 * wipe old (x2: zeroes, ones)
 * 1 unidentified
 17:00: fuck.. i said there were ones and zeroes version of everything but this
doesn't seem true. the versions seem identical but there must be -some- 
difference, right? the left,right code tables and offsetmask tables are 
differ. but why also the start code, then? the versions of the delta rout have
the offsetmask tables swapped. this probably means that masks are inverted and 
the exact offset effect is unkown to me. 
 17:30: looking at the difference between offsetmask tables this does not invert
the masks, since they are swapped in the table as well.. but the offsets are
completely different. i also notice (all of a sudden) that these tables include
some form of clipping! and one table has a much bigger 'delta' in the offsets
than the other. this is exactly 20 times the other offset. and so 20 pieces of
iteration code down the road. why the hell a wierd number like 20?
 20:30: need to find out the magic of 20.. it's also clear some offsets cause
the thing to look inside neighbour code tables. nasty.. 
 22:00: yes! the 20! it's 20x16= 320!! there's one table to control the right
and one for the left. this gives 400 combos. 400x$92 = 29200x2. 29200 is the 
size of most code tables in there. the x2 is because there is a positive and
negative side. yes, i understand!! :)

21-04-2008:

so, i understand a bit. but i still don't really understand the table versions
thing. i think the different version of delta/wipe/paint are basically left or 
right 'dominant', respectively. as i see it now, the big jumps (20 pieces of 
code) are for the right side. the small jumps are fox the x. 
 22:00: the new_right becoming new_left confuses me. there's also some nasty-
ass compare in the left paint paint code. it seems like a clip case for the
right paint. yes, it clips the left side of the right delta span. (leftright-
leftrightleft...) 
 22:30: yes, the compares seem to be mere clipping. probably.. another 
interesting is that the thing totally doesn't use orring.. which is logical
since the bitplanes are used like i use them: separately. this indeed means
you can just overwrite. now why the hell didn't i come up with that?! that's
not very smart, is it? now using it! but keep in mind the poly can't
overlap! that's nasty! means things can be made too small or close to 
eachother.
 alright.. that's where synergy had to make sacrifices. it's clear. 
 22:50: about clipping. for a delta clearing effort.. it seems logical to avoid
clearing over bits you need to paint later on. so you just avoid it.. by 
clipping. 
 23:00 this means i completely understand one of the delta routines 
('paint_delta_spans'). the one with the single steps instead of the 20's is not
clear yet (what i call 'wipe_delta_spans'). but i guess that's up for tomorrow.
or else i'm gonna die. 

22-04-2008:

seems the 'wipe_delta' version, as i call it, has different offsets in the old
scan tables.. this means it is probably coupled to another routine. 
so, the 'wipe' version seems to uses x20 aligned old scan tables, but its
offsetmask table is 'unaligned'. yet the 'paint' version uses unaligned old scan
tables and a x20 aligned offsetmask table. this means the paint version has the
new scans as 'dominant' factor and the wipe version has the old scans. 
 in my eyes, this is teh wierd. cos the code tables are basically hline routs.
the position of the 'end mask' varies depending on index. can be either right or
left. hey! the a2 and a3 code tables are identical.. they do the same. only the 
a3 one has the administrative stuff rolled in. the masked side position varies 
with index (x1) and the unmasked side with x20. still holds for both. so a2 and 
a3 are identical except for different registers and an administrative stage.
 ah!! that was for the wipe version. in the paint version the unmasked position
is controlled by x1 (low index). so, that's the difference! now we're getting
somewhere! 
 so, now to figure out what this all means. i guess since the lut and old scans
hi/lo index are swapped this could be convenient. for swapped offsets you need
swapped code tables. but why for fucks sake choose two cases, then? why just
need keep things in the right order?! i could speculate but the only plausible
explanation at this moment seems that the two versions alternate. you see, one
writes x20 offsets, so it -must- be handled by the other version in the next
frame (!) let's try that. 
 of course, this is a bitch to test. unless i have some constant translation
going on instead of the rotation, like now. 
 20:40: tried testing that hypthesis. but i'm skipping it. the frame counter
has some pattern. but nothing really convincing. i could do a not on a var i 
guess. okay, that's a good one. 
 20:50: they alternate every 4 frames. this makes absoletely bollocks to me. i'm
at a loss to explain this. i'm also checking the more high-level routs at this
moment. L0045 seems to use two structures, one for the old scan tables and the
other for the new. there are some counters/positions in there too but i 
understand fuck all about them. 
 21:00: one of those values is an y offset, it seems. the others are y ends. 
it's funny to see that the last row of scans is untouched by the delta rout and
is subsequently passed on to a normal paint rout. 
 21:20: i now understand the business with trap #0 and move #$300,sr. it's to 
abuse the a7 register safely. when an interrupt comes it uses the ssp, not the
usp that we're now hacking on. that's only completely besides the point. but at
least it means there's no anti-ripper code.. 
 21:50: found (one of) the poly loop(s). this iterates over 'poly structures'
which actually seem to be the structures which i looked at at 20:50. i think
these may be only 2 scantables? and not multi-edges like what i'm using now?
there is also an additional loop to reprocessed marked polys. interesting.
 22:00: seems there is only one major poly loop. that's the one mentioned 
above. 
 22:20: so at least i got the main structure figured out. the poly loop seems
simple enough but i wonder about one case that involves a monster of a rout
which calls the delta/normal painters/wipers. nastyass shit. i gotta keep an
eye out. that's for tomorrow. 

23-04-2008:

got a feeling i'm getting to the simpler routines now. at least not so goddamn
obfuscated. but it can be deceiving. 
 22:30: hhmm, all the high level stuff seems quite easy. transform, then some
more geometry processing. and finally some scanconversion and filling. in this
case really incredibly nasty filling, but ok. i still want to know how the
polygons are organised. it must be somewhere just after the scan convert or
transform. 

24-04-2008:

need to find out that poly structure soon.. i wonder if it really edge based
or that the total sides of polys are used. i still have a feeling it's 
completely trapezoid / edge based. 
 20:10: identifying more and more routines: now the matrix generator is found.
it seems these routs are nothing special at all. the stuff i'm looking for is
probably found in 'scan_convert_polys'. the poly / edge structures must be in
there somewhere. there's some magical pointer block floating around.. what's it
for? seems like all 6 point to data. poly data? the structures are $36 bytes
long. although, more like $36-10 = 44. there are pointers in there (next, term)
and contents remain over frames (no x,y coords in there?).
 20:50: rotating around the z now and it seems like the poly edges are scan
converted after eachother. 
 21:30: scan conversion is a nasty process. loads and loads of cases. reversed
edges, copying instead of scanning. two loops. probably done for speed, tho. i
can imagine the same code working in half the space and more readable. 
 it indeed seems the scan conversion creates a struct of pointers to the scan
buffer. it seems to be a trapezoid! yes! finally some solution to this shit!
this basically means it's the same approach as mine.
 21:50: i also see the edges are scanned to to minimum length. i still don't
understand what happens to the rest.. the second and third trapezoids. afterall,
this is a quadrangle, isn't it? 
 22:10: found the wibble code too. completely special trap/scan conversion too. 
 22:50: L008A seems like a funny one. the rest i've seen is a min/max poly
direct-maker thingy.. really standard. i think he doesn't even use edge-based
geometry. damn. 
 23:00: fuck, i'm close.. but it seems all the slope calcs.. minmaxing.. 
clipping.. is complex. at least. after the the filler routs it's the most
complex thing in here. 
 23:15: confused.. i know where the trapezoids are. but there is just only one?!
it's fucking me up! this is shit. every rout seems the same, just 1 goddamn
trapezoid. nothing more. there should be two or three, or is this just some 
fucking effect of the limited rotation? can't be the scans seemed to have a 
slope already. 
 23:30: no!! finally! after all waiting 20 frames or so for the front poly to
rotate far enough.. it seems the goddamn thing does use continuous fucking 
sides. that explains all. and it's ofcourse also a goddamn lot easier that 
way. my trapezoid way is almost impossible to do, with all the fucking 
overlaps. 
 i think this is it! i understand. it makes sense! as stated in the previous
log entries, i had a suspicion but maybe synergy took the hardest way to save
a 100 cycles per poly. it could have been. but not really. it's all logical.
 now i know i can do this. no edge-driven engine required, no trapezoids. what a
goddamn waste.. hahaha. but this one seems so logical now. i reckon the way to 
do things best is just to start with basics. a simple engine using the scanned 
poly shit i already had. and build simplified (not table-based) fillers on top.
 i'll start with a single poly. i think there aren't any polygon inter-
dependencies anyway. it's quite clear because everything uses separate bit 
planes. that makes things sooo much simpler. i should write a doc on this. wow.
i can go to sleep with a good feeling for a change.. after many many days. 

25-04-2008:

for the first time in ages i actually worked on the damn presentation. the back-
grounds inbetween parts are now finally ok. delayed the main part a bit to wait
for the music to end. the whole thing feels better that way. don't know if i
should go on with this silly presentation stuff. but maybe i should. 
 00:05: got the glass moving slowly to the edges.. instead of jumping to it. 
packed the shit up and feeling tired now. 

26-04-2008:

setting a hard 60 Hz now in steem and it seems like only the bee at the start
should be changed. no problems, otherwise. 
 11:15: fixed that one, yihaa! 
 18:30: holy fuck. i just spent 6 hours setting up the falcon that just came
back from france. it's in a better condition than initially. CF cards remain a
problem. the pc is very picky about the partition table integrity. fuck pc!
 19:00: sh3 sent some graphics. the big bee looks cute.. but i kinda like the
nasty old bug. the background does look like an improvement, though. but i
hope the dither won't break the 96k. omg, i wasted so much time on the CF crap
that i only have an evening left!! i can't do a fucking delta poly rout in this
weekend. it's for the fail! my common sense tells me it's better to just save it
for the next project and work on the presentation and compatibility. but i want 
to do it. i'm a coder goddamnit, or not? 
 20:00: first attempt was to separate scan buffers, scanning and filling. this
works! now i will make a wipe rout instead of a filler. 
 00:45: the wipe version is done. i just reversed left and right masks. seems i
underestimated my chaotic state, laziness, and general shit. here i am, just 
trying write the first lines on the delta filler. i should have been at this 
point hours ago. it's rather annoying after many weeks still not having written
an actual delta fill rout, however unoptimised. there was just so much fucking
reverse engineering, speculation, and pen+paper work going on.. and loads of
wrong turns.. for god sakes people, a fully scanned poly, the simplest variation
imaginable! it's not so hard, is it?
 but delta polys were shrouded in blankets of fog, and mystique. teh magick ov 
teh poly named delta. it's just that these oldschool wankers never bothered to 
release sources... ever. so, things quickly got blown out of proportion. omg, 
syncscroll, omg delta polygons. okay, they are great routines. and yeah, 
syncscroll is a crazy concept, but as evl once explained it's not like it's next
to impossible to code or combine with other routs. delta polys are the same.
the massive code tables with the jumps and such, they seemed to illude. but 
after a while it's noticable that it's only the damn filler that's in these 
tables and the rest of the code is plain and simple. and behind the tables is
also a simple concept. with some documentation it would have been alot easier.
less trivia like digging around dissassembled code, commenting out traps and
status register moves would have been nice.
 wow, i'm writing like mad. must be the caffeine. too bad i'm not doing anything
productive. fuck! let's do that delta shit! 
 03:30: the first pessimised and untested delta filler in there. clipping cases
not done but wrote em down on paper. it's gonna be slow. the branches don't help
and the bsr already wasn't fast to begin with. i guess i'll do the clipping
tomorrow, first thing. then i'll test with horizontal displacement only. i need
some simple housekeeping on the buffers too. i think i will make the damn 
buffers external, otherwise they form a constant overhead on the demo. 

27-04-2008:

it seems i coded my first delta filler. i had to take care of the clipping 
cases. these aren't trivial, for sure. now to assemble it and take care of all
the bugs. after that. i'm making a small test case: horizontal displacement 
only. and i really hope i can get even further than that. if i manage to take
care of vertical displacement i might have a good chance to optimise this baby
in the coming days.
 17:00: reorganised the scan tables. made polygon structures too. tested. now
double buffering everything too and making room for old/new. 
 22:50: loads of buffers and pointers. preparing for the (near) future. sadly,
though. the pointer swapping and rotation is still not right.. grrr. 
 23:00: paint+wipe test with horizontal movement not working yet. although i
think i clear at the right time.. ah!! but it works now (stupid pointer rotation
things). so, i think i got a solid basis now. can't wait to hook up the delta
routine with this! 

28-04-2008:

02:45: messed up loads of things in calling the delta rout. now testing it 
against the framework. it's gonna need bugfixing i fear. and the question then
remains if it will be fast enough. on friday i will need to decide. 
 02:55: hey, at least it doesn't crash. the wiping seems dodgy.. on the other 
hand, however, the painting seems right (wow?!).
 03:10: this is incredible! there was a minor bug in the hline wipe and that was
all. it looks spotless, checked with steem frame-by-frame. left and right sides
seem to work. now i gotta move it to the other side. but i'm so euforic now. it
might spoil my buzz! i didn't do much tonight. but i didn't have to! up for
tomorrow is moving right-to-left as well, and possibly moving pretty fast to 
test the clipping. 

29-04-2008:

11:30: seems like both the wipe/paint and delta rout take exactly the same
amount of time. which is not bad. i'm already break-even! it's slightly (just
about) faster when the poly is wider.
 11:50: holy fuck, moving it left->right, right->left, letting it jump. it all
works!!! i can't fucking believe it! the first implementation i did and it just
works, straight away. what are the odds. this is the break i've been waiting 
for! i can finish this demo and put delta polys in there! i should now work on
the vertical case. 
 13:00: vertical stuff is not a success yet.
 13:40: upwards motion no problem. downward jump is a big mess! hhmm, i managed
to avoid the crash. but it still looks like tripe.
 14:30: vertical delta works! just reversing some cases, computing some 
additional offsets and all is solved. next up is circling it all around. it 
seems that the thing is alot faster when doing pure vertical motion. which is
logical cos the hlines detect they got nothing to do. 
 15:30: thing is moving all around now and it just looks perfect. unbelieveable!
now to use this baby! i've come this far, i'm not going back, no way! 
 17:30: the modified box glenz crashes most horribly.. and it looked like shit
as well. oh boy. turning off background restoral doesn't seem to help. am i 
doomed? how odd, 1 poly seems to work just fine.. already with 2 it messes up.
eh.. at least something is right.. of course, the scan table are overwritten.
let's clean this the fuck up. 
 18:00: it's a delta cube, alright. but a buggy one. i think the wipe 
(occlusion) isn't any good. dunno how, but with a single poly it's no problem.
i fixed it. it was the goddamn delta polygon giving back the wrong end 
addresses. okay. so, now it works (!!!!) but it's goddamn slow. here comes the
fun part :) optimising till you drop! there's a huge amount of work to do. it
seems the routine is slower than the original non-delta screen. which isn't too
hard to imagine since i worked long and hard on that routine right there. 
 18:15: i think i really would need to optimise the delta filler. the other
stuff seems decent. let's kill that silly width checking inside the hline. and
that bombed?! what on earth? what the hell? it crashes in the original hline 
routs? not the ones i modified?! ok, that ain't working. seems it still needs
somekind of guard around it. i've settled for a worst case optimisation. the real
speed will come from nesting, though. it will make the code ten times uglier, 
though, so i'll keep my old version safe. 
 21:15: this optimisation really works but it's not enough. it's still quite a
bit behind my scantable-less engine. i guess i can save some stack pushes and
pops. after that i'd need to copy scanned edges, instead of rescanning. okay,
that didn't speed up but did make things more readable. what actually did save
some time was not swapping the a1 and a3 but making the wipe optimised for this.
 22:10: maybe weeding out some dead branches could help. but i just compared it
to my other engine. and this thing is just too fucking slow. i think i cannot do
a full code table version. that would solve things. maybe if i didn't go to 
sleep tonight. but, that's just madness. i hate this. i came so damn close!! i
could still try at the party. wednesday night should be free too. wait! i can
probably also fixed the wipe/fill routs. these still have the bsr. that helped!
but it still over 1 VBL worst case. the dead branches might lower the threshold
but.. we still need to add another small cube. it's just.. impossible. damn! if
i just had another day! 
 23:20: tried scaling + masking the scans. it works but i don't see too much
improvement. i actually wonder why synergy didn't premask things. i could also
do this and it would make the hlines simpler. it would also be faster combined
with edge copies. i can make the hline use different registers for wipe and fill
(0,-1) that will reduce the setup cost. okay, did that. seems to hold. but
still not fast enough. fuck! i'm running out of options here! 
 23:40: another option might be using a datareg to store the address reg instead
of the stack. that would definitely speed up! yes! that one really helps. 
although it would be much better if i could perhaps abuse the stack pointer.
yes, it would save 16 cycles / scanline. i already saved 32 cycles / scanline 
now. it's just that the delta polygon's worst case is so goddamn awful. 
 23:50: knocked off another 4 cycles per scanline. that makes it so damn close
to 1 VBL worst case, i can't believe it. the biggest speed up would be a7 abuse
and.. that's one the code table will make wipe/fill case tests obsolete. that's
what's so great about that one. it's also a shame short branch fall-through 
can't be used at the moment. 
 00:15: and another 2 cycle average case.. but wtf.. i can probably write out
the macros, kill the dead branches and stuff.. i killed a branch in one case.
that takes away some of the worst case overhead. but it's still not enough. what
the hell do i need? a code table, quite probably! i can also destroy the damn 
masking on the sides saving 4 to 8 cycles per hline. it tears me apart to see
the best case at 60% and the worst at 105% or so. so fucking horrid! 
 00:40: compared to synergy i think i'm 20% slower or something. i think that
without a code table i won't make it. but hey, i can try. but actually, i need
that 20%. 

30-04-2008:

added a fade-out when the end part stops. 
14:00: just optimised the screen the normal way, reusing coordinates and such.
disabling the masks for the big object. that really helped. that engine is still
very fast. a delta engine needs code tables or other hacks. i can try later on
but it's rather senseless since i'd also need to chance design to show it off.
i can have a chat with defjam about it. 
 18:10: in the car right now. waiting for havoc. might do a bit of coding.
 22:10: havoc popped up just about when i was about to get some coding done. 
damn crewmates! let's try again. 
 22:30: fixed the final point in the main todo list. delta polys was actually
also a todo. but i'd need a couple of nights + some show-off idea. fat chance.
i'll have to save it for the next demo. i guess i could fix a glitch in the
ribbons. did that. i think now every screen has the desired frame rate and 
there are no tearing artifacts visible anywhere. this is how it should be. 
 22:50 guess i could do some code.. let's try to work a little on the delta
polygons some more. but i think i will write about that more in the chipsink 
log. this should be one of the final entries in this log right here. 3 days to
go. then the thing will be shown on the big screen. i better keep it a secret.
maybe i'll look at it a bit more with msg. 