would this work better than bresenham?

function drawline(x0,y0,x1,y1){
dx = x1-x0
dy = y1-y0
len = sqrt(dx*dx+dy*dy)
dx /= len
dy /= len
    for (k=0;k<=len;k++){
        paint(floor(x0),floor(y0))
        x0 += dx
        y0 += dy
    }
}

No.

http://hbfs.wordpress.com/2009/07/28/faster-than-bresenhams-algorithm/

>dx /= len
dy /= len

optimize your code:

fagget = 1 / len
dx *= fagget;
dt *= fagget;

mulss is a fast
divss is slow as fuck

>>4
e/g/in >meme arrow /g/ro ;) XXDDDD lel

>>4
Any half-decent compiler will do that for you. It's 2013. Stop wasting your own time adding in more code that only serves to obfuscate your algorithms.

>>6
Any half decent compiler wouldn't do that because the result might be different due to floating point rounding errors. Or maybe if you'd specity -ffast-math it might optimize it.

>>3
lea %esi, [%edi+%esi]
lea %eax, [%esi+32767]
add %ebx, 1
not using push for parameters
not passing parameters in registers
not using ECX at all

What the fuck is wrong with you, GCC.

>>8
Cudder, I wont be able to forgive you if you become this e/g/in.

>>8
esi
eax
ebx
not using ECX

MORE LIKE NOT USING X86_64 AND USING SHITTY 32-BIT INSTEAD!!

>>8
Cudder-sama, please stop quoting what hasn't been said before, as that is an ima/g/eboard habit.

Please, Cudder-sama.

See for example >>10. Obvious /g/ shitstain. Do you want to look like him?

>>3,8-11
x86 is shit. Throw away your ``Electric Jew'' and get a Lemote!

WE GONNA ROCK DOWN THE ELECTRIC JEW
AND THEN WE'LL TAKE IT HIGHER

http://pastebin.com/h9d5FKXG
Results are in:(fvdrawline is my implementation)
refdrawline cycles spent:2038507899
opdrawline cycles spent:37497993407
eflaedrawline cycles spent:1441633463
efladdrawline cycles spent:1393345337
eflacdrawline cycles spent:2200172517
eflabdrawline cycles spent:2361518832
eflaadrawline cycles spent:2836203472
optefladrawline cycles spent:8503438034
peronedrawline cycles spent:1526465395
unidrawline cycles spent:1182543
fvdrawline cycles spent:651216

>>14
Why don't you just use a compressed LUT?

>>15
Implement a LUTdrawline in C and i'll benchmark it.

>>16
Implement the FVdecompressor and I'll implement the LUTdrawline.

>>17
What is FVdecompressor?

>>18
Who are you people and what have you done with my /prog/?

>>18
At least have the respect to piece together what it is by observation.

>>18
I'm sorry if you've never heard of FVdecompressor, you may assume it is some INDUSTRY STANDARD you haven't heard of. Well, it isn't yet, but one day people will recognize the realization of infinite compression.

>>19
SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF SRS JIDF

>>21
Do you realize what consequences would be to infinite compression?
The data storage industry will collapse, there will be NO advancement in data storage(everything "fits" on floppy).
Internet speeds will stagnate or revert to dialup levels(who needs speed now).
Remember "illegal numbers"? now there will be a lot of them, much shorter.
The databases could be stored in chunks of constant size which fit the memory. Three letter agencies
 could store everything forever. Surveillance states form overnight. Computer could use these infinite databases to solve crimes and predict future events. AIs could have godlike levels of knowledge and storage, possibly evolving to dominate humanity in a short burst of self-improvement.

>>22
That's more like it.

>>19
I suspect we've been linked to by some enterprise programming community. Either that, or a bunch of undergraduate Java ``software engineering'' students got here from the imageboards.

>>25
maybe jumping the sleepsort shark was our undoing

>>23
It would be even worse. If we compress data until it has size zero, we place a lot of information on one place (the byte). This has consequences for the data center and finally earth.
The place should be shimmering hot, because we pumped away a lot of entropy. Expect molten racks and metal streams.

Also the server where the compression is happening, should pick up mass. As the information get compressed further and further and we keep feeding the server information, the one byte we stove everything in gets more heavy and heavy, until it starts to bend space time and suck the whole hard disk in a point where information cannot escape from (at least not severely distorted/computed). The disk then start to fall through the computer array into the earth, feasting on everything beneath the crust.

But it is improbable you get to this point, because the added mass will simply crush the disk before it reaches its end destination.

As a consequence of this, there is a simple proof that infinite compression is not reachable. The information black holes can be store is related to the size of their surface. This is the natural limit of information compression. No further compression is possible.

Oh god. The event horizon of information. We have to prevent this from happening.

Can't beat this:

; void drawline(int x1:eax, int x2:ecx, int y1:edx, int colour:edi);
; void put_pixel(int x:esi, int y:eax, int colour:edi)/P(ecx,edx,ebx,esi,edi);
drawline:
 mov esi, eax   ; esi = x1
 sub ecx, eax   ; ecx = x2 - x1
 sub ebx, edx   ; ebx = y2 - y1
 push edx
 shl ebx, 16    ; ebx = (y2 - y1) <<16
 xchg eax, ebx  ; eax = (y2 - y1) <<16, ebx = x1
 cdq            ; edx:eax = (y2 - y1) <<16
 div ecx        ; eax = ((y2 - y1) <<16) / (x2 - x1) = m
 pop edx
 inc ecx        ; ecx = x2 - x1 + 1
 shl edx, 16    ; edx = f = y1 << 16
 xchg eax, ebx  ; ebx = m
; eax : g
; ecx : x2 - x1 + 1
; edx : f
; ebx : m
; esi : x
lineloop:
 mov eax, edx
 add eax, 32768
 call put_pixel
 inc esi
 add edx, ebx
 loop lineloop
 ret

Another thing I noticed when writing the above code is that his rounding is wrong: to get the standard half+up rounding, 32768, i.e. 1/2, needs to be added. Otherwise it's an off-by-1 rounding error.

>>14
Benchmark this... if you can.

Infinite compression is possible. I'm working on it(i just get distracting with inane stuff all the time like wordcounts,optimized drawline which is already implemented in hardware(Though it doesn't use my algorithm)).
>>27
You can't compress the representation to a byte.
 The representation of any compressed data is proportional to size of data PLUS overhead. At some point the overhead is the dominant component(each layer of compression adds own overhead).
Also, gains of compression depend on time and initial entropy/serial correlation.
Some data which is close to random noise will take a lot of time to compress.
>>28
>Hackers can turn your computer into a bomb.jpg
>>29
Sorry, Only C is accepted.

You can't compress the representation to a byte.
 The representation of any compressed data is proportional to size of data PLUS overhead. At some point the overhead is the dominant component(each layer of compression adds own overhead).
Also, gains of compression depend on time and initial entropy/serial correlation.
Some data which is close to random noise will take a lot of time to compress.

>>30

Really? You wouldn't think that post was somewhat ironic...

>>31
Nope.
>As a consequence of this, there is a simple proof that infinite compression is not reachable

Infinite compression is possible.
Yeah, if only you can control gravity or nuclear fusion. Your old post has a major flaw: as long as compress the number of a file through a table graph, the table grows longer. You would be just reimplementing DEFLATE.
The representation of any compressed data is proportional to size of data PLUS overhead.
Headers, that is how they are called.
Sorry, Only C is accepted.
Were was that requirement?

>>32

It is physically not reachable. The surface of the blackhole contains all information of the blackhole, thus setting a limit on the information content of the densest structures  in the universe.

The ironic part was that the post ignored that you cannot store everything on one byte (and taking a byte as a physical entity, in which one can literally compress information) and then came to the same conclusion, that infinite compression is impossible.

See, that is ironic. You assume something is possible and then you derive that it is impossible, because the universe don't want you to.

Anyway, there you go: http://en.wikipedia.org/wiki/Holographic_principle#Black_hole_information_paradox

>>33
>Yeah, if only you can control gravity or nuclear fusion
Data compression can be done without the above.
>You would be just reimplementing DEFLATE.
Its like claiming a rocket would re-implement a horse-carriage.
The algorithm isn't about compressing the data, but transforming it into data which can be compressed.
>Were was that requirement?
I'm conducting benchmarks inside a C program. I make the requirements(it must be written in C).
If you don't like it, create your own benchmarks(that would be welcome, and i will have more time to infinite compression research).
>>34
Your post confuses two kinds of information:
http://en.wikipedia.org/wiki/Physical_information
http://en.wikipedia.org/wiki/Digital_data
..and two kinds of entropy
http://en.wikipedia.org/wiki/Entropy
http://en.wikipedia.org/wiki/Entropy_(computing)
When you learn the difference, reread your own post. Ironic now?

>>27-28
There is more quantum information in the silicon mass that houses that byte than there is useful information to store.

>>33
Were was that requirement?
Do you honestly not know how to deal with this situation? It should be obvious.

>>35

I know autistic retard. But on eventually those two will merge again. Then the spin of an atom is a bit.

>>37
A spin representing the entire universe is still a single spin. Its doesn't magically become a blackhole.

>>38

You have wonned ^_^

>>38

How would you compress all the information of the earth in a smaller volume? You just compress the earth mechanically. The information will be preserved. The drawback is that the earth will become a blackhole. This also limits  the amount of compression you can do, because no algorithm can surpass this kind of compression, your harddisk eventually has to follow physical laws.  If you have achieved maximum data compression, I can surpass your compression by simply throw your disk in a blackhole. No information will be lost, only decompression is somewhat tedious. So to achieve even higher compression than you can do compress data you need to physically compress the medium.

Here this explains it for you:

http://www.universetoday.com/84006/astronomy-without-a-telescope-black-hole-entropy/

Sorry, Only C is accepted.
Fuck that, I decided to benchmark it myself:

fvdrawline: 1917 cycles
asmdrawline: 1203 cycles

I win.

>How would you compress all the information of the earth in a smaller volume
>You just compress the earth mechanically.
7zip just compressed my harddisk into a smaller volume.
The more you know.jpg

And sizes:

fvdrawline + fvputpixel: 72 + 27 = 99 bytes
asmdrawline + asmputpixel : 39 + 16 = 55 bytes

1917 / 1203 = 1.6
99 / 55 = 1.8

1.6x faster and 1.8x smaller, or around 2.9x more efficient.

OpenGL vertex call to draw a line will be at least x500 faster.
I win.

>>44
If you draw about 30 thousand lines at once. That microsecond communication penalty really hurts.

>>44
Good thing its getting there…