while fixing the hint oracle for me on the PPC I tried out CSBwin (out from the Part I-III *.rar package of Conflux III) and thought: "uuhh... it looks so much better on the PPC just because of the pixelsize, why is there no antialiasing mode in CSBwin?" And back to my mind came a long lost thought about making the 320 x 200 look nicer on a modern Desktop PC with those modern LCD Flatscreens without exccesive use of an complex anti-aliasing algorithm.
Please keep in mind, that I'm not a computer geek, so my thoughts may seem childish.
Lets say you would like to increase the resolution to 1280 x 800 pixels. Streching the original 'dotpile' without enlarging the pixels to ugly squares (the old TV attached to the Atari would just use every second line and displayed a pixel as a dot rather than a square) would result in something looking like that:
(it is needed to copy/paste the ASCII 'art' into an Editor with fixed spacing!)
o___o___o___o___o___o
_____________________
_____________________
_____________________
o___o___o___o___o___o
_____________________
_____________________
_____________________
o___o___o___o___o___o
_____________________
_____________________
_____________________
o___o___o___o___o___o
(o = Pixel)
Giving all of the 64000 pixies a name and and adressing their new x/y position, then drawing 4 lines (N E S W) between all dots interpoling the color difference on each pixel of the added lines would result in:
o---o---o---o---o---o
|___|___|___|___|___|
|___|___|___|___|___|
|___|___|___|___|___|
o---o---o---o---o---o
|___|___|___|___|___|
|___|___|___|___|___|
|___|___|___|___|___|
o---o---o---o---o---o
|___|___|___|___|___|
|___|___|___|___|___|
|___|___|___|___|___|
o---o---o---o---o---o
Between 4 pixels, there will be 9 black pixels left:
(for 960 x 600 it would be 4, for 640 x 400 it would be 1)
___
___
___
Using openGLs option to drag a nicely interpoled color-rectancle with 4 dots + their colorinformation would of course have saved you from drawing the lines at all, but in any case the dungeon (grey) would optically 'melt' with for example a monster, producing the look of early *.jpg images.
Lets still stick to the lines, additionally connecting all the dots diagonally:
o---o---o---o---o---o
|\_/|\_/|\_/|\_/|\_/|
|_X_|_X_|_X_|_X_|_X_|
|/_\|/_\|/_\|/_\|/_\|
o---o---o---o---o---o
|\_/|\_/|\_/|\_/|\_/|
|_X_|_X_|_X_|_X_|_X_|
|/_\|/_\|/_\|/_\|/_\|
o---o---o---o---o---o
|\_/|\_/|\_/|\_/|\_/|
|_X_|_X_|_X_|_X_|_X_|
|/_\|/_\|/_\|/_\|/_\|
o---o---o---o---o---o
leaving 4 free (unpainted black) pixels _in_ every square, replacing the 2 pixels at the beginning and end of a line with black ones + interpol the overlapped diagonal lines (dot in the middle of a square) would result:
from:
o---o
|\_/|
|_X_|
|/_\|
o---o
to:
o_o_o
_o_o_
o_o_o
_o_o_
o_o_o
This would produce an ST-like look (ok - without killing every second line), buts still the 'melting effect' dungeon<->monster is there of course. (Again it would have been much easier creating the same result drawing the colored interpol-rectancle in openGL, then blacken every second pixel)
To eliminate the melting or at least make it look smoother it has to be judged if a line is drawn or not.
And this is where it starts to get complicated.
First thought was to detect large color differences (--> return null to draw_interpolline)
or (if possible) detect the mask of the monster/decal so it can be directly judged which pixel belongs to the dungeon and which one belongs to the object in the dungeon. (avoiding: gray pixel from golem = gray pixel from dungeon)
Assuming this or any way of drawing a virtual mask around the monster, decal, etc. using the lines that surround each orig pixel would work, doing it blindly could result in:
D___D___D___D___D___M
|\_/|\_/|\_/|\_/___/|
|_X_|_X_|_X_|_/___/_|
|/_\|/_\|/_\|/___/__|
D___D___D___D___M___M
|\_/|\_/|\_/___/|\_/|
|_X_|_X_|_/___/_|_X_|
|/_\|/_\|/___/__|/_\|
D___D___D___M___M___M
|\_/|\_/|___|\_/|\_/|
|_X_|_X_|___|_X_|_X_|
|/_\|/_\|___|/_\|/_\|
D___D___D___M___M___M
(D = Dungeon)
(M = monster, decal, etc)
Between the monster and the dungeon a black line made of staight horizontal/vertical and 45° diagonal lines will appear, likely looking ugly.
Approaching the screen as it pops out of CSBwin or doing the smootening before dungeon and monster/items/decals marry surely makes a difference, avoiding the black line, but keeping the mentioned step-like look on the standalone dungeon, monster, etc. plus having to dig into the code before the dungeon is put together. Also the dungeon frame has to done in another way than the ingame menu (spells/wepons/chars), but let's say the screen is threatend as a whole and not seperately - used as an addon for CSBwin.
Maybe you code-wizard can hack in a nice routine withhin 30 minutes. I can't judge it, I'm a lame coder. Avoiding the 90°/45° step-look from dungeon to item and viaversa surly is the hardest part, maybe even with the need to vectorice the grafic using the 'extended' pixels of a monster as hooks for drawing the connecting line, avoiding 45° steps.
What existing tools could be used to make the original DM grafix look better?
Maybe its enough to just increase the resoltion to 800x600, then forcing the grafic card to antialiase the window for an satisfiing result, I haven't tried yet. Maybe a better approach would be to try to emulate/recreate the Atari screen output as mentioned above. I remember the ST emulator PacifiST did this quit nicely without ressorce eating calculations from the graca.
greetings
T0Mi
/mophus.png)
