Can I write a game in 3 weeks?

[DanScott]

could the C compiler be creating just awful 68k code perhaps?

[deimos]

Originally Posted by DanScott

could the C compiler be creating just awful 68k code perhaps?

I'm pretty sure now that the fault is mine. The last post that I just updated shows numbers that point to my code doing something stupid.

[sandruzzo]

why don't drive blitter filling with copper?

[deimos]

Originally Posted by sandruzzo

why don't drive blitter filling with copper?

Would I be able to do all the blits in 1/50th of a second? If I can't, can I break them up into chunks that I can do over several frames?

Also, this will limit me to only blitting from with the blitter queue.

Plus, I still think there's a problem with my interrupt code. I should make sure my code is actually correct before we take the easy route of writing of the concept.

[deimos]

If I can't fix my code by the end of the weekend, I'll start looking at implementing the queue with the copper. I'll lose a lot of the stuff I want, but life is full of disappointment.

If anyone wants to look at the code, I can post bits, or zip up and attach the whole thing.

If I do go down the copper list route, is there a way to have to copper write a value into somewhere I can read? that way I could know which blit the copper had reached and set up the next copper list to start from the next blit.

[DanScott]

Copper blitting is probably the most efficient way... I am not sure how to handle the situation over multiple frames (ie. slower than 50 fps), especially with variable sized blits...

There was a thread here on EAB somewhere discussing how to potentially do this.

EDIT: http://eab.abime.net/showthread.php?t=96968 <- here

[deimos]

Originally Posted by DanScott

Copper blitting is probably the most efficient way... I am not sure how to handle the situation over multiple frames (ie. slower than 50 fps), especially with variable sized blits...

There was a thread here on EAB somewhere discussing how to potentially do this.

I don't doubt that using the copper is the most efficient. But I'd still like to have a working blitter queue first.

[Tigerskunk]

Just want to say I like this project, and hope something comes out of it...

[Steve]

Originally Posted by Steril707

Just want to say I like this project, and hope something comes out of it...

Same here. Really enjoying this development of TFX 2.

Can't wait for the implementation of Gouraud shading.

Be great if someone could disassemble the code for Zeewolf 2. Probably the best 3D engine ever developed on the Amiga? Much quicker than the original.

[Tigerskunk]

Originally Posted by Steve

Zeewolf 2. Probably the best 3D engine ever developed on the Amiga? Much quicker than the original.

Wow, just youtubed that. Looks amazingly fluid...

[DanScott]

Originally Posted by Steve

Be great if someone could disassemble the code for Zeewolf 2. Probably the best 3D engine ever developed on the Amiga? Much quicker than the original.

It's fast, but the fixed viewpoint allows for a lot of optimisation compared to a full "free" roaming 3D engine. For example, the "landscape" and static ground objects don't need any rotation applied to them, and are purely translated to world space before perspective projection (that can also be highly optimised due to the limited Z depth)

[deimos]

As a test, and as a way to try and gauge the overhead of interrupts, I have modified my code to use polling rather than interrupts.

I still use a queue of blits, but rather than an interrupt being triggered that starts the next blit when one finishes I regularly test (using an inline function) whether the blitter has finished, and if so, then start the next blit.

Because it's possible for blits to be added to the queue faster than they are removed I loop over all remaining queue entries at the end of drawing a frame. This is the only place where I busy-wait for the blitter.

I have carefully chosen where I put my blitter-finished tests to try and minimise the amount of blits left over, without excessively littering my code with calls to the test. I often manage no blits left over, usually it's 1 or 2, never more than 3.

The only changes I've made to my code are what's necessary to do this.

My test draws 100 frames of my jet slowly spinning round. Prior to the changes it took 33 seconds. With the changes it now takes 30 seconds.

[deimos]

Originally Posted by Steve

Be great if someone could disassemble the code for Zeewolf 2. Probably the best 3D engine ever developed on the Amiga? Much quicker than the original.

Isn't that just a Zarch clone though?

[Steve]

Originally Posted by deimos

Isn't that just a Zarch clone though?

Yeah that's true. Still really fast 3D but as DanScott says, it's easy to optimize when the view is in a fixed plane.

[deimos]

Originally Posted by deimos

As a test, and as a way to try and gauge the overhead of interrupts, I have modified my code to use polling rather than interrupts.

One side effect of this is that I can now see more clearly where my normal, non-interrupt, spends its time:

Function Name			Calls	Time (ms)
PlayGame			1	77753
  DrawScreen			101	77557
    FillScreen			101	118
    Renderer_TransformModel	101	2348
    Renderer_RenderModel	101	68371
      RenderFace		2558	60542
        ClipPolyToNearPlane	2490	2269
        ClipAndFillPolygon2D	2490	55232
          FillPolygon2D		2490	46059
            DrawOneDotLine	20478	20614
            ScratchAreaFill	2490	2729
            CopyScratchInColour	2490	3835
    DrawingComplete		101	104
      Blitter_Yield		101	6154

These numbers are still distorted by the profiling code. Tomorrow I'll see if I can be smarter about that.

[deimos]

Well, I don't think I'm going to get my blitter queue to work fast enough. It's not the overhead of the interrupts (that's only 10% of my execution time), it's the fact that (as pointed out by DanScott) instead of just writing out the blitter registers I need to write them out, then read them in, then write them back out again, just to say that they were queued.

I'm now working on a copper blitter queue list. That way I just write out the values to the copper blitter queue list once, and the read back in and write back out will happen in cycles that I don't get to see, and will effectively be free for me.

That's how it works, isn't it?

Anyway, I've read ross's post (http://eab.abime.net/showpost.php?p=...5&postcount=19) about how he's done this, and I think I understand, but I'd like to see what the reaction in the room is before I go too much further.

In pseudo-copper-code, I'd be building this:

main() {
    ...
    blitter_copper_list = generate_copper_list();
    ...
}

vblank_interrupt() {
    custom->cop1lc = main_copper_list;
    if screen_update_ready
        custom->cop2lc = blitter_copper_list
}

Data in Chip Memory
===================

main_copper_list
    bpl1pth <= xxxx
    bpl1ptl <= xxxx
    bpl2pth <= xxxx
    bpl2ptl <= xxxx
    ...

    cop1lc <- loop

loop:
    skip_if_blitter_not_busy
    goto cop1lc                // loop

    goto cop2lc

    wait_for_ever


blitter_copper_list_a:
blit_clear_Screen:
    cop2lc <- blit_sky

    blt.... <- xxxx
    blt.... <- xxxx
    bltsize <- xxxx

    goto cop1loc                // return / loop

blit_sky:
    cop2lc <- blit_0

    blt.... <- xxxx
    blt.... <- xxxx
    bltsize <- xxxx

    goto cop1loc                // return / loop

blit_0:
    cop2lc <- blit_1
    
    blt.... <- xxxx
    blt.... <- xxxx
    bltsize <- xxxx

    goto cop1loc                // return / loop

blit_1:
    cop2lc <- blit_2
    
    blt.... <- xxxx
    blt.... <- xxxx
    bltsize <- xxxx

    goto cop1loc                // return / loop

blit_2:
    ...

If I understand correctly, this blitter queue will continue where it left off even when the main copper list restarts.

EDIT:

And I'd turn my current graphics functions to something like this:

void FillPrimaryDisplay(const UWORD colour) {
    F_START

    extern UWORD * previousBlit;
    extern UWORD * nextCopperWord;

    APTR bltdpt = backBuffer;

    for (UWORD i = 0; i < PRIMARY_DISPLAY_DEPTH; i++) {
        UWORD * currentBlit = nextCopperWord;

        *nextCopperWord++ = BLTCON0; *nextCopperWord++ = DEST | (colour & 1 << i ? 0xff : 0x00);
        *nextCopperWord++ = BLTCON1; *nextCopperWord++ = 0;
        *nextCopperWord++ = BLTDPTH; *nextCopperWord++ = HIGH_WORD(bltdpt);
        *nextCopperWord++ = BLTDPTL; *nextCopperWord++ = LOW_WORD(bltdpt);
        *nextCopperWord++ = BLTDMOD; *nextCopperWord++ = SCREEN_WIDTH_IN_BYTES * (PRIMARY_DISPLAY_DEPTH - 1);

        *nextCopperWord++ = BLTSIZE; *nextCopperWord++ = PRIMARY_DISPLAY_HEIGHT << 6 | SCREEN_WIDTH_IN_WORDS;

        *nextCopperWord++ = COP2LCH; *nextCopperWord++ = HIGH_WORD(previousBlit);
        *nextCopperWord++ = COP2LCL; *nextCopperWord++ = LOW_WORD(previousBlit);

        *nextCopperWord++ = COPJMP2; *nextCopperWord++ = "FFFF";

        previousBlit = currentBlit;

        bltdpt += SCREEN_WIDTH_IN_BYTES;
    }

    F_STOP
}

[sandruzzo]

@deimos

Speaking of Driving blitter with copper, I've taken another way: instead doing all that jmp with copper, I've created a well formated copper list, and I fill it with cpu when I need. Every blitter's chunck is stopped by copper end instruction, and if I need to call x-time blitter, I unlock that chunck x-time.

I did a test with draw 4 lines with this tecnique and it work fine. If you want better sync copper, you can put one wait blitter before copper end instruction. If you want reload copper list when copper end, jump add a coppers' interrupt.

Here:
Copperlist:
dc.w .... , ....
dc.w .... , ....
dc.w $ffff,$fffe -> I'll turn this into blitter wait if needed
Blt1:
dc.w .... , ....
dc.w .... , ....
dc.w $058, $0000
dc.w $ffff,$fffe -> same as above
Blt2:
dc.w .... , ....
dc.w .... , ....
dc.w $058, $0000
dc.w $ffff,$fffe

I have a small example done, if you need I can give you my source.

[deimos]

Originally Posted by sandruzzo

@deimos

Speaking of Driving blitter with copper, I've taken another way: instead doing all that jmp with copper, I've created a well formated copper list, and I fill it with cpu when I need. Every blitter's chunck is stopped by copper end instruction, and if I need to call x-time blitter, I unlock that chunck x-time.

I did a test with draw 4 lines with this tecnique and it work fine. If you want better sync copper, you can put one wait blitter before copper end instruction. If you want reload copper list when copper end, jump add a coppers' interrupt.

Here:
Copperlist:
dc.w .... , ....
dc.w .... , ....
dc.w $ffff,$fffe -> I'll turn this into blitter wait if needed
Blt1:
dc.w .... , ....
dc.w .... , ....
dc.w $058, $0000
dc.w $ffff,$fffe -> same as above
Blt2:
dc.w .... , ....
dc.w .... , ....
dc.w $058, $0000
dc.w $ffff,$fffe

I have a small example done, if you need I can give you my source.

How do you keep track of where to restart the blitter queue when the copper is reset during VBLANK?

[sandruzzo]

Originally Posted by deimos

How do you keep track of where to restart the blitter queue when the copper is reset during VBLANK?

I don't know how to do it, but my way is working. Maybe you don't need it. Ok, workload isn't big so far, I just write 4 lines (one polygon). Like I said, it works.

[sparhawk]

Maybe you already have read this thread, but then again it might be some help as it also is about blitter queues: http://eab.abime.net/showthread.php?t=58398