Contents:
What the hell is 4x4 Texture Designer?
Quick tips
C64 viewer
File types
Miscellaneous
What the hell is 4x4 Texture Designer?
This is a crossdevelopment tool that will allow you to create textures for the well-known 4x4 mode on Commodore 64. This program can handle textures with maximum size of 74 x 50 texels (which is the maximum number of pixels in this mode). This means that you can also draw a full-screen 4x4 picture. :-P These textures can be converted to C64 by a few clicks. :) There's a built-in viewer that will allow you to immediately see the texture on C64. Check the file types section for more information on how to use the texture in your demos. Note that you'll need at least DirectX 7 to run it.
The proggy is quite simple to use. Upon start, you'll see a menu bar at the left and a palette at the bottom of the screen. You draw the texels in the matrix placed at the center of the screen. Have in mind that you can use two colors at the same time (one for the left and one for the right mouse button). When clicking a color in the palette, it _is_ important which mouse button you'll click. The currently selected colors are shown at the left of the palette. The right of the palette shows you the X and Y positions of the mouse. The coordinates are, of course, counted from 0. There're seven items in the menu: New, Load, Save, Convert, Preview, Undo, and Exit. All these are pretty straightforward. There're a few things to have in mind. The maximum length for the filenames is 13 characters. _Never_ write extensions in this program's dialogs. All letters, numbers, and underline (_) are allowed. Make sure you save your textures using 'Save' and convert them after they are ready to hit the C64. This is important because converted textures _cannot_ be loaded back into the editor anymore. When converting, two files will be created: a raw texture and a file with attached viewer that will be ready to be run on C64 or an emulator. You'll be asked to select the last (lower-right) texel in your texture. Note that this information is only used for the raw texture. The preview contains the whole screen. Another thing to note is that there's _only one_ undo buffer.
To make your life easier, the source of the C64 viewer used
here is also released. It requires ACME to assemble, so grab ACME here
if you haven't already done that. :) A description of the 4x4 mode follows:
one pixel of this mode is consisted of 4x4 hires pixels (thus the name of
the mode. :)) Although the pixels look ugly, there're two reasons people have
used this mode:
1. Each pixel (I'm referring to the 4x4, not the hires pixel) can have its
own color (unlike e.g. a multicolor bitmap where every pixel inside a char-block
can have one of the three colors specified for the block).
2. To change the color of a pixel, you only need to write one byte and you
don't set the color for every hires pixel inside the 4x4 pixel. Have in mind
that a byte contains color for two pixels. It's important to use the correct
nibble and not to disturb the other.
The mode is based on FLI (Flexible Line Interpretation). The main difference
is that you don't create a badline at each rasterline, but each 4th rasterline.
It's _very_ important to have in mind that each 2nd badline starting with
the very first needs to be created before cycle 14. The badlines between have
to be created _exactly_ at cycle 14. I won't explain the reason it has to
be this way, but if you'd like to know, contact
me. So what's the real idea? You create a bitmap containing vertical bars,
which are 4 hires pixels wide. This can be achieved both in hires and multicolor
mode. I'll use hires because the viewer uses it. :) So you fill the bitmap
with $F0 bytes (you can also use $0F, but the first case makes more sense.
:)) As you can see, every block of 4x8 pixels can have its own color. But
how do we make it 4x4? Here's where FLI comes into view. As you'll create
a badline each 4th rasterline, the video chip will read new color data. You'll
need to switch to another video bank to make it read new colors. So the lower
part of the 4x8 blocks will have another two colors. If you think for a second,
you'll realize that we have achieved the 4x4 mode. :) You have probably realized
that two video banks are needed (only one bitmap of course). So what's the
organization of the pixels in memory? As already mentioned, each byte holds
two colors. The high nibble contains the color for the pixel on the left,
and the low nibble contains the color for the pixel on the right. The very
first byte contains colors for the two top-left pixels. The next byte contains
colors for the two pixels on the right. There're 40 bytes per row. Here's
how the rows are organized:
- Row 1 on screen: row 1 of video bank 1
- Row 2 on screen: row 1 of video bank 2
- Row 3 on screen: row 2 of video bank 1
- Row 4 on screen: row 2 of video bank 2
- Row 5 on screen: row 3 of video bank 1
- Row 6 on screen: row 3 of video bank 2
Get the idea? :) Well, ok you don't actually have 40 usable bytes per row. Note that the first 3 bytes (6 pixels) of each row are covered with the FLI bug! Since the video memory is now used for colors, this area will be covered with grey. You can easily remove this if you use multicolor mode. The included viewer uses hires, thus it has to cover this area with sprites! If you wanted to cover this area with graphics, you'd have to use sprites no matter if you use hires or multicolor. Here're a few things to be aware of: different sprites act differently on the timing. Sprites 0-2 are ok to be used, so you'll need to multiplex them. This may make some trouble as the multiplexing will make differences to the timing. Or you can use 5 vertically stretched sprites, but you'll need to change the timing at the 4th sprite. The included viewer uses multiplexing.
This program uses 3 different file types: DES, DAT, and PRG. There's not much to say about the PRG. It is a C64 program that can be run in emulators, or be transferred to the real thing. The editor will save the runable preview with PRG extension. The DES file contains a texture that _can_ be loaded back into the editor. The length of these files is 1850 bytes (74*50/2). Each byte contains two pixels, thus the division by 2. :) The DAT file contains a texture (with the size you've specified when converting), which can be used in your demo. Note that there's _no_ start address in the file. Each byte contains only one color (one pixel) for easier manipulation in your texture mapper. :) The data is organized into rows. Each row contains X bytes (where X denotes the width of the texture in 4x4 pixels). As you might have noticed, the size of the file is variable. It's calculated like this: Filesize = texture_width * texture_height
This section contains unimportant crap. Feel free to skip it. Note that skipping this section means clicking close as this is the last one. :) All the graphics (except for the mouse cursor and the application icon) was drawn by me (Cybernator) using.... Erm.... Don't ask. :-P If you are able to create your effect without using 4x4 mode, please don't use it. 4x4 looks ugly. :-P This program was meant to be done on C64 at first. However, it is a PC program now because I wanted to practice DirectX programming, and this was the most appropriate program as you'll rarely use 4x4.
Greetings to: Oxyron, Covert BitOps, Role, Crest, Creators, Dekadence, Byterapers, People of Liberty, Spiders Crew, Booze Design, Cosine, TND, WOW, and all da dudez that keep this scene alive.
Till da end of da world ....
.... Commodore !