Clipped line routine

Here you can ask questions or provide insights about how to use efficiently 6502 assembly code on the Oric.
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Clipped line routine

Post by Dbug »

Ok, here is my first "semi working" attempt at having the line routine support clipping in assembler.

You can find it here:
http://www.defence-force.org/ftp/forum/ ... ench-4.zip

It's not particularly clean or efficient, and it's a bit buggy (for some reasons at some points it draws one more pixel at the bottom Oo), but at least it's a basis for working :)
Don't hesitate signaling any weird stuff or potential optimisations (I know the branches and jumps can be optimized, but for modification purpose I was not trying to make that more efficient)

Basically what I did is just to add a 16 bits clipper in front of the normal non clipped 8 bit version:
- LargeX0,LargeY0,LargeX1,LargeY1 must be filled with the source coordinates (-32768,+32767 range), and in return CurrentPixelX, CurrentPixelY, OtherPixelX and OtherPixelY are filled with clipped values.
- The clipping window is defined in the file params.h, by the bunch of #define CLIP_LEFT, CLIP_RIGHT, CLIP_TOP and CLIP_BOTTOM values.
- You can additionally enable/disable the 24 bits mode by commenting out the USE_ACCURATE_CLIPPING symbol.
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema »

Well done Mike!

Had no time to integrate it into the 3D demo, but it seems speed is quite appropriate.

Seems it is on the good path indeed!
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema »

Greetings again.

I integrated your clipped line routine in an old demo of the obj3D library and it works!

I had to use an old version which was not well debugged (and was not optimized), because the newer versions use your polygon routine, not wireframe.

The result is quite good. Still the horrible flickering (which is not related to the line routine) and the speed seems not to have decreased too much (from 328 "units" to 338 when rotating the tetrahedron fully on-screen), so if we had a good double-buffer technique we would be ready for an Elite Clone.

Tried some values for the clipped region and all seemed to work nicely, except for the extra pixel which is sometimes drawn. Had an strange bug where the program hungs sometimes when the lines have to be clipped from the top. Not sure if it is due to the old version of the library or any bug in the line routine, though.

Very good work indeed!
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

If you can provide me with the parameters you use for the frozen line, I can investigate this week end: clipping window, line coordinates :)

Thanks
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema »

Dbug wrote:If you can provide me with the parameters you use for the frozen line, I can investigate this week end: clipping window, line coordinates :)

Thanks
Will try to figure out, as it happens when drawing the Cobra ship when it crosses the clipping window from the top, but not allways (maybe with vertical or very short lines?).

Will need to dig into the code or add some kind of inspection...
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema »

Did not have time to check till today but it seems it was easier than I expected.

I just watched at the memory contents after the program crashed (it hungs) and it seems that the coordinates were drawing from (58,5) to (75,-31), so I entered this into the main() of your LineBench

Code: Select all

 	LargeX0=58;
	LargeY0=5;
	LargeX1=75;
	LargeY1=-31;
		
	DrawClippedLine();
And it hangs too.

Taking a look at the debugger, it is not a crash. It seems an endless loop in the dicothomy search. It happens whith and without the USE_ACCURATE_CLIPPING flag activated.

Any ideas?
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

Looks like a off by one error. Y0 est equal to CLIP_TOP, so it should not even enter the dichotomy clipping, should just accept the value and exit immediately.

Will trace the code :)

Most probably something totaly stupid. With some luck it's also the reason about why there is this additional random pixel.
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

Ok, corrected version here:
http://www.defence-force.org/ftp/forum/ ... ench-5.zip

Have to admit that the bug was absolutely ridiculous... and probably due to the lack of sleep... accumulated with the lack of testing.

There was two errors, but second was never reached because the code bugged before.

I had this:

Code: Select all

	; if (LargeY0==CLIP_TOP)
	cpx #_LargeY0+0
	bne skip
	lda #_LargeY0+1
	bne skip
	jmp _ClipReturnP0
skip
instead of that:

Code: Select all

	; if (LargeY0==CLIP_TOP)
	cpx _LargeY0+0
	bne skip
	lda _LargeY0+1
	bne skip
	jmp _ClipReturnP0
skip
With the additional "#" it was guaranteed not to work very well...

After correcting, I found out that the routine I was calling was buggy as well, I had that:

Code: Select all

	; LargeX=LargeX0;
	lda _ClipX0+0
	sta _LargeX+0
	lda _ClipX0+1
	sta _LargeX+1
instead of this:

Code: Select all

	; LargeX=LargeX0;
	lda _LargeX0+0
	sta _LargeX+0
	lda _LargeX0+1
	sta _LargeX+1
It does not solve the +/- 1 pixel; but should solve the infinite loop.

Please test and signal any error :)

Thanks !
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema »

ROTFL

Had the same error several times :)

It seems to work very well now. Will try to do more testing, and maybe even tidy everything up and post a demo with wireframe...
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

Hehe :)

I will try to find out about why this +/- 1 pixel issue, and then try to adapt the code for filled polygons.

Yesterday I tried Driller and Total Eclipse on an C64 emulator, it's technically impressive, but extremely slow.

Wonder if we can achieve a better framerate :)
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema »

Dbug wrote: Wonder if we can achieve a better framerate :)
With your odd/even line trick, it is possible indeed!

Only issue I still see is what we will do with stars, for instance.

BTW I have built up a demo in wireframe mode so you can see the ClippedLine with the 3D engine. It is here:

http://www.defence-force.org/ftp/forum/ ... /TEST1.tap

Press "O" to get the ship closer and you will see how lines are clipped perfectly.

Some notes:
1/ Frame rate is low, due to the software double buffer. The C64 guys could change the video memory address, so this step is done by hardware. Here we need to clear the buffer, draw and dump, which is deadly slow. I am doing:

Code: Select all

         
        LDY #$0
loop2    
         lda $5000,y
         STA $A000,Y
         lda $5100,y
         STA $A100,Y
         lda $5200,y
         STA $A200,Y
         ...
         lda $6300,y
         STA $B300,Y
         iny
         bne loop2
for dumping and something similar for clearing the buffer. Anyone knows a better way?

I know the Spectrum guys could dump a buffer into the screen quite quickly with the LDIR instruction, and clear it quite efficiently too. This with the ability of syncronizing with the screen was a perfect combination.

2/ It shows some flickering... sort of. This is due to the lack of sync with the vertical retrace when dumping :(

3/ There are some issues where some faces that should not be visible are drawn and viceversa. Maybe some roundoff or overflow errors in the code? I know the model of the ship also has some errors...

4/ You won't notice the +1 pixel error, because that last scan is not dumped to the screen :)

I slightly modified your code so it can be used by the engine and also lines are drawn with ora, instead of eor for this demo.

Err... sorry for going off topic again :oops:
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

For the clearing routine, instead of erasing every 256 bytes, now I'm doing that instead:

Code: Select all

    ldx #WIDTH
loop
    lda buffer+LEFT+40*0,x
    sta $a000+LEFT+40*0,x
    lda buffer+LEFT+40*1,x
    sta $a000+LEFT+40*1,x
    lda buffer+LEFT+40*2,x
    sta $a000+LEFT+40*2,x
    ...
    lda buffer+LEFT+40*199,x
    sta $a000+LEFT+40*199,x
    dex
    beq end
    jmp loop
end
The reason is that with this I can do rectangular copies, preserving attributes on the left, and possibly being able to keep a frame around that will not be erase (windshield/cockpit style).
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

Hum, apparently the clipping code is correct, the +/- 1 is not in the clipper, but in the line drawer...
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema »

Greetings.

Working on a possible radar display for the 3D game, I noticed the line drawer does NOT draw a line when origin and destination are the same.

Drying to draw a line from (24,24) to (24,24) I expected to see a dot at that position, but nothing was drawn.

Don't know if this is the desired behaviour or not...

Cheers.
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

For a filled polygon routine, yes. For a line routine, no. This is a bug. Need to fix it.
Btw, I think I found how to modify the clipper so it behave well on the polygon routines. Need to test.
Post Reply