Posts filed under 'softat'

Pixel Polizei is out

A project I’ve been working on for the last few weeks is now out: Pixel Polizei is a helper tool for the retro artist. The purpose is to let the “graphician” draw using whatever software they happen to like, check/force color clashes and finally save the outcome in native formats that can be viewed using emulators or the real deal. So far there is support for these machines and screen modes:

  • Amstrad CPC modes 0 and 1 with or without overscan
  • C-64 hires and multicolor
  • MSX screen 2
  • Oric hires
  • Plus/4 hires and multicolor
  • ZX Spectrum

More formats and platforms will appear when I find the time and motivation again. As usual, the tool should work on Lin/Mac/Win as long as Java 7 or newer is installed. Open source, too.


Add comment May 17th, 2016

PETSCII editors – design thoughts

After more than two years of improving and honing my own project, and checking the competition I got the urge to share some of my thoughts on what makes or breaks a PETSCII editor. A lot of this stuff is actually pretty self-evident in the end, but it has taken hours and hours to figure it out. Bear with me 🙂

Not pixels

When comparing a PETSCII editor to a generic paint program there are plenty of similarities, but also notable differences. Instead of tens of thousands of individual pixels we’re dealing with a relatively low-resolution grid consisting of predefined symbols. On the one hand it is easier to deal with text, since tools such as lines, ellipses and curves are rather useless, but on the other hand there is a constant need to effectively choose and alternate between the available symbols, which requires different kind of thinking altogether. In other words, adopting tried and tested methods from paint programs alone will not lead to optimal outcome.

Among the most powerful features of PETSCII (the editor) are smart rotation and flipping of a selected area which take into account the form of the character. I take no credit for these, as it was Tero who came up with the idea in the first place and wrote the remapping tables. Not every character can be rotated or flipped, but even so you’ll save a lot of time when working with symmetric forms. See the following image for an example of how “smart” flipping works as opposed to simply moving the characters:


Typing vs. drawing

In essence there are two main methods to get characters on the screen. The traditional way, typing, was initially the only possible option and is still heavily present in modern-day editors (for example AAE). A mouse is something of a rarity on C-64s and graphical symbols can be conveniently found on the keys, so on a real machine typing makes all sense – but a lot less so on your PC or Mac which has a different keyboard to begin with.

I’ve included a half-assed typing mode in PETSCII, mostly for the sake of actually writing text, even though all the symbols can be typed too if it’s really necessary. In any case, drawing with a mouse was the preferred metaphor right from the beginning. There are pros and cons to both, but using a mouse definitely makes it quicker to sketch forms in the spirit of direct manipulation. A little but important detail is to show the character before it is actually placed: otherwise you end up constantly undoing the operation.

Character selection

When drawing, a great deal of time is spent on selecting the next character. The first thing to do was to reorganize the otherwise messy character set to group related symbols together (thanks go to Tero again). Jambonbill went even further and repeated the same characters multiple times to create visually continuous groups.


A well-organized character selector is a good start, but much more can be done to facilitate an efficient workflow. For example in PETSCII the aforementioned rotate and flip operations work with individual characters as well: press a single key and get the next corner for a window or a box. In the same lines I came up with “smart sets”, predefined sets that you can walk through with a keypress. Another little bit that arose from a real need was to let the user quickly shift stick characters (used for various lines) right/left/up/down.

As a piece of PETSCII art is drawn, you typically start accumulating useful characters and their combinations in the image itself. Instead of always going for the selector – which in Playscii even occludes part of the canvas – it makes sense to quickly pick a character from the surroundings.


You can get away without a grid if the images are comparably small, but all in all a well-working grid can be of great benefit when selecting regions and aligning symbols with each other. After at least three complete rewrites of the drawing code I’ve eventually come up with the following findings:

  • Don’t make the grid intrusive (thick, contrasty etc.)
  • No single color works for the grid alone. Instead, darken light colors and lighten dark colors to keep it harmonious.
  • It’s useful to have a quick on/off toggle

Below a few real-life examples of how the grid looks like in different editors.


File formats

The file formats supported by an editor tend to reveal its intended use. Some editors are clearly geared toward actual machines, stick to their limitations and facilitate easy exporting to formats like .prg, which can be run on real hardware. At the other end of the spectrum you might get only PNG files or GIF animations out for easy distribution on the web.

I’ve been balancing between the two extremes myself: initially the idea was to support software development and participate in demoscene competitions. However, it soon became evident that many people needed and wanted to distribute their works online for easy viewing, so I had to give in and add a PNG exporter. Supporting multiple exporters for multiple machines obviously means plenty of error-prone extra work.

Automatically converting existing images to PETSCII is a different discussion altogether. Having said that, many users would welcome such a feature for, say, converting their self-portrait into retro character art. In addition, an artist can benefit from a reference image, as some of them prefer sketching on paper first before firing up the actual editor.

Animation and other fancy features

Creating proper support for animation is probably as big a task as all the others combined. As of now there are animation features in multiple editors, but none of them really go beyond simple copy/paste and playback of the frames. Think of a proper video or animation editor to realize how many possible features there could be.

Undo and redo aren’t exactly “fancy” features from a user perspective, but it takes some effort to include them in your editor. It’s definitely a good idea to implement them early on, as adding them as an afterthought might prove painful – speaking from experience 🙂 There are more and less sophisticated ways to go about undo, but as we’re dealing with quite little data it’s not all that bad to just save the buffers between operations for undoing or repeating the steps. Another welcome safety network comes in the form of automated backups.

There are a couple of editors that support layers, approximately in the lines of your familiar photo editing software. I can definitely see some uses for them, for example for separating the background from foreground figures. Then again, to fully support layers requires considerable effort, and they aren’t quite as useful as in photo editing, as you can’t really have things like translucency or color manipulation.


While some users are after a genuine user experience – tapping away on a real C-64 – most seem to welcome the ease of cross-development. Supporting the three main desktop platforms (plus their different flavors) is tedious at best, and thus some of the editors run on Windows only. Being a Mac/Linux user myself this was, of course, out of the question, but luckily Processing lets you export multiplatform applications with little extra effort. On the downside, Java is required on the target machine, which will turn off some possible users (and rightfully so).

As I see it, the best bet these days would be to develop for the web. In spite of the possible troubles with browser compatibility, web applications tend to be multiplatform by nature. In addition, you don’t need to go through the trouble of installing anything on the local computer. If I were to start from scratch, I’d probably take this route. As of now there are two online editors already, even if neither of them is quite complete yet (see my previous post).

Another angle to accessibility follows from the fact that people use laptops and tablets with a crammed keyboard. Therefore, relying on numpad or function keys beyond F10 is obviously out. Likewise, touch pads (esp. Apple ones) might not have more than one or two mouse buttons available, which requires some thought. Even more so for touch screens, which again introduce a new set of challenges.


I can wholeheartedly relate to programmers that want to spend their free time on interesting coding problems instead of writing documentation. Even if it’s not exactly fun, there is a need for at least some product support: be it a manual, online help or a website. A few nice example works done with the editor definitely don’t hurt, as they show what’s possible and spark user interest.


Cross-development tools for PETSCII are a surprisingly new phenomenon. As far as I know, they’ve been around for not much more than five years, after which things have really started picking up speed. The threshold of starting to do character art has probably never been lower, and new authors are popping up every now and then.

All in all, the challenge of programming a PETSCII editor is twofold: there’s the tech and then there are the users. It’s not hard to put together basic minimum functionality, but going beyond that has turned out so laborious that most projects have been abandoned shortly after their initial release. PETSCII too would require quite an overhaul by now to accommodate any new major features – feature requests are, of course, neverending.

Implementing new modes, tools and so on is one thing, but thinking about the workflow and making the features useful is another. If you’re not much of an artist yourself, it’s at least good to have one in the loop: user feedback or even going so far as to observe someone’s work over their shoulder provide valuable insight and motivation. Ok ok, that was the design teacher in me speaking 🙂

2 comments April 6th, 2016

PETSCII editors: an overview

I’ve been rather actively involved with PETSCII art for the last couple of years, coding, drawing and even conducting a bit of research. As PETSCII is kinda fashionable now, and many people would like to experiment with it, here’s a little overview of the available editors and their pros and cons. The list aims to be complete, so if there’s anything missing, let me know. Let’s start with native tools and then move on to cross-development.

It’s a fine line, but I’ve decidedly excluded various text editors that could be used for character graphics as well.

Digital Paint 4.0 (C-64, link)

Probably ok for its time – can’t quite pinpoint when exactly it was released. In addition to the original version coded by Aaron Hightower there are various hacks by sceners who added missing features. In addition to typing, you can paint filled boxes and edit colors.


TBoard-Painter 1.1 Pro (C-64, link)

Another oldie, this time by Tao/Triad. The most notable extra feature is the 1/4 char pseudographics drawing mode. The image can be larger than the screen size, which together with the name suggests it was meant for BBS graphics. As a nice little touch the x/y location display uses hex numbers 🙂


Tyronpaint 2.1 (C-64, link)

Not much new to say about this: you can type text, change the color or draw blocky 1/4 dots. The images can be higher than 25 lines. Created by Lynchbit/Alpha Flight in 1996, this improved version is from 2006.


Kaleidoscope 4.0 (C-64, link)

Very simple, but at the same time easily comprehensible editor by BroBryce64 all the way from 1989. Not many features there, but you can type chars and change colors. A curious extra is the “rainbow mode” which cycles the colors after each character.


PETSCII Paint 0.5 (C-64, link)

A rudimentary tool by 0xDB from 2011. The basics do work: you can select characters, change colors and save the outcome, but even simple things tend to be on the tedious side.


Petscii Editor 4.6 (C-64, link)

FieserWolf’s editor is undoubtedly the most popular one when it comes to programs running on real hardware. As the version number suggests, there have been plenty of iterations and the workflow has been improved a lot since the initial releases. Once you get used to the UI, there’s useful functionality such as copy/paste, recoloring and multiple pages available. Several notable works have been produced with this editor.


Online PETSCII Editor (online, link)

A web-based solution by Krissz from 2013. I like the idea that you can draw on a normal browser without installing any software or digging the old warhorse from the closet, but this particular project seems to have been abandoned. You can both draw and type, and the character selector is well though out. On the other hand, there is little functionality to support advanced editing.


PET Shop Pro (online, link)

As of now there’s very little documentation on this editor by Jambonbill, as it is still work in progress and not officially released. Nevertheless, quite a promising online tool which lets you even do animations. Originally based on Krissz’s editor (see above), but was mostly rewritten after that. The character selector is well designed, you can edit images of various sizes plus export them to different formats, and even script the editor. There are still some bugs around, which will hopefully be ironed out at some point.


CBM .prg Studio (Windows, link)

Arthur Jordison’s CBM .prg Studio is a complete development environment that lets you create software for the Commodore 8-bits. One of its parts is the screen editor, which is actually quite usable for artistic endeavours too. Largely served as the source of inspiration for the editor below.


APE (Windows, link)

APE (Another Petscii Editor) by MrXaliasH from 2013 is Windows-only, but does run fine under Wine as well. The basic functionality (drawing, color selection, copy/paste and even undo) is there, but it seems the project was quickly dropped after its initial release.


C64 AAE (Windows, link)

C64 ASCII Art Editor by RADSoft hails from Poland. Windows-only, but runs somewhat ok under Wine except the color editor. Apparently the development ceased in 2012, but in spite of that there are some unique features – most notably layers, which were a firstie in the scene. The animation features are also among the most advanced. Drawing happens by writing, but unfortunately the key mapping doesn’t suit all keyboards. Furthermore, keyboard shortcuts require quite heavy juggling with various ctrl/shift/alt combinations.


EDSCII and Playscii (multiplatform, link)

EDSCII by JP “Vectorpoem” LeBreton was one of the first editors I tried in 2013. Later on its development halted and Vectorpoem created a new tool called Playscii. Both versions focus on PETSCII-like retro graphics instead of sticking to the exact capabilities of the C-64. Still under development, Playscii already features plenty of functionality such as different character sets, layers, animation frames and smooth zoom, plus of course the standard editing tools. There is also something called “game mode”, which I didn’t quite understand at first sight, though.


PETSCII (multiplatform, link)

Do not expect me to be very objective with this 🙂 The project, initially coined by me and Dr. TerrorZ, started in 2013 and has received occasional updates ever since. In addition to the standard stuff there’s rudimentary support for animation and other machines than just the C-64 (VIC-20, PET and Plus/4). One recognized problem is that because of Processing, the program runs on Java, which spells trouble these days. The GUI is undeniably “no-nonsense” with most functions hidden behind single-key shortcuts.


In conclusion, there’s already quite a variety of tools available these days, and some are surely still missing from the list – not everyone has made their software public in the first place. At one end of the spectrum there are hardcore editors running on genuine hardware, and at the other retro art oriented tools aimed at recreating the old look with less regard for authenticity (at times called fakescii). Pick your poison!

edit: More additions, thanks to Goto80 for the tips!

edit2: More details on Pet Shop Pro received from Jambonbill himself.

4 comments March 22nd, 2016

Kaksikin artikkelia

Hieman hyytynyt kirjoittelutahti on toivottavasti taas lähdössä nousujohteiseksi nyt, kun intensiivi-workshopista ja opiskelijavalinnoista on selvitty. Eilen ja tänään tuli sentään pihalle pari kepeähköä pätkää: ensimmäinen Teron kanssa PETSCII-taiteesta Skrollissa ja toinen WiderScreenissä Merja Salon kanssa Seppo Kilgastista, joka teki 1980-luvun lopulla Amigalla valokuvataidetta. Widerin artikkeli on linjoilla täällä ja Skrollin juttu tässä pdf:nä. Alla Teron “Evening at Home” ja kaksi kuvaa Kilgastin lopputyöstä.

Add comment March 16th, 2016

Raspberry Pi 2: hyvät ja huonot uutiset

Lägään tällä hetkellä näiden Raspien kanssa hieman perässä, sillä rupesin vasta testailemaan synttärilahjaksi saamaani 2B-mallia. Jälleen kerran hieman nopeampi kolmonenhan tuli juuri uunista ulos.

Juhlapuheista huolimatta etenkään alkupään Raspeista ei todellakaan ollut työpöytäkäyttöön: muistia oli liian vähän, X:n ja SDL:n kiihdytykset riittämättömiä, ja jo muutenkin hitaan koneen hyydytti viimeistään käyttiksen ajaminen SD-kortilta. Muutaman vuoden aikana ytimiä on tullut kolme lisää, ja kenties vielä tärkeämpänä parannuksena muistin määrä on noussut gigatavuun. Mutta ollaanko vieläkään työpöytäkäyttöön riittävällä tasolla?

Kyllä, ei ja ehkä. Raspi 1:een verrattuna työpöytä pyörii mainiosti, mutta toisaalta hitainkin nykypäivän Intel-pohjainen miniläppäri on edelleen nopeampi. Hitaus ja nopeus ovat pitkälti ohjelmista kiinni: mukana seuraava Web-selain ja LibreOffice ovat aivan käyttökelpoisia, kun taas Java-pohjainen Processing hyytyi varsin ikävästi. Pikaisesti kokeilemani kevyet emulaattorit toimivat sinänsä ok X:n päällä, mutta kiinteän resoluution ja puuttuvan video-overlayn vuoksi niitä ei saanut koko näytölle (resoa voisi toki pudottaa, mutta se on ongelman kiertämistä eikä ratkaisua).

Pahin pullonkaula tuntuu edelleen olevan massamuisti. Siinä missä SSD:istä on tullut päivittäistavaraa isojen koneiden puolella, pikkulaudoissa ollaan edelleen jumissa USB2:n ja muistikorttien maailmassa. Odroideissa nähty eMMC on jonkin verran parempi, mutta jää sittenkin SSD:lle mennen tullen.

Parhaimmillaan Raspit ovat niille erityisesti räätälöityjen softien kanssa: mediatoistimista, emulaattoreista ynnä muista on optimoituja versioita, jotka käyttävät videoskaalaajaa tai OpenGL ES:ää tavanomaisten kirjastojen sijaan. Yllätyin itsekin, kuinka paljon 3D-rauta jaksoi puskea, kun sitä ohjelmoi järkevästi. Ylimääräiset kerrokset, kuten Java ja JavaScript, ovat puolestaan myrkkyä suorituskyvylle.

Monia päivittäisiä asioita voi tehdä jo nykyiselläänkin riittävän sujuvasti, kunhan hyväksyy tietyn ajoittaisen tahmailun. Ainoaksi peeseen korvaajaksi en Raspia edelleenkään laittaisi, enkä usko kolmosenkaan tilannetta merkittävästi muuttavan, varsinkin kun massamuistiväylät eivät ole sen nopeammat. Toisaalta tarkkaan rajatussa yksittäisessä käytössä etenkin tämä uusi Rapsutin voi olla aivan riittävän tehokas ja hinnaltaan kymmenesosa “oikeasta” tietokoneesta. Palataan asiaan taas parin sukupolven päästä.


1 comment February 29th, 2016

Yosemite ja VirtualBox

Pitipä tätäkin kokeilla: eräänlainen “Hackintosh” eli OS X 10.10:n asennus virtuaalikoneeseen. Lähtökohtaisesti hommassa on kaksi ongelmaa, nimittäin a) Macintoshien rauta ja firmware poikkeaa edelleen PC:stä ja b) lisenssiehdot eivät salli asentamista kuin Mäkkeihin, minkä takia virtuaalikoneet eivät sitä myöskään virallisesti mahdollista muilla alustoilla.

OSx86-projektin ansiosta OS X:n saa asennettua – lukuisien reunaehtojen puitteissa – ihan tavalliseenkin peeseehen, kunhan rauta on juuri sopivaa. Seuraava käyttöjärjestelmäpäivitys saattaa aina räjäyttää kaiken, mutta motivaatio lienee useimmilla pikemminkin “because I can” kuin OS X:n ajaminen missään tuotantokäytössä halvemmalla raudalla. Pääasiallisia asennustapoja on nykyään kaksi: virallisen asennusmedian käyttö loaderilla höystettynä sekä erilaiset häkätyt distrot, joissa on mukana ajureita ym.

Googlettamalla löytyi ohjeet Yosemite+VirtualBox-yhdistelmälle. Yosemite Zone -distro löytyi Internetin uumenista, joten asennus käyntiin. Alkuunsa meni ihan lupaavasti, mutta kuten monella muullakin, virtuaalikone jämähti melkein asennuksen lopussa pysyvästi. Keskusteluista löytyi apu ongelmaan, ja pienen komentoriviräpellyksen jälkeen Yosemite todellakin käynnistyi:


Asiat toimivat suunnilleen odotetusti, mutta grafiikka on kiihdyttämättömänä varsin hidasta ja hieman bugistakin – oikealla raudalla tuetaan kyllä kiihdytystäkin. BeamOff-niminen kikkale nopeuttaa menoa poistamalla näytönpäivitykseen synkronoinnin, mitä en tosin itse päässyt todentamaan, sillä syystä tai toisesta Hackintosh jämähti melkein joka buutissa, teki sitten mitä hyvänsä. Erääksi lääkkeeksi kaupitellaan sitä, ettei konetta koskaan sammuta, vaan tallentaa laitteiston tilan. Järin kestävästä ratkaisusta ei sittenkään ole kyse, minkä lisäksi mm. äänet toimivat pieleen.

Eipä tästä jäänyt paljon käteen: OS X kyllä buuttaa, mutta on melko lailla käyttökelvoton ja bugittaa. Ehkäpä eri distro olisi toiminut paremmin, mutta ongelmia tuntui foorumin perusteella olleen monilla muillakin. Seuraavaksi pitänee kokeilla ihan oikealla koneella.

Add comment February 8th, 2016

Super Meat Boy trouble on Linux

This is more of a note for myself, since I run into the same problem quite frequently and it’s kind of tricky to find the fix even with Google. So… the next time you get this dreaded error message from Super Meat Boy:

Fatal Error: MojoShader compile failed!

Download this and extract it in your supermeatboy directory (local copy here in case the file disappears). It will replace the binaries for both 32- and 64-bit, after which you should be able to play the game again. The problem seems to have to do with Mesa’s Intel integrated graphics support, which lacks a required feature.

Note that the fix is for the downloadable copy only. No idea if it is needed or works with the Steam version at all.

Add comment January 24th, 2016

AMD-ATI ja videon repeily (lisää kökköä)

Taannoisen Nvidia-valitusvirren vastapainoksi vielä samasta aiheesta AMD/ATI-perspektiivistä, eli mitä tehdä, jos video repeilee? Asetelma on lähtökohtaisesti hieman samanlainen kuin Nvidiallakin: tarjolla on sekä avoimen sorsan (xserver-xorg-video-ati) että suljettu ajuri (fglrx eli Catalyst), joista suljettu on se nopeampi ja samalla ongelmallisempi. Vakiona näistä AMD:llä tulee avoin versio, jolla repeilyä ei nähdä, mutta samalla menetetään tehoja OpenGL:stä sekä kätevä hallintapaneeli, ja pelien toimivuus heikkenee.

Netistä löytyy yhtä sun toista vanhahtavaa ohjetta, joissa sorkitaan xorg.confiin välillä TexturedVideota päälle ja välillä pois. Itse en saanut niillä mitään näkyvää vaikutusta aikaan, eikä xvinfo koskaan tunnistanut video-overlaytä. Toisin sanoen ollaan jumissa OpenGL-ikkunan kanssa, jossa video repeilee – jos nyt ei järin pahasti. Perfektionistille repeily sattuu kuitenkin silmään, joten järjestelmäasetuksista AMD Catalyst Control Center auki ja Näyttövalintojen alta Repeytymätön työpöytä päälle (miksi nämä tekstit näkyvät suomeksi?).

Jo vain toistuvat videot kauniisti, minkä lisäksi työpöydän normaalit ikkunat liikkuvat pehmeästi. Varjopuolena on lisääntynyt kuormitus, mutta asetus on helppo käydä muuttamassa, jos vaikkapa haluaa peleille parempaa päivitystaajuutta. Vaikkei AMD/ATI ole perinteisesti mikään Linuxin paras ystävä ollutkaan, niin ainakin koko ruudun kompositointi toimii paremmin kuin Nvidialla.

edit: Compiz hoitaisi luultavasti homman sekin, mutta ainakaan itse en sitä suostu käyttämään muista syistä. Samoin Compton tekee kompositoinnin raudalla, mutta on AMD:n omaan toteutukseen verrattuna kömpelö.

Add comment January 22nd, 2016

Intel MEI + Linux + fan control

Everything related to meifand was moved to its separate project page:

Add comment December 12th, 2015

Nvidia ja videon repeily (voi kökkö)

Ehdin jo tottua Intelin integroidun näyttiksen kanssa siihen, että video toistuu nätisti repeilemättä VLC:llä, mutta nyt palasin Nvidia-maahan ja ongelmia ilmeni saman tien. Alla on Mint/MATE ja ikkunamanagerina vsyncin päälle huonosti ymmärtävä Marco. Useamman tunnin googletuksella tuli vastaan seuraavia paremmin ja huonommin toimivia ehdotuksia:

  1. Käsienheiluttelut. Laita Nvidian asetuksista täydet tehot päälle, poista käytöstä X-palvelimelta backing store jne. Ei auta.
  2. VLC:n videoulostulo. Xvideo repeilee pahasti, normaali X11 on kohtuuttoman hidas ja vielä GLX:kin repeilee tarpeettoman paljon. Ei auta.
  3. Compiz. Marcon vaihtaminen Compiziin tosiaankin auttoi asiaa, koska jälkimmäinen kompositoi koko ruudun. Valitettavasti bugeja tuli vastaan lyhyelläkin käytöllä ihan liikaa, enkä saanut asetuksia muutenkaan mieleisikseni.
  4. Compton. Marcon kanssa toimiva pelkkä komposiittori (kompostori?) ratkaisi sekin repeilyn kunnialla, mutta vei valitettavasti aivan liikaa tehoa, minkä lisäksi päivitystaajuus lerpahti.
  5. Nvidian kikkale. Nvidiakin tukee kaikessa hiljaisuudessa kompositointia, vaikkei sitä saakaan normaaleista asetuksista päälle. Jonkin verran vie tehoja sekin, mutta vähemmän kuin Compton.

Kohta 5 vaatii seuraavanlaisen, ei aivan ilmeisen /etc/X11/xorg.confin:

Section "Screen"
  Identifier "nvidia"
  Device "nvidia"
  Option "TripleBuffer" "True"
  Option "metamodes" "nvidia-auto-select +0+0 { ForceFullCompositionPipeline = On }"

Tämän jälkeen Nvidian ajuri kompositoi ja synkronoi ruudunpiirron ja videot toistuvat kauniisti, eivätkä ikkunatkaan splittaile liikutellessa. Pienenä kauneusvirheenä Xvideo on hidas, joten VLC:hen kannattaa vaihtaa ulostuloksi GLX. Ei tämäkään mikään täydellinen ratkaisu ole, sillä X vie nyt tyhjän panttina jonkin verran prosessoritehoa ja kuormitettuna enemmän, minkä lisäksi OpenGL hidastuu jonkin verran. Riittää kuitenkin tähän hätään tilapäisratkaisuksi parempaa etsiessä — vinkkejä otetaan mielellään vastaan.

edit: eihän tämä ollut tietenkään koko kuva vielä. Kävi ilmi, että Nvidian ajuri hukkaa kompositoinnin, jos kone käy nukkumassa. Tilannetta voi korjailla palauttamalla kompostorin nvidia-settingsin avulla. Itse laittoin paikkaan /etc/pm/sleep.d ajettavan tiedoston 20_nvidia seuraavilla sisuksilla:

case "${1}" in
        nvidia-settings --assign CurrentMetaMode="nvidia-auto-select +0+0 { ForceFullCompositionPipeline=Off }"
        nvidia-settings --assign CurrentMetaMode="nvidia-auto-select +0+0 { ForceFullCompositionPipeline=On }"

Hieman kludge, mutta tuntuu toimivan toistaiseksi.

edit 2: Ruudunsäästäjä tuhoaa kompositoinnin myös! Tämän saa kierrettyä poistamalla ruudunsäästäjän kokonaan käytöstä ja pimentämällä näytön virransäästöasetuksilla.

Add comment December 2nd, 2015

Next Posts Previous Posts

Kommenttien virta