English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 18 October 2019, 22:11   #61
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Sunny Bournemouth, UK
Posts: 536
could the C compiler be creating just awful 68k code perhaps?
DanScott is offline  
Old 18 October 2019, 22:51   #62
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 537
Quote:
Originally Posted by DanScott View Post
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.
deimos is offline  
Old 19 October 2019, 08:07   #63
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,739
why don't drive blitter filling with copper?
sandruzzo is offline  
Old 19 October 2019, 09:09   #64
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 537
Quote:
Originally Posted by sandruzzo View Post
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.

Last edited by deimos; 19 October 2019 at 10:36.
deimos is offline  
Old 19 October 2019, 10:32   #65
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 537
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.

Last edited by deimos; 19 October 2019 at 10:39.
deimos is offline  
Old 19 October 2019, 11:07   #66
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Sunny Bournemouth, UK
Posts: 536
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

Last edited by DanScott; 19 October 2019 at 11:21.
DanScott is offline  
Old 19 October 2019, 11:21   #67
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 537
Quote:
Originally Posted by DanScott View Post
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.
deimos is offline  
Old 19 October 2019, 12:56   #68
Steril707
Tigerskunk!

Steril707's Avatar
 
Join Date: Sep 2016
Location: Amiga Island
Posts: 1,248
Just want to say I like this project, and hope something comes out of it...
Steril707 is offline  
Old 19 October 2019, 13:06   #69
Steve
You are Fake News!
Steve's Avatar
 
Join Date: Jul 2001
Location: UK
Age: 41
Posts: 2,288
Quote:
Originally Posted by Steril707 View Post
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.
Steve is offline  
Old 19 October 2019, 13:15   #70
Steril707
Tigerskunk!

Steril707's Avatar
 
Join Date: Sep 2016
Location: Amiga Island
Posts: 1,248
Quote:
Originally Posted by Steve View Post
Zeewolf 2. Probably the best 3D engine ever developed on the Amiga? Much quicker than the original.
Wow, just youtubed that. Looks amazingly fluid...
Steril707 is offline  
Old 19 October 2019, 13:56   #71
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Sunny Bournemouth, UK
Posts: 536
Quote:
Originally Posted by Steve View Post
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)
DanScott is offline  
Old 19 October 2019, 19:01   #72
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 537
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 is offline  
Old 19 October 2019, 19:21   #73
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 537
Quote:
Originally Posted by Steve View Post
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?
deimos is offline  
Old 19 October 2019, 20:14   #74
Steve
You are Fake News!
Steve's Avatar
 
Join Date: Jul 2001
Location: UK
Age: 41
Posts: 2,288
Quote:
Originally Posted by deimos View Post
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.
Steve is offline  
Old 19 October 2019, 21:24   #75
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 537
Quote:
Originally Posted by deimos View Post
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:

Code:
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.

Last edited by deimos; 19 October 2019 at 21:59.
deimos is offline  
Old 20 October 2019, 17:13   #76
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 537
Copper Blitter Queue Lists

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:

Code:
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:

Code:
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
}

Last edited by deimos; 20 October 2019 at 19:28.
deimos is offline  
Old 22 October 2019, 12:40   #77
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,739
@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.
sandruzzo is offline  
Old 22 October 2019, 13:38   #78
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 537
Quote:
Originally Posted by sandruzzo View Post
@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?
deimos is offline  
Old 22 October 2019, 15:05   #79
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,739
Quote:
Originally Posted by deimos View Post
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.

Last edited by sandruzzo; 22 October 2019 at 15:13.
sandruzzo is offline  
Old 22 October 2019, 15:26   #80
sparhawk
Registered User

sparhawk's Avatar
 
Join Date: Sep 2019
Location: Essen/Germany
Age: 51
Posts: 240
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
sparhawk is online now  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
So, I'd like to write a new Amiga game - what do you want to see? Graham Humphrey Amiga scene 88 26 February 2012 22:50
My sales over next couple of weeks emdxxxx MarketPlace 4 31 October 2007 11:17
AmigaSYS 1.7 Released ETA : 1-2 Weeks. Dary News 34 22 March 2005 20:51
HOL mentioned in this weeks Micro Mart fiath Amiga scene 8 07 June 2004 00:56

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 23:54.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.10693 seconds with 16 queries