This fake demo is not possible on ECS... But AGA?

[Photon]

Originally Posted by Mrs Beanbag

I think a real starfield is possible using the blitter. The blitter can plot a lot of points in a frame by clever use of line mode

Stopped reading here. Did you notice the filled circles in the starfield? Inventing effects is not about could and probably. It's about constantly testing ideas and seeing all but a few fail. Hehe. Apart from this, line mode is very slow on OCS and AGA, and no CPU can make it faster, so I can save you one test.

Why not enlighten people by showing what can be done instead? It's basically demo making in a nutshell - the opposite of making speculations.

Sine in 4 blits per 16px was done in summer of 1990. Perhaps before. I say no more.

Anyway.

Let me make some speculations that are more fruitful I think.

I've seen some porridge-pixel handcammed "newly rediscovered" old demos, one of them was very impressive but turned out to be an anim played from harddisk, ie. not possible on stock A500/1MB. OCS is really quite capable if given the same CPU, memory and storage options usually available for AGA/060, but that would not really be a sane platform Anyway, AGA just doubles the colors and palette depth and does nothing else.

It's impossible to tell anything definite from the potato-shaped video. But a very educated guess as to how it would be done on OCS is:

1) Background is basically the highlight of this intro (unless it looks like crap when run). Looks like 1 bitplane+vertical coppershade, leaving 3 for sine+buffershadows and 1 for the copperbars covering bg (you can also shuffle colors and decrease BPLCON by 1, but since 1 shadowbuffer has the same color as the copperbars it's the former). Even with this video quality, I can judge that the bg is not an anim that repeats. Odds are not bad that it's real circular 1bpl vectorbobs on a repeating star-anim - and of course you would see that instantly on a real Amiga instead of on crappy video. That's why videos of demos don't count.

2) The rest is no problem. The framerate and resolution of the sine non-scroller is impossible to judge, but 50 fps/1px is no problem. No offset on the shadows and no scrolling, but that's not a problem either. The sinebuffer is quite small so no clearing trick needed.

Horizontally shaded copperbars are pretty nice but even with 6 bitplanes they would shade nicely at 16px horiz resolution, in fact there are so few colorsteps between green and cyan that the visible resolution would have to be made coarser, 32px or higher.

Gotta agree with Stingray's "nothing special" this time. I think you get a bit fooled by that one perhaps doesn't really see it properly with the low video quality and assume it's a bad video of a flawlessly running demo, which it could indeed be, and which is understandable. But what you see is possible without tricks, and of course it's possible on OCS. So suspecting the source is not necessary in this case.


Infobox on YT apologized for the music but apart from lacking any memorable melody I think the sound overall was nice and Kraftwerkish and adds to the intro

If someone finds this, remember that BitWorld are keen on archiving it for the future! We have 29000 demos and counting...

We wouldn't mind a newly made OCS intro, but of course if it's some Python+SDL test code you'd have to go elsewhere

[pmc]

Photon: just curious, did you achieve the four blit per sixteen pixels sinescroller using the method mentioned here?


EDIT: Off topic but I need to ask Another one for you Photon: how can I get info on releases on Bitfellas updated? Last release of mine on there (which I didn't add myself) has most of the details wrong.

[Photon]

Darn, you caught me. I thought I was being coy. Nothing escapes you pmc.

No, I use trickery, because I have to do so much more than just a 1bpl sine scroller in full framerate It's possible to do mine with a slope > 45°. I remember Slayer made the Hangover Bobs circle scroll in 'Oh yeah!? Well check this!' response when he cracked the cartridge protection in my demo and saw the trick. Still no red bar inside the tube, but a very nice mapping formula in asm and I think of him as the king of cracktro scrollers because he made that and the screw and the 8-loop and...

Mrs. Beanbag's idea... well, with what he wrote, how is the 3rd blit done (in a single 3rd blit), if the second 0011 mask needs to shift 1px or 2px less upward than the first 0011 mask (because the slope is curving slightly, such as near the top of a sine wave)?

As a normal "DPaint skew" (except Silva only made the horizontal one) it works of course, but the slope mustn't change except between characters, and I think it would look not so good with those slope-changes. Also, if you're not happy with every character being 16/32px wide, characters would be bent at an angle mid-character rather than curved. If the slope-change is mild enough you could get away with it, but then it's so mild you could go 2px/3px wide blits and save even more time... so.

[Mrs Beanbag]

the slope changes, it is a smooth curve. the masks given were only examples, you calculate the masks from whatever curve you want to make. the calculation is essentially the same as a chunky to planar conversion. I can give you the source soon, I've almost finished it. it does work!

also I'm pretty sure that line mode is fast enough for over 500 points per frame, I've done spinning cubes.

[Photon]

Does the spinning cube have the dots spaced by perspective, as stars would be? Anyway.

Was about to edit my post and say I was fooled by the ascii graphics. Yes, setting the conditional shifting in the mask and copying is possible (without extra blits if abs(dy)<=1). For the 3rd blit you'd replace the 0011 with 0000 to only shift the first sliver. If the curve is steep there might be icky things to solve near max and min curves, but it only takes aligning peaks to between 16px words to solve that, so it's a non-problem.

[mc6809e]

Originally Posted by Mrs Beanbag

also I'm pretty sure that line mode is fast enough for over 500 points per frame, I've done spinning cubes.

But I think filled circles are being displayed and not just points. And some of the filled circles look pretty large at times.

Maybe a hybrid approach involving the CPU for writing small circles and blitter area fill for large might work. CPU needs to do perspective/circle edge calculations. Using MULs and DIVs makes that almost free when the blitter is running concurrently.

Still, I don't think there's enough time per frame to do this.

[Mrs Beanbag]

I don't know why so many people think the circles are a problem... they're not that big, and they're only one bitplane, and the maths could all be put in look-up tables.

[Photon]

Hehe, I think he as I just had a problem with making zooming starfields with linemasks.

Either way it's not a question of rastertime, it's very possible on OCS and is, you know, the standard look of a cracktro so why not do something else instead. If I wanted to spend the whole frame on the starfield I would just prerender the sine-nonscroller as an anim, don't even need a font

I'd be much more interested if you or someone made a demo with your effect and tweaked or gave it some twist or added some other nice thing, rather than a clone with starfield and copperbars to prove it can be done, to be honest.

[Mrs Beanbag]

yeah, actually, I'm planning something pretty special now it's got me thinking...

still, I'll post the sinewave scroller sourcecode tomorrow, I've got it pretty well sorted now, it's doing something like 75 blits per frame on a 320 pixel wide screen, or an average of 3.75 blits per 16 pixel strip. That could be optimised, currently the 8-pixel step is never skipped because that's the "master" one. It could be optimised away, but, I can't be bothered.

[mc6809e]

Originally Posted by Photon

I'd be much more interested if you or someone made a demo with your effect and tweaked or gave it some twist or added some other nice thing, rather than a clone with starfield and copperbars to prove it can be done, to be honest.

The effect takes something that naively is O(n) and makes it O(log n). Maybe there's some cool effect that naively runs in O(n^2) that can be made to run in O(nlog n).

[Galahad/FLT]

Originally Posted by mc6809e

But I think filled circles are being displayed and not just points. And some of the filled circles look pretty large at times.

Maybe a hybrid approach involving the CPU for writing small circles and blitter area fill for large might work. CPU needs to do perspective/circle edge calculations. Using MULs and DIVs makes that almost free when the blitter is running concurrently.

Still, I don't think there's enough time per frame to do this.

But thats an immediate waste of valuable time when predrawn circles would make the process far quicker.

If you look at the screen, only a few at a time ever get to full size in comparison to how many are on screen.

[Mrs Beanbag]

As promised - sine scroller source code! Requires some graphics memory to be passed to it, and a sine table. The blitting is adaptive, the shallower the sinewave the fewer blits it does. About 3 blits per 16 pixel slice seems typical. Everything between "Loop" and "doBlit" could be pre-calculated and stored in look-up tables.

bltapt    =    $50
bltcpt    =    $48
bltdpt    =    $54
bltafwm    =    $44
bltalwm    =    $46

bltcmod    =    $60
bltamod    =    $64
bltdmod    =    $66

bltcon0    =    $40
bltcon1    =    $42
bltsize    =    $58

bltbdat    =    $72

Height    =    32

*-----------------------------------------
* MERGE macro for chunky to planar routine
* takes two registers and swaps the bits
* specified by the mask.
*-----------------------------------------
    
merge    MACRO
    move.l    \1,D5
    eor.l    \2,D5
    and.l    \3,D5
    eor.l    D5,\1
    eor.l    D5,\2
    ENDM

*-----------------------------------------
* in:
* A0 - destination bitplane
* A1 - source bitplane
* A2 - source sine table (bytes)
*
* out:
* D6 counts the number of blits
*-----------------------------------------

sinescroll
    movem.l    A3-A6,-(SP)

    lea    $DFF000,A6
    moveq    #19,D7
    clr.l    D6

Loop    clr.l    D0
    clr.l    D1

    moveq    #15,D5
    move.l    A2,A3

.base    move.b    (A3)+,D1    ; look at the next 16 values
    cmp    D1,D0    ; and find the lowest Y-coordinate
    bge.s    .ge    ; (i.e. highest numerical value)
    move    D1,D0    
.ge    dbra    D5,.base

    move    D0,D1
    mulu    #40,D1

    addq.b    #1,D0
    and    #$F,D0
    move    D0,D2
    lsl    #8,D2
    or    D2,D0

    move    D0,D2
    swap    D0
    move    D2,D0

    lea    (A0,D1),A5    ; it is the user's responsiblity
    movem.l    (A2)+,D1-D4    ; not to let it go over the edge

calcMasks            ; Chunky to planar routine.
    sub.l    D0,D1    ; These masks are used to slice up
    sub.l    D0,D2    ; each 16-pixel column and scroll
    sub.l    D0,D3    ; multiple single-pixel columns at once
    sub.l    D0,D4    ; in worst-case log_2(n) time

    not.l    D1    ; Mentally keeping track of all the
    not.l    D2    ; bits was a nightmare but it looks
    not.l    D3    ; intuitively right, and it works
    not.l    D4    ; so don't ask too many questions.
            ; (We could precalculate all of these.)

    move.l    #$0F0F0F0F,D0
    and.l    D0,D1
    and.l    D0,D2
    and.l    D0,D3
    and.l    D0,D4
    lsl.l    #4,D1
    lsl.l    #4,D3
    or.l    D2,D1
    or.l    D4,D3
    ror.l    #8,D3
    merge    D1,D3,#$00FF00FF
    rol.l    #8,D3

    move    D1,D2
    swap    D2
    move    D3,D2
    swap    D3
    move    D3,D1

    ror.l    #2,D2
    merge    D1,D2,#$33333333
    rol.l    #2,D2

    move    D1,D3
    swap    D3
    move    D2,D3
    swap    D2
    move    D2,D1
    
    ror.l    #1,D3
    merge    D1,D3,#$55555555
    rol.l    #1,D3
    
doBlit    bsr    _waitblit        ; Wait for the blitter

    move    #38,bltcmod(A6)
    move    #38,bltamod(A6)
    move    #38,bltdmod(A6)
    move.l    #-1,bltafwm(A6)

    lea    40*1(A1),A4    ; The first blit copies the data
    lea    -40*1(A5),A5    ; from the source onto the screen.
    move.l    A1,bltapt(A6)    ; The mask selects which slices to
    move.l    A4,bltcpt(A6)    ; place 1 pixel higher than the others.
    move.l    A5,bltdpt(A6)    ; Leave a blank line above the source!

    move.l    #$0BB80000,bltcon0(A6)
    move    D3,bltbdat(A6)    ; the mask goes in bltbdat
    move    #64*(Height+1)+1,bltsize(A6)
    addq    #1,D6        ; count how many blits we did

.blit1    tst    D1
    beq.s    .blit2        ; we can skip if the mask is empty
    bsr    _waitblit

    move.l    A5,bltcpt(A6)
    lea    -40*2(A5),A5    ; move selected slices by 2 pixels
    move.l    A5,bltapt(A6)
    move.l    A5,bltdpt(A6)
    move    D1,bltbdat(A6)
    move    #64*(Height+3)+1,bltsize(A6)    ; BLIT
    addq    #1,D6

.blit2    swap    D3
    tst    D3
    beq.s    .blit3
    bsr    _waitblit

    move.l    A5,bltcpt(A6)
    lea    -40*4(A5),A5    ; move selected slices by 4 pixels
    move.l    A5,bltapt(A6)
    move.l    A5,bltdpt(A6)
    move    D3,bltbdat(A6)
    move    #64*(Height+7)+1,bltsize(A6)
    addq    #1,D6

.blit3    swap    D1
    tst    D1
    beq.s    .next
    bsr    _waitblit

    move.l    A5,bltcpt(A6)
    lea    -40*8(A5),A5    ; move selected slices by 8 pixels
    move.l    A5,bltapt(A6)
    move.l    A5,bltdpt(A6)

    move    D1,bltbdat(A6)
    move    #64*(Height+15)+1,bltsize(A6)
    addq    #1,D6

.next    addq.l    #2,A0
    addq.l    #2,A1

    dbra    D7,Loop

    bsr    _waitblit
    movem.l    (SP)+,A3-A6
    rts
    
_waitblit
    move    #$8400,$96(A6)    ; might as well give the blitter
                ; priority while we're waiting for it
    btst    #6,$2(A6)
.bl    btst    #6,$2(A6)
    bne.s    .bl

    move    #$0400,$96(A6)
    rts

Note this is hard-coded for 320-wide screens! But you can work that out...

[Galahad/FLT]

Sorry mrs.beanbag, quoting system has gone wrong, I was quoting mc6809e and it appears to have quoted you! :/

[mc6809e]

Originally Posted by Galahad/FLT

But thats an immediate waste of valuable time when predrawn circles would make the process far quicker.

If you look at the screen, only a few at a time ever get to full size in comparison to how many are on screen.

It's possible I suppose if one sacrifices some accuracy by only holding a subset of all possible circles in chipram. I wonder if it would be noticeable.

Hmm. 512k would hold 128 4k single plane filled circles but most wouldn't even need to be 4k in size.

Yeah, that might work out well. Use the CPU/blitter to precompute all filled circles of diameters say 1 to 128. Determine the memory needed for each one. Create a table of pointers to structures that hold the address of the bitmap and its size with the index to the table being the diameter of the circle. If the size is less than about 10, don't bother with the blitter. Just use the CPU to render.

Okay. I'm convinced.

[Mrs Beanbag]

no cracktro would use that much RAM! Wouldn't even run on stock original A500...

blitter fill mode isn't that expensive, I reckon you could draw the outlines with the CPU just by storing tables of width as a function of Y (for every different size if you like). XOR them into the bitplane and fill them all in one go. I never see two of them overlap in the video, or maybe I'm wrong. Then plot the stars on top. We assume the stars are behind, but it makes no difference if you draw them last.

[Amiga1992]

Originally Posted by Mrs Beanbag

As promised - sine scroller source code!

Anyone kind enough to compile it into an executable file for us non-coding retards?

[Mrs Beanbag]

it won't run as an executable on its own, I was only loading it into AMOS and calling it from there to test it. if you want an executable I'll have to do some more work, but the real purpose of the code is for people to look at the code

I'm mucking about with starfields now

[prowler]

Originally Posted by Galahad/FLT

Sorry mrs.beanbag, quoting system has gone wrong, I was quoting mc6809e and it appears to have quoted you! :/

Fixed!

[Amiga1992]

Originally Posted by Mrs Beanbag

ithe real purpose of the code is for people to look at the code

*looks at code real hard*

...

I don't get it But I take your word for it!

[Mrs Beanbag]

I've been reading all about Bresenham line functions lately. Circles with integer math are not a problem! Furthermore I think an entirely integer math (no division) starfield is possible as well with a similar technique.