flat assembler
Message board for the users of flat assembler.
Index
> Heap > Slope of a line??? 
Author 

bitRAKE
I did an implementation about 20 years ago with the following algorithm:
http://en.wikipedia.org/wiki/SutherlandHodgeman 

28 Dec 2007, 03:26 

rhyno_dagreat
Thanks bitRAKE. I talked with my dad about it, and he explained it's all about what is your primary axis of motion. (x or y).
Also I have a 3D program on the way I'm writing in FreeBASIC. I still have a few bugs to get out of it. 

28 Dec 2007, 06:39 

Borsuc
rhyno_dagreat wrote: With a triangle, you have three lines, designated with points P1, P2, and P3. In fact, you can think of the slope as "how many x per y to move each line". Let's assume you have the following simple line which takes up three vertical positions: Code: / / / And it also makes perfect sense. Each successive vertical line has a different 'starting' x value, in fact, it's one to the left. The first line has x=2. The second has x=1. That is, we moved by 1 to the left. The last one has x=0, again, we moved by 1 to the left from the second one. This is the slope. It calculates the newly 'x' positions for each vertical line (drawn on the screen). Obviously for a triangle, you'll have to keep track of two slopes (left and right edges), and calculate the 'x' on both sides (so you know where the respective line you draw begins and ends). I am quite experienced with 3D programming and math (my advice is not to learn formulas by heart, but rather understand them in the true sense, not in the 'symbolic' sense , or derive them yourself). I don't think the coordinate system really matters, as long as you're drawing in increasing 'y' order (i.e if the coordinate were to have y=0 at the bottom, the formula would have been the same if you started drawing from the bottom upwards!). The normal "slope" of the line is concerned mainly with linear functions, so it's the (y2y1)/(x2x1) thingy. If you were to use that formula, you should have instead drawn the screen verticalhorizontal (i.e draw a vertical line, use slope to calculate new 'y' positions, draw next vertical line, etc..). This makes sense because (y2y1)/(x2x1) means "how much y per x". Since you draw the screen horizontallyvertical (i.e leftright then topbottom), you need to calculate 'x' from y, which means you have to use the other slope. You can usually compute the left and right edges simultaneously (in parallel), but I'd reserve the full registers for the drawing where you can do several pixels in parallel. in case you're dealing with curves the idea is similar but a bit more complicated. In fact, the derivatives of the function actually represent the 'slope'. For higherorder polynomials (e.g 3rd), you'll need 3 formulas to update because the poly has 3 derivatives in such a case. But I'm not going to overcomplicate matters since you're only interested in lines I guess if rearranging formulas is a bit tedious, have a look at Maxima and Pari (two CAS programs). Maxima is very useful for symbolic stuff (it can solve equations, etc.), while Pari has arbitrary precision, is much faster, but for numeric stuff. I use them both and they're free. In fact, I got a lot of enthusiasm in math because of Maxima, and now I view it from a different perspective. It really isn't that hard once you get it. have fun 

28 Dec 2007, 12:45 

rhyno_dagreat
Ah, the reason I posted this was to gain an understanding. I knew after I tried it it worked, but I didn't see why. My dad help by explaining it, and you elaborated it. Thanks!
Also, I'm working on my first ever solid 3D program which allows you to rotate around and move towards or away from a pyramid. However, the translation algorithm is broke (even though all I'm doing is incrementing or decrementing all Z values of the model!) I'm programming it in FreeBasic, so please don't be a hater. 

28 Dec 2007, 17:08 

edfed
P1 P2 P3
who is the top left? who is the bottom right? one list: y x xl 1 2 5 2 3 4 3 4 3 4 5 2 5 6 1 y is the possition in list, x is the x coordinate for the Y entry xl is the lengh of horizontal line... result of this list is a triangle. 

28 Dec 2007, 17:13 

Borsuc
edfed wrote: P1 P2 P3 

28 Dec 2007, 17:16 

edfed
painting polygon is not a simple thing.


28 Dec 2007, 17:18 

Borsuc
painting a polygon with a simple color is not THAT hard really, you only need slopes, etc..
texture mapping, shading, those are beasts you need to be afraid of on a sidenote, you can even do the reverse (i.e scan the bitmap image and find the position of each 'texel' on the screen). 

28 Dec 2007, 17:21 

edfed
light ray tracing.


28 Dec 2007, 17:29 

rhyno_dagreat
Raytracing is easy in some cases (i.e. spheres and planes), but it's a beast for the CPU to handle.
I've been trying to figure out how do I raytrace a triangle though. 

28 Dec 2007, 18:07 

edfed
what wrong whith this code?
Code: 

28 Dec 2007, 19:14 

rhyno_dagreat
Nothing there...?


28 Dec 2007, 19:27 

edfed
erf, was a joke


28 Dec 2007, 19:28 

rhyno_dagreat
Lol, kinda figured. XD


28 Dec 2007, 21:22 

edfed
triangle tracing, but bug, not really beautifull.
and really not optimised. just for tries. the principle is to find the up, the down and the middle dot of the triangle. then, fill two tables, start and stop. with up/down for start, and up/mid mid/down for stop. then, convert the stop coordinates in counters. and trace it. the problem is for start and stop pixels, sometimes it is good, but mostlly it is bad computed, it need to know what is really the start and the stop before to fill the tables. Code: dots: .1 dd x,y .2 dd x,Y ... polygon: dd dot.1,dot.2,dot.3 .p1x rd 1 .p2x rd 1 .p3x rd 1 .p1y rd 1 .p2y rd 1 .p3y rd 1 raster: .start: rd 200 .stop: rd 200


14 Mar 2008, 17:14 

rugxulo
rhyno_dagreat wrote: I'm programming it in FreeBasic, so please don't be a hater. You could always post on their forums (if not already, I haven't checked). But FB supports inline asm, which I assume you're using , so you shouldn't have any complaints. (BTW, FB rocks, really nice!) 

17 Mar 2008, 18:33 

< Last Thread  Next Thread > 
Forum Rules:

Copyright © 19992020, Tomasz Grysztar.
Powered by rwasa.