Tiny Intro Toolbox Thread
category: code [glöplog]
Code:
; st0 st1 on fpu stack - leaves the maximum in st0
_max:
fcomi st0, st1
fstsw ax
jbe _max0
_max1:
fxch st1
_max0:
fstp st0
ret
Any suggestions for a smaller version?
oppps not fcomi st0, st1 - that's a fcom st(1) - fcomi seems unsupported - at least in DOSBox
las, what about replacing:
jbe ...
fxch ...
with
fcmov or fcmovnb
?
jbe ...
fxch ...
with
fcmov or fcmovnb
?
that's pentium pro and it seems those instructions are not supported in dosbox. (otherwise fcomi & fcmovXX would do a pretty nice job there...).
btw ignore the code above - it's a complete failure.
this seems to work.
btw ignore the code above - it's a complete failure.
Code:
_max:
fcom st1
fstsw ax
sahf
jbe _max0
_max1:
fxch st1
_max0:
fstp st0
ret
this seems to work.
maybe I should give bochs a try.
uh, so i don't have a smaller max(a,b) without using unsupported instructions, but if you can work with 2*max(a,b) you could do this:
since avg(a,b)=(a+b)/2, define diff(a,b):=|a-b|/2, then max(a,b) = avg(a,b) + diff(a,b) and min(a,b) = avg(a,b) - diff(a,b) giving 2*max(a,b) = a+b+|a-b| (note the code computes |b-a|+b+a, but same difference).
Code:
_2max:
fld st0
fsub st2
fabs
faddp
faddp
ret
since avg(a,b)=(a+b)/2, define diff(a,b):=|a-b|/2, then max(a,b) = avg(a,b) + diff(a,b) and min(a,b) = avg(a,b) - diff(a,b) giving 2*max(a,b) = a+b+|a-b| (note the code computes |b-a|+b+a, but same difference).
sweet.
In case you need also min, this code can be useful:
Copy-pasted from PHOBIA source (gosh, it's already 5 years), we decided to waste some bytes for DOSBox compatibility.
Notice that fnstsw is smaller than fstsw.
Code:
compare_min:
fcom ST1
fnstsw AX
sahf
jc short throw
jnc short exchange
compare_max:
fcom ST1
fnstsw AX
sahf
jnc short throw
exchange:
fxch ST1
throw:
fstp ST0
retCopy-pasted from PHOBIA source (gosh, it's already 5 years), we decided to waste some bytes for DOSBox compatibility.
Notice that fnstsw is smaller than fstsw.
I guess I'll first write a compatible version + later use fcomi and friends.
Then there's at least a version that can be run with DOSBox.
Then there's at least a version that can be run with DOSBox.
ryg btw. sphere tracing is not the worst idea in 256b - it can look much better than constant stepping at the same maximum iteration count and is not (that much?) bigger as long you go for parallel perspective such that you only have to increment z by the distance of the SDF - given that z is on the fpu stack anyways and the result of the SDF too.
What can I use for "animation" - is just incrementing an register good enough? I have that already - is that the commonly accepted solution or do I have to go for a real "timer"?
What can I use for "animation" - is just incrementing an register good enough? I have that already - is that the commonly accepted solution or do I have to go for a real "timer"?
To get some sort of constant speed you can use the check for vsync (posted some page ago) if your stuff is too fast or somehow changing in speed. changing a register/variable is good enough for moving things around (:
My stuff is damn slow - I don't need vsync :D
I now have pretty ugly spinning cube in 154 byte.
I now have pretty ugly spinning cube in 154 byte.
sensenstahl: the only problem with vsync is that its not implemented in dosbox, if thats what he use. also i would guess that modern computers with lcd screens dont have vretrace-support :D
Actually I have now something _way_ better than a cube :D
las: Check out "only a cube" by lord kelvin if you did not. That one helped me a lot ( even if you have something way better than a cube :D ). And damn, I'm so looking forward to your intro (:
rudi: Strange thing. I have an LCD and code under XP. After putting that loading bar into amber I realised it rises way faster in dosbox (in lower cycle areas too) than under XP (even with very high counting registers + in al,40h each loop which is very slow). But with vsync there is constant speed under both "platforms". So something must happen there (=
rudi: Strange thing. I have an LCD and code under XP. After putting that loading bar into amber I realised it rises way faster in dosbox (in lower cycle areas too) than under XP (even with very high counting registers + in al,40h each loop which is very slow). But with vsync there is constant speed under both "platforms". So something must happen there (=
one could make vsync-rasterbars that would actually work in dosbox if they implemented it correctly.
Quote:
Actually I have now something _way_ better than a cube :D
A lasball? :)
And yeah, vsync doesn't work correctly on dosbox. Then again, I don't think a lot of people miss the DOS rasterbars...
Actually it's pretty damn slow (worse than puls) and I had to stick to a very simple grayscale palette + 32 steps of sphere tracing only. And the "real" 256b" version is untested - the 264 bytes version works with DOSBox. Sensenstahl: I'm sorry - you have to wait a bit :) - still not done yet.
Thank you all for another pretty useful pouet thread.
Thank you all for another pretty useful pouet thread.
las: How about you drop by this thread ?
If you're happy with grayscale, you might be as happy using parts of the default VGA palette, thus saving a few bytes that should bring easily your intro down to 256b
If you're happy with grayscale, you might be as happy using parts of the default VGA palette, thus saving a few bytes that should bring easily your intro down to 256b
16 shades of gray is a bit too few :)
Preacher: i do.
actually alot of unused potential is being spoled by not supporting it. especially when it comes to <256b intro-making.
actually alot of unused potential is being spoled by not supporting it. especially when it comes to <256b intro-making.
Doesn't have to be gray. There are a couple of not too funky gradients in the default palette. Beside AFAIK 16 shades of gray did the job for Ballsy.
Code:
salc
_palette:
mov dx, 0x3c9
times 3 out dx, al
inc ax
jnz short _palette
This is what I currently use - inspired by the palette code of some other 256b/128b intros (one of them is spongy - not sure what the other intro with the "ignore setting the index" trick was and another one brought the salc trick for setting ax to zero). Not sure whether that's a good idea or not ;)
Pirx: could you release your bmp framegrabber one day? :)
13h frame-grabber is a piece of lame unoptimized code written within one long evening, and even if it's small, I don't want to release to public anything that is totally unpolished. Currently I'm out of time to fine tuning, (since incoming Friday most probably I will be offline for some days), so I can share it with you by email. Just give me your address (don't see any contact info on Mercury page), or write me on the address present on IND website.