A.D.A. Amiga Demoscene Archive

z5: Are you sure the module is loaded in chipmem? Also make sure it's word-aligned.

Doing something on Amiga again would of course be nice, but it is not the most important thing to do right now. For the moment I'll limit my activities to keeping an eye on the scene and enjoying what is released and done by others.

Btw., it is your turn now. We all want to see your coming out with a first intro at next Breakpoint, don't we?

Regarding you effecttracker questions:

1) ET is called from the VBI, so Dooms advise applies ("don't take longer than 1/50s to complete" - DISPLAY2 takes more than 1/50s to complete - there you go). In most cases, ET is best used to call routines that influence the flow in your effect rather than calling the effect itself. Typical examples of routines that could be called from ET would be
- adjusting movements of all kinds
- setting new fade targets
- setting sprites

2) the "0" is an empty slot and thus does not get called. have a look at doc/Effecttracker.txt which explains the whole effecttracker system in depth (including hoe to set loops etc.)

I didn't know it was called from the vbi. That sheds a completely different light on it. I thought i could do the whole demo timing with it (start routine,...). However, one could still do a mainloop jumping to a routine and just move the routine pointers into it timed to the music.

Something like doom did for the interrupt:

mainloop
move.l current_main_routine,a0
tst.l a0
beq.b .skip
jsr (a0)
.skip
do_mainloop

In the "effects" started from the effecttracker, one could then write routine pointers to current_main_routine? Just thinking out loud here.

Believe me, i read the effecttracker docs.

ps. it's not my intention to release anything simply because i don't think i could achieve something worth releasing.

Don't you think you should get started before you give up? ;)

I fixed my Amiga today so i had the opportunity to watch my little "intro" on a real Amiga. Everything that wasn't vbi timed (mainly the non-color effects) fucked up and went way slower, meaning effects starting when others weren't finished yet. I imagine that this would also apply if i run it on different 68k processors aswell.

The conclusion seems to be that you need to at least time every start of an "effect/whatever runs in your mainloop" to a vbi-timer. Or am i missing something?

A last question on that matter: how can i time a start of an effect when i don't know how many 1/50s it will last.

Assume: i put a counter in vbi and increment it with one each vbi.

In my mainloop i check:
cmp.w #10,vbi_timer
beq.s .do_effect
rts

.do_effect
...
move.w #0,vbi_timer
rts

The thing is: how can i know that my effect will not take longer than 10*1/50? Because in that case, i'm doomed :) and my routine will never start.

(why do i get the feeling that this is a silly question :))

not sure if i get you right here so i am only commenting on your effect after effect problem. you might want to code each effect on its own, set ISREADY, assemble, save it to disk, etc. then you can write another effect that calls those effects according to some timing. keywords here are DEFEFX, INCEFX, CALLEFX.

hope that made any sense to you.

There are as many ways of timing effects as there are coders, I think. :) But the simple way is for each effect to simply count vertical blankings in parallel to the effect rendering. Then it loops until a certain amount of time has passed, after which the effect returns, and the main program goes on to call the next effect. That way you can be sure your first effect runs for 15 seconds, the next runs for 22 seconds, etc., regardless of the actual number of frames being rendered within those time frames.

To improve that, you could use a global timer that increments through your entire demo. Then make a single main loop for the demo that runs like this:

mainloop:

move.w globaltimer,d0

cmp.w #EFFECT1_START,d0
blt.b .skip1
cmp.w #EFFECT1_STOP,d0
bge.b .skip1
bsr effect1
.skip1

cmp.w #EFFECT2_START,d0
blt.b .skip2
cmp.w #EFFECT2_STOP,d0
bge.b .skip2
bsr effect2
.skip2

.
.

<do the c2p and doublebuffering>
<test mouse>
beq .mainloop

Each "effect" is then structured to render a single frame into the chunky buffer and return to the mainloop. You could also schedule multiple effects to run "layered" that way, by simply letting the EFFECTx_STARt..EFFECTx_STOP intervals overlap. Effects can be reused easily as well.

And the obvious improvement on that is to put the schedule in a table, giving you:

timetable:
dc.l <start>,<stop>,<entry_point>,<arg1>,<arg2>,<arg3>
.
.
dc.l -1

Which makes it easier to manage. Those arguments could be passed to the effects to enable more code reuse. Macros can accomplish the same thing as such a table, but then you have less freedom to optimize the code that scans the table, in case it gets significantly long.

A variation is to define the intervals in terms of module playback positions. You can read those out of the replayer's internals just as you could read off your own global timer.

Alternatively, you could use effects in the module to signal when each effect should end. The idea is to use a global flag as the loop condition for each effect, and instruct the replayer to call a routine when it encounters a given effect (such as E80) that switches the flag.

@doom: great explanation as usual. However, not what i was referring to. I already have a vbi-timer that STARTS the effects.

Assume i have two effects. The 2nd effect starts 10 seconds later than the first. The first one does this: clear 16*6 rectangles, one after the other => so it loops 16*6 times in my "main" loop. 10 seconds after the start of the first one, the second effect begins (regardless of the fact that the first has actually finished).

On Winuae, my first effect is already finished within 10 seconds. If i run it on my Amiga, the first effect is only halfway after 10 seconds, when the 2nd effects (at the correct time) starts.

So it appears that the first effect (clear rectangles) takes much longer on my Amiga than on Winuae. Which seems logical: there isn't any timing in my first effect. I just loop, clear rectangle, loop, clear rectangle,... so the faster the amiga (or pc in case of winuae) the faster my routine will be finished.

There is a difference between starting an effect at a given time and actually executing the effect at a certain speed.

Yes, that's the second issue. Generally speaking, an effect that relies on one frame of output to generate the next frame must run at full speed on the slowest of the target configurations, or it won't look the same across the range of targets. An example of such a "bad" effect is fireplasma, which repeatedly filters the same image while adding some random noise to it. There's no way it can look the same at different framerates without another approach than the standard 3x3 blur filter.

There are many things you could do in your case. All address the fact that how your effect progresses right now is (implicitly) timed to the number of frames shown, not a framerate-independent timer.

In any case, the effect must be coded so that it either:
- runs at full framerate on the minimum configuration,
- accepts a variable timestep as a parameter, or
- can do all its stuff based on a time index or set of parameters that can be updated independently from the effect itself

I personally prefer the first of those, but that's hardly traditional :). Most demos use one or both of the other two. Your clear operation is no doubt very easy on the CPU, so you probably want to use a variable timestep. That means:

vbiprocess:
increment timestep
return

effectloop:
currenttimestep = timestep
timestep = 0
for i=1 to currenttimestep
<your wipe effect>
next
c2p and buffering
(wait until timestep is at least 1) // if WOS doesn't already do the same thing
goto effectloop

This is assuming <your wipe effect> doesn't take too long to execute. If it does, you may run into a nasty feedback effect, where each frame is "measured" to be slower than the previous one. This can happen when there's a correlation between the rendering time and the size of the timestep. There is in your case, but it's negligible because by far most of the CPU time is used up by the C2P routine, which is run only once per step, regardless of the size of that step.

I don't get the point of that last example but i'll think about it somemore. An obvious question for me would be: if an effect runs at full framerate on the minimum config, won't you have the opposite effect: faster configs will mean that your effect will finish too early, leaving a gap to the start of the next effect. So no, i don't get it (yet).

On another topic, one thing i always wanted to do: horizontal scrolling of a picture. You can admire this in for example Heartcore or the intro of rain/TBL.

I seem to remember that there was a special register for that purpose and that this, combined with the modulo, was pretty easy to do. However, thinking about it, i don't see how i could do this in a chunky way, in this case on a 320*200 chunky screen?

You typically wait until the raster has drawn the previous frame at least once before you set the bitplane pointers to point to the next frame. The DISPLAY macro in WOS certainly does that just before switching buffers, which limits the framerate of any effect to 50. If your effect (including C2P etc.) should finish rendering in less than 1/50s, the CPU will simply wait for the raster.

The point of the second example is to measure how many vertical blankings occur between each time you reach the beginning of "effectloop". This is a measure of how long it takes to render your effect and do C2P conversion (and wait for the raster). Actually it measures the time it takes to completely render the previous frame, but that's good enough because that's exactly is the amount of time you need to "make up for" in the current frame to stay synchronized.

So, if your effect is designed to be called 50 times per second, but you measure that last frame it took 3 * 1/50s for the whole thing to get shown, then it's logical to do 3 times as much wiping in the current frame to catch up.

Re scrolling, the method is more or less exactly what the chipset does. If your picture is 1000 pixels wide, for example, do this every frame:

inptr = your picture ; 1000x200
outptr = chunky buffer ; 320x200

for y=1 to 200
for x=1 to 320
copy pixel from (inptr) to (outptr)
inptr++
outptr++
next x
inptr = inptr + 1000-320 ; skip the part of each line that doesn't fit (add source modulo)
next y

To move the picture, you'd then change the initial value of inptr.

minor correction to what doom said, just to avoid any confusion:
DISPLAY does not wait for the next frame (do not use it for synced effects)
DISPLAY1 waits for the next frame (so: maximum speed is limited to 50 fps)
DISPLAY2 waits for every other frame (so: maximum speed is 25 fps)

DISPLAY2 is the sensible choice for 320x200 effects in mode 1 since you can't sensibly reach 50 fps with 320x200 c2p effects in 8 bitplanes. many times you might be able to get faster than 25 fps, but then the frame sync would happen alternating at 1 or 2 frames from the last bitplane change. the result is a speed jitter which is much less desireable than a slightly slower but constant 25 fps.

I didn't think that copying the entire picture would be fast enough for smooth scrolling. I'll give it a try :o)

That's the only way to do it in basic chunky mode. You can optimize it, but it'll still amount to updating the entire screen. So don't expect supersmooth one-frame scrolling. You can get supersmoothness with hardware scrolling, but that's much more complicated, and also very limited with regards to what else you can do besides scrolling.

I'm a bit confused now... can i use the blitter (line drawing mode) within the wos environment or is it up to the cpu to do it?

Don't know anything about the WOS environment but the blitter can only draw lines in chip memory in bitplane mode. So you'd have to draw the blitter lines on top of the chunky graphics once they've been converted to planar in chip ram.

On cpus faster than 020 you are better off using the CPU to draw lines anyway because Commodore never updated the blitter chip from 1985.

Well, then i will repost my bresenham line drawing topic (it all seemed pretty ridiculous at some point so deleted the topic).

LOL I read that and then wonderd what had happend.

LOL I read that and then wonderd what had happend.

toffee, instead of "lol"ing, you should start doing something yourself :o) damn it, you know 99,99% more about effects, amiga hardware and assembler than me! Get something on screen! (that is ofcourse meant in a friendly way :o))

There was a flag that would forbid the usage of c3b1 c2p for 030 CPUs in WickedOS. I think it was called NO030C2P. If you set this flag you would only get CPU only C2P which are a tad slower on the 030 hardware but it might enable you to do your experiments with the blitter in chipmem and then manually overriding the bitplane pointers in the VBI to get some visible results that combine chunky screen and your blitter effects. Using the 64 cols C2P screenmode could be an option because it would leave 2 bitplanes free for you to toy around. Maybe?

toffee, instead of "lol"ing, you should start doing something yourself :o) damn it, you know 99,99% more about effects, amiga hardware and assembler than me! Get something on screen! (that is ofcourse meant in a friendly way :o))

I will code you 1 effect if you put my demos up :0)

Does vbi actually run every 1/50 sec in Winuae (a "no" is the only explanation that remains for my timing problems...).

It does run once every 1/50s, but the timing is messed up in UAE.

As far as I've been able to determine, in UAE, VBI occurs at the top of the display window, not at the beginning of the video frame where it's supposed to. When the VBI is generated you should have a lot of time before the raster reaches line $2c or wherever your DIW starts, but in UAE that doesn't seem to be the case. It's hard to test because UAE doesn't really emulate the copper and raster beam. It sort of fakes it.

But try to explain your timing problems. They might be trivial you know. ;)

I'm sure it is trivial but i just can't get my head around it.

Imagine: very simple effect: a grid of 6 lines, each with 16*16 squares on a 320*200 chunky pic (so 20 squares per line).

Effect = clear each square, one by one.

vbi_timer is updated each vbi (so 1/50 s).

routine: (this is a non-vbi routine)
cmp.w #2, vbi_timer
beq.s .do_clear_square
rts

.do_clear_square
here i clear one 16*16 square
clr.w vbi_timer
rts

It's important to note that i clear one square after the other. So visually i can check if everything goes to plan and i can see how much time it takes.

When i run this on my Amiga, one square is cleared every second (approx) which is way too slow. Winuae gives me a far better result because in any case, i should expect very fast clearing of the square.

Both in Winuae and Amiga, i see each square cleared, one after the other.

The strange thing is: if my routine was slower than my Amiga could handle (which can't be the case anyway), then it would just stop clearing squares because of the way i wrote the routine. I wrote especially the compare the vbi_timer with 2, not higher, not lower. Now imagine my routine extremely slow, the vbi_timer would have been way past 2 before clearing the next square, so it would never again be executed. And that's the part i don't understand.

You're right about the beq and all that. It looks like the vbi_timer isn't incremented right. A sure way to test that is to make another counter, call it vbi_timer2 which is never reset but just incremented right after you increment vbi_timer. Ie.:

add.w #1,vbi_timer
add.w #1,vbi_timer2

Use a stopwatch or some such to run the routine for ten seconds, then type

hvbi_timer2

The first two bytes of the memory dump would be this global timer. To convert to decimal easily use the ? command. E.g. ?$2a8 at the prompt gives you $2a8 in hex, decimal and binary.

Anyway, that'll tell you if the problem is with the VBI routine or not.

Oh and one more thing. You should clear vbi_timer right before you do the effect rendering, not afterwards. Otherwise the time it takes to render the effect is ignored, and if your routine is extremely slow, it'll still get called again two VBs after it last finished.

You should clear vbi_timer right before you do the effect rendering, not afterwards. Otherwise the time it takes to render the effect is ignored, and if your routine is extremely slow, it'll still get called again two VBs after it last finished.

Hm... by clearing the vbi_timer at the start of the routine, the routine only clears two blocks and then stops. When i put "cmp.w #3, vbi_timer", it works again, clearing all blocks.

I assume this means my routine is taking longer than two vbi's? I can imagine it being a lot slower on my real Amiga also. That would also explain why it cleared all the blocks on my real Amiga but did it slower: i was not counting for two vbi's between each start of my effect, but between the end and the next start, which it managed in two vbi's. :o)

Great help there doom!

Now the only question remains: why is it so slow? I've got palette cycling going on in the vbi + SETCOLS (each 1/25 s), i've got a little calculation on the adress for the block to be cleared + block clear + two DISPLAY2's.

Such an effect should imo take a lot less time.

Two DISPLAY2's? Why?

The block clear and all the other stuff finishes in almost no time. But C2P conversion is really slow. The DISPLAY2 macro IIRC does C2P conversion and waits until two frames have passed since it was last called, then switches buffers. So calling it twice should limit the speed of your effect to 50/4 fps.

Two DISPLAY2's? Why?

Because noname used two DISPLAY2's for his showpicture example (first page of this thread). I think you can't use anything else with this screenmode (being 320*200 256 colors)?

Ofcourse, i'm beginning to understand that it is quite ridiculous to use c2p and chunky mode (let alone double, triple buffering...) for such simple effects that would run on an A500.

Maybe i should find my old startup-code again and try doing some bitplane stuff again. I started with WickedOS because i could concentrate on learning assembler first, without the need to learn the custom chipset.