Independent Software

Mercator: gridded earth data as map tiles

2026-06-11T07:00:00+00:00

A few years ago I wrote here about generating current-flow animations on map tiles from sparse vector data. That little tile-by-tile animation experiment never quite left me alone. I have spent the last while turning the idea into a real product, and it is now live: mercator, a gridded earth data API that serves weather, ocean, air quality and elevation as map tiles.

The problem

There is an enormous amount of earth-science data on the internet, and almost none of it is shaped for a map. Most commercial weather APIs answer one question well: what is the value at this latitude and longitude? You send a coordinate, you get a number. That is perfect for a “weather in your city” widget and useless if you want to draw temperature as a continuous field across a continent, or animate wind as flowing particles over an ocean.

If you want the continuous surface, a point API forces you to make thousands of requests and then interpolate between them yourself. You end up rebuilding a grid the provider already had and threw away at the API boundary. What you actually want is the grid. The raw model output (NOAA’s GFS, ocean state from HYCOM, air quality from Copernicus CAMS, elevation from GEBCO) is already a regular array of values over the globe. The real job is just getting that array into a browser efficiently enough to render it at 60fps.

Values baked into pixels

Map tiles already solved “deliver a huge raster to a browser, lazily, at the zoom and region the user is actually looking at, cached hard at a CDN”. Every mapping library on earth speaks that protocol. The only twist mercator adds is that its tiles do not carry colours. They carry values.

The bytes in each pixel are the actual physical quantity, scaled and offset to fit the 8-bit channels of an ordinary PNG, and a fragment shader decodes them back to real units on the GPU at draw time. This is the same idea as Mapbox’s Terrain-RGB, which packs elevation into RGB, generalised to scalars like temperature and to vector fields like wind and currents.

The payoff is that the developer controls the visualisation entirely on the client. Swap the colour ramp, switch from a filled raster to streamlines to contours, change the value range, all without refetching a single byte, because the bytes are the data and not a picture of it. The current-flow animation from that old article is now just one of the things you can render, except the heavy lifting happens in a shader instead of being baked into a GIF.

What it does

mercator has two halves. The first is the tile service: an HTTP endpoint serving the value-encoded tiles plus a metadata.json that fully documents the encoding, so any developer can decode the pixels without my code. The second is an open-source SDK that ships the shader decoders and ready-made visualisations (colormapped rasters, animated wind and current streamlines, arrows, contours, value labels) for MapLibre, Mapbox, Leaflet, OpenLayers, deck.gl and React. Six lines of JavaScript get you an animated wind field on a map.

The catalogue spans atmospheric weather, ocean currents and waves, air quality and elevation, and the forecast datasets refresh on a six-hourly cycle. The whole thing follows the same shape as Mapbox GL JS or Deck.gl: the SDK is free and open (Apache-2.0), and the paid part is the data API, with a free tier of 10,000 tiles a month. Because the tile format is documented, you are never locked to my renderer.

Have a look

There is a live interactive globe on the homepage with wind streaming over it, a live playground for each framework, and the full tile-encoding and API docs if you want to decode the tiles yourself. The free tier needs no credit card.

It started as a tile-animation hack in a C# project, and it has grown into a proper gridded-earth-data service. If you build maps and have ever wanted real weather or ocean data on them without wrestling a point API, I would love for you to try it and tell me what you think.

Getting your PHP backend to finally send email

2024-04-11T10:11:00+00:00

You’re developing a back-end in PHP (Laravel, Lumen, or just freewheeling it) and you want it to send out email when users use your “forgot password” functionality. Getting everything configured just right can be a headache and this article lists all the things you need to do. You could also reach for a third-party solution, but then you’d have to have your credit card handy.

Using a 3rd-party service?

If you don’t want to code the email sending yourself, you can reach for a third-party solution. Mailgun, Sendgrid and Mailchimp come to mind, but they all cost money. Mailgun has a free tier, but it’ll only work for sending out email to up to 5 known email addresses, and that’s not what you want - you want to send email out into the world (but only one email at a time). Even if you did pay for a third-party solution, it may have a free tier of up to, say, 1,000 emails per month, after which you start paying. God forbid that your API key falls into the wrong hands and someone sends out a million emails with it!

Using your own server

In my case, I have a shared-hosting server that runs PHP. Through CPanel, I am able to create email addresses, so I can go ahead and create info@myserver.org and use that to send email from.

Problem 1: Email sent manually from my server does not arrive

With so many spammers around, email has become something like the Wild West. Anyone can send out emails, and users are bombarded with spam. To fight some of this, email providers try to block emails where it can’t be determined where the email came from - in which case it could be a spoofed address.

Sending out a simple email manually from my CPanel email client to a GMail address will result in this (I’ll get an email back from CPanel or from Gmail):

550-5.7.26 This message does not pass authentication checks (SPF and DKIM both 
550-5.7.26 do not pass).
550-5.7.26 This mail is unauthenticated, which poses a security risk to the 
550-5.7.26 sender and Gmail users, and has been blocked. The sender must 
550-5.7.26 authenticate with at least one of SPF or DKIM. For this message, 
550-5.7.26 DKIM checks did not pass and SPF check for [example.com] 
550-5.7.26 did not pass with ip: [x.y.z.n]. The sender should visit 
550-5.7.26 https://support.google.com/mail/answer/81126#authentication for 
550 5.7.26 instructions on setting up authentication.

In other words, if your domain doesn’t have SPF and DKIM records, GMail (and likely others) will reject your mails straight out of the gate.

A solution is brought by CPanel itself: the Email deliverability option.

If you have no DKIM or SPF records setup, then the Email Deliverabilty screen will report that there is a problem and offer to repair it:

If your DNS is actually under CPanel’s control, you can CPanel create SPF and DKIM records automatically. If not, and like me, you have your domain at GoDaddy while you’re hosting somewhere else, it’s not going to be automatic. But never fear, CPanel can still help. If you choose the Manage option, CPanel will tell you that no DKIM record exists, and provide you with a suggested record:

This system does not control DNS for the “myserver.org” domain and the system did not find any authoritative nameservers for this domain. You can install the suggested “DKIM” record locally. However, this server is not the authoritative nameserver. If you install this record, this change will not be effective. Contact your domain registrar to verify this domain’s registration.

Suggested DKIM (TXT) record:
Name = default._domainkey.www.myserver.org.
Value = v=DKIM1; k=rsa; p=a-long-encrypted-value;

Suggested SPF (TXT) record:
Name = www.myserver.org.
Value = v=spf1 +mx +a +ip4:(ip number) ~all

You can actually take these values to GoDaddy and create the DNS records yourself. Note that both need to be TXT records. Create these and save them, wait a few minutes, and then manually send an email again. It should now arrive without issue into a GMail inbox.

Getting Laravel’s mailer to behave

With the TXT records configured, I found that while I could send emails manually through the email web client and receive them, emails from PHP would not be received.

It turns out that for Lumen, after configuring all that’s necessary for Illuminate/mail, no email would be sent. I also found that the email sending route returns rather quickly; ordinarily it would be processing a little while before returning.

I there checked my STMP settings using the GMass SMTP Test Tool which came in handy. I found that I was able to send email email through this and receive it in a GMail inbox, so my SMTP settings were correct. I also noted that sending the email took a few seconds, so it was suspicious that the Laravel code returned immediately.

Finding no way to get the Laravel code to tell me why it failed, I installed the venerable PHPMailer instead. Testing it out by pasting its sample code into my back-end implementation, it immediately worked.

Stepping away from Laravel’s SwiftMailer was made easier by using Laravel’s ENV variables in PHPMailer instead of using hardcoded values (these are the settings from the .env file):

$mail->Host       = env('MAIL_HOST');            // Set the SMTP server to send through
$mail->SMTPAuth   = true;                        // Enable SMTP authentication
$mail->Username   = env('MAIL_USERNAME');        // SMTP username
$mail->Password   = env('MAIL_PASSWORD');        // SMTP password
$mail->SMTPSecure = PHPMailer::ENCRYPTION_SMTPS; // Enable implicit TLS encryption
$mail->Port       = env('MAIL_PORT', 2525);      // TCP port

Further, it’s still possible to use Laravel’s Blade templates by rendering them to string:

$mail->isHTML(true);
$mail->Subject = 'Database password reset';
$mail->Body    = view('reset', compact('user'))->render();
$mail->send();

I know I’ve had Laravel’s SwiftMailer work for me in the past, but PHPMailer does me the courtesy of letting me put a try…catch around the mail sending process so that I’ll know when it’s failed. Also, a full SMTP debug can be echoed to the output to see precisely what went wrong.

Denthor/Asphyxia’s VGA trainers: Texture mapping

2023-02-06T16:32:00+00:00

This trainer is on texture mapping. I know, I know, I said light sourcing, then Gouraud, then texture mapping, but I got enough mail (a deluge in fact ;) telling me to do texture mapping.

DENTHOR, coder for ...
_____   _____   ____   __   __  ___  ___ ___  ___  __   _____
/  _  \ /  ___> |  _ \ |  |_|  | \  \/  / \  \/  / |  | /  _  \
|  _  | \___  \ |  __/ |   _   |  \    /   >    <  |  | |  _  |
\_/ \_/ <_____/ |__|   |__| |__|   |__|   /__/\__\ |__| \_/ \_/
smith9@batis.bis.und.ac.za
The great South African Demo Team! Contact us for info/code exchange!

Grant Smith, alias Denthor of Asphyxia, wrote up several articles on the creation of demo effects in the 90s. I reproduce them here, as they offer so much insight into the demo scene of the time.

These articles apply some formatting to Denthor's original ASCII files, plus a few typo fixes.

Free Direction Texture Mapping

There are two things you should know before we begin.

Firstly, I am cheating. The texture mapping I am going to show you is not perspective-correct, with clever divides for z-placement etc. This method looks almost as good and is quite a bit faster too.

Secondly, you will find it all rather easy. The reason for this is that it’s all rather simple. I first made the routine by sitting down with some paper and a pencil and had it on the machine in a few hours. A while later when people on the net started discussing their methods, they were remarkably similar.

Let me show you what I mean.

Let us assume you have a texture of 128x128 (a straight array of bytes [0..127, 0..127]) which you want to map onto the side of a polygon. The problem of course being that the polygon can be all over the place, with one side longer then the other etc.

Our first step is to make sure we know which end is up. Let me demonstrate:

                      1
                    +
                 /    \
              /         \
          4 +            +  2
              \        /
                \   /
                  +
                  3

Let us say that the above is the chosen polygon. We have decided that point 1 is the top left, point 3 is bottom right. This means that

1 - 2 is the top of the texture
2 - 3 is the right of the texture
3 - 4 is the bottom of the texture
4 - 1 is the left of the texture

The same polygon, but rotated:

                      3
                    +
                 /    \
              /         \
          2 +            +  4
              \        /
                \   /
                  +
                  1

Although the positions of the points are different, point 1 is still the top-left of our texture.

How to put it to screen

Okay, so now you have four points and know which one of them is also the top-left of our texture. What next?

If you think back to our tutorial on polygons, you will remember we draw it scanline by scanline. We do texture mapping the same way.

Let’s look at that picture again:

                      1
                    +
               a /    \  b
              /         \
          4 +            +  2
              \        /
                \   /
                  +
                  3

We know that point 1 is at [0,0] in our texture. Point 2 is at [127,0], Point 3 is at [127,127], and point 4 is at [0,127].

The clever bit, and the entire key to texture mapping, is making the logical leap that precisely half way between Point 1 and Point 2 (b), we are at [64,0] in our texture. (a) is in the same manner at [0,64].

That’s it. All we need to know per y scanline is:

The starting position on the x axis of the polygon line
The position on the x in the texture map referenced by that point
The position on the y in the texture map referenced by that point
The ending position on the x axis of the polygon line
The position on the x in the texture map referenced by that point
The position on the y in the texture map referenced by that point

Let me give you an example. Let’s say that (a) and (b) from the above picture are on the same y scanline. We know that the x of that scanline is (say) 100 pixels at the start and 200 pixels at the end, making it’s width 100 pixels.

We know that on the left hand side, the texture is at [0,64], and at the right hand side, the texture is at [64,0]. In 100 pixels we have to traverse our texture from [0,64] to [64,0].

Assume at the start we have figured out the starting and ending points in the texture:

  textureX = 0;
  textureY = 64;
  textureEndX = 64;
  textureEndY = 0;

  dx := (TextureEndX-TextureX)/(maxx-minx);
  dy := (TextureEndY-TextureY)/(maxx-minx);
  for loop1 := minx to maxx do BEGIN
    PutPixel (loop1, ypos, texture [textureX, textureY], VGA);
    textureX = textureX + dx;
    textureY = textureY + dy;
  END;

Do the above for all the scanlines, and you have a texture mapped polygon! It’s that simple.

We find our beginning and ending positions in the usual fashion. We know that Point 1 is [0,0]. We know that Point 2 is [127,0]. We know the number of scanlines on the y axis between Point 1 and Point 2.

  textureDX = 127/abs (point2.y - point1.y)

We run though all the y scanlines, starting from [0,0] and adding the above formula to the X every time. When we hit the last scanline, we will be at point [127,0] in the texture.

Repeat for all four sides, and you have the six needed variables per scanline.

In closing

As you can see, texture mapping (this type at least) is quite easy, and produces quite a good result. You will however notice a bit of distortion if you bring the polygon too close. This can be fixed by a) Subdividing the polygon, so the one is made up of four or more smaller polygons. Much bigger, but works; b) Using more accurate fixed point; or c) Figuring out perspective correct texture mapping, mapping along constant-z lines etc.

Denthor/Asphyxia’s VGA trainers: Hidden face removal

2023-02-06T16:27:00+00:00

This trainer is on 3D hidden face removal and face sorting. I was going to add shading, but that can wait until a later trainer. For convenience I will build on the 3D code from Part 8. The maths for face removal is a bit tricky, but just think back to your old high school trigonometry classes.

DENTHOR, coder for ...
_____   _____   ____   __   __  ___  ___ ___  ___  __   _____
/  _  \ /  ___> |  _ \ |  |_|  | \  \/  / \  \/  / |  | /  _  \
|  _  | \___  \ |  __/ |   _   |  \    /   >    <  |  | |  _  |
\_/ \_/ <_____/ |__|   |__| |__|   |__|   /__/\__\ |__| \_/ \_/
smith9@batis.bis.und.ac.za
The great South African Demo Team! Contact us for info/code exchange!

Grant Smith, alias Denthor of Asphyxia, wrote up several articles on the creation of demo effects in the 90s. I reproduce them here, as they offer so much insight into the demo scene of the time.

These articles apply some formatting to Denthor's original ASCII files, plus a few typo fixes.

Face Sorting

There are many ways to sort faces in a 3D object. For now, I will show you just about the easiest one of the lot.

Say you have two polygons….

                ------P1

           ------------------P2

                   Eye

As you can see, P1 has to be drawn before P2. The easiest way to do this is as follows:

On startup, find the midpoint of each of the polys, through the easy equations:

x = (P2.1.x + P2.2.x + P2.3.x + p2.4.x)/4
y = (P2.1.y + P2.2.y + P2.3.y + p2.4.y)/4
z = (P2.1.z + P2.2.z + P2.3.z + p2.4.z)/4

NOTE: For a triangle you would obviously only use three points and divide by three.

Anyway, now you have the X,Y,Z of the midpoint of the polygon. You can then rotate this point with the others. When it is time to draw, you can compare the resulting Z of the midpoint, sort all of the Z items, and then draw them from back to front.

In the sample program I use a simple bubble sort… basically, I check the first two values against each other, and swap them if the first is bigger than the second. I continue doing this to all the numbers until I run through the entire list without swapping once. Bubble sorts are standard computer science topics… perhaps borrow a text book to find out more about them and other (better) sorting methods.

The above isn’t perfect, but it should work 90% of the time. But it still means that when you are drawing a cube, you have to draw all 6 sides every frame, even though only three or so are visible. That is where hidden face removal comes in…

Hidden Face Removal

Pick up something square. A stiffy disk will do fine. Face it towards you, and number all the corners from one to four in a clockwise direction.

                1 +-------------+ 2
                  |             |
                  |             |
                  |             |
                  |             |
                4 +-------------+ 3

Now rotate the stiffy disk on all three axes, making sure that you can still see the front of the disk. You will notice that whenever you can see the front of the disk, the four points are still in alphabetical order. Now rotate it so that you can see the back of the stiffy. Your points will now be:

                2 +-------------+ 1
                  |             |
                  |             |
                  |             |
                  |             |
                3 +-------------+ 4

The points are now anti-clockwise! This means, in its simplest form, that if you define all your polygon points in a clockwise order, when drawing you ignore the polys that are anticlockwise. (Obviously when you define the 3D object, you define the polygons facing away from you in an anticlockwise order.)

To find out whether a poly’s points are clockwise or not, we need to find its normal. Here is where things start getting fun.

In school, you are told that a normal is perpendicular to the plane. In ASCII:

                      | Normal
                      |
                      |
        --------------------------- Polygon

As you can see, the normal is at 90 degrees to the surface of the poly. We must extend this to three dimensions for our polygons. You’ll have to trust me on that, I can’t draw it in ASCII :)

To find a normal, you only need three points from your poly (ABC):

A(x0,y0,z0), B(X1,Y1,Z1), C(X2,Y2,Z2)

then the vector normal = AB^AC = (Xn,Yn,Zn) with

Xn=(y1-y0)(z0-z2)-(z1-z0)(y0-y2)
Yn=(z1-z0)(x0-x2)-(x1-x0)(z0-z2)
Zn=(x1-x0)(y0-y2)-(y1-y0)(x0-x2)

We are interested in the Z normal, so we will use the function:

normal:=(x1-x0)(y0-y2)-(y1-y0)(x0-x2);

The result is something of a sine wave when you rotate the poly in three dimensions. A negative value means that the poly is facing you, a positive value means that it is pointing away.

The above means that with a mere two MULs you can discount an entire poly and not draw it. This method is perfect for “closed” objects such as cubes etc.

I am anything but a maths teacher, so go borrow someone’s math book to find out more about surface normals. Trust me, there is a lot more written about them than you think.

An extension of calculating your normal is finding out about light-sourcing your polygons. Watch for more information in one of the next few trainers.

A combination of the above two routines should work quite nicely in creating 3d objects with little or no overlapping.

Denthor/Asphyxia’s VGA trainers: Flame effect

2023-02-06T16:11:00+00:00

This trainer is on assembler. For those people who already know assembler quite well, this tutorial is also on the flame effect.

DENTHOR, coder for ...
_____   _____   ____   __   __  ___  ___ ___  ___  __   _____
/  _  \ /  ___> |  _ \ |  |_|  | \  \/  / \  \/  / |  | /  _  \
|  _  | \___  \ |  __/ |   _   |  \    /   >    <  |  | |  _  |
\_/ \_/ <_____/ |__|   |__| |__|   |__|   /__/\__\ |__| \_/ \_/
smith9@batis.bis.und.ac.za
The great South African Demo Team! Contact us for info/code exchange!

Grant Smith, alias Denthor of Asphyxia, wrote up several articles on the creation of demo effects in the 90s. I reproduce them here, as they offer so much insight into the demo scene of the time.

These articles apply some formatting to Denthor's original ASCII files, plus a few typo fixes.

Assembler - the short version

Okay, there are many assembler trainers out there, many of which are probably better than this one. I will focus on the areas of assembler that I find important… if you want more, go buy a book (go for the Michael Abrash ones), or scour the ‘net for others.

First, let us start off with the basic set up of an assembler program.

DOSSEG

This tells your assembler program to order your segments in the same manner that high level languages do.

.MODEL <MODEL>

<MODEL> can be:

Tiny       Code + Data < 64k   (Can be made a COM file)
Small      Code < 64k          Data < 64k
Medium     Code > 64k          Data < 64k
Compact    Code < 64k          Data > 64k
Large      Code > 64k          Data > 64k
Huge       Arrays > 64k

Enable 286 instructions … can be .386 ; .386P etc.:

.286

Set the stack. <size> will be the size of your stack. I usually use 200h:

.STACK <size>

Tells the program that the data is about to follow. (Everything after this will be placed in the data segment):

.DATA

Tells the program that the code is about to follow. (Everything after this will be placed in the code segment)

.CODE

Tells the program that this is where the code begins:

START:

Tells the program that this is where the code ends:

END START

To compile and run an assembler file, we run:

tasm bob
tlink bob

I personally use tasm; you will have to find out how your assembler works.

Now, if we ran the above file as follows:

DOSSEG
.MODEL SMALL
.286
.STACK 200h
.DATA
.CODE

START
END START

You would think that is would just exit to DOS immediately, right? Wrong. You have to specifically give DOS back control, by doing the following:

START
        mov     ax,4c00h
        int     21h
END START

Now if you compiled it, it would run and do nothing.

Okay, let us kick off with registers.

Firstly: A bit is a value that is either 1 or 0.

This is obviously quite limited, but if we start counting in them, we can get larger numbers. Counting with ones and zeros is known as binary, and we call it base 2. Counting in normal decimal is known as base 10, and counting in hexadecimal is known as base 16.

    Base 2 (Binary)     Base 10 (Decimal)    Base 16 (Hexadecimal)
         0                      0                       0
         1                      1                       1
         10                     2                       2
         11                     3                       3
         100                    4                       4
         101                    5                       5
         110                    6                       6
         111                    7                       7
         1000                   8                       8
         1001                   9                       9
         1010                   10                      A
         1011                   11                      B
         1100                   12                      C
         1101                   13                      D
         1110                   14                      E
         1111                   15                      F

As you can see, you need four bits to count up to 15, and we call this a nibble. With eight bits, we can count up to 255, and we call this a byte. With sixteen bits, we can count up to 65535, and we call this a word. With thirty-two bits, we can count up to lots, and we call this a double word.

A quick note: Converting from binary to hexadecimal is actually quite easy. You break up the binary into groups of four bits, starting on the right, and convert these groups of four to hex.

      1010 0010 1111 0001
  =      A    2    F    1

Converting to decimal is a bit more difficult. What you do, is you multiply each number by its base to the power of its index…

  A2F1 hex
= (A*16^3) + (2*16^2) + (F*16^1) + (1*16^0)
= (10*4096) + (2*256) + (15*16) + (1)
= 40960 + 512 + 240 + 1
= 41713 decimal

The same system can be used for binary.

To convert from decimal to another base, you divide the decimal value by the desired base, keeping a note of the remainders, and then read the results backwards.

               16   |   41713
               16   |   2607    r   1       (41713 / 16 = 2607 r 1)
               16   |   162     r   F       (2607 / 16 = 162 r 15)
               16   |   10      r   2       (162 / 16 = 10 r 2)
                    |   0       r   A       (10 / 16 = 0 r 10)

Read the remainders backwards, our number is A2F1 hex. Again, the same method can be used for binary.

The reason why hex is popular is obvious: using bits, it is impossible to get a reasonable base 10 (decimal) system going, and binary gets unwieldly at high values. Don’t worry too much though: most assemblers (like tasm) will convert all your decimal values to hex for you.

You have four general purpose registers: AX, BX, CX and DX. Think of them as variables that you will always have. On a 286, these registers are 16 bytes long, or one word.

As you know, a word consists of two bytes, and in assembler you can access these bytes individually. They are separated into high bytes and low bytes per word.

   High byte | Low byte
   0000 0000 | 0000 0000  bits
   [--------Word-------]

The method of access is easy. The high byte of AX is AH, and the low byte is AL. You can also access BH, BL, CH, CL, DH and DL.

A 386 has extended registers: EAX, EBX, ECX, EDX… you can access the lower word normally (as AX, with bytes AH and AL), but you cannot access the high word directly … you must ror EAX,16 (rotate the binary value through 16 bits), after which the high word and low word swap … do it again to return them. Acessing EAX as a whole is no problem: mov eax, 10; add eax,ebx … these are all valid.

Next come segments. As you have probably heard, computer memory is divided into various 64k segments (note: 64k = 65,536 bytes, sound familiar?) A segment register points to which segment you are looking at. An offset register points to how far into that segment you are looking. One way of looking at it is like looking at a 2D array… the segments are your columns and your offsets are your rows. Segments and offsets are displayed as Segment:Offset … so $a000:50 would mean the fiftieth byte in segment $a000.

The segment registers are ES, DS, SS and CS. A 386 also has FS and GS. These values are words (0-65,535), and you cannot access the high or low bytes separately. CS points to your code segment, and usually if you touch this your program will explode. SS points to your stack segment, again, this baby is dangerous. DS points to your data segment, and can be altered, if you put it back after you use it, and don’t use any global variables while it is altered. ES is your extra segment, and you can do what you want with it.

The offset registers are DI, SI, IP, SP, BP. Offset registers are generally associated with specific segment registers, as follows: ES:DI DS:SI CS:IP SS:SP … On a 286, BX can be used instead of the above offset registers, and on a 386, any register may be used. DS:BX is therefore valid.

If you create a global variable (let’s say bob), when you access that variable, the compiler will actually look for it in the data segment. This means that the statement:

ax = bob

could be

ax = ds:[15]

A quick note: A value may be signed or unsigned. An unsigned word has a range from 0 to 65,535. A signed word is called an integer and has a range -32,768 to 32,767. With a signed value, if the leftmost bit is equal to 1, the value is in the negative.

Next, let us have a look at the stack. Let us say that you want to save the value in ax, use ax to do other things, then restore it to its origional value afterwards. This is done by utilizing the stack. Have a look at the following code:

mov   ax, 50      ; ax is equal to 50
push  ax          ; push ax onto the stack
mov   ax, 27      ; ax is equal to 27
pop   ax          ; pop ax off the stack

At this point, ax is equal to 50.

Remember we defined the stack to be 200h further up? This is part of the reason we have it. When you push a value onto the stack, that value is recorded on the stack heap (referenced by SS:SP, SP is incremented) When you pop a value off the stack, the value is placed into the variable you are popping it back in to, SP is decremented and so forth. Note that the computer does not care what you pop the value back into.

mov   ax, 50
push  ax
pop   bx

This would set the values of both ax and bx to 50. (There are faster ways of doing this, pushing and popping are fairly fast though).

push ax
push bx
pop  ax
pop  bx

This would swap the values of ax and bx. As you can see, to pop the values back in to the original variables, you must pop them back in the opposite direction to which you pushed them.

push ax
push bx
push cx

pop cx
pop bx
pop ax

would result in no change for any of the registers.

When a procedure is called, all the parameters for that procedure are pushed onto the stack. These can actually be read right off the stack, if you want to.

As you have already seen, the mov command moves a value…

mov  <dest>, <source>

Note that dest and source must be the same number of bits long.

mov  ax, dl

would not work, and neither would

mov  cl,bx

However:

mov  cx,dx
mov  ax,50
mov  es,ax

are all valid.

shl I have explained before, it is where all the bits in a register are shifted one to the left and a zero added on to the right. This is the equivalent of multiplying the value by two. shr works in the opposite direction.

rol does the same, except that the bit that is removed from the left is replaced on the right hand side. ror works in the opposite direction.

div <value> divides the value in ax by value and returns the result in al if value is a byte, placing the remainder in ah. If value is a word, the double word DX:AX is divided by value, the result being placed in ax and the remainder in dx. Note that this only works for unsigned values.

idiv <value> does the same as above, but for signed variables.

mul <value> If value is a byte, al is multiplied by value and the result is stored in ax. If value is a word, ax is multiplied by value and the result is stored in the double word DX:AX.

imul <value> does the same as above, but for signed variables.

The j* commands are fairly simple: if a condition is met, jump to a certain label.

jz  <label>   Jump if zero
ja  <label>   Jump above     (unsigned)
jg  <label>   Jump greater   (signed)

and so forth.

An example:

cmp  ax,50    ; Compare ax to 50
je   @Equal   ; If they are equal, jump to label @equal
call MyProc   ; Runs procedure MyProc and then returns to the next line of code.

Procedures are declared as follows:

MyProc   proc near
         ret    ; Must be here to return from where it was called
MyProc   endp

Variables are also easy:

bob  db 50

creates a variable bob, a byte, with an initial value of 50.

bob2 dw 50

creates a variable bob2, a word, with an initial value of 50.

bob3 db 1,2,3,4,5,65,23

creates bob3, an array of 7 bytes.

bob4 db 100 dup (?)

creates bob4, an array of 100 bytes, with no starting value.

Go back and look at Part 7 for a whole lot more assembler commands, and get some sort of reference guide to help you out with others. I personally use the Norton Guides help file to program assembler.

Fire Routines

To demonstrate how to write an assembler program, we will write a fire routine in 100% assembler. The theory is simple.

Set the palette to go from white to yellow to red to blue to black. Create a 2D array representing the screen on the computer. Place high values at the bottom of the array (screen) for each element, do the following:

Take the average of the four elements under it:

                         * Current element
                        123
                         4  Other elements

Get the average of the four elements, and place the result in the current element.
Repeat

Easy, no? I first saw a fire routine in the Iguana demo, and I just had to do one ;) … it looks very effective.

With the sample file, I have created a batch file, make.bat. It basically says:

tasm fire
tlink fire

So to build and run the fire program, type:

make
fire

The source file is commented quite well, so there shouldn’t be any problems.

In closing

As you can see, the sample program is in 100% assembler. For the next tutorial I will return to Pascal, and hopefully your newfound assembler skills will help you there too.

Denthor/Asphyxia’s VGA trainers: File packing

2023-02-06T15:22:00+00:00

This trainer is about reading PCX files, file packing, and putting everything into one executable file.

DENTHOR, coder for ...
_____   _____   ____   __   __  ___  ___ ___  ___  __   _____
/  _  \ /  ___> |  _ \ |  |_|  | \  \/  / \  \/  / |  | /  _  \
|  _  | \___  \ |  __/ |   _   |  \    /   >    <  |  | |  _  |
\_/ \_/ <_____/ |__|   |__| |__|   |__|   /__/\__\ |__| \_/ \_/
smith9@batis.bis.und.ac.za
The great South African Demo Team! Contact us for info/code exchange!

Grant Smith, alias Denthor of Asphyxia, wrote up several articles on the creation of demo effects in the 90s. I reproduce them here, as they offer so much insight into the demo scene of the time.

These articles apply some formatting to Denthor's original ASCII files, plus a few typo fixes.

Loading a PCX file

This is actually quite easy. The PCX file is divided into three sections, namely a 128 byte header, a data section, and a 768 byte palette.

You can usually ignore the 128 byte header, but here it is:

0  Manufacturer     10 = ZSoft .PCX file
1  Version
2  Encoding
3  Bits Per Pixel
4  XMin, Ymin, XMax, YMax  (2 bytes each)
12 Horizontal Resolution (2 bytes)
14 Vertical Resolution (2 bytes)
16 Color palette setting (48 bytes)
64 Reserved
65 Number of color planes
66 Bytes per line (2 bytes)
68 1 = Color    2 = Grayscale  (2 bytes)
70 Blank (58 bytes)

That makes 128 bytes.

The palette file, which is 768 bytes, is situated at the very end of the PCX file. The 769’th byte back should be the decimal 12, which indicates that a VGA color palette is to follow.

There is one thing that we have to do to get the palette correct in VGA… the PCX palette values for R,G,B are 0 to 255 respectively. To convert this to our standard (VGA) palette, we must divide the R,G,B values by 4, to get them into a range of 0 to 63.

Actually decoding the image is very simple. Starting after the 128 byte header, we read a byte.

If the top two bits of this byte are not set, we dump the value to the screen.

We check bits as follows:

if ((temp and $c0) = $c0) then ...(bits are set)... else ...(bits are not set)

C0 in hex = 11000000 in binary = 192 in decimal

Let’s look at that more closely…

  temp  and  c0h
  temp  and  11000000b

That means, when represented in bit format, both corresponding bits have to be set to one for the result to be one.

0 and 0 = 0     1 and 0 = 0    0 and 1 = 0    1 and 1 = 1

In the above case then, both of the top two bits of temp have to be set for the result to equal 11000000b. If it does not equal that, the top two bits are not both set, and we can put the pixel.

So:

  if ((temp and $c0) = $c0) then BEGIN
  END else BEGIN
    putpixel (screenpos,0,temp,vga);
    inc (screenpos);
  END;

If the top two bits are set, things change. The bottom six bits become a loop counter, which the next byte is repeated.

  if ((temp and $c0) = $c0) then BEGIN
    { Read in next byte, temp2 here.}
    for loop1:=1 to (temp and $3f) do BEGIN
      putpixel (screenpos,0,temp2,vga);
      inc (screenpos);
    END;
  END else BEGIN
    putpixel (screenpos,0,temp,vga);
    inc (screenpos);
  END;

There is our PCX loader. You will note that by and’ing temp by $3f; I am and’ing it by 00111111b… in other words, clearing the top two bits.

The sample program has the above in assembler, but it is the same procedure… and you can read the next tutorial for more info on how to code in assembler.

In the sample I assume that the pic is 320x200, with a maximum size of 66,432 bytes.

File packing

The question is simple: how do I get all my files into one executable? Having many small data files can start to look unprofessional.

An easy way to have one .exe and one .dat file when dealing with many cels etc. is easy… you would alter your load procedure, which looks as follows:

VAR temp : Array [1..5,1..256] of byte;
Procedure Init;
BEGIN
  loadcel ('pic1.cel',temp[1]);
  loadcel ('pic2.cel',temp[2]);
  loadcel ('pic3.cel',temp[3]);
  loadcel ('pic4.cel',temp[4]);
  loadcel ('pic5.cel',temp[5]);
END;

For one compile you would do this:

VAR temp : Array [1..5,1..256] of byte;
Procedure Init;
VAR f:File;
BEGIN
  loadcel ('pic1.cel',temp[1]);
  loadcel ('pic2.cel',temp[2]);
  loadcel ('pic3.cel',temp[3]);
  loadcel ('pic4.cel',temp[4]);
  loadcel ('pic5.cel',temp[5]);
  assign (f,'pic.dat');
  rewrite (f,1);
  blockwrite (f,temp,sizeof(temp));
  close (f);
END;

From then on, you would do:

VAR temp : Array [1..5,1..256] of byte;
Procedure Init;
VAR f:File;
BEGIN
  assign (f,'pic.dat');
  reset (f,1);
  blockread (f,temp,sizeof(temp));
  close (f);
END;

This means that instead of five data files, you now have one! You have also stripped the 800 byte cel header too. Note that this will work for any form of data, not just cel files.

The next logical step is to include this data in the .exe file, but the question is how? In an earlier tutorial, I converted my data file to constants and placed it inside my main program. This is not good mainly because of space restrictions … you can only have so many constants, and what if your data file is two megs big?

Attached with this tutorial is a solution. I have written a program that combines your data files with your executable file, no matter how big the data is. The only thing you have to worry about is a small change in your data loading methods. Let’s find out what.

Using the file packer

Normally you would load your data as follows:

Procedure Init;
BEGIN
  loadcel ('bob.bob',temp);
  loadpcx ('den.pcx',VGA);        { Load a PCX file }
  loaddat ('data.dat',lookup);    { Load raw data into lookup }
END;

Easy, hey? Now, using the file packer, you would change this to:

USES fpack;
Procedure Init;
BEGIN
  total := 3;
  infodat[1] := 'bob.bob';
  infodat[2] := 'den.pcx';
  infodat[3] := 'data.dat';
  loadcel (1,temp);
  loadpcx (2,VGA);
  loaddat (3,lookup);
END;

Not too difficult? Now, this is still using the normal data files on your hard drive. You would then run PACK.EXE, select the program’s .exe as the base, then select “bob.bob”, “den.pcx” and “data.dat”, in order (1, 2, 3). Hit “c” to contine, and it will combine the files. Your programs .exe file will be able to run independently of the separate data files on disk, because the data files are imbedded with the .exe.

Let us take a closer look at the load procedures. Normally a load procedure would look as follows:

Procedure LoadData (name:string; p:pointer);
VAR f:file;
BEGIN
  assign (f,name);
  reset (f,1);
  blockread (f,p^,filesize(f);
  close (f);
END;

In FPack.pas, we do the following:

Function LoadData (num:integer; p:pointer):Boolean;
VAR f:file;
BEGIN
  If pack then BEGIN
    assign (f,paramstr(0));
    reset (f,1);
    seek (f,infopos[num]);
    blockread (f, p^, infopos[num+1]-infopos[num]);
    close (f);
  END else BEGIN
    assign (f,infodat[num]);
    reset (f,1);
    blockread (f, p^, filesize (f));
    close (f);
  END;
END;

As you can see, we just have two special cases depending on whether or not the .exe file has been packed yet.

NOTE: After you have packed the file, you CAN NOT pklite it. You can however pklite the .exe_before you run pack.exe … in other words, you cannot use pklite to try pack your data files.

PACK.EXE does have a limitation … you can only pack 24 data files together. If you would like it to do more, mail me … It should be easy to increase the number.

In the sample program, FINAL.EXE is the same as temp.pas, except it has its PCX embedded inside it. I ran pack2.exe, selected final.exe and eye.pcx, hit “C”, and there it was. You will notice that eye.pcx is not included in the directory … it is now part of the exe!

In closing

Well, that’s about it for this trainer… next one (as I have mentioned twice already ;) will be on assembler, with a flame routine thrown in.

This tut has been a bit of a departure from normal tuts … aside from the PCX loading routines, the rest has been “non programming” oriented … don’t worry, next week’s one will be back to normal.

Denthor/Asphyxia’s VGA trainers: Pixel morphing

2023-02-06T15:16:00+00:00

This trainer is on a few demo effects (pixel morphs and static).

DENTHOR, coder for ...
_____   _____   ____   __   __  ___  ___ ___  ___  __   _____
/  _  \ /  ___> |  _ \ |  |_|  | \  \/  / \  \/  / |  | /  _  \
|  _  | \___  \ |  __/ |   _   |  \    /   >    <  |  | |  _  |
\_/ \_/ <_____/ |__|   |__| |__|   |__|   /__/\__\ |__| \_/ \_/
smith9@batis.bis.und.ac.za
The great South African Demo Team! Contact us for info/code exchange!

Grant Smith, alias Denthor of Asphyxia, wrote up several articles on the creation of demo effects in the 90s. I reproduce them here, as they offer so much insight into the demo scene of the time.

These articles apply some formatting to Denthor's original ASCII files, plus a few typo fixes.

Pixel Morphing

Have you ever lain down on your back in the grass and looked up at the cloudy sky? If you have, you have probably seen the clouds move together and create wonderful shapes… that cloud plus that cloud together make a whale… a ship… a face etc.

We can’t quite outdo Mother Nature, but we can sure give it a shot. The effect I am going to show you is where various pixels at different starting points move together and create an overall picture.

The theory behind it is simple: each pixel has bits of data associated with it, most important of which is as follows:

This is my color
This is where I am
This is where I want to be.

The pixel, keeping its color, goes from where it is to where it wants to be. Our main problem is how it moves from where it is to where it wants to be. A obvious approach would be to say “If its destination is above it, decrement its y value, if the destination is to the left, decrement its x value and so on.”

This would be bad. The pixel would only ever move at set angles, as you can see below:

                Dest   O-----------------\
                                           \  <--- Path
                                             \
                                               \
                                                O Source

Doesn’t look very nice, does it? The pixels would also take different times to get to their destination, whereas we want them to reach their points at the same time, i.e.:

     Dest 1   O-------------------------------O Source 1
     Dest 2   O-----------------O Source 2

Pixels 1 and 2 must get to their destinations at the same time for the best effect. The way this is done by defining the number of frames or “hops” needed to get from source to destination. For example, we could tell pixel one it is allowed 64 hops to get to its destination, and the same for point 2, and they would both arrive at the same time, even though pixel 2 is closer.

The next question, it how do we move the pixels in a straight line? This is easier than you think…

Let us assume that for each pixel, x1,y1 is where it is, and x2,y2 is where it wants to be.

   (x2-x1) = The distance on the X axis between the two points
   (y2-y1) = The distance on the Y axis between the two points

If we do the following:

  dx := (x2-x1)/64;

we come out with a value in dx which is very useful. If we added dx to x1 64 times, the result would be x2! Let us check…

  dx = (x2-x1)/64
  dx*64 = x2-x1         { Multiply both sides by 64 }
  dx*64+x1 = x2         { Add x1 to both sides }

This is high school math stuff, and is pretty self explanatory. So what we have is the x movement for every frame that the pixel has to undergo. We find the y movement in the same manner.

  dy := (y2-y1)/64;

So our program is as follows:

  { Set x1,y1 and x2,y2 values }
  dx:= (x2-x1)/64;
  dy:= (y2-y1)/64;

  for loop1:=1 to 64 do BEGIN
    putpixel (x1,y1)
    wait;
    clear pixel (x1,y1);
    x1:=x1+dx;
    y1:=y1+dy;
  END;

If there was a compiler that could use the above pseudocode, it would move the pixel from x1,y1 to x2,y2 in 64 steps.

So, what we do is set up an array of many pixels with this information, and move them all at once… voilá, we have pixel morphing! It is usually best to use a bitmap which defines the color and destination of the pixels, then randomly scatter them around the screen.

Why not use pixel morphing on a base object in 3d? It would be the work of a moment to add in a Z axis to the above.

The sample program uses fixed point math in order to achieve high speeds, but it is basically the above algorithm.

Static

A static screen was one of the first effects Asphyxia ever did. We never actually released it because we couldn’t find anywhere it would fit. Maybe you can.

The easiest way to get a screen of static is to tune your TV into an unused station … you even get the cool noise effect too. Those people who build TVs really know how to code ;-)

For us on a PC however, it is not as easy to generate a screen full of static (unless you desperately need a new monitor)

What we do is this:

Set colors 1-16 to various shades of grey.
Fill the screen up with random pixels between colors 1 and 16
Rotate the palette of colors 1 to 16.

That’s it! You have a screenful of static! To get two images in one static screen, all you need to do is fade up/down the specific colors you are using for static in one of the images.

A nice thing about a static screen is that it is just palette rotations … you can do lots of things in the foreground at the same time (such as a scroller).

In closing

Well, that is about it … as I say, I will be doing more theory stuff in future, as individual demo effects can be thought up if you know the base stuff.

Note the putpixel in this GFX3.PAS unit … it is very fast .. but remember, just calling a procedure eats clock ticks… so embed putpixels in your code if you need them. Most of the time a putpixel is not needed though.

Denthor/Asphyxia’s VGA trainers: Bitmap scaling

2023-02-06T15:06:00+00:00

This trainer is on the scaling of an arbitrary sized bitmap to screen in two dimensions. The sample program seems to work quite quickly, and the code is documented. The scaling procedure is however totally in assembler… hopefully this won’t cause too many problems.

DENTHOR, coder for ...
_____   _____   ____   __   __  ___  ___ ___  ___  __   _____
/  _  \ /  ___> |  _ \ |  |_|  | \  \/  / \  \/  / |  | /  _  \
|  _  | \___  \ |  __/ |   _   |  \    /   >    <  |  | |  _  |
\_/ \_/ <_____/ |__|   |__| |__|   |__|   /__/\__\ |__| \_/ \_/
smith9@batis.bis.und.ac.za
The great South African Demo Team! Contact us for info/code exchange!

Grant Smith, alias Denthor of Asphyxia, wrote up several articles on the creation of demo effects in the 90s. I reproduce them here, as they offer so much insight into the demo scene of the time.

These articles apply some formatting to Denthor's original ASCII files, plus a few typo fixes.

What is scaling?

I think that most of you know this one already, but here goes. Let us say you have a picture (10x10 pixels) and you want to draw it to a different size (say 5x7 pixel), the process of altering the picture to fit into the new size is called scaling. Scaling only works on rectangular areas.

With scaling to can easily stretch and shrink your bitmaps.

Okay, so how do we code it?

Right. The way I am going to do scaling is as follows:

For the horizontal area, I am going to calculate a certain step value. I will then trace along the bitmap, adding this step to my position, and place the nearest pixel on to the screen. Let me explain this simpler…

Let us say I have a 10 pixel wide bitmap. I want to squish it into 5 pixels. Along the bitmap, I would draw every second pixel to screen. In ASCII:

  1234567890   13579
  +--------+   +---+
  |        |   |   |
  | bitmap |   |   |dest
  |        |   |   |
  +--------+   +---+

As you can see, by stepping through every second pixel, I have shrunk the bitmap to a width of 5 pixels.

The equation is as follows:

step = origionalwidth / wantedwidth;

Let us say we have a 100 pixel wide bitmap, which we want to get to 20 pixels.

step = 100 / 20
step = 5

If we draw every fifth pixel from the original bitmap, we have scaled it down correctly! This also works for all values, if step is of type real.

We also find the step for the height in the same way.

Our horizontal loop is as follows:

       For loop1:=1 to wantedwidth do BEGIN
         putpixel (loop1,height,bitmap[round (curpos)],vga);
         curpos:=curpos+xstep;
       END;

And the vertical loop is much the same. Easy huh? So east in fact, I wrote the procedure in pure assembler for you ;-) … don’t worry, it’s commented.

In the sample program, instead of using reals I have used fixed point math. Refer to Part 14 if you have any hassles with fixed point, it is fairly straightforward.

I also use psuedo 3-d perspective transforms to get the positions smooth… after Part 8, this should be a breeze.

There are no new commands in the assembler for you, so you should get by with what you learned in tut7/8 … whew! A lot of back referencing there ;) We really are building on our knowledge :)

In closing

Well, that is about it. As you can see the concept is easy, and in fact fairly obvious, but that didn’t stop me from having to sit down with a pencil and a piece of paper a few months ago and puzzle it out ;-)

Denthor/Asphyxia’s VGA trainers: Plasmas

2023-02-06T15:06:00+00:00

Plasmas are a great way to wow your friends by their weird shapes and forms. I was at one stage going to write a game where the bad guy just had two circular plasmas instead of eyes… I am sure you will find creative and inventive new ways of doing and using plasmas.

DENTHOR, coder for ...
_____   _____   ____   __   __  ___  ___ ___  ___  __   _____
/  _  \ /  ___> |  _ \ |  |_|  | \  \/  / \  \/  / |  | /  _  \
|  _  | \___  \ |  __/ |   _   |  \    /   >    <  |  | |  _  |
\_/ \_/ <_____/ |__|   |__| |__|   |__|   /__/\__\ |__| \_/ \_/
smith9@batis.bis.und.ac.za
The great South African Demo Team! Contact us for info/code exchange!

Grant Smith, alias Denthor of Asphyxia, wrote up several articles on the creation of demo effects in the 90s. I reproduce them here, as they offer so much insight into the demo scene of the time.

These articles apply some formatting to Denthor's original ASCII files, plus a few typo fixes.

How do plasmas work?

I will only cover one type of plasma here: a realtime plasma of course. Other types of plasmas include a static picture with a pallette rotation.

When you get right down to it, this method of realtime plasmas is merely an intersection of four COS waves. We get our color at a particular point by saying:

 
      col := costbl[one]+costbl[two]+costbl[three]+costbl[four];

The trick is getting the four indexes of that cos table array to create something that looks nice. This is how we organize it: have two of them being indexes for vertical movement and two of them being indexes for horizontal movement.

This means that by changing these values we can move along the plasma. To draw an individual screen, we pass the values of the four to another four so that we do not disturb the original values. For every pixel across, we add values to the first two indexes, then display the next pixel. For every row down, we add values to the second two indexes. Sound complex enough? Good, because that what we want, a complex shape on the screen.

By altering the original four values, we can get all sorts of cool movement and cycling of the plasma. The reason we use a cos table is as follows: a cos table has a nice curve in the value of the numbers… when you put two or more together, it is possible to get circular pictures… circles are hard to do on a computer, so this makes it a lot easier…

Okay, now you can have a look at the source file, all I do is put the above into practice. I did add one or two things though…

Background: This is just a large array, with the values in the array being added to the plasma at that pixel.

Psychedelic: This cycles through about 7000 colors instead of just rotating through the base 256.

Clever fading

You will notice when the sample program fades in and out that the colors all reach their destination at the same time … in other words, they don’t all increment by one until they hit the right color then stop. When done in that way the fading does not look as professional.

Here is how we do a step-crossfade:

Each r,g,b value can be between 0 and 64. Have the palette we want to get to in bob and the temporary pallette in bob2. For each step, from 0 to 63 do the following:

 
     bob2[loop1].r:=bob[loop1].r*step/64;

That means if we are halfway through the crossfade (step=32) and the red value is meant to get to 16, our equation looks like this:

 
    r:=16*32/64
     r=8

Which is half of the way to where it wants to be. This means all colors will fade in/out with the same ratios… and look nicer.

Rotating the pallette

I have done this one before, I think. Here it is:

 
move color 0 into temp

move color 1 into color 0
move color 2 into color 1
move color 3 into color 2
and so on till color 255

move temp into color 255

And your palette is rotating. Easy huh? Recheck Part 2 for more info on palette rotation.

In closing

The tutorial was a bit short this time, but that is mostly because the sample file is self-explanatory. The file can however be speeded up, and of course you can add certain things which will totally change the look of the plasma.

Denthor/Asphyxia’s VGA trainers: Glenzing, Faster polygons, fixed-point math

2023-02-06T14:56:09+00:00

Well, this trainer is mainly on four things: glenzing, faster polygons, fixed-point math and assembler. The sample program is basically Part 9 rewritten to include the above. I’ll go through them in order, and hopefully you won’t have any hassles grasping the concepts.

DENTHOR, coder for ...
_____   _____   ____   __   __  ___  ___ ___  ___  __   _____
/  _  \ /  ___> |  _ \ |  |_|  | \  \/  / \  \/  / |  | /  _  \
|  _  | \___  \ |  __/ |   _   |  \    /   >    <  |  | |  _  |
\_/ \_/ <_____/ |__|   |__| |__|   |__|   /__/\__\ |__| \_/ \_/
smith9@batis.bis.und.ac.za
The great South African Demo Team! Contact us for info/code exchange!

Grant Smith, alias Denthor of Asphyxia, wrote up several articles on the creation of demo effects in the 90s. I reproduce them here, as they offer so much insight into the demo scene of the time.

These articles apply some formatting to Denthor's original ASCII files, plus a few typo fixes.

What is glenzing?

This is an easy one. Imagine, in a 3D object, that all the sides are made out of colored glass. That means that every time you look through a side, everything behind it is tinged in a certain color.

In ASCII:

          +---------+
          |      <--|---Light blue
          |         |
     +--------+     |
     |    | <-|-----|---Dark blue
     |    +---|-----+
     |     <--|---------Light blue
     +--------+

So where the two sides overlap, the color values of the two sides are added. Easy huh? It is also easy to code. This is how you do it:

Set up your palette to be a nice run of colors.
Draw your first poly.
While drawing poly 1, instead of plonking down a set pixel color, grab the background pixel, add 1 to it, then put the result down.
Draw your second poly.
While drawing poly 2, instead of plonking down a set pixel color, grab the background pixel, add 2 to it, then put the result down.
and so forth.

So if the color behind poly 1 was 5, you would place pixel 6 down instead.

If you do this for every single pixel of every single side of your 3D object, you then have glenzing going. This is obviously slightly slower than just drawing an item straight, but in the sample program it goes quite quickly. This is because of the following sections.

Faster polygons

In Part 9, you probably noticed that we were using a multiply for every single line of the poly that we drew. This is not good. Let’s find out how to speed it up, shall we?

With the multiply method, we went through every line, to find out the minimum x and maximum x value for that line.

                           +
                   ------/---\------- Find min x and max x, draw a line
                       /       \        between them.
                     +           +
                       \       /
                         \   /
                           +

How about if we found out all the min and max x’s for every line first, then just went through an array drawing them. We could do it by “scanning” each side in turn. Here is how we do it:

We go from point one to point two. For every single y we go down, we move a constant x value. This value is found like this:

xchange := (x1-x2)/(y1-y2)

Remember gradients? This is how you calculated the slope of a line waaay back in school. You never thought it would be any use, didn’t you?

Anyway, with this value, we can do the following:

    For loop1:=y1 to y2 do BEGIN
      [ Put clever stuff here ]
      x:=x+xchange;
    END;

and we will go through all the x-values we need for that line. Clever, huh?

Now for the clever bit. You have an array, from 0 to 199 (which is all the possible y-values your onscreen poly can have). Inside this is two values, which will be your min x and your max x. You start off with the min x being a huge number, and the max x being a low number. Then you scan a side. For each y, check to see if one of the following has happened:

If the x value is smaller than the xmin value in your array, make the xmin value equal to the x value
If the x value is larger than the xmax value in your array, make the xmax value equal to the x value

The loop now looks like this:

    For loop1:=y1 to y2 do BEGIN
      if x>poly[loop1,1] then poly[loop1,1]:=x;
      if x<poly[loop1,1] then poly[loop1,1]:=x;
      x:=x+xchange;
    END;

Easy? Do this for all four sides (you can change this for polys with different numbers of sides), and then you have all the x min and x max values you need to draw your polygon.

In the sample program, if you replaced the Hline procedure with one that draws solid lines, you could use the given drawpoly for solids.

Even this procedure is sped up by the next section, on fixed point.

What is fixed point?

Have you ever noticed how slow reals are? I mean slooooow. You can get a massive speed increase in most programs by replacing your reals with integers, words etc. But, I hear you cry, what happens to the much needed fraction bit after the decimal point? The answer? You keep it. Here’s how.

Let us say you have a word, which is 16 bits. If you want to use it as a fixed point value, you can separate it into 2 sections, one of which holds the whole value, and one which holds the fraction.

00000000  00000000   <-Bits
Whole     Fraction

The number 6.5 would therefore be shown as follows:

 
Top byte    :  6
Bottom byte :  128

128 is half (or .5) of 256, and in the case of the fraction section, 256 would equal one whole number.

So let us say we had 6.5 * 2. Using reals this would be a slow mul, but with fixed point …

 
Top Byte    :  6     
Bottom Byte :  128
Value       :  1664   <-This is the true value of the word
                         ie. (top byte*256)+bottom byte).
                         this is how the computer sees the 
                         word.
 1664 shl 1 = 3328    <-shl 1 is the same as *2, just faster.
Top byte    :  13
Bottom byte :  0

As you can see, we got the correct result! And in a fraction of the time that a multiplication of a real would have taken us. You can add and subtract fixed point values with no hassles, and multiply and divide them by normal values too. When you need the whole value section, you can just read the high byte, or do the following:

 
             whole = word shr 8
         eg  1664 shr 8 = 6

As you can see, the fraction is truncated. Obviously, the more bits you set aside for the fraction section, the more accurate your calculation is, but the lesser the maximum whole number you can have. For example, in the above numbers, the maximum value of your whole number was 256, a far cry from the 65,535 a normal (non fixed point) word’s maximum.

There are a lot of hassles using fixed point (go on, try shift a negative value), most of which have to do with the fact that you have severely decreased the maximum number you may have, but trust me, the speed increase is worth it (With long integers, and/or extended 386 registers, you can even have 16x16 fixed point, which means high accuracy and high maximum values)

Try write a program using fixed point. It is not difficult and you will get it perfect easily. Trust me, I’m a democoder ;-)

Assembler

In the sample program I used one or two assembler commands that I havent discussed with you. Here they are:

 
  imul  value           This is the same as mul, but for integer values. It
                        multiplies ax by the value. If the value is a word,
                        it returns the result in DX:AX

  sal  register,value   This is the same as shl, but it is arithmetic,
                        in other words it works on integers. If you
                        had to shl a negative value, the result would
                        mean nothing to you.

  rcl  register,value   This is the same as shl, but after you have
                        shifted, the value in the carry flag is placed
                        in the now-vacated rightmost bit. The carry
                        flag is set when you do an operation where the
                        result is greater than the upmost possible
                        value of the variable (usually 65535 or 32767)
                        eg mov ax,64000
                             shl ax,1     {<- Carry flag now = 1}

For more info on shifting etc, re-read Part 7, it goes into the concept in detail.

The sample program is basically Part 9 rewritten. To see how the assembler stuff is working, do the following … Go into 50 line mode (-Much- easier to debug), then hit [Alt - D] then R. A little box with all your registers, segments etc and their values will pop up. Move it down to where you want it, then go back to the program screen (Hit Alt and its number together), and resize it so that you have both it and the register box onscreen at once (Alt - 5 to resize) … then use F4, F7 and F8 to trace though the program (you know how). The current value of the registers will always be in that box.

In closing

Well, that is about it. The sample program may start as being a little intimidating to some when they first look at it, just remember to read it with Part 9, very little is different, it’s just with fixed point and a bit of assembler.