
<JackAsser> hey folks
[msg(WVL_KsZeN)] hey man
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] hey dude :)
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] sorry, didn't get home last night
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] so I couldn't download java
[msg(WVL_KsZeN)] hehe, no problem. It's nothing to see. I've done some additional work at home and began experimenting with the UI. This morning I did most of the outline
                 algorithm. Convex corner handling are done => insert circle arcs, concave is easy to implement, just find the intersection between the two stroked lines.
[msg(WVL_KsZeN)] angle measurment is also done, it's part of the outlining.
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] wow
[msg(WVL_KsZeN)] The UI is based on the fact that you edit solid polygons. These are overlayd in transparent ontop of the bitmap. The outlined areas are also shown immediatly
                 with a different shade so you can actually see how narrow things get etc...
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] damn
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] you're hell fast man
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] it took me weeks to get some simple things running..
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] then again, I'm coding in c64 assembler
[msg(WVL_KsZeN)] =) When I get inspired I'm fast. Also java with IntelliJ is so fucking smooth to code in.
[msg(WVL_KsZeN)] It'll be a bit pain in the ass to do the manual polygon rasterizer. In the GUI I use java's internal, but when exporting angle-pixels I've to manually
                 rasterize the polygons. This can however be done quite easy but ugly by using java's internal into a backbuffer then grab some pixels and modify the values of
                 them.
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] hmmm
[msg(WVL_KsZeN)] regarding the don't care pixels, those should be set to the value of the nearest edge angle-pixel, right?
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] yeah
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] to the left or to the right
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] not the pixels above/below though
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] this makes sure RLE-ing is done better :)
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] that's all
[msg(WVL_KsZeN)] I figured. =)
[msg(WVL_KsZeN)] But it would yield a more correct result if it's the 2d-distance.
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] 2d distance?
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] it doesn't matter?
[msg(WVL_KsZeN)] What about the pixels in the corners. Currently I was thinking of setting the to the average between the two adjacent lines.
<Jucke> hehe..
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] the ball never gets there anyway, it's inside a solid
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] I'm not quite sure what would be the best, maybe we should just try a lot and see what happens
[msg(WVL_KsZeN)] Well, I imagine you don't do collision detection each pixel so you could probably end up in the inside. How do you handle that actually?
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] I *DO* handle collision detection each pixel :D
[msg(WVL_KsZeN)] hehe, so do you do like a linedrawing between the last frame and the current one for the ball movement?
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] i divide the pixels the ball has to travel each frame in a way the stepsize is >.5 and <1 pixel
<JackAsser> oj! anal-sadel, sicken lyx!
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] and i step through the whole 'line', one step at a time
<Jucke> JackAsser: jag menar allts vanlig cykelsadel som gr upp i analen.
[msg(WVL_KsZeN)] ok, so if the speed is very fast, then you have to do quite alot then.
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] yes
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] the routine also keeps track of time
[msg(WVL_KsZeN)] ahh, ok. nice.
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] if the speed changes after a collision, and is multiplied by 2 for example, it cannot do the same # of steps
[msg(WVL_KsZeN)] nono.
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] it just keeps on doing steps until the total time in a frame has run out
[msg(WVL_KsZeN)] yea, ok.
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] so the ball CAN hit a wall multiple times /frame
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] without causing weird effects
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] also, I *MAKE SURE* the ball stays out of solids
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] that's guaranteed by how the step-engine works
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] so I'm really safe, and thus don't care about how solids work ;)
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] oh
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] there's one thing that would be nice :
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] at a later stage though :
[msg(WVL_KsZeN)] yea. The only backdraw with this pixel-method compared to mathematical analasys is that you get small rounding errors on each hit since the pixel isn't exactly
                 on the mathematical line. But it should look nice enough, but you will see that your kinetic energy of the ball will vary.
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] being able to draw special walls
[msg(WVL_KsZeN)] i've thought about that already
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] there's a small need to draw a wall for layer-changing
[msg(WVL_KsZeN)] my intention was that you may specify either solid, or special solid for a polygon, such as a layer-change area.
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] but that would only be a line-segment
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] maybe you could also enter it by hand in the data later on though
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] there's still another special solid though
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] one-way-pass-through solid
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] which basically is a solid inside out ;)
[msg(WVL_KsZeN)] ahh, ok. And those special solids should not have any angle calcs, i.e. only odd special #.
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] you see, to be more safe, I made the collision routine in a way the ball cannot move INTO solids
[msg(WVL_KsZeN)] ok
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] but it can move out of it
[msg(WVL_KsZeN)] ahh, ok.
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] -> if i draw a horizontal wall, $00 for example == solid below
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] -> a ball coming from above will bounce on it
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] a ball coming from below will just pass through
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] very nifty
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] -> I use this to close off certain areas of the playing field
[msg(WVL_KsZeN)] hmm, ok. Gotta do some work now. I'll figure something out.
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] like the exit of the ball shooter
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] but maybe we should just enter those things manually in the data
[msg(WVL_KsZeN)] nah, i'll figure something out in the UI.
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] basically that would also be solids, but just one vector drawn, not a whole circumsection
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] i thought that this way would be very nifty to describe things like that ;)
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] hehehe
[msg(WVL_KsZeN)] yeah.
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] also, you could make things where the ball can drop, but not go back up anymore
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] things like that
[msg(WVL_KsZeN)] well, l8er dude
[WVL_KsZeN(~poop@grensvlak24.leidenuniv.nl)] l8rs
[msg(WVL_KsZeN)] =)
