Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » [problem] turning out blur/filtering effect in low-res modes on hi-res display

This thread is locked; no one can reply to it. rss feed Print
[problem] turning out blur/filtering effect in low-res modes on hi-res display
Kotlet
Member #10,714
February 2009

I am aiming to create a 2d game with retro feel (pixel art and low-res).
Setting graphic mode to low-res (320 x 200 : 800 x 600) on hi-res displays results in something I can describe as "pixel blur", similar to bilinear filtering effect.
Is there a way to disable this effect? If not, would it be possible to run the program in native screen resolution and somehow disable the filtering?

Thomas Harte
Member #33
April 2000
avatar

That blurring is added either by your video card or by your monitor and will depend on your monitor and graphics card driver settings. The only reliable thing to do is to run at your user's desktop resolution and do whatever type of scaling you think is correct.

Allegro's stretch blit doesn't smooth and should produce the effect you want. However, using Allegro's software routines for any size of display larger than 'tiny' is an extremely bad idea, since your code will run extremely slowly.

Offhand, I can't think of a more helpful solution than switching to Allegro 4.9 in preparation for Allegro 5.0 so as to get the GPU to do all the heavy lifting for you. That's not an ideal solution because the API is still in flux and there are no support guarantees — maybe someone else can think of something smarter?

count
Member #5,401
January 2005

allegro + openlayer
or allegro 4.9

are the both solutions I would consider for this task.

Kotlet
Member #10,714
February 2009

Yes, that sould do the trick I guess. Thank you for quick reply.

Audric
Member #907
January 2001

To avoid pixel blur caused by the resolution itself, I let the user choose a resolution which he knows has exact pixels (ex: his desktop resolution), I compute the bigger facter I can multiply my 320x240 buffer (x1, x2, or x3), and use a single stretch_blit from my buffer to screen. I center the display, displaying black bars in the unused areas. The speed seems decent.

It's even easier in windowed modes, since you know the desktop resolution to start with, and you can make a window of the size you choose.

Donald_W
Member #7,982
November 2006

Hehe I had same problem for my game and I'm stretching my buffer to screen (I can provide you a class for drawing using double/triple buffer or page flipping, also it stretches image if needed).

Thomas Harte
Member #33
April 2000
avatar

Quote:

It's even easier in windowed modes, since you know the desktop resolution to start with, and you can make a window of the size you choose.

I admit to being slightly out of touch with the Allegro API, but if there is any way to automatically detect the desktop resolution, even if it means momentarily flashing a window on screen before switching to fullscreen mode, then I'd highly recommend it.

Also, way back when I used to support stretching in one of my emulators and found that many people consider half number multiples to be acceptable for stretches (e.g. scaling 640x480 up 2.5 times in each dimension to make 1600x1200), so you might want to consider checking that as an option.

Slartibartfast
Member #8,789
June 2007
avatar

Quote:

I admit to being slightly out of touch with the Allegro API, but if there is any way to automatically detect the desktop resolution, even if it means momentarily flashing a window on screen before switching to fullscreen mode, then I'd highly recommend it.

With 4.2 you get:
get_desktop_resolution(&screen_width,&screen_height);

Tobias Dammers
Member #2,604
August 2002
avatar

Quote:

However, using Allegro's software routines for any size of display larger than 'tiny' is an extremely bad idea, since your code will run extremely slowly.

It's not that bad really.
I've done it before and I've never found it to be a speed bottleneck.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

Thomas Harte
Member #33
April 2000
avatar

Oh, actually it suddenly occurs to me that most of my experiences with Allegro for the past four years have been with the OS X port. Loosely speaking, the compositing window manager means that software-mode Allegro is doing the rough equivalent of using the CPU to draw a frame, getting the OpenGL driver to repack it as a texture and shoot it off across the bus, then having the GPU draw it onto the screen. Prior to Vista, Windows had a compositing model whereby Allegro could just write pixels directly to the screen. In Vista and onwards it can fall back on doing that, but may have to disable Aero if you're in windowed mode.

Hence, on OS X using Allegro's software rendering is really very bad indeed - even compared to the same software rendering on the same hardware on Windows. GPU-based rendering should be much the same. As a result, I quite possibly have a distorted view.

Therefore, you can almost certainly afford to be less dismissive of software rendering than me. I simply hadn't invested sufficient thought into the topic.

Kotlet
Member #10,714
February 2009

Thanks for all the replies. I have tested the method including stretch_blit function using Allegro 4.2.2.

First I draw in a 320 x 240 bitmap, then I stretch blit it into the screen (1400 x 1050 in my case). Under Windows, on 1.8 Core2Duo laptop it works quite fast, but probably I should use video memory instead of simply drawing into bitmap which is, I guess, created in RAM or something.

Thomas Harte
Member #33
April 2000
avatar

As a broad rule, video bitmap to video bitmap blitting is fast (including masked blitting now, I think, but possibly not stretch blitting and definitely not rotations/etc), anything else to video bitmap blitting is slow. But if what you have is fast enough then probably everything is already fine.

Donald_W
Member #7,982
November 2006

Hi, I've attached my improved drawing class + example, any suggestions, improvements & criticism are welcome.

@Edit: I'll add optimised create bitmap soon (It will check which accelerations do we have for faster blitting).

Feel free to modify sources :)

Kotlet
Member #10,714
February 2009

That's great, many thanks!

Go to: