drawing lines with cpcTelera / SDCC (V1.0 RELEASE)

[ervin]

I've now got the clipping working for lines in half the quadrants.
It's really cool seeing the lines not being drawn outside the clipping region.
I actually can't believe I've got it working; it's been quite tricky!

[arnoldemu]

I've now got the clipping working for lines in half the quadrants.
It's really cool seeing the lines not being drawn outside the clipping region.
I actually can't believe I've got it working; it's been quite tricky!

To check your clipping make the rectangle much smaller than the screen and draw lines that are inside, cross each of the sides (top, bottom, left and right), and cross top and bottom, cross left and right, and do the ones which cross left and top, left and bottom etc. Then also draw some outside.

Do all combinations and you can be sure you are clipping all correctly and that all cases in your code are working.

[ervin]

Thanks for those ideas.


One thing which was tripping me up was lines which start and finish outside, and may or may not cross into the visible region.
For example, you might have the starting point to the left of the screen but vertically within screen bounds.
And the end point might be above the screen but within the horizontal screen bounds.
Depending on the angle, this line may or may not cross into the top-left corner of the screen.
Catching that was tricky, but I think I have it working! 

[ervin]

All clipping cases are now working successfully!!!


Lots of testing to do now, but it's looking good!
I'm absolutely chuffed right now!

[ervin]

Alrighty!
I've uploaded bres_2.zip to the first post in this thread.
It contains a number of mode 0 tests.

If you're interested, please download it and have a play.
Let me know if you find any problems.


I recommend running it on an emulator at high-speed, as it's still very slow.

[AMSDOS]

Alrighty!
I've uploaded bres_2.zip to the first post in this thread.
It contains a number of mode 0 tests.

If you're interested, please download it and have a play.
Let me know if you find any problems.


I recommend running it on an emulator at high-speed, as it's still very slow.

No really a problem, more an observation, to me the vertical lines were getting across the screen faster than the horizontal lines. Have you noticed that?

[ervin]

No really a problem, more an observation, to me the vertical lines were getting across the screen faster than the horizontal lines. Have you noticed that?

Actually yes, I did notice that earlier today, and I did some tests.
They are moving the same speed - the only conclusion I could come up with is that it's an illusion caused by the awful flickering!

[AMSDOS]

Actually yes, I did notice that earlier today, and I did some tests.
They are moving the same speed - the only conclusion I could come up with is that it's an illusion caused by the awful flickering!

Ok, wasn't sure if it was an illusion, or if the Line Drawing routine was slowly calculating the next point along the Horizontal Axis.

[ervin]

Just fixed a bad bug in the mode 1 drawLine routine... been stuck on it for a while.
Turned out I was rotating a byte the wrong way, when determining the next pixel mask.
Man, that was a tough one to solve!

I hate bugs like that.
They can really make you doubt yourself, and the project you're working on!

[EDIT] I've added double-buffering, so testing is now much more bearable.
No more evil flickering!

[ervin]

 

With double-buffering, I didn't have much memory left for all the test code, and all the clipping/drawing code for modes 0,1 and 2.
So I had to bite the bullet and split the development into 3 projects, one for each mode.

So now we have bres0, bres1 and bres2.
It's a bit of a pain in the buttocks!

Ah well, at least I no longer have to worry about running out of memory...
(And it was very easy to split it up into multiple projects, so there's that, eh?)

[ervin]

A new file has been uploaded to the first post.
The dsk contains 3 programs: bres0, bres1 and bres2.

All of them are now feature complete.
All clipping cases are accounted for, and appear to be working correctly.
I've got double-buffering working as well.

All 3 programs draw an eye-shape with option A from the main menu.

Options B to J run different tests.
These are very slow due to full screen-clearing and buffer-swapping going on between each refresh.

However, my favourite part of development will now begin... optimisation!
Expect to see MAJOR speed increases in the coming weeks.

[ervin]

Had a really great idea this morning (whilst taking a shower!).

Thus far, I've been checking the video page when moving the current video address up or down, in order to allow double-buffering to work "out of the box". Of course, this sort of check slows things down and complicates what should be a simple routine.

So, I thought I'd implement a remainder variable, which is incremented/decremented/reset appropriately anytime the y pixel position needs to change.
Much simpler, a bit faster, and also results in slightly smaller code.
It'll also be easier to convert to asm.

WIN!

[EDIT] The first round of optimisations has made it take 30% less time to draw the mode 0 eye.

[AMSDOS]

Sorry I was following till I got to the point of the shower, after that I'm stumped    Could it be pseudocode or C (if possible), with screenshots?

[ervin]

Sorry I was following till I got to the point of the shower, after that I'm stumped    Could it be pseudocode or C (if possible), with screenshots?

I'm not sure I can explain this very well...
I've put some comments in which hopefully sort of describe what is going on.

Code Select Expand

// calculate remainderX for mode 0

remainderX=ux1%2;

// calculate remainderY

remainderY=uy1%8;

// calculate vram address for mode 0

vram=yAddress[uy1]+(ux1/2);

// prepare masks

for (i=0;i<remainderX;i++){
    lineMaskRotateRight();
    colourMaskRotateRight();
}

// determine the y-length of the line

len=uy2-uy1+1;

// draw the line

for (len;len!=0;len--){
    *vram=*vram&colourMask|lineMask;
    xn+=dx;

    if (xn>=dy){
        xn-=dy;

        if (remainderX==1){
            lineMaskRotateLeft();
            remainderX=0;
            vram++;
        }
        else{
            lineMaskRotateRight();
            remainderX++;
    }   

    colourMaskRotateRight();

    // increment vram y position

    if (remainderY==7){
        vram-=0x37B0;
        remainderY=0;
    }
    else{
        vram+=0x0800;
        remainderY++;
    }
}

[AMSDOS]

Wasn't sure what ux1 or uy1 meant, to me they look like Screen Based variables for mapping out the screen?

[ervin]

Wasn't sure what ux1 or uy1 meant, to me they look like Screen Based variables for mapping out the screen?

Yes, they are unsigned variables:
0 <= ux1 <= 159 (mode 0)
0 <= uy1 <= 199

I use signed variables for all the clipping business, and then copy them to unsigned variables, to make the loop a bit more efficient.

[ervin]

Holy cow that was frustrating!
I've been stuck on one stupid little obscure bug for the last few days.

I had a situation where very long lines weren't clipping correctly, and then proceeding to trash parts of memory.
The solution... in ONE case, I had forgotten to change an 8-bit variable to 16-bit.
I had made the change in all other cases in the entire program, but this one little case had snuck under the radar.

When I solved it, it was like the heavens opened and light shone down on me.
(Like beating a particularly difficult boss in Dark Souls - like the Smelter Demon in DS2).

[AMSDOS]

Holy cow that was frustrating!
I've been stuck on one stupid little obscure bug for the last few days.

I had a situation where very long lines weren't clipping correctly, and then proceeding to trash parts of memory.
The solution... in ONE case, I had forgotten to change an 8-bit variable to 16-bit.
I had made the change in all other cases in the entire program, but this one little case had snuck under the radar.

When I solved it, it was like the heavens opened and light shone down on me.
(Like beating a particularly difficult boss in Dark Souls - like the Smelter Demon in DS2).

Always good to update your code under a new file in case something goes wrong. Because I write in the Emulator, I also keep a Text File to open in Notepad, which comes in handy when dealing in multiple files and have to deal in another part of the program.

[ervin]

Always good to update your code under a new file in case something goes wrong. Because I write in the Emulator, I also keep a Text File to open in Notepad, which comes in handy when dealing in multiple files and have to deal in another part of the program.

I keep lots of backups (using Dropbox), so that's covered.


I write my code in Sublime Text - an absolutely outstanding text editor.

[arnoldemu]

@ervin:

I put my cpctelera code through visual studio 2015 community edition's static analysis tools. I also run it through cppcheck.

Both of these may have picked up the problem.

I think it's definitely worth running static analysis a lot of issues can be found this way.

[AMSDOS]

[ot]I haven't used Dropbox, just in case it got deleted by Hacker, but I always think worst case scenario with the net, the census hacking is just another "I'm not surprised". With all the advertising for it, the Bureau of Stats should of popped up a large banner "Census Night - Hackers Welcome!" [/ot]

[ervin]

@ervin:

I put my cpctelera code through visual studio 2015 community edition's static analysis tools. I also run it through cppcheck.

Both of these may have picked up the problem.

I think it's definitely worth running static analysis a lot of issues can be found this way.

That's a brilliant idea.
I should give it a go!

[ervin]

Optimisation is coming along very nicely.

The difficulty is making sure the optimisations are in-sync between the mode 0/1/2 versions of code.
(There are subtle differences, but general optimisations are pretty much the same).

Drawing the eye 3 times in mode 0 used to take 18 seconds (in pure SDCC), before I improved the masking and memory positioning routines.
Now, after a bunch of asm (and a bit of self-modifying code) it's down to around 7 seconds.


The really awesome thing is that there are still *lots* more things I can do to the mode 0 code to make it much faster.

I've also (hopefully) ironed out all the issues with clipping - this took a few weeks, but I finally feel like things are all working correctly.

[Arnaud]

How many memory take your code ?

[ervin]

How many memory take your code ?

I'm not sure how much RAM the drawing routines take up.
I've got the code inside of test programs at the moment, and the test routines themselves take up a lot of memory.

For example, the mode 0 program is currently 8,845 bytes, but a *very* large part of that is due to the testing routines.

[EDIT] I commented out a bunch of testing code, and it's now 6,858 bytes.
Which is too large in my opinion.
But there is still a *lot* of optimisation to do, so it will shrink a lot.