Archive: code bug?


28th January 2008 13:40 UTC

code bug?
i've run into a problem that causes winamp to crash 100% of the time.
it's a simple enough texer and as far as i can see there's nothing wrong with the code so i'm hoping one of you senior codemonkeys can tell me what the hell's going on.
here it is;

init/
n=1;

frame/
nx=w/ix;
ny=h/iy;
xsc=2/nx;
ysc=2/ny;
x1=rand(nx)*xsc-1;
y1=rand(ny)*ysc-1;

/point
x=x1;
y=y1;

basically, it divides the screen height/width by the texer height/width to find the number of particles it can fit on screen dynamically. for some reason though, the division process causes winamp to crash. the strange thing is, i had it working at one stage.


28th January 2008 16:12 UTC

that is dangerous stuff! o_O

but if i remeber correctly the image width/height ist iw/ih respectively, not ix/iy. let me check that...

yup, solves it :)
seems division by 0 is evil anywhere ;)

/frame/
nx=w/iw;
ny=h/ih;
xsc=2/nx;
ysc=2/ny;
x1=rand(nx)*xsc-1;
y1=rand(ny)*ysc-1;


gc

28th January 2008 16:32 UTC

/me throws in some bananas


29th January 2008 02:10 UTC

cheers gc.
it's so frustrating how much one letter can fuck things up -_-


29th January 2008 12:27 UTC

re-written and refined.
i'm sure someone else can find it useful.
and also a quick disco-ball preset i made with it.
comments?


30th January 2008 01:28 UTC

first one is somewhat nice, don't like the disco ball too much though..
but here's mine :)
movement largely drawn on fsk's newer stuff [thanks heaps for these jan! :D]
disable the convo-EL if you like...

who dares an improvement, huh?? come on...


30th January 2008 02:13 UTC

cheers gc. the first one was not really a preset, more just a "here's this scope i wrote" thing.
nice remix but the movement kinda takes away from the whole perfectly shaped grid look imo.
one of my submissions for wfc7 uses the grid for a background so keep an eye out for it.


11th February 2008 13:53 UTC

just to explain, division by zero does whats called "throwing a floating point exception". the cpu handles it in one of two ways depending on how it is set... it either carries on with a #NAN or #INF value and silently ignores it, or it catches the exception and "gracefully" stops execution.

I've yet to see a gracefully caught exception... probably because its so graceful I don't see it. :)

When you get a crash like this, look up the exception code (you can get it from the error box), e.g. 0xC0000005 is an invalid memory read/write (the most common one). Looking these up can actually help with debugging. e.g. I would assume you got a 0xC000008E, which if you google, pops up with some web pages about floating point divide by zero.