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