pouët.net

Tryin to do an XOR texture in DOS

category: code [glöplog]
Code confirms what Ile says. Also there's more room for improvement in that piece of code, but that's up to you.
added on the 2012-01-13 18:19:15 by superplek superplek
Quote:

Basic frame here:
http://pastebin.com/7mA6b26k


Sorry for flipping the page (har har) :)
added on the 2012-01-13 18:20:52 by superplek superplek
maybe he doesnt want it to move.

Code:mov bx, 140h mov cx, 64000 xor di, di loop1: mov ax, cx xor dx, dx jnz loop1 div bx xor ax, dx stosb loop loop1
added on the 2012-01-13 18:22:27 by rudi rudi
A div, that's rich.
added on the 2012-01-13 18:23:15 by superplek superplek
superplek: i just used his code man! i dont know what he's trying to do
added on the 2012-01-13 18:26:28 by rudi rudi
No need to go berserk, I just commented on the div :)

(also: cdq!)
added on the 2012-01-13 18:28:16 by superplek superplek
:)
added on the 2012-01-13 18:28:54 by rudi rudi
superplek: now, don't tell me i can't code: http://www.pouet.net/prod.php?which=58322
added on the 2012-01-13 18:29:47 by rudi rudi
Yeah I really wasn't trying to imply that :)

(also disregard the CDQ comment, the highest bit is 1 at times and that means it wouldn't "do" the same as xor dx,dx)
added on the 2012-01-13 18:32:54 by superplek superplek
yea, i know. i was just silly *P
added on the 2012-01-13 18:34:47 by rudi rudi
Tips for improvement:
1. For xor texture it's not so critical to
make buffer area to start exactly at 0a000h.
les/lds bx, [bx] works fine here.
2. It's absolutely normal to white 2^16 bytes to it,
don't check for 64000.
3. Why to inc cx? We have di increasing by stosb, use it!
3. At the start and after dividing ah is zero, we can
use cwd instead of xor dx, dx.

And now it's easy to make 19b xor texture.
Code:mov al, 13h int 10h les bx, [bx] mov si, 320 L: cwd mov ax, di div si xor al, dl stosb jmp L
added on the 2012-01-13 19:06:03 by frag frag
Quote:
i dont know what he's trying to do

Is a wrote in the first post I want to do a static XOR texture. I don't want it to move or flickr in any way and I can't figure out why my current code does. The reason why there is a loop in the first place is for future expansion.

Also the code you posted (rudi) achieves what I'm trying to do. But it doesn't help me figure out what I'm doing wrong in my attempt.

And what's the problem with div?
added on the 2012-01-13 19:14:17 by paldepind paldepind
Thanks frag! That was very helpful. Is there any particular reason for storing 320 in si?

Also I still don't see why my current code doesn't work. Only why it's very inefficient.
added on the 2012-01-13 19:21:05 by paldepind paldepind
paldepind: i think its the offset. you don't change di after the "frame-update"
added on the 2012-01-13 19:27:58 by rudi rudi
paldepind
The mistake in you code is in fact that in the same cycle
cx value goes from 0 to 64000 and
di value goes from 0 to 65535.
And they are not equal after first cycle.
You must set to zero them simultaneously.
added on the 2012-01-13 19:28:40 by frag frag
paldepind: for example stosb is the same as [es:di] = al. inc or dec di (according to a flag). di just goes on forever until it wraps to zero again.
added on the 2012-01-13 19:29:38 by rudi rudi
Oh yeah! I've just figured it out myself. The problem was that I only let cx run up to 64000 but di went all the way up to 2^16. Thus cx got shifted a bit on every drawn frame.

Thanks a lot guys. Now I'll see if I can do a neat plasma effect :D
added on the 2012-01-13 19:30:41 by paldepind paldepind
paldepind: my point is, your code doesnt handle di. it starts rewriting at the wrong offset, causing it to flicker.
added on the 2012-01-13 19:31:07 by rudi rudi
yeah, and frag allready said it. :P
added on the 2012-01-13 19:31:44 by rudi rudi
... And you explained it to me as well :D
added on the 2012-01-13 19:32:32 by paldepind paldepind

login