English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 16 October 2019, 11:30   #21
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 545
Interim Update, Day 3

I've not been able to get blitter fill mode to work correctly, my polygons are just not being drawn right for it to work. I have a feeling that for onedot mode to make sense, it needs a different set up to the normal line blit code - if the lines are always drawn from top to bottom and the first bit is always set, then this won't be correct for lines on the right hand side of the polygon, which need their last bit set instead of the first.

In order to make some progress I've kludged the area fill code to just draw the outlines of the polygons. Today I will try to catch up with the Day 2 tasks by cleaning up my 3D transformation and BSP code, adding some movement to the jet, and drawing the ground / sky.
Attached Thumbnails
Click image for larger version

Name:	outlines-only.png
Views:	202
Size:	7.9 KB
ID:	64784   Click image for larger version

Name:	another-view.png
Views:	103
Size:	8.7 KB
ID:	64785  

Last edited by deimos; 16 October 2019 at 11:48.
deimos is online now  
Old 16 October 2019, 13:15   #22
hooverphonique
ex. demoscener "Bigmama"

 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,062
I've used both the 'xor the first line pixel using the cpu' and the 'draw top-down with bltsize-1' approach, and they both work fine for blitter fill.

Why would lines on the right hand side need the last pixel set in favour of the first? With regards to filling, it should work if you draw all lines top down and skip the final pixel.
hooverphonique is offline  
Old 16 October 2019, 13:41   #23
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 545
Quote:
Originally Posted by hooverphonique View Post
I've used both the 'xor the first line pixel using the cpu' and the 'draw top-down with bltsize-1' approach, and they both work fine for blitter fill.
I'll come back to this later with some test cases. When you say bltsize-1, what do you actually mean? If my normal bltsize is calculated as "((dmax + 1) << 6) + 2", do you mean dropping the "+ 1"?

Quote:
Originally Posted by hooverphonique View Post
Why would lines on the right hand side need the last pixel set in favour of the first? With regards to filling, it should work if you draw all lines top down and skip the final pixel.
Because if you'd drawn the outlines, all the pixels from the first to the last would be set? So, the most extreme point on the right hand side is the last pixel? Unless you're drawing the line upside down...
deimos is online now  
Old 16 October 2019, 15:21   #24
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 545
The jet and the camera now move and I'm drawing the ground, so now I'm going to go back and look at the blitter area fill again.
Attached Thumbnails
Click image for larger version

Name:	with-ground.png
Views:	93
Size:	9.1 KB
ID:	64786  
deimos is online now  
Old 16 October 2019, 16:22   #25
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 545
Problematic Polygons

Here's my first problematic polygon - it leaks out of the top and bottom (screenshot attached):

Code:
Point2D cracker [] = {
    {{ 169, 57 }},
    {{ 180, 35 }},
    {{ 179, 36 }},
    {{ 167, 57 }}
};
UWORD n = 4;
And my line drawing code:

Code:
static UWORD BlitDrawOneDotLine(Blit * blit) {
    custom->bltbmod = blit->registers.bltbmod;
    custom->bltamod = blit->registers.bltamod;
    custom->bltapt = blit->registers.bltapt;
    custom->bltcon1 = blit->registers.bltcon1;
    custom->bltcmod = blit->registers.bltcmod;
    custom->bltdmod = blit->registers.bltdmod;
    custom->bltcpt = blit->registers.bltcpt;
    custom->bltdpt = blit->registers.bltdpt;
    custom->bltcon0 = blit->registers.bltcon0;
    custom->bltadat = blit->registers.bltadat;
    custom->bltafwm = blit->registers.bltafwm;
    custom->bltalwm = blit->registers.bltalwm;

    blitter.running = TRUE;
    custom->bltsize =  blit->registers.bltsize;

    return TRUE;
}

void DrawOneDotLine(const ScreenBuffer * scratchScreenBuffer, const Point2D line [2]) {
    Blit * blit = Blitter_AquireBlit();

    blit->callback = BlitDrawOneDotLine;

    UWORD dx = ABS((WORD) line[0].value[X] - (WORD) line[1].value[X]);
    UWORD dy = ABS((WORD) line[0].value[Y] - (WORD) line[1].value[Y]);

    UWORD octant = 0;
    if ((dx >= dy && line[0].value[X] >= line[1].value[X]) || (dx < dy && line[0].value[Y] >= line[1].value[Y]))
        octant |= AUL;
    if ((dx >= dy && line[0].value[Y] >= line[1].value[Y]) || (dx < dy && line[0].value[X] >= line[1].value[X]))
        octant |= SUL;
    if (dx >= dy)
        octant |= SUD;

    UWORD dmax = MAX(dx, dy);
    UWORD dmin = MIN(dx, dy);

    blit->registers.bltbmod = 4 * dmin;
    blit->registers.bltamod = 4 * (dmin - dmax);

    blit->registers.bltapt = (APTR) (4 * dmin - 2 * dmax);
    blit->registers.bltcon1 = LINEMODE | ONEDOT | octant | ((4 * dmin - 2 * dmax) < 0 ? SIGNFLAG : 0);

    blit->registers.bltcmod = blit->registers.bltdmod = (scratchScreenBuffer->width >> 3);

    APTR firstWord = scratchScreenBuffer->data +
                     line[0].value[Y] * (scratchScreenBuffer->width >> 3) +
                     (line[0].value[X] >> 3);

    blit->registers.bltcpt = firstWord;
    blit->registers.bltdpt = firstWord; // point elsewhere to drop first pixel

    blit->registers.bltcon0 = line[0].value[X] << 12 | SRCA | SRCC | DEST | A_XOR_C;

    blit->registers.bltadat = 0x8000;

    blit->registers.bltafwm =
    blit->registers.bltalwm = 0xffff;

    blit->registers.bltsize = ((dmax + 1) << 6) + 2;

    Blitter_EnqueueBlit(blit);
}
Attached Thumbnails
Click image for larger version

Name:	problematic-polygon.png
Views:	69
Size:	7.8 KB
ID:	64787  

Last edited by deimos; 16 October 2019 at 17:55.
deimos is online now  
Old 16 October 2019, 16:58   #26
hooverphonique
ex. demoscener "Bigmama"

 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,062
Quote:
Originally Posted by deimos View Post
I'll come back to this later with some test cases. When you say bltsize-1, what do you actually mean? If my normal bltsize is calculated as "((dmax + 1) << 6) + 2", do you mean dropping the "+ 1"?

I guess so.. The point this that the last pixel (vertically) of the line is skipped, so reducing the blit height by one sounds right.

Again, this only works when drawing all the lines in the same direction. Try taking a look at the lines without fill enabled, and any errors should be visible.

Man, it's been many years since I tinkered with this stuff

Last edited by hooverphonique; 16 October 2019 at 17:07.
hooverphonique is offline  
Old 16 October 2019, 19:35   #27
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 545
Like this?

Edit: Doesn't 100% work for drawing the ground, but I have a more efficient method in mind for that, so I probably won't bother fixing it.
Attached Thumbnails
Click image for larger version

Name:	maybe-working.png
Views:	115
Size:	8.7 KB
ID:	64796   Click image for larger version

Name:	broken-ground.png
Views:	140
Size:	9.2 KB
ID:	64797  

Last edited by deimos; 16 October 2019 at 20:00.
deimos is online now  
Old 16 October 2019, 20:17   #28
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 545
Update, Day 3

So, 3 days in and I'm a day or more behind schedule.

Tomorrow I want to rework my blitter code to use separate scratch areas for the fill operations and bounding boxes for those and the blits into the screen buffer. This should cut out about 80% of the data the blitter needs to move about and I might start to get decent frame rates.
deimos is online now  
Old 17 October 2019, 00:42   #29
Antiriad_UK
OCS forever!

Antiriad_UK's Avatar
 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 189
Thought I was giving you tips. Within 2 posts you'll be giving me tips!
Antiriad_UK is offline  
Old 17 October 2019, 12:40   #30
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 545
Quote:
Originally Posted by deimos View Post
So, 3 days in and I'm a day or more behind schedule.

Tomorrow I want to rework my blitter code to use separate scratch areas for the fill operations and bounding boxes for those and the blits into the screen buffer. This should cut out about 80% of the data the blitter needs to move about and I might start to get decent frame rates.
I've done this rework and it's doubled my frame rates, so I'm quite happy.
deimos is online now  
Old 17 October 2019, 13:51   #31
hooverphonique
ex. demoscener "Bigmama"

 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,062
Quote:
Originally Posted by deimos View Post
Like this?
Nice fighter jet
hooverphonique is offline  
Old 17 October 2019, 13:55   #32
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 545
Quote:
Originally Posted by hooverphonique View Post
Nice fighter jet
Thanks, I made it myself.
deimos is online now  
Old 17 October 2019, 16:45   #33
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,719
This is indeed looking nice. Am I right that you did manage to fix the Blitter fill in the end?

If so, I'd be very interested in knowing what the performance difference between CPU and Blitter polygon drawing is. IIRC Jay Miner once said some of the Blitter's features were intended to help with flight simulation (or was that HAM mode? I forget...). So it'd be nice to see if they indeed help rather than hinder
roondar is offline  
Old 17 October 2019, 17:08   #34
gimbal
cheeky scoundrel

gimbal's Avatar
 
Join Date: Nov 2004
Location: Spijkenisse/Netherlands
Age: 38
Posts: 3,565
Woof, a flight simulator game for the Amiga in 3 weeks. My hat off to you.

I want only one feature: the Cool Cam.
gimbal is offline  
Old 17 October 2019, 17:20   #35
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 545
Quote:
Originally Posted by roondar View Post
This is indeed looking nice. Am I right that you did manage to fix the Blitter fill in the end?

If so, I'd be very interested in knowing what the performance difference between CPU and Blitter polygon drawing is. IIRC Jay Miner once said some of the Blitter's features were intended to help with flight simulation (or was that HAM mode? I forget...). So it'd be nice to see if they indeed help rather than hinder
Yes, I have blitter fill (apparently) working. At the moment I'm getting a lot less frames per seconds as my previous CPU only attempt, which is why I'm looking at timing my code.
deimos is online now  
Old 17 October 2019, 17:23   #36
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,719
It will be interesting to see what timing tells you, yeah.

Cool to see Blitter filling working though, as I recall not many games actually used the Blitter to draw polygons.
roondar is offline  
Old 17 October 2019, 17:25   #37
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 545
Quote:
Originally Posted by gimbal View Post
Woof, a flight simulator game for the Amiga in 3 weeks. My hat off to you.

I want only one feature: the Cool Cam.
Sure, I'm going to have a camera system that should be flexible to do that, to support control tower views, etc. As long as I can define how "cool" works, I should be able to point the camera at the closest cool object.
deimos is online now  
Old 17 October 2019, 22:20   #38
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 545
Update, Day 4

I'm taking a slight detour to look at performance. In short, I'm not getting the frame rate I thought I would be getting, and I think I need to know if it's a fundamental flaw before I add features.
deimos is online now  
Old 18 October 2019, 10:22   #39
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 545
Performance

I've added profiling to the majority of my code, and if I run it for a minute (approx) these are the results I get:

Code:
Function Name		Number of Calls	Total Elapsed Time (ms)
PlayGame		1		61290
FillScreen		88		56
Blitter_AquireBlit	22556		1268
Blitter_EnqueueBlit	18440		5923
Renderer_TransformModel	88		2221
Renderer_RenderModel	88		58462
RenderFace		2237		51954
ClipPolyToNearPlane	2187		1913
ClipAndFillPolygon2D	2187		47156
FillPolygon2D		2187		39131
DrawOneDotLine		18006		19968
ScratchAreaFill		2187		1659
CopyScratchInColour	2187		3457
DrawingComplete		88		52
The functions are listed in the order in which they are first executed, so this roughly leads to how they call each other:

Code:
PlayGame
  -> FillScreen
       -> Blitter_AquireBlit
       -> Blitter_EnqueueBlit
  -> Renderer_TransformModel
  -> Renderer_RenderModel
       -> RenderFace
            -> ClipPolyToNearPlane
            -> ClipAndFillPolygon2D
                 -> FillPolygon2D
                      -> DrawOneDotLine
                           -> Blitter_AquireBlit
                           -> Blitter_EnqueueBlit
                      -> ScratchAreaFill
                           -> Blitter_AquireBlit
                           -> Blitter_EnqueueBlit
                      -> CopyScratchInColour
                           -> Blitter_AquireBlit
                           -> Blitter_EnqueueBlit
  -> DrawingComplete
       -> Blitter_AquireBlit
       -> Blitter_EnqueueBlit
So, with this in mind, I should concentrate on the function FillPolygon2D and maybe on DrawOneDotLine.

Problem is... There's nothing of note in these functions. They do some simple calculations and add operations to the blitter queue...

[EDIT] I missed the EnqueueBlit call, but I don't think that's the problem.

Last edited by deimos; 18 October 2019 at 11:09.
deimos is online now  
Old 18 October 2019, 10:48   #40
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,599
Looks as if you need more than 1ms on average for drawing a line (in 4 bitplanes?). That's less than 20 lines per frame, which is pretty low.

Would it help if you draw a polygon once, then copy it masked into all the bitplanes needed for the chosen colour?

EDIT: Some optimisation hints concertning DrawOneDotLine:
1. Don't do complex comparisons multiple times, like (dx >= dy && line[0].value[X] >= line[1].value[X]). Save and resuse the result. Even better: save the x/y coords in local variables for faster access and to avoid calculating array indexes all the time.
2. Although every decent compiler should do it automatically, you might want to replace *2 and *4 by shifts.
3. Do your blitter registers in the blit-structure have 16- or 32-bit width? Or mixed? Make sure you calculate with 16 bits when nothing more is needed. bltapt definitely looks like 32-bits, as you're casting to (APTR) (a good compiler should print a warning here). I would use 16-bit bltaptl.
4. If nothing helps: consider to implement such a critical function in assembler.

Last edited by phx; 18 October 2019 at 11:14. Reason: Optimisation
phx is offline  
 


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 21:50
My sales over next couple of weeks emdxxxx MarketPlace 4 31 October 2007 10:17
AmigaSYS 1.7 Released ETA : 1-2 Weeks. Dary News 34 22 March 2005 19:51
HOL mentioned in this weeks Micro Mart fiath Amiga scene 8 06 June 2004 23: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 22:05.


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