Problem with Sprite Antialiasing

Previous topic - Next topic

Miroslav-Stimac

Strange, a friend of mine and I see differences between the .PNG file in our Opera browser, where it looks as nice as it looks in Paint .NET, and in the game running with GLBasic, where the antialiasing is not good.
But we have NVidia graphic cards, not AMD Radeon. Maybe that is the difference.
As I mentioned, when I change the graphic card driver settings to maximum quality, then it looks better. But the default settings are causing bad quality antialiasing in GLBasic.
Maybe your AMD Catalyst drivers have by default better antialiasing settings.
Is there any way by using GLBasic to force using the best graphic device settings respectively to use high quality software antialiasing as it is the case in Photoshop and Paint .NET?
Software antialiasing may be slow, but we have only 2D animations. Such games ran fast even on 15 years old computers.

Best wishes,
Miroslav
PC: AMD Phenom II X4 955 BE, Microsoft Windows 8 64 Bit, 12 GB DDR3-RAM, 2 TB hard disk, NVidia GTX 560

Home computers:
1. Commodore 64, 1541-II floppy, Final Cartridge 3
2. Commodore Amiga 1200, Blizzard 1230-IV, FPU 50 MHz, 16 MB fast memory, 4 GB Flash HD
3. Atari Mega ST2

spacefractal

#16
I guess its could mightbeen the same issue I have in the early development of the game, seen in the attachment (the box behind the toy mouse was a alphabox test). Its could been a multiply issues, and they can been quite annoying. We use insane much antialasing and alpha in the game.

Here I use SETTRANSPARENCY -1, SetAlphaMode(1) and ALPHATESTING 1.0 in Greedy Mouse worked for me.

Code (glbasic) Select

FUNCTION SetAlphaMode: alpha#=-5
STATIC Lasta#
IF alpha=-5
ALPHAMODE Lasta#
RETURN
ENDIF
Lasta#=alpha#
IF alpha#>0
alpha#=0-alpha#
ELSE
alpha#=-alpha#
ENDIF
IF alpha#=0 THEN alpha#=0.1
ALPHAMODE alpha#
ENDFUNCTION


Yes I did not like that way ALPHAMODE worked and for me 0 should been off and 1 to on, not the other way, which cause some confuction for me. Its not a bug throught of course.

[attachment deleted by admin]
Genius.Greedy Mouse - Karma Miwa - Spot Race - CatchOut - PowerUp Elevation - The beagle Jam - Cave Heroes 2023 - https://spacefractal.itch.io/

erico

In my system I have to get the gfx settings to operate lower and allow program control, otherwise I get garbage.
But I mess with this settings a lot, can´t remember performance on default.

I think one way to keep it default on pcs/mac/linux is using the alpha mode false but if some system is set to override the application choice, then there isen´t much you can do.

Wampus

Quote from: Miroslav-Stimac on 2012-Oct-04
But we have NVidia graphic cards, not AMD Radeon. Maybe that is the difference.
As I mentioned, when I change the graphic card driver settings to maximum quality, then it looks better. But the default settings are causing bad quality antialiasing in GLBasic.
Maybe your AMD Catalyst drivers have by default better antialiasing settings.

Catalyst is set to 'performance' for antialiasing, i.e. lowest quality, so it must a quirk of the nVidia OpenGL drivers. I've heard before that the nVidia 400/500 series have problems with OpenGL in some instances and aren't going to be kind on smaller multi platform games since they use OpenGL on the whole. Oddly, my nVidia 320m in my Mac Mini is very good with GLBasic games. Meh. What can you do?

If there is a way to force software rendering instead of hardware acceleration it would be a disaster for anything but Windows, Linux and MacOS. Yuck! If its driving you crazy one way to do that for development purposes only would be to compile on a virtual machine in VMware with hardware acceleration off.

spacefractal

#19
today I thinks this is a real glbasic bug. antialiasing and offbuffers simply dont work and you see that issue. I did never workaround that, and that why I avoid using offbuffers.

I used test code like this:
Code (glbasic) Select

IF OFFBUFFER=0
USESCREEN -1
SETTRANSPARENCY -1
ALPHATESTING 1.0
ELSE
USESCREEN -1
CLEARSCREEN RGB(0, 0, 0)
SETTRANSPARENCY -1
ALPHATESTING 1.0

USESCREEN 1
CLEARSCREEN RGB(0, 0, 0)
SETTRANSPARENCY -1
ALPHATESTING 1.0
ENDIF


this is the output:


the upper is with USESCREEN 1 (and then paint the buffer directly to USESCREEN -1 with DRAWSPRITE), and second image is USESCREEN -1. The upper is wrong and the below is correct. they should show the same. Hence its a confirmed bug.

I guess GlBasic use wrong blendmode and I did never found what its happens and gave up offbuffers. So this is just a test for this bug.

So I thinks its should been moved to the bug forum? Its was not needed for me to create a new thread, since I think I experimentere extractly same issues.
Genius.Greedy Mouse - Karma Miwa - Spot Race - CatchOut - PowerUp Elevation - The beagle Jam - Cave Heroes 2023 - https://spacefractal.itch.io/

mentalthink

If I can help in something--- I always the .png I saved whit 24 Bits of depth and the black Background, and never I have extrange things, using alpha or not...


Wampus

#21
If you use CREATESCREEN then draw to it without using the CLEARSCREEN command (or a SHOWSCREEN command before drawing) then alpha transparency should be OK, i.e. set to 0. My Chaos remake relies on it to create new sprite sheets when in debug mode. The output is the equivalent of using TexturePacker or sprites straight out of Photoshop. However, using CLEARSCREEN will set the alpha to 255. Does that make sense?

EDIT: The thread How to clean a virtual screen confirms this as MSX is finding the same thing. It isn't just my graphics card.