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?
added on the 2012-05-21 19:19:40 by las las
oppps not fcomi st0, st1 - that's a fcom st(1) - fcomi seems unsupported - at least in DOSBox
added on the 2012-05-21 19:21:12 by las las
las, what about replacing:

jbe ...
fxch ...

fcmov or fcmovnb

added on the 2012-05-21 19:30:05 by gopher gopher
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.

Code: _max: fcom st1 fstsw ax sahf jbe _max0 _max1: fxch st1 _max0: fstp st0 ret

this seems to work.
added on the 2012-05-21 20:22:32 by las las
maybe I should give bochs a try.
added on the 2012-05-21 20:35:27 by las las
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:

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).
added on the 2012-05-21 21:47:05 by ryg ryg
added on the 2012-05-21 22:07:35 by las las
In case you need also min, this code can be useful:
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 ret

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.
added on the 2012-05-21 22:34:11 by Pirx Pirx
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.
added on the 2012-05-21 23:17:23 by las las
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"?
added on the 2012-05-22 10:59:32 by las las
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.
added on the 2012-05-22 21:02:31 by las las
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
added on the 2012-05-23 00:59:36 by rudi rudi
Actually I have now something _way_ better than a cube :D
added on the 2012-05-23 01:38:43 by las las
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 (=
one could make vsync-rasterbars that would actually work in dosbox if they implemented it correctly.
added on the 2012-05-23 13:31:46 by rudi rudi
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...
added on the 2012-05-23 14:02:13 by Preacher Preacher
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.
added on the 2012-05-23 15:08:06 by las las
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
added on the 2012-05-23 15:19:35 by p01 p01
16 shades of gray is a bit too few :)
added on the 2012-05-23 16:28:26 by las las
Preacher: i do.
actually alot of unused potential is being spoled by not supporting it. especially when it comes to <256b intro-making.
added on the 2012-05-23 16:36:57 by rudi rudi
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.
added on the 2012-05-23 16:37:32 by p01 p01
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 ;)
added on the 2012-05-23 17:50:46 by las las
Pirx: could you release your bmp framegrabber one day? :)
added on the 2012-05-23 18:57:43 by las las
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.
added on the 2012-05-23 22:14:12 by Pirx Pirx