| |
Cybernator
Registered: Jun 2002
Posts: 154 |
STr34kZ (aka. EOR lines)
Streaks, not freaks. :)
Does anyone have any idea how to _completely_ avoid the streaks in EOR fillers. SLJ in his tutorial mentioned that ---*--- intersections will fail. I wanted a complete 3D scene to be EOR filled at once. After some experimenting I came up with a technique to handle obscured objects, objects partially or wholly on the top of another, and it works ok (as long as the filling of a single object is successful). Pick up yer jaws, this doesn't work at realtime. :) Because of this, implementing of an algorithm to handle these intersections will not be a trouble, but I can't think of anything.
Lines are drawn from left to right and the last pixel is not drawn for horizontal lines (where dx>dy). For vertical lines, I don't draw the endpoints, and I only draw the last pixel of each vertical chunk (the way SLJ's routine works).
One interesting thing with the object where this happens is that if you watch it from the other side, there're no streaks.
Check out: http://www.geocities.com/lazeristoski/eor.zip
Use left/right arrows to change frames, F to toggle filling.
Btw, clipping against the upper border is handled as well, though you won't see that from the animations I have included.
Ah yes, make sure you have DirectX 7 or later installed. :P
(addon: just drag one of the .eor files onto the Exorizer.exe)
|
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
1st rule: always draw your lines in the same direction (usually from left to right)
2nd rule: make fitting definition for your starting end endpoints. which points do belong to a line and which don't?
example: line from x0 to x1 should contain pixels >= x0 but < x1. another possible definitaion is > x0 and <= x1. anything else will give you either gaps or pixels belonging to two lines. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
I drew lines in both directions for my glenz routine in yktr/cml, so apparently it's possible. My rule #1: Just tweak around with it untill it works. |
| |
Oswald
Registered: Apr 2002
Posts: 5076 |
rule 1 is not important indeed. sometimes you can even speed up things.
once I needed a speedcode, which has to check wether Y is in the range 0-7, so it had the code:
dey
beq *+x
if you always go to the same direction horizontally (left 2 right) you will need to use this when lines are drawn downwards:
iny
cmp #$08
beq *+x
if you keep your lines always drawn from bottom to top, in 2 cases you need to go left to right, in 2 right to left. going always from bottom to top you can avoid the cmp, and have always dey, beq. (this might need the rule of setting or not the start/end pixel to be changed for diff cases, but I dont remember now how I did it)
rule #2 is wiser than SLJ's one, and it's used in most (if not all) 'modern' eor fillers. |
| |
Krill
Registered: Apr 2002
Posts: 2940 |
wtf? you definately complicate things too much, oswald.
for me it worked fine to:
1) always draw left->right
2) always DON'T draw the first (leftmost) pixel of a line
3) put the pixels using eor
no extra measures were needed to avoid any colour leaks and similar problems. |
| |
Oswald
Registered: Apr 2002
Posts: 5076 |
krill: to avoid the extra cmp in the speedcode I needed a lineroutine which always goes from bottom to top (dey, beq). Notice, that this lineroutine is SPECIALIZED to make advantage of the bitmap mode to fasten up fillings (you can fill a whole char by one sta into the color ram, rite?), so it has to KNOW wether it moved out of the current character or not.. == it has to check the Y register after each pixel set.. and that is faster by dey beq than by doing iny cmp #$08 beq |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Krill wrote:
"2) always DON'T draw the first (leftmost) pixel of a line"
or the last... as i wrote in my previous post:
x0 <= xp < x1
x0 < xp <= x1
i never need any tweaking when following one of those rules. |
| |
Krill
Registered: Apr 2002
Posts: 2940 |
oswald: ok, i thought we were talking about basic eor filling instead of a specialized version working with whatever screen/bitmap mode :)
graham: yes true, i just wrote how i did it, it's of course not the only way possible. |
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
As I already stated, lines are always drawn from left to right: x0 <= xp < x1. And yes, pixels are drawn using EOR. It wouldn't work otherwise. :) I believe the reason for the streaks is not because two polygons share the same edges. I'll try to get the exact polygon (one of'em, coz there're two streaks) which misbehaves, and I'll try it in SLJ's routine. In case it doesn't work, I don't know. I tweaked the routine enough, I have no ideas left.
One thing I noticed with the "3objects.eor" animation is that streaks _will_ appear if you don't take half the step the first time. The trouble was with the vertical lines (i.e. dy>dx). Add that to the rules. :) (and it should've been 57r34k2 :P) |
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
How many times were you searching for a bug or a cause, and you found it where you least expected it? Have a look at http://www.geocities.com/lazeristoski/bug.zip
This polygon needs 4 lines, and here they go as found in bug.eor:
1. 68,33 - 274,33
2. 68,33 - 271,48
3. 71,48 - 271,48
4. 68,33 - 271,48
Doesn't look very nice, does it? If you try to draw'em, you'll see that the vertical ones are missing. Furthermore, you'll also find the line which divides the rectangle into triangles. That line exists twice, so it gets erased when EOR-ed. The trouble was caused by my ASE parser (or maybe by 3D Studio Max itself). In ASE files, lines that divide one face into triangles are marked as invisible (cheers to the dude who thought of this when he was creating the file format :)) So in the case of the boxes, there was no problem. However, the troublesome object was a box consisted of several segments, so that I could sharpen it. After that, the fuselage was optimized. This is most likely where Max had the trouble. (I mentioned the fuselage; this is supposed to be an alien aircraft. Who knows? Maybe I'll make it look like one. :P)
Oh well.. Let's see if there's cure for this. |
| |
Oswald
Registered: Apr 2002
Posts: 5076 |
my filledvectors use a routine which eliminates lines that 'normally' would be drawn more than once... simply checks which lines would be drawn more than once, and precalculates what the resulting color would be after that, and then only one line is drawn in the resulting color.. or no line if the color would be the bitpair 00. Guess other coders routines does this too ? |
... 19 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 - Next |
