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.
Quote:
Basic frame here:
http://pastebin.com/7mA6b26k
Sorry for flipping the page (har har) :)
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
A div, that's rich.
superplek: i just used his code man! i dont know what he's trying to do
No need to go berserk, I just commented on the div :)
(also: cdq!)
(also: cdq!)
:)
superplek: now, don't tell me i can't code: http://www.pouet.net/prod.php?which=58322
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)
(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)
yea, i know. i was just silly *P
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.
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
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?
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.
Also I still don't see why my current code doesn't work. Only why it's very inefficient.
paldepind: i think its the offset. you don't change di after the "frame-update"
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.
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.
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.
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
Thanks a lot guys. Now I'll see if I can do a neat plasma effect :D
paldepind: my point is, your code doesnt handle di. it starts rewriting at the wrong offset, causing it to flicker.
yeah, and frag allready said it. :P
... And you explained it to me as well :D