dirkdeftly
10th February 2005 22:15 UTC
Truchet lines
long time since i've avsed...
simple preset that draws truchet tilings. i'll expand it later.
the reason i'm posting it now is because gmegabuf acts really weird in this preset. i have two instances of texerII. the first does some changes to gmegabuf onbeat. both should immediately accept these changes, but it seems that one or the other doesn't accept them until one frame aftewards (i *think* it's the first one, but i'm not sure)
the first texerII changes reg00-02 as well, and occasionally it seems to take two frames for both texerIIs to synch that as well.
i tested gmegabuf on this in another preset (included in the zip). if this were a universal bug, the two dots in that preset would be on different sides every beat. that doesn't happen, so i'm going to assume that the bug is isolated to my preset.
i'd like to resolve the bug before i go any further with this idea. does anyone have a clue why avs would be doing something like this?
Tuggummi
10th February 2005 22:39 UTC
I don't know why it does that, but putting the gmegabuf control to a superscope before the effect list's atleast solves the problem and you can use just 1 frame to render them.
btw. Great idea and preset so far :)
Warrior of the Light
10th February 2005 22:45 UTC
get the same problem here.. what about it if you'd calculate the globals in a seperate t2/ssc or in Jheriko's Global Variable Manager (still in beta)?
Welcome back my the way...
/edit: doh! you beat me on that!
S-uper_T-oast
10th February 2005 23:24 UTC
OMG HE TEH LIVES!!!One!@$#!#elven@#!^!!!!
Nice to see your back.
jheriko
12th February 2005 17:08 UTC
Re: Truchet lines
First off, I'd like to welcome you back. (We had best start warning teh n00bs!11!!!!1!)
Originally posted by dirkdeftly
i have two instances of texerII. the first does some changes to gmegabuf onbeat. both should immediately accept these changes, but it seems that one or the other doesn't accept them until one frame aftewards (i *think* it's the first one, but i'm not sure)
From my recent work with apes I can tell you that Texer II probably executes init, frame, beat and point in a fixed order every frame. If it was executing init->frame->beat->point then changes on beat would only affect the second texer's frame code
The reason for using this order is that you want on beat code to always take priority over on frame. This is because setting variables on beat should always overwrite what they were set to per frame so that right values are there for the per point code. In addition, it means that you can respond to a beat on the frame that the beat happens on, and not have to wait for the next one.
I haven't tested this theory out... but I'd guess that superscope, dm etc do the same and that this is why they provide the 'b' variable.
If I was making Texer II this is certainly how I would implement it, and this would cause a problem like what you describe where the first texer executes the code on beat and the second one executes its frame code with these new values, but the first does not.
EDIT: just looking at your test preset... i don't get any bug... what is odd though is that if i insert effect lists to destroy fps then sometimes 4 blobs are rendered per frame instead of 2... I thought maybe I was going nuts so I slowed it right down to 10fps and screenshotted it a few times. All sensibly coded so as to avoid the problem I mentioned above too... setting the el to 1 frame has no effect here
EDIT2: the above is actually just an artifact of the preset construction (els). If two consecutive frames are beat frames then the framebuffer isn't cleared so 4 dots are drawn instead of 2. could this be causing your problem also?(although i cant see it?).. i doubt it as this effect list job looks like it was made to expose the problem. btw... the tiling pattern is nice... looks correct in all res I tried it on.
PAK-9
13th February 2005 13:05 UTC
Re: Re: Truchet lines
Originally posted by jheriko
init, frame, beat and point in a fixed order every frame. If it was executing init->frame->beat->point then...
I'm pretty sure the init code isnt evaluated every frame my friend ;)
jheriko
13th February 2005 13:48 UTC
potentially every frame....
PAK-9
14th February 2005 13:54 UTC
...but realistically not
jheriko
15th February 2005 18:03 UTC
The point is that you have the same order of code execution every frame... which is useful to know for debugging since you know in which order all of your code gets evaluated at any time.
And I make mistakes. :P
Tuggummi
23rd February 2005 20:47 UTC
Here's a "remix" i did, though as the preset isn't finished yet, so i can't say if it's a mix or a "making the preset complete"... but anyway, hope you "dig it" dude :p