STePS by Excellence In Art [web]
Checkpoint presents
STePS
- Postscript on the Atari STE!
System requirements: STE, Falcon030 or
Falcon CT60 with 4MB RAM (to run on
Falcon, start from ST Low)
---------
Features
---------
* Postscript parser, reads postscript
data and outputs to screen
* Rotating of postscript images
* Fully anti-aliased graphics with 4x4
interpolation, which is as good as it
can be done with 16 colors
* Full 4X subpixel accuracy in drawing
* Monophonic DMA softsynth with pulse-
width modulation ("SID Sound")
* And all this in a 4K executable that
runs on STE, Falcon030 and CT60, as
long as you have at least 4MB RAM.
-------------------------------
So, in what way is this really
"postscript"?
-------------------------------
Well, technically, this is encapsulated
postscript, EPS. As you may or may not
know, the EPS file format comes in an
ASCII version and a binary version. All
I've done is removed the gigantic page
header information from the ASCII
version,, converted all coordinates to
ints, and packed in the "command" data
("move", "line", "curve") in the upper
bits of the vertices' X value.
All the graphics in this 4K demo were
drawn in Corel DRAW, then exported to
EPS and using a little preparser written
in JustBasic(!), the ASCII is converted
to dc.w statements and saved to .S
files.
So apart from the GIGANTIC printer setup
block (that I doubt ANYONE could decode)
and the rounding off of the coordinates,
all the vector data could be converted
back to .EPS format really easily.
The .EPS format isn't bad to work with,
by the way. As mentioned earlier, all
I've had to implement are three commands
that for lack of real docs on EPS, I
named Move(), LineTo() and CurveTo().
The Move() command contains absolute (as
opposed to relative) X and Y coordinates
to move the "drawing cursor" to.
The LineTo() command, as you probably
guessed, simply contains X and Y to draw
a line to.
Finally, the CurveTo() command contains
THREE vertices (X and Y respectively)
that, along with the drawing cursor's
current position, are used to form a
bezier curve.
All in all, not all that hard to grok,
proven by (if nothing else) that I was
able to build the parsing in just a
couple of hours. 8-)
------------------------------------
Why does this little demo need 4MB?
- and -
Why does the precalc take so long?
------------------------------------
The reason (and answer to both these
questions) can be summed up in one word:
Anti-aliasing.
If you haven't noticed, the graphics
aren't REALLY black-and-white; along the
edges are different greys to remove the
"jaggedness" or "staircase effect" you
would normally see in low-resolution
computer graphics.
This is something you might be used to
seeing in PC demos, because it looks
great, but there's a reason you don't
see it on 80's machines: without special
hardware or LOTS more computing power
(both of which modern PC's have), it's
really hard to achieve. As you may or
may not know, for some types of demo
effects, you can use lots of memory to
save processing power (by setting up
special tables or optimized buffers, for
example), and indeed, this demo uses a
full megabyte of buffering for the
anti-aliasing alone.
And, for technical reasons I won't go
into here, the method used results in
fairly heavy "over-reading", which at
least I simply can't think of a way to
solve. I'm no John Carmack, that's for
sure.
------------------------------------
So, why a 4K? Isn't making a 4K a
typical coder project? And let's be
honest, your "normal" projects
aren't about code, are they?
------------------------------------
This is a really good question. I don't
think I could have put it better myself.
As with almost all my projects, this was
completely idea-driven; I got the idea
of rendering top-quality postscript into
my head, and it simply wouldn't leave me
alone.
The problem was mainly that it was hard
to motivate the on-the-fly rendering, it
isn't as if my renderer could do a
better job than Photoshop anyway (altho
the final demo, given that the target
platform is 16 colors, doesn't do a
WORSE job than Adobe's expensive
software!) - so how would I make it
worth the effort?
And well, it wasn't hard to see that the
ONE advantage to rendering the graphics
manually would be that I could make it
really small, perhaps even small enough
to fit in a 4K executable... And I think
you can guess the rest.
----------------------
What was the hardest?
----------------------
Another really good question! In the end
the hardest part was motivating myself
to finish it. I know a lot of people
will be disappointed about the precalc
time and the memory requirements, and I
fully expect some vitriolic comments on
the tubez of the interwebz.
But I'll have to live with it, I spent a
lot of time optimizing this, and while I
expect it could probably be done a bit
faster, it's been a great learning
experience for me, and if nothing else,
it's a world first on the STE.
So bring it on, Pouet! 8-)
--------
Credits
--------
Before giving out the information about
who did what in this production, I feel
I must give a short disclaimer:
Despite having programmed the STE for
many years now, I'm really not a very
good programmer. However, I can be very
stubborn, so I usually get stuff done
anyway. To help me out, I'm fortunate
enough to have a lot of friends who are
a lot smarter than I am, and never
before have I had more help by all these
amazing people than during the making of
this little 4K demo.
If there's anything in this demo that
seems cool, it's probably thanks to one
or more of these fantastic programmers.
And if you find anything that sucks,
blame me, not the fine people below.
I'm aware that this is not a very cool
demo, and probably won't impress anyone
either with its art, music or code. So
why on earth did I spend the time doing
this? And sure, it might be a fun little
project to MAKE, but we release it to
the public, if I don't think it's any
good?
The first question is fairly easy to
respond to; For literally YEARS, I've
been thinking about how I'm always using
vector art in my demos, but always
converting it to bitmaps before moving
it over to the STE. And all of a sudden,
a couple of months ago, I thought of a
way to do it in seconds rather than
hours. And the idea just wouldn't leave
me alone. I would lie awake at night
thinking about it.
Ok, so perhaps that's reasonable, but
if the results aren't what I hoped for,
why release it? Well, if you're familiar
with my previous work, you've probably
figured out I'm pretty damn vain. In
fact, it's probably reasonable to say
that vanity is a major driving force in
my life. And I know myself well enough
to know and admit that.
But I'm fairly good at using vanity to
push myself harder, and in this case, I
simply promised myself to release this
no matter how it turned out. If nothing
else, I can claim that because of that,
I've worked really hard, done my best,
and well... It is what it is.
Never apologize, never explain, eh? 8-)
-------------------
So... the credits!
-------------------
Idea, graphics, music, code:
Per Almered/XiA/Checkpoint
Enormous amounts of patient debugging,
help and support:
GGN
MegaSTE testing, Falcon debugging and
compatibility fixing:
GGN
A weekend of hard optimising, shaving
off an enormous 300(!) bytes:
Dbug
Borrowed: Sine table generator:
Mcoder+Ziggy Stardust
Borrowed: Bresenham line routine:
Ray
Packed using PackFire 1.2e by:
hitchhikr
Fill routine based on an implementation
by:
Jubanka
Additional support:
Defjam
Zerkman
Quotes:
"Suck all the air out from between the
bits. Don't forget to put me in the
credits!"
Comp7
"Why the hell STE?!?! We need STF
demos! :-)"
lsl
Postscript developed by Adobe Systems,
1985
-------------------------------
Why are your readme's so LONG?
-------------------------------
Yeah, it IS ironic that this readme file
is so much larger than the actual demo,
I agree.
One answer is that I feel that the
documentation work is an important part
of the process of creating something.
I know, I sound like some damn IT guru
on the book-signing circuit who probably
hasn't written a line of code in 20
years...
But that's not quite my angle. For me,
personally, finishing a project (by
documenting it) is a way to overcome the
depression that always seems to hit when
I finish something. It's a very real
problem for me, and I'm honestly very
grateful that I've found this method to
overcome it.
And also, I like reading about how
stuff was made, and hey, who knows,
maybe one day when I'm old(er) and have
even LESS hair than today, I'll find
a ZIP file of this demo and read the
README.TXT, the file you're reading now,
and maybe I can be happy being reminded
of the demomaking process and the Atari
demoscene in general.
So, thanks for watching the demo, hope
you enjoyed it, and thanks for taking
the time to read this README as well.
Now go play in the sun and think up your
own 4K demo!
Contact information:
Per Almered
per@brainfish.net
http://brainfish.net/atari
[ back to the prod ]