I remember the year 1998 when I bought my first computer (or… when my parents bought me my first computer)… It was an Intel Celeron PC clocked at 366MHz, 64kb L2 cache, with a 4mb Trident 3D Accelerator and 32mb of RAM operating at a frequency of 100MHz. The HDD was 4.3 gigs.

Today, Its a totally different story. I have a Dual Core processor clocked at a speed of 3600MHz, with 6144kb L2 cache. The 3D card has GDDR3 memory of size 896mb. The RAM is 4096mb and operated at almost 1000MHz. The HDD is 500 gigs.

Point is, times have changed. The world of computers is advancing at a breathtaking pace. New processor architectures are unveiled almost every couple of years. In the same way, 3D graphic cards are also getting faster and powerful by the day. The mainstream cards of today are able to process teraflops of data without breaking sweat.

Now suppose you own a GTX 260 and you see an old game that you want to play. By old, I don’t mean Doom 2 old. I’m talking about games from this decade. For this tutorial, I’ll be using the game Cricket Revolution as an example. Although a new game, Cricket Revolution’s graphical requirements are very modest. The game runs fine on most 3D cards, and even on the built-in Intel chipset accelerators. Now if you run this game on a GTX 260, you are wasting a lot of graphical power! Well… Why not apply anti-aliasing to the game? Why not force anisotropic filtering? We’ll do just that.

This tutorial is for NVIDIA cards only. You can do this with ATI cards as well, but since I currently use NVIDIA, I can only assist NVIDIA users.

1- Open the NVIDIA  Control Panel.

2- In the left pane, click Manage 3D Settings.

3- Click Add and point the browser to your game executable (.exe).

4- Once your game appears in the drop-down list, select it. Now comes the important part. Applying settings.

5- In the field next to Anisotropic Filtering, select 16x.

6- In the field next to Anti-aliasing Mode, select Override any Application setting.

7- In the field Anti-aliasing Setting, select 16xQ.

8- Click Apply.

That is it! You’re done. Now, when you run your game, it will have proper AA (anti-aliasing) and AF (anisotropic filtering). The difference it makes in Cricket Revolution can be seen below:

Cricket Revolution WITHOUT AA/AF

Cricket Revolution WITH AA/AF

As you can see, the edges of the second images are much more smooth compared the first one.

Try this on other games and see if it improves your gaming experience!

(This is going to get technical. Fast.)

I’m a big fan of deferred rendering as you might have gathered from my GDC 09 talk. So it made sense that for Frameranger, and subsequent projects, I moved my demo engine over from what was essentially a forward renderer to a complete deferred renderer. I wanted to share some of the experience here. There are some good introductions to deferred rendering out there, like this one, which cover the basics so I don’t have to.

Note, I’m working on DX9 – DX10 wasn’t an option at the time of development (and still isn’t, really, until the supporting OSes take the vast majority of the market) – so that adjusts my available feature set. No depth buffer reads, no hardware MSAA.

So, why go deferred?

• Only need one geometry pass for the main render. Previously we usually needed a z prepass for performance, and sometimes even another separate pass for motion blur velocities and for depths for SSAO and other effects. For some of the stuff we had to render which was very high poly or had a lot of draw calls, or where it wasn’t polygons at all, only having to do them once is important. (Shadows still always cost extra, though.)
• Separate rasterisation and shading. Not having to worry about lighting and so on at the geometry stage means that the geometry stage becomes simple, and most geometry shares one shader – we don’t need so many combinations of ubershader anymore. Combined with the reduced number of geometry passes it means we can reduce our batch count, amount of state changes and number of shaders we have to generate by a lot.
• Lighting as a 2D post process. Apply as many lights as you want, efficiently, and without having to build many uber shader combinations. As many lights as we want, as many types of lights as we want, mixing shadowed and unshadowed, potentially handling 1000s of lights.
• Spatially optimise lighting and complex shading. Only apply light to the pixels which are actually in the light’s area of effect.
• Only shade pixels with complex lighting shaders once (per light) – less issues with overdraw from geometry rendering.
• Use the additional GBuffer information to do some more interesting post fx and rendering.

So there were a lot of things we wanted a piece of. Unfortunately there are some major downsides too, which is why I hadn’t gone down this road before:

• No hardware antialiasing (on DX9). For me this had been the killer up to now. I don’t like unantialised renders. This time around though the benefits were so big that I decided to just screw it and worry about antialiasing later.
• Overhead of memory use – we need to store those fat-ass GBuffers somewhere – and rendering. It smooths out the render performance with all the pretty fixed overheads – which makes the complex cases faster (or work at all), but the simple cases are potentially a lot slower. I decided our general case is complex enough not to care about the simple cases.
• Potentially reduced material flexibility. We can’t just hack a shader which computes some lighting and messes with the equations for that one material – we have to do everything en-masse in 2D processes.
• Alpha stuff still has to be handled in a second, forward rendered pass. Which means we still need a working forward renderer.

So, I managed to sufficiently minimise in my head how much I cared about the downsides and just crack on and implement the deferred renderer to see what happened. It was actually very easy to do – a day or two’s work had the whole thing up and running with multiple types of light working. Then there were weeks or months of work in adding all the interesting stuff on top.

The first task was to get the geometry rendered to GBuffers. When rendering the GBuffers it’s important to minimise the number of channels and the bit depth required – the greater it is, the more memory and slower the render is. You also have to consider how you want to read the data – you probably don’t need the colour info until late in the day, whereas the normals are needed a lot – so don’t pack something you need a lot with the colours, because it’ll be a wasted additional GBuffer read.
I used 3 or 4 MRTs for my GBuffer rendering, depending on whether or not motion blur was enabled, where each MRT was 32 bits wide. The channels I rendered to GBuffers were:

Colour+ObjectIndex : RGBA8888;
Normal+MaterialIndex : RGBA8888;
Depth : Float32
VelocityBuffer (optional – only if motion blur enabled) : RG Float16
and of course a D24S8 depthstencil. Which I cant read from, because DX9 doesnt allow it. How annoying. If I could I could skip that float32 depth, like I would on PS3. But I can’t. Damnit. Actually it works on ATI, so it’s just NVIDIA that’s the problem. Dear NVIDIA: you guys managed to hack in almost every other feature under the sun using 4CCs and other tricks, so how about adding depth buffer value reads for DX9, and multisampled buffer reads while you’re there? Go on – I bet it’s there in the drivers already, and I just don’t know what the magic incantation is to access it.

One thing that comes up a lot when discussing deferred renderers is the storage of normals. Nearaz has a really good summary / investigation of the different methods. I’m lazy, so initially I just wrote out the normal as an XYZ, deciding that if I ever needed an extra GBuffer channel I’d fix it and use XY in a compacted form and recreate Z. So far I didn’t.

Next I added the basic light types. It’s pretty easy to move the lighting code over from a forward render – it just needed the extra code to pull the values out of the GBuffers and back project to recreate positions, rather than pull everything out of the vertex interpolators.
Spot lights were trivial, of course. A single projected shadow map did the job. Point lights proved annoying because of another D3D limitation – I couldn’t create a depth stencil cubemap, and I wanted to render to a depth stencil for efficiency on render and for free hardware PCF – so I ended up making a “virtual cube map” which spread the faces out on a 2D texture. Finally, for directional lights I implemented a varying number of cascaded shadow maps. Directionals proved to be by far the most used light type, and I put some work into making it calculate a good set of shadows for the splits.

The nice trick with a deferred renderer is that I can apply the splits separately to the screen in 2D, rather than sampling all of them per pixel. I first render a series of view-aligned planes at the depth of each split, front to back, into the depth+stencil, marking the stencil where they pass the depth test. This gives me a series of stencil masks that I can use to test against when rendering full screen quads, one per split, which sample just that one split’s shadow map each.

The initial work of adding the lighting was quite easy, but it instantly proved the benefits of deferred shading. Previously, just adding a new type of light, changing lighting code or adding more influencing lights cost work – a new shader code path which had to be propogated through the ubershaders – increasing the compile time every time – and then into the code to select the ubershaders. There was a hard limit on the complexity of each light and the number of lights, because of the hard limit on the size of shaders and, more pressingly, the number of textures that could be used at once. But now it was simply a case of adding another 2D pass, and a single piece of shader code which could be edited and reloaded over and over again easily. I had never bothered to add all the different light types or cascading shadow map support to my forward renderer because it required too many permutations and too many simultaneous textures, but now I had it all working easily, and finally could handle shadows well from massive scenes with directional lights. Adding deferred rendering had already paid off.

Now, what about those classic problems with deferred rendering?

Flexibility

The next issue was that of flexibility – how to get materials that look different to each other. With forward renders it’s easy – you just make a different shader for the material, and change the behaviour of that material. But with deferred renderers it doesn’t work like that – everything is done in a series of 2D passes on the whole screen. So, you have to render extra information into the GBuffers which tell those passes how to produce the correct behaviour for each pixel. Unfortunately GBuffers get fat fast if you add a lot of parameters. Most of our parameters varied per material, so I simply created a material palette as I was rendering the objects of all the unique materials, and wrote two indices to the GBuffers – the object index, and the material index. Both limited to 256 indices (lists updated per frame). Bad news? Well, if we had that many draw calls we’d be screwed performance-wise anyway, so a 256 material+object limit didn’t matter.

As development continued, the data in our material palette grew and grew. By the end it was several textures worth – with data for fresnel coefficients, how to apply envmaps, various light equation constant modifiers, and so on. It enabled us to easily adjust the material parameters without adding a lot to our GBuffers. I’ve heard it said that this doesn’t work – because you want to vary a lot per pixel, like specular gloss, specular power, and so on, and this doesn’t allow it. I’ve also heard that you need lots of different shaders to get a good look. Well, it was never the case for us. Probably 90% of our geometry always went through the same default shader; we didn’t adjust that much per pixel in textures except where it was really needed – it added a lot more work to the art side as well as more space requirements.

Another useful thing about the material palette came to light later on when optimising the renderer to reduce draw call counts. The only remaining per-material parameters that were used when rendering the mesh were the textures and the material index – everything else was in the material palette. That meant that it was easy to merge meshes together and store a palette index in a vertex buffer channel I didn’t need (I used vertex colour alpha). This meant I could pack the meshes down completely except where the textures differed, but still allow on-the-fly editing of the separate material properties. In addition I could actually change the material index per pixel if I wanted – e.g. using a mask texture to select between two materials – with very little overhead. This exposed a whole new set of tricks and went some way to solving the problem of not being able to vary material properties using textures.

Besides that, where we did need something special there were a few tricks we could use when applying shading in the deferred passes. The material ID + object ID could be used to mask in whole special materials for certain objects (or parts of objects). For example, the car had a special paint shader that was masked in. Each material palette entry had a world-space bound box which was accumulated for all the objects which used it per frame; this was used to generate accurate-enough masks for 2D passes quickly and efficiently. And when it came to that extra bit of per-pixel data we needed but just didn’t have – we generated it. A simple function of the position and normal was plenty enough to sample a dirt texture or noise texture for fading reflections in and out or adjusting the bluriness. It’s a basic, hacked up form of deferred texturing, and it did the job nicely. Fortunately it’s really easy in my renderer to add extra passes and stages into the rendering pipeline, so this was something we could use a lot to customise things.

The deferred approach obviously worked great for lights. Number of lights is usually the big sell for deferred rendering. But it worked great for environment maps too. In Frameranger we had quite a lot of shiny stuff – e.g. a car and a robot – and we wanted to handle it by multiple dynamic environment maps. With the deferred render it was easy to apply. We attached dynamic envmap nodes to things so they moved around, and then attached different objects as inputs and outputs. The inputs get rendered to the envmap, and the outputs get the envmap applied to them. To apply, I generated a small dynamic 1d mask texture which mapped the object indices to white or black – so I could sample it per pixel using the object index and determine whether that object was affected by the envmap. I calculated world-space bounds for the objects which received the envmap and used that to roughly stencil in the shader, and applied the envmap additively, adjusting it using parameters from the material tables. To control fresnel reflection we wanted something better than the usual single “fresnel power” parameter. In Lightwave you can create an envelope for it and explicitly control the fresnel response over the range of the incident angle values, and I wanted something similar – so I exposed 4 control values and used a 1d bezier curve to interpolate them. Worked great – you could generate a very flexible response with it.

Non-polygonal elements

We hand to render more than just triangle-based meshes. Some of the effects – specifically the liquids / fluid dynamics – were raytraced using distance fields. Rather than write a special shading path to handle their lighting I decided to just add these into the deferred rendering pipeline and use the routines that were already in place. This had the benefit of making them interact properly with the other objects in the scene, casting shadows onto them, receiving shadows from them, working with dynamic environment maps and so on – it meant the effects looked properly part of the scene, not just floating in space separate from everything else.

It was pretty easy to add. I raytraced the distance fields and output the results straight to the GBuffer – depth, normal, colour, etc. This also meant the ZBuffer was correct so the effects overlapped properly with the rest of the geometry. For the shadow map rendering passes I just raytraced them from the light’s point of view straight into the depth shadow map. It worked out nicely without too much effort.

Alpha stuff

Alpha stuff doesn’t like deferred rendering – sad but true. Actually I have found a way around it so you can perform deferred rendering on some alpha stuff too – I’ll get onto that in another post – but in terms of general alpha blended stuff, you’re limited to using a forward render which mimics the look of the deferred rendered geometry. Fortunately in Frameranger we didn’t have that much generic alpha mesh stuff to deal with – the particles, smoke, light beams and so on were already special cases or handled with effects in other ways – so it wasn’t a massive deal. We also avoided treating punch-through alphas or cutouts as “alpha” by using alpha testing dithered with a random noise map. As it turned out I just used my ubershadered forward rendering code for the alpha stuff like a “legacy” pass. One compromise I made was to skip shadow receiving for alpha stuff – although it would have been possible, it would have meant I’d have had to keep the shadow maps around longer than the deferred passes, whereas at present the same maps could be reused for all the lights. In reality, the only real alpha stuff we had to deal with in this way were a couple of transparent bits on the car.

Antialiasing

One of the major downsides of deferred rendering is the inability to apply standard hardware MSAA to it. On some architectures it’s possible to use MSAA when rendering the Gbuffers, but you have to do the slow bit – using the GBuffers to perform deferred rendering passes – on a per-sample basis. i.e. for 4x MSAA, you have to light 4x as many pixels and then average the results at the end. Our aim is to achieve a comparable quality of antialiasing as MSAA provides forward renderers, but with the cost of deferred rendering with unantialiased rendertargets – i.e. only lighting the number of actual pixels on screen. With deferred rendering much of the cost of rendering is pushed to the deferred, 2D passes, so it’s important to avoid incurring a large performance cost there when adding antialiasing – scaling that cost by 4 to support 4x MSAA is not feasible.
On consoles or DX10 the natural starting point is to render the geometry to MSAA GBuffers and to try and optimise the lighting process so you don’t need to light every sample. Indeed, I outlined how to optimise the process on Playstation 3 in my GDC 09 presentation. That can reduce the number of additional samples you have to light to only around 20-30% more than the number of pixels in the unantialiased buffer, which is a great improvement but still costs.
On DX9 the problem is even worse because you can’t read the individual samples from an MSAA buffer, so MSAA is completely unusable for deferred rendering there.

So, plan B then.

There are several ways to tackle antialiasing of deferred renderers. First, you could just render everything 2x or 4x the size, light it as usual, and downsample it at the very end. It looks nice – much like MSAA on a forward render, really – and it’s easy to add. But it has exactly the effect on framerate you might imagine, so it’s not a practical solution for realtime. So the usual way people try and do it is to fake it – perform a 2D post process on the result of the deferred render which somehow works out where the edges are and fixes them in a way that looks like they were rendered with antialiasing. This approach is apparently rife on xbox360 titles where the hardware’s dubious memory arrangement makes using proper MSAA on HD framebuffers problematic.

So, how would that magic post process work exactly? Step 1 – detecting edges – is easy, particularly in a deferred renderer where we have a ton of information around to help. An edge detection kernel filter applied to the depth, normal and material index/object index usually gives great results, far superior to using a colour buffer for our purposes. Step 2 – antialiasing those edges – is a little bit more difficult. It’s important to remember that what antialiasing is doing is over-sampling: generating a load of possible values and averaging them. The usual approach with post-process AA is to blur the neighbouring pixels on the edges, which is really the opposite of what we wanted. So it doesn’t really work. For Frameranger I experimented a lot and managed a reasonable attempt at it which used noise, a poisson disc and some magic weighting of the samples – and it looked marginally better than a typical edge blur – more like an “edge dither”.

Here’s some screenshots of the edge noise technique. As you can see, it doesn’t entirely look like antialiasing. Actually as an effect, adding noise to the edges, it was alright – but as antialiasing it wasn’t a good substitute. It appeared that if I wanted to achieve the look of antialiasing I was going to have to move away from using only the 2D results as input and render the geometry differently in the first place – try and gain some more information that way. By the way, all the antialias comparsion screenshots should be matched so you can download the images and diff them or toggle back and forth between them if you want to see the differences.

The second approach I used borrowed from temporal reprojection techniques, and a very old way of antialiasing in an OpenGL example. In that example, antialiasing was done by rendering the scene over and over again to an accumulation buffer and jittering the projection matrix by a sub-pixel amount each time. It’s basically stochastic sampling of the render but flipped around so that you render the screen with one stochastic offset, then again with another offset etc. and average the results at the end. When you offset the projection slightly you cause the edges of the triangles to move slightly, and you get slightly different coverage and a different set of aliasing artefacts – when you average enough of them together you get an antialiased image.

Sadly, as you might expect, rendering the scene loads of times per frame isn’t too practical for realtime. But we can take the basic idea and split it over frames – so each frame we slightly jitter the projection matrix when we render, and we blend the current frame on top of the previous frames with a low alpha value. That works great and gives you a really nice antialiased image.. as long as nothing moves. As soon as you move you get big ugly motion-blur-like trails. So what we need to do is try and fix the case where it moves.

I split “movement” into two cases: object movement and camera movement. Camera movement is where temporal reprojection comes into play. How this works is, when we’re blending the current frame onto the previous frame we don’t just use the same pixel in the previous frame. Instead we project the current frame’s pixel back into the previous frame’s camera space by using a combination of the inverse view projection for the current frame and the view projection from the previous frame – which also requires the pixel depth, which is fortunately kicking around in a GBuffer – then sample the pixel there and blend it. This is basically trying to track positions in world space as they move in screen space. It does indeed fix most of the camera movement artefacts. Of course, problems do occur – at the edge of the screen, or where pixels that were occluded become unoccluded and vice versa. To cancel those, I weight the alpha of the blend by the world-space distance between the previous and last frame pixels. What it’s trying to work out is “is it really the same pixel”, and if it isn’t, don’t try and blend it – just overwrite it. Conveniently that can be used to fix object motions too. Finally use an edge detect mask on the whole thing so only the edges get blended.

Here’s some images to compare (off and on):

Well, it works! It actually works pretty nicely. The thing about temporal techniques is that they settle over time – so when you get a relatively static screen it quickly convolves to an antialiased image, becoming more aliased as movement is introduced. For a situation where you didn’t have too much movement on screen it’s a good technique. The problem is, for Frameranger we had some very fast camera movements – it just wasn’t working well enough.

Here’s some shots showing how it looks when the red cube is in motion (off and on again) – and with a small camera motion too. As you can see, some aliasing does creep back in.

Finally, over time, I came up with an actual real solution to deferred rendering with antialiasing. Unfortunately it requires an additional geometry pass, but it gives you the look of proper MSAA. The idea is to render the GBuffers, lighting passes and so on to a non-MSAA buffer, then re-render the geometry to an MSAA buffer, which a shader that just samples the buffer containing the lighting results using a bilateral filter based on depth. Then resolve that MSAA buffer to give you an antialiased result. This is in a way quite similar to a light prepass using inferred lighting, but the MSAA pass only samples the lighting results buffer – it doesn’t need to compute any shading of it’s own.

We know that the reason MSAA is efficient is it only runs the pixel shader once per pixel, but generates a depth/stencil value for each sample in the pixel – so depth test+write is performed multiple times. This means that for primitive interiors with no intersections, the value of the pixel will be the same as for the non-MSAA buffer – only the edges of primitives and the intersections between primitives will have different values. This technique exploits this. We generate the depth values for MSAA by re-rendering the primitives; we just need to work out what colour to write for each pixel on each primitive. On edge pixels for a non-MSAA buffer, the final pixel value will be that of the front-most primitive. On edge pixels for a resolved MSAA buffer, the pixel value will be an average of the MSAA sample values – the value of the front-most primitive per sample. This technique estimates the value per primitive to write by using the bilateral filter to look around a small area around the pixel in the same screen location as the one it’s currently shading on the non-MSAA buffer, and asking “which of these probably came from the primitive I’m rendering, and is therefore a good estimate”. Or in practice a weighted average of the pixels in the area, weighted by the difference between the non-MSAA depth and the primitive’s pixel depth.

Bilateral upsampling is an extremely useful technique for fixing up edges. It’s also a very good way to upsample lower resolution soft particle buffers, for example. I’m pretty happy with this method, and it’s what we’re now using for the much improved Frameranger final version (due out soon!). It’s made a lot of difference to the quality and cleanness of the look, with a pretty acceptable overhead. It scales to 4x, 8x or more MSAA samples nicely and only impacts the cost for that one pass, which has a reasonably simple shader and output bandwidth requirement (compared to the GBuffer stages or the deferred lighting passes). It actually has some similarities to Inferred Lighting, although my method is just for antialasing and not for shading.

Now, if you happen to be on a more flexible API or piece of hardware than me where you can read samples from MSAA buffers – like a PS3 – there’s an optimisation / extension to this – you can use the same technique but avoid the re-render. It goes like this: render the GBuffers to MSAA targets; resolve the buffers using a point sampling scheme – e.g. “pick top left sample”; run the lighting processes on these resolved buffers; now perform an additional fullscreen pass:, read in your original MSAA Gbuffers, then for each MSAA sample from that buffer – perform a bilateral filter w.r.t depth/normal, sampling from the resolved GBuffers and light buffer, to weight the resolved light buffer samples for that MSAA sample from the GBuffer. That will give you a bilateral upsampled light result per MSAA sample of the Gbuffer, and you can average them in the shader and write out one final antialiased light value. Clearly you only need to run these shaders on edges if you wish to optimise it further. So there you go – a practical solution to deferred rendered antialiasing which only needs one geometry rendering pass, and lets you perform lighting on a single-sample screen-sized buffer without worrying about MSAA at that stage. Shame it doesn’t work on DX9, because then for me it would be the ideal solution.

Coming up in part 2 : ambient occlusion.

Ketika kita bekerja dengan huruf entah itu untuk percetakan atau online publishing, komputer yang akan menjadi mediumnya, dimana kita akan mengumpulkan materi dan mengerjakan konsep dan desain yang akan dibuat. Oleh karena itu kebutuhan akan pengetahuan grafis pada tampilan layar dan reproduksi grafis sangat dibutuhkan untuk mendapatkan final output yang terlihat oleh target audiens sesuai seperti apa yang kita harapkan.

1. Bitmap
Dalam Tampilan layar monitor atau pun cetak digital, teks di render oleh ribuan kumpulan grid mosaik berwarna berbentuk seperti titik yang disebut pixel untuk membuat sebuah bentuk yang diinginkan. Susunan bentuk grid inilah yang disebut dengan Bitmap. Bitmap sangat intensif terhadap memory, sebuah file harus mengandung informasi tentang warna dan posisi dalam sebuah halaman di setiap pixelnya. Ketika sebuah gambar bitmap di perbesar, software hanya bisa memperbesar bentuk pixel pada gambar tersebut, sehingga mempengaruhi pixel asli dari gambar tersebut dan bagian pixel yang kecil dan bergerigi akan menjadi terlihat besar dan menjadikan gambar terlihat lebih bergerigi.

2. Vektor
Vektor mendeskripsikan sebuah bentuk sebagai sebuah garis seperti garis lurus atau garis melengkung yang saling menyatu dengan titik yang telah ditentukan. Garis-garis tersebut (vektor) di rekam dalam bentuk file sebagai formula matematika. Dan kemudian garis yang telah terbentuk di isi oleh pixel. Vektor sangat baik untuk kualitas pengskalaan, ketika sebuah gambar vektor diperbesar, posisi kordinat titik vektor di susun ulang dengan dikontrol oleh formula matematika agar garis lurus dan lengkung pada titik-titik tersebut tetap konstan, dan bentuk baru ini kemudian di isi oleh pixel sesuai dengan bentuk dari vektor tersebut tanpa ada cacat pixel. File gambar vektor memakan memory lebih kecil dibandingkan dengan file bitmap. Menggambar dengan vektor sangat efisien akan tetapi bagaimanapun juga gambar vektor ini ketika bertemu dengan layar monitor harus di render sebagai titik-titik matrix atau dengan kata lain garis vektor harus di konversi kedalam bentuk bitmap. Informasi garis vektor di konversi menjadi bitmap untuk dicetak, bedanya bitmap yang akan dicetak ini memiliki resolusi yang tinggi.

Huruf dan Layar Komputer
Gambar dihadirkan di layar komputer oleh kumpulan titik-titik berwarna yang disusun dalam grid yang rapat yang dinamakan pixel, kualitas on-screen rendering dari huruf digital dihambat oleh kecilnya resolusi dari layar komputer yaitu, 72 pixel per inch (ppi) di layar Macintosh dan 96 ppi di layar PC. Ukuran huruf yang kecil akan tampil buruk dilayar dan sangat mengganggu dan masalahnya huruf berukuran kecil sering digunakan dalam penkerjaan desktop publishing. Ukuran resolusi yang rendah dari layar komputer tidak bisa menghadirkan detail yang baik, sehingga ketika huruf berukuran kecil di raster dan disesuaikan dengan grid pixel, detail dengan ukuran lebih kecil dari 1 pixel harus dibesarkan atau dihilangkan, ini menyebabkan fitur seperti ketebalan stroke atau serif menjadi tidak konsisten atau mungkin menjadi hilang dan akhirnya membentuk huruf dan ruang yang tidak baik. Beberapa teknik diperlukan untuk mengatasi permasalahan tersebut, teknik tersebut dinamakan Hinting, font-font yang berkualitas tinggi telah melewati proses ini dan mengandung informasi hinting. Saat meraster, software mengusahakan untuk meratakan outline gambar terhadap grid pixel, hanya pixel yang jatuh di outline gambar yang digunakan secara normal. Jika terdapat sedikit pixel untuk menghadirkan huruf berukuran kecil dengan benar, perintah hinting digunakan untuk membuat penyesuaian yang akan memberikan bentuk yang lebih baik secara optis.

Huruf dan Media Cetak
Untuk melihat detail font dengan jelas bisa di capai dengan mencetaknya diatas kertas, mesin cetak menggunakan titik kecil hitam atau berwarna untuk membentuk sebuah gambar. Jumlah dot per inch (dpi) / titik per inci sangatlah jauh lebih baik dibandingkan layar komputer dan oleh sebab itu gambar yang lebih detail bisa dibentuk. Kebanyakan mesin cetak inkjet atau laserjet memiliki output resolusi 300 hingga 600 dpi, dan bahkan imagesetter memiliki output resolusi hingga 3000 dpi. Saat ini mesin cetak inkjet dan laserjet sudah bisa menghasilkan kualitas cetak yang sangat baik, tetapi jika diteliti lebih dekat akan terlihat formasi titik-titik yang membentuk area gambar, mesin cetak tersebut tetap memiliki keterbatasan resolusi, pembentukan gradasi dan warna. Secara kontras, titik-titik yang digunakan oleh imagesetter sangatlah kecil hingga sulit dideteksi oleh visual, sehingga sudut-sudut pada gambar dan huruf terlihat sempurna.

1. Postscript
Adalah bahasa deskripsi halaman yang dipatenkan oleh Adobe. Mengkonversi informasi vektor menjadi bitmap beresolusi tinggi untuk rendering berkualitas tinggi. Adobe Type Manager (ATM) menggunakan postscript untuk menghasilkan bitmap superior dari outline di pencitraan layar komputer.
2. Inkjet Printer
Titik-titik mikroskopik dari tinta disemprotkan ke atas kertas dengan resolusi 300 hingga 1500 dpi. Dengan keterbatasan resolusi dan kualitas kertas banyak mesin cetak inkjet murahan tidak mampu memaksimalkan postscript hingga tidak bisa merender bentuk huruf dengan tepat. Tapi inkjet-inkjet keluaran terbaru yang dilengkapi oleh postscript atau postscript simulation bisa menghasilkan output yang sangat baik.
3. Laser Printer
Kebanyakan Laser Printer sudah dilengkapi oleh software postscript, yang akan bisa dengan baik menerjemahkan bentuk huruf dan pengaturan jarak dengan akurat, walaupun mereka membuat tampilan yang ‘crisp’, laser printer mengalami hambatan ketika ukuran ukuran gambar yang akan di cetak kecil. Karena partikel dari bubuk toner digunakan untuk membuat gambar lebih lebih kecil dan huruf-huruf berstroke tipis tampil lebih tebal ketika tercetak.
4. Imagesetter
Imagesetter berbasis postscript, dengan menggunakan cermin putar dan sinar laser, memberikan hasil gambar dengan kualitas tinggi, pemanfaatan eksposur fotografi dikombinasikan dengan resolusi yang sangat tinggi untuk mendapatkan detail yang sangat baik. Imagesetter mengarahkan cahaya keatas film, yang akan digunakan untuk menyinarkan cahaya ke atas pelat cetakan. Gambar sekarang sudah berpindah ke atas pelat yang sudah ditintakan dan gambar inilah yang akan dipindahkan keatas kertas atau media cetak lainnya.
5. Online Viewing
Online viewing adalah istilah aplikasi desain yang dibuat dengan tampilan yang terlihat dilayar komputer adalah hasil akhir yang akan dilihat oleh pemirsa desain contohnya, desain website atau multimedia interaktif. Permasalahan yang kerap hadir dalam pengaplikasian online viewing adalah keterbatasan resolusi yang dimiliki oleh layar monitor komputer yaitu 72 ppi untuk Macintosh dan 96 ppi untuk PC sehingga memberikan efek yang tidak baik untuk penampilan-penampilan huruf dalam ukuran kecil, oleh karena itu banyak desain-desain website yang menggunakan huruf dengan ukuran besar untuk aplikasi text dan ini sangat mengganggu untuk kenyamanan komposisi layout, dan juga permasalahan online viewing yang berhubungan dengan resolusi belum terpecahkan. Untuk mengatasi permasalahan resolusi ini hadirlah sebuah teknik yang dinamakan Antialiasing.

a. Antialiasing
Terkadang menggunakan font dengan ukuran kecil adalah satu-satunya cara yang memungkinkan untuk mendisplay text dengan ukuran kolom yang terbatas. Agar font tetap terlihat baik di ukuran kecil tanpa kehilangan legibility nya, para pembuat software membuat teknik antialiasing, teknik ini bekerja membandingkan garis vektor dengan grid bitmap dan membaca bagian dari gambar atau huruf yang hilang atau terdistorsi, lalu dengan kecanggihan teknologi, software memasukan pixel berbentuk bayangan warna abu-abu yang bervariasi disekeliling bentuk huruf untuk menciptakan ilusi mata bentuk stroke yang halus. Kekurangan dari teknik antialiasing adalah teks dengan font berukuran kecil akan terlihat kurang hitam akan tetapi kekurangan ini cukup terbayar dengan kehalusan dan integritas atas bentuk huruf yang ditampilkan.
[IMG]http://i21.photobucket.com/albums/b266/ritchienedhansel/Untitled5.png[/IMG] gambar diambil dari http://www.newcottage.com

Sumber:
1. http://id.wikipedia.org/wiki/Huruf_Digital_(Font)

A strange thing happened to me every time I composed a piece of text on my OS X 10.5.7-powered Mail.app.

(My text setting is Lucida Grande at 12pt. size)

On random occasions, the rendered text would look the exact same way, yet somehow kerned loosely. It’s as if the line of text loses its spacing information entirely. See it?

Note how the text “I just saw” on the second line and the one on the fourth is spaced differently. Let’s juxtapose the two directly below each other to make it clearer.

I noted that the kerning between the letters j–u, s–t and s–a shifted to the right by 1 pixel, yet these minor changes are enough to make the spacing between the word “just” and “saw” appear larger, thus distracting the eye from the normal pace of reading.

If you’re an OS X 10.5.7 and Mail.app user, try reproducing this problem by writing several lines of new mail on Mail.app. See how, from time to time, the spacing of the letters would shift.

Have anyone else had this problem?

PS. Despite the pixel shift, the anti-aliasing method used to draw these letters remains unchanged. Note how the ‘fringes’ around the alphabets are actually of the same color—except for the leftmost stroke of the letter ‘u’ which lightened considerably.

Il mondo dei programmi open source gratuitamente disponibili per ogni utente o azienda presenta un’importante novità. L’applicazione Open Office è giunta alla versione 3.1 con una utilissima serie di features aggiuntive. Gli sviluppatori del software dichiarano cifre a dir poco sorprendenti dei download effettuati  che superano anche le più rosee aspettative. Sarà il periodo di crisi globale ma già la versione di Open Office 3.0 aveva superato i 50 milioni di download: di questi quasi 5 milioni sono stati collezionati dalla sola localizzazione italiana. Un traguardo significativo sul nostro mercato, dove il numero mensile dei download ormai supera regolarmente quello delle vendite di nuovi PC.

Il PLIO (Progetto Linguistico Italiano OpenOffice.org) che cura la versione italiana della suite, dichiara sulla nuova suite:  “La novità più importante e più facile da notare è la completa riscrittura del modulo per la visualizzazione degli elementi grafici sullo schermo (circa mezzo milione di linee di codice), che apporta – grazie all’antialiasing – un evidente miglioramento della qualità, e influisce sul modo in cui le immagini vengono visualizzate durante il trascinamento e i testi selezionati vengono evidenziati, e permette di effettuare la sopralineatura del testo». L’antialiasing viene applicato ad ogni oggetto di tipo vettoriale, come grafici e diagrammi, e può contribuire a migliorare l’aspetto di documenti e presentazioni. Open Office 3.1 è disponibile in download per Windows, Linux, MacOS X e Solaris.

Cutting corners is generally thought of as a bad thing. It generally is, I agree. But in some occasions, optimally cutting corners is the right thing to do. I can show you what I mean. Using the Logo programming language (precisely the KTurtle implementation), I devised the following experiment. Consider the following image:

Two circles drawn with KTurtle

The two circles do look the same, aside from color and shift, that is. The blue circle is done using the classic child-like approach: the turtle repeats 360 times the forward 1 turnright 1 commands. Superficially, at that resolution, the red circles does look quite a lot like the blue one. Or does it? Shifting back both circles to the same position:

The two circles, superimposed.

We see that there are minutes differences between the two. But the red circle doesn’t have 360 sides, only 36. The second, red, circle is drawn by repeating 36 times forward 10 turnright 10 commands. It is only by superimposing the two that we actually see the difference.

Granted, Logo programming is not exactly a major concern for modern graphics rendering or game programming, but this short example does prove my point that sometimes, a great speedup can be obtained by using short-cut evaluation of more complex mathematical expressions, such as Bézier curves that are often used to calculate smooth trajectories of cameras in scenes. Using a simple method (the de Casteljau’s algorithm) one can compute a sufficiently precise approximation without exceeding a given number of computations; or at least balance between the precision and the number of points computed. Does a Bézier curve approximated by 10, 20 segments looks smooth under your rendering conditions? Or does the roller-coaster ride still looks realistic? That’s up to you to decide.

Taking back the circle example. How precise does it have to be, really? We would probably all agree that it should be precise to the rounded-pixel. Some will argue that anti-aliasing is quite necessary so that sub-pixel precision is required. Is splitting pixels in four enough? In 16? Answering this question first will help you guide your efforts toward the development of a good enough algorithm.

This reasoning doesn’t apply only to graphics applications; it is true for a large number of other applications and contexts. It is not because someone came up with a complex algorithm that offers the best precision and that it’s the accepted method that there is no room to cut corners. You may get away with a much faster prediction algorithm that is right 95% of the times instead of 97% because the cost of being wrong 2% more often doesn’t mean all that much because it occurs comparatively rarely.

*
* *

Balancing between the amount of computation and the precision of the result is one of the eternal struggles in computing. You have to chose between the usine à gaz that provides precision up to the umpteenth bit, or much simpler devices that will give you acceptable precision, often with a much reduced computational load. You have to fully understand the trade-offs involved in the precision vs accuracy dilemma for your specific problem. Increasing the computation time does not mean you will gain a significant amount of accuracy or precision; moreover even though the difference may be significant mathematically, it doesn’t mean it’s pragmatically relevant.

As everything else, nothing is as simple as it first seems.

Further Readings
An Introduction to Error Analysis: The Study of Uncertainties in Physical Measurements (Google Books). Although this book does not discuss the subject of numerical approximation, it is still a must read to understand the precision vs accuracy dilemma under the more mathematical approach of error propagation. Or you can get it from Amazon.com

Текстът е превод от www.artlebedev.com

Специалистите по предпечат, знаят, че изображенията, подготвени за печат трябвва да имат разделителна способност от поне 300 точки на инч. Уеб дизайнерите също са чували за това вълшебно число и искрено му се доверяват. Като резулатат както хората, които се занимават с печат, така и интернет дизайнерите стават неспособни да отпечатат правилно пиктограма или снимка на екрана, изображения с първоначално ниска резолюция.

Като правило, проблемът свързан с разделителната способност, който дизайнерите не успяват да разберат е:

Ако напишете “300″ в полето “разделителна способност” на софтуера на крайното устройство, например принтер, то получава инструкции, които му казват, че всяка точка трябва да заеме 1/300 от инча (85 микрона).

Затова, ако трябва да отпечатаме голяма икона (), простото 16 кратно увеличение ще предизвика ужасяващи резултати:

Това е резулататът, който любителите на 300 точки на инч ще преценят като задоволителен. Цялостното замазване и омекотяване на образа се дължи на автоматичният antialiasing, който се опитва да попречи на простото увеличаване на размера на пикселите, като генерира нови според вградения си алгоритъм. Заради малкото налична графична информация, програмата за редакция на изображения, започва да обработва образа. Алгоритимите, които използва работят добре, когато се използват за смаляване или увеличаване на фотографски изображения, тоест такива с преходи на цветовете и полутонове.

Така изглежда същото изображение, с размер променен без интерполация от графичния софтуер.

В случая опростените форми са точно това, което искаме – иконата изглежда добре.

Какво ще видим, ако отворим книга, наречена “Дизайн на икони”? Изображения, които доказват, че някои хора не отстъпват от догмите (трябва да бъде изображение с 300 точки на инч), но не могат да повярват на собствените си очи (резултатът ви кара да потръпнете от ужас).

Steve Caplin. Icon Design: Graphic Icons in Computer Interface Design. Moscow, Astrel, AST, 2003. Достойно за отбелязване, технолозите на английското издание са предотвратили грешката.

Същото се отнася за снимките на екрана – трябва да използвате софтуер за страниране за увеличаването на размера им, а не редактори на изображения.

Правило:

За да отпечатате икона или снимка на екрана, просто трябва да промените размера и, без предварително смекчаване. Ако някой, който е свързан с печата застане на пътя ви, казвайки “72 точки на инч за печат? Само през трупа ми,” промушете го с кола.

С пожелание за по-малко излишни пиксели,

Мартин

Yesterday, the Safari 4 beta died on my work PC, taking with it a slew of tabs with no mechanism to restore them. I am so accustomed to Firefox and Chrome saving my sessions that I really take that for granted, but it is so awful that I resumed using Chrome as my default browser on my PC. (At home, I move back and forth between Firefox and Camino.)

No sooner did I fire up Chrome than I was reminded how awful the type display on Windows is. Look at the three samples below:

Type rendered in Chrome using XP and no ClearType

The same thing, with ClearType enabled

And finally, the same text from Safari 4 in Windows.

Seriously, it is 2009 – how is it possible that Apple can manage to display type on a Windows machine more attractively than the native rendering routines? Wikipedia says ClearType is now 10 years old – yet type looks better on my iPod touch than it does on my PC, for crying out loud!

Even more amazing, when Apple first released Safari for Windows, was the outcry by so many users that Apple made the type look blurry, which is (I assume) the reason Safari 4 brags about native rendering as the default.

In my book, this is further proof that the Windoze world does not deserve a satisfying, aesthetically coherent computing experience. Thank heavens I can go home and return to my Mac at the end of the day.

Problem: Some games do not give you the option to increase the anti aliasing or other graphical features, such as MMORPGs. If your video card has the capability why not increase the them!? (This method only works for Nvidia cards)

Solution: On your computer find the Nvidia control panel. For XP it is usually in your tray, but vista you need to right click on your desktop and click Nvidia Control Panel. Once you are there click on the “Manage 3d Settings” category. If the game you want to modify is not in the drop-down menu then find the .exe file of that program (probably found here C:\Program Files\(game folder)\(game exe file)). Once the game is selected simply change the Anisotropic and Antialiasing to what ever you want. I always choose to enhance the application settings or to override them.

Hope this helped, Good luck.

As I mentioned in my last post, I had trouble with Fallout 3. I finally got it working. Sort of.

If you have having problems with the game, try the usual steps:

1. Update your video card and sound card drivers.

2. Make sure that any firewall and anti-malware software are set to allow Fallout 3 to run properly. Such programs often pop up request windows that are not visible when Fallout 3 (or other games) run. So, the fix might be as simple as running Fallout in Windowed Mode. This will allow you to see such popup windows and allow Fallout 3 the permissions it needs. To run Fallout 3 in Windowed Mode, launch Fallout 3 and click on Options. When the options window comes up, check Windowed in the Mode section. Now click on Play. If the warning pop ups appear, give Fallout 3 the permissions it needs.

3. Run a check on your system with anti-malware software (something that should be done anyway). Also, run a check on your disk (right click on the icon for the drive, select properties,  select Tools and then click on the button to start the error checking. You can also try a registry checker, if you have one.

Even after doing all of this, Fallout 3 might still fail to run. If you are getting a black screen and a a lock up when you try to play the game, run Fallout 3 and then select Options. I was able to get the game to run by checking the Windowed Mode option, setting the Screen Effects to None, the Antialiasing to 8, the Ariristosropic Filtering to 8, the Aspect Ratio to 16:10, and the Resolution to 1280X800. This might not work for you. If you have the patience, try changing a setting and then running the game. Keep doing this until it works or you get sick of it.

Of course, if you get the game to work and spend too much time playing it, your significant other might send you one of these.

VEJA TAMBÉM O ARTIGO "COMO HABILITAR O ARRASTA E SOLTA NO AMSN"

Antes de iniciar execute
apt-get install xorg-dev libpng12-dev libjpeg-dev subversion build-essential
1.Faça o download destes arquivos:
http://ufpr.dl.sourceforge.net/sourceforge/tcl/tcl8.5.2-src.tar.gz
http://ufpr.dl.sourceforge.net/sourceforge/tcl/tk8.5.2-src.tar.gz

2.Instalando os pacotes:
tar xvzf tcl8.5.2-src.tar.gz
cd tcl8.5.2/unix
./configure
make
make install
make clean

tar -xvzf tk8.5.2-src.tar.gz
cd tk8.5.2/unix
./configure –with-tcl=/usr/local/lib –enable-xft (substituir o hifen por dois hifens)
make
make install
make clean
cd ~


3.Baixe a ultima versão do amsn via svn.
svn co https://amsn.svn.sourceforge.net/svnroot/amsn/trunk/amsn amsn

4.Acesse o diretorio amsn e execute:
./configure –with-tk=/usr/local/lib/ –with-tcl=/usr/local/lib/ (substituir o hifen por dois hifens)
make
make install
make clean

5.Finalizando
vi /usr/local/bin/amsn
Substitua o wish por wish8.5
(abra o amsn antes para criar a pasta .amsn)

6.Instalando o skin
Faça o download do arquivo Cold.zip.
Descompacte-o
unzip cold-1.0.zip

Mova a pasta Cold para pasta skins do amsn
mv Cold ~/.amsn/skins/

Agora no Amsn, clique em Account – Select Skin e selecione Cold – Ok
Era isso!

Ubuntu mi ha rotto. Da ieri sono infatti passato definitivamente ad Arch Linux (http://www.archlinux.org/), una distribuzione basata sul KISS (Keep It Simple Stupid, il significato penso sia ovvio…): una volta installata, infatti, è priva di qualsiasi interfaccia grafica e in generale l’intera distribuzione ha una struttura poco complessa.

Per questo non è adatta a tutti, ma solo agli “smanettoni” e a quelli che vogliono il massimo della personalizzazione. Nel mio caso, ho installato GNOME e numerosi programmi indispensabili (GIMP e Inkscape per la grafica, Kino e Avidemux per l’editing video, VLC come media player e cosí via…).

Lo ammetto: ho installato anche aMSN, il client open-source per chattare con chi utilizza quell’obbrobrio di Windows Live Merdenger. Ma… sorpresa! Quei bravi ragazzi che creano i pacchetti per Arch hanno compilato le TCL/Tk con l’antialiasing attivo, cosí aMSN sembra molto piú bello!

Per il momento non mi ha deluso nulla di Arch (a parte i driver della scheda video, ma quella è colpa di ATI): ho fatto molta fatica in piú rispetto a quando ho installato Ubuntu, ma devo ammettere che ne è valsa la pena, data la grande reattività e stabilità di questa distribuzione.

Salve a tutti!!

In questa guida voglio proporre un metodo alternativo alla compilazione di aMsn 0.98 con antialiasing visto che la precedente guida, sta cominciando a dare problemi. L’altra guida proponeva uno script scritto da alcuni utenti del forum di Ubuntu, ma dall’ultimo aggiornamento mi sono reso conto che cercava di compilare aMsn con le Tcl/Tk 8.6 e durante la compilazione con queste librerie viene restiuito un errore.

Se avete seguito questa guida e vi siete ritrovati installate le Tcl/tk 8.6 seguite questa procedura per ripulire il sistema altrimenti saltate direttamente al passo 2.

1. Ripulire il sistema dalle Tcl/Tk 8.6

1. Entrate nella directory /usr/local/lib col comando cd /usr/local/lib/
2. Eseguite uno alla volta questi comandi:
   • sudo rm -r tk8.6/
   • sudo rm -r tcl8.6/
   • sudo rm libtkstub8.6.a
   • sudo rm libtk8.6.so
   • sudo rm libtclstub8.6.a
   • sudo rm libtcl8.6.so
3. Entrate nella directory tcl8 con cd tcl8
4. Eliminate le 8.6 dando il comnando sudo rm -r 8.6/

2. Installare le Tcl/Tk 8.5

Per installare le Tcl/tk 8.5 su Ubuntu Gutsy Gibbon basta inserire nel file /etc/apt/sources.list il repository di backports di Hardy Heron:

sudo gedit /etc/apt/sources.list

Inserite la seguente stringa in fondo al file, salvate e chiudete:

deb http://archive.ubuntu.com/ubuntu gutsy-backports main universe multiverse restricted

Aggiornate la cache dei pacchetti:

sudo apt-get update

Rimuovete le Tcl/Tk 8.4 cercandovele da Synaptic e usate il front-end grafico per rimuoverle.

Installate i seguenti pacchetti:

sudo apt-get install tcl8.5 tcl8.5-dev tcl8.5-doc tk8.5 tk8.5-dev tk8.5-doc

3. Compilare aMsn da SVN

Per prima cosa scarichiamoci i sorgenti, quindi date un cd ~ e poi il seguente comando:

svn co https://amsn.svn.sourceforge.net/svnroot/amsn/trunk/amsn amsn

Rimuoviamo qualsiasi altra versione di aMsn da Synaptic.

Entriamo nella directory appena scaricata:

cd amsn

E diamo i soliti comandi per compilare assicurandoci che dopo il comando ./configure venga resituito l’uso delle Tcl/tk 8.5, se diversamente consiglio di non proseguire, verrà dato al 90% un errore di compilazione.

./configure

make

sudo make install

Provate a lanciare aMsn, e se non viene restituito nessun errore…… !!BRAVI!! avete appena installato l’ultima versione di aMsn con antialiasing!!

¹Altrimenti provate a dare questo comando:

sudo update-alternatives –config tclsh && sudo update-alternatives –config wish

E assicuratevi che venga restituito un qualcosa del genere:

C’è un solo programma che fornisce tclsh
(/usr/bin/tclsh8.5). Non c’è nulla da configurare.

C’è un solo programma che fornisce wish
(/usr/bin/wish8.5). Non c’è nulla da configurare.

¹Se vi permette di scegliere tra più versioni della stessa libreria ma non risultano le Tcl/Tk 8.5 date questi comandi e poi di nuovo il precedente:

sudo update-alternatives –install $(which tclsh) tclsh /usr/local/bin/tclsh8.5 900;

sudo update-alternatives –install $(which wish) wish /usr/local/bin/wish8.5 900;

Se da terminale provando a dare il comando /usr/local/bin/amsn viene restituito “/usr/local/bin/amsn: line 3: exec: wish: not found” o qualcosa del genere provate a dare questo comando:

sudo ln -s /usr/local/bin/wish8.5 /usr/local/bin/wish

¹ATTENZIONE: Questi comandi funzionano solo in distribuzioni Debian-Like (Debian Etch, Ubuntu Gutsy Gibon, Ubuntu Hardy Heron, etc), per altri tipi di distro Linux vi rimando al wiki ufficiale di aMsn

Ulteriori info qui e qui

4. Plugins e Skins

Se volete potete scaricare questo archivio di plugins e skin da me creato estraetelo e copiatene il contenuto nella directory ~/.amsn

5. Aggiornare a nuove versioni.

Per aggiornamenti futuri vi basta andare dalla vostra home nella directory amsn e dare il comando:

svn update

Poi compilate dando:

make clean

./configure

make

sudo make install

Non mi resta che augurarvi buona fortuna e ovviamente postate commenti, soprattutto se ci sono stati problemi nel seguire la mia guida!

A presto, NonSolo1x

Uno dei problemi maggiori che affligge chi usa Debian è sicuramente la resa dei font.

Per risolvere questo inconveniente, basta seguire alcuni semplici accorgimenti.

1) Installare font aggiuntivi

I font che preferisco aver installato nel mio pc sono i font bitstream e quelli che seguono nel comando che segue:

$ apt-get install ttf-bitstream-vera ttf-freefont ttf-opensymbol

2) Settare la resa dei font su KDE

Bisogna aprire Kcontrol e settare alcuni parametri:

“Aspetto e temi -> Tipi di carattere”

A questo punto: “Utilizza antialiasing” -> “abilitato” e nel tasto “Configura” selezionate “Stile di hinting -> Nessuno”

Successivamente su “Sistema tutti i caratteri” settate il font “Bitstream Vera Sans”

Infine: “Forza DPI” -> “96 DPI”

3) Riconfigurare il gestore dei font

$ dpkg-reconfigure fontconfig-config

Durante la riconfigurazione bisogna rispondere a 3 domande:

• Nativo
• Automatico
• No

Dopo un riavvio del server X si potrà ammirare probabilmente un netto miglioramento della resa dei font.

In giro si trovano vari post (io in particolare mi riferisco a questo) che spiegano come installare amsn con attivato l’antialiasing tramite uno script. Questo script si chiama fixamsn. Ma ha un problema, almeno con il mio portatile (in effetti la procedura di installazione della pagina a cui faccio riferimento funziona benissimo sul mio fisso) e si pianta allegramente dando un fastiodiosissimo errore: Could not install build dependencies.

Per fortuna, però sono riuscito, smanettando un pò, a risolvere questo problema. Facendo quindi riferimento alla guida di prima, il cui blogger ovviamente ringrazio, spiegerò come installare amsn senza problemi.

Per prima cosa dobbiamo scaricare lo script, apriamo la shell, entriamo in una cartella a piacere e digitiamo:

• wget  http://repo.intilinux.com/fixamsn.tar.gz

Scompattiamo il file:

• tar zxvf fixamsn.tar.gz

Ora apriamo il file (kwrite fixamsn.sh) e andiamo alla riga 135 e la sostituiamo con quella successiva:

• sudo apt-get $APTOPTIONS build-dep tcl8.4 tk8.4 amsn || error_exit “Could not install build dependencies.”
• sudo apt-get $APTOPTIONS build-dep tcl8.4 tk8.4 || error_exit “Could not install build dependencies.”

Ora installiamo l’ultima versione di amsn, ci vorrà un pò di tempo, dato che scaricherà e compilerà le librerie necessarie:

• bash fixamsn.sh cvs

Ora è pronto per essere eseguito.

Aggiornamento 03.12.08: Dalla versione 8.04 di ubuntu questa guida è diventata obsoleta, visto che il pacchetto presente nei repository ha abilitato l’opzione antialiasing di default.