Forums

Hi. I've investigated new blit options a bit further, conclusions are presented below:
1. stretch works ok, but it does nothing if double filter is selected
2. hq2x works ok only if video_depth=16 is set, segfaults when 8bit is set and probably does nothing on 32 bit.
3. triple buffering causes segfault all the time
4. video depth different than 8 causes image to look like this:
16-bit

32-bit

However 16-bit combined with hq2x works perfectly.
All tests have been performed using windowed_double blitter, I was using either double or hq2x filter (sometimes eagle one). Hope you will find this information useful.

I'm concerned with 3.
Where does triple buffered mode crash?
I suppose you're referring to running it under GNU/Linux with your build?

(I have no feedback yet on triple buffering under Windows, but it works on my machine and DjRobX's at least)

Yes, a Linux build compiled with gcc 3.2.3. With this meka.blt:

Quote

[Windowed Double::UNIX]
res = 512x400
blitter = double
driver = auto_win
video_depth = 16
triple_buffering

the baacktrace is as follows:

Quote

(gdb) bt
#0 0x080f63f4 in clear_to_color ()
#1 0x08080962 in Video_Setup_State () at video.c:212
#2 0x0809a193 in Action_Switch_Mode () at g_action.c:98
#3 0x08088820 in Inputs_Check_GUI (sk1100_pressed=0) at inputs.c:219
#4 0x08085b74 in Main_Loop_No_Emulation () at mainloop.c:107
#5 0x08085b1d in Main_Loop () at mainloop.c:78
#6 0x0804ccee in main (argc=1, argv=0xbfa769f4) at meka.c:393
(gdb)

#1) Stretching is an optional parameter passed into a blitter. The blitter doesn't necessarily need to implement it. It seems kind of redundant to use a doubling blitter with a stretching blitter, no?

#2) HQ2X requires a 16 bit video mode. It cannot work in an 8 bit mode. There is a 32 bit version of the filter, but I have not implemented it. I suppose we should code some validity checks in and bomb out on an improper use. I honestly hadn't anticipated my code actually ending up in a release. :)

#3) Triple buffering requires hardware and a video driver that supports it. Not all cards can handle it. I assume it only works in full screen modes. Do you know if triple buffering works in some other emulator on your setup? It's a pretty simple implementation on the emulator side, Allegro is doing all of the dirty work. I've tested it on 5 different PCs here but they're all running relatively recent NVIdia or ATI cards and under WIndows.

I am using preety large number of emus, can you name some that use triple buffering? As for my videocard, it's a GeForce FX 5700 so it should support this feature. And triple buffering crashes in fullscreen also.

Yep, that card definitely supports it (at least under Windows), that's what I'm using on my main game machine. Fceu (nes emulator) and ZSnes can do triple buffering, but I don't think either of them use it by default. Neither of them use Allegro though. It seems most emulators have gone to SDL. If you download the allegro package there's a triple buffering test in the examples dir (run "exupdate 3").

-- Rob

Hmm, the triple buffering option in linux version of zsnes is nonexistent, same in nintencer. Running exupdate 3 and trying to run X11 in fullscreen returns the message:

Quote

This driver does not support triple buffering

I guess the linux nVidia driver, allegro or X.org itself does not support triple buffering. Double works ok. I'll investigate further.

[edit]
I don't know where to look, but here is what I've found. There is an option to enable triple buffering in America's Army. It either works or does nothing (presumably the first one), but definitely does not crash the game.

Ah, that explains it. If exupdate can't do it, nor can we. Like the other issues, we just need to add some error reporting and bomb out gracefully when the user supplies an unsupported configuration. Since we know your card can do it, and NVidia is generally well supported by Linux, it would be interesting to find out what component is missing support.

-- Rob

Thanks for the info on the thread, guys. Don't worry too much about compatibility. I enabled triple buffering by default to get this kind of results (and I'd like to get more under Windows).

I'm now in the process of switching MEKA to hi-color modes and blitters should be overhauled along the way.

Author	Message
Belegdol Joined: 27 Apr 2005 Posts: 50 Location: Poland	WIP 2005-06-25 aka 0.71 and new blit options Posted: Sun Jun 26, 2005 9:13 am
Belegdol Joined: 27 Apr 2005 Posts: 50 Location: Poland	Hi. I've investigated new blit options a bit further, conclusions are presented below: 1. stretch works ok, but it does nothing if double filter is selected 2. hq2x works ok only if video_depth=16 is set, segfaults when 8bit is set and probably does nothing on 32 bit. 3. triple buffering causes segfault all the time 4. video depth different than 8 causes image to look like this: 16-bit 32-bit However 16-bit combined with hq2x works perfectly. All tests have been performed using windowed_double blitter, I was using either double or hq2x filter (sometimes eagle one). Hope you will find this information useful.

Bock Site Admin Joined: 08 Jul 2001 Posts: 8653 Location: Paris, France	Posted: Sun Jun 26, 2005 9:27 am
	I'm concerned with 3. Where does triple buffered mode crash? I suppose you're referring to running it under GNU/Linux with your build? (I have no feedback yet on triple buffering under Windows, but it works on my machine and DjRobX's at least)

Belegdol Joined: 27 Apr 2005 Posts: 50 Location: Poland	Posted: Sun Jun 26, 2005 9:40 am
Belegdol Joined: 27 Apr 2005 Posts: 50 Location: Poland	Yes, a Linux build compiled with gcc 3.2.3. With this meka.blt: Quote [Windowed Double::UNIX] res = 512x400 blitter = double driver = auto_win video_depth = 16 triple_buffering the baacktrace is as follows: Quote (gdb) bt #0 0x080f63f4 in clear_to_color () #1 0x08080962 in Video_Setup_State () at video.c:212 #2 0x0809a193 in Action_Switch_Mode () at g_action.c:98 #3 0x08088820 in Inputs_Check_GUI (sk1100_pressed=0) at inputs.c:219 #4 0x08085b74 in Main_Loop_No_Emulation () at mainloop.c:107 #5 0x08085b1d in Main_Loop () at mainloop.c:78 #6 0x0804ccee in main (argc=1, argv=0xbfa769f4) at meka.c:393 (gdb)

DJRobX Joined: 04 May 2005 Posts: 23	Posted: Wed Jun 29, 2005 10:50 pm
DJRobX Joined: 04 May 2005 Posts: 23	#1) Stretching is an optional parameter passed into a blitter. The blitter doesn't necessarily need to implement it. It seems kind of redundant to use a doubling blitter with a stretching blitter, no? #2) HQ2X requires a 16 bit video mode. It cannot work in an 8 bit mode. There is a 32 bit version of the filter, but I have not implemented it. I suppose we should code some validity checks in and bomb out on an improper use. I honestly hadn't anticipated my code actually ending up in a release. :) #3) Triple buffering requires hardware and a video driver that supports it. Not all cards can handle it. I assume it only works in full screen modes. Do you know if triple buffering works in some other emulator on your setup? It's a pretty simple implementation on the emulator side, Allegro is doing all of the dirty work. I've tested it on 5 different PCs here but they're all running relatively recent NVIdia or ATI cards and under WIndows.

Belegdol Joined: 27 Apr 2005 Posts: 50 Location: Poland	Posted: Thu Jun 30, 2005 7:00 am
Belegdol Joined: 27 Apr 2005 Posts: 50 Location: Poland	I am using preety large number of emus, can you name some that use triple buffering? As for my videocard, it's a GeForce FX 5700 so it should support this feature. And triple buffering crashes in fullscreen also.

DJRobX Joined: 04 May 2005 Posts: 23	Posted: Thu Jun 30, 2005 3:35 pm
DJRobX Joined: 04 May 2005 Posts: 23	Yep, that card definitely supports it (at least under Windows), that's what I'm using on my main game machine. Fceu (nes emulator) and ZSnes can do triple buffering, but I don't think either of them use it by default. Neither of them use Allegro though. It seems most emulators have gone to SDL. If you download the allegro package there's a triple buffering test in the examples dir (run "exupdate 3"). -- Rob

Belegdol Joined: 27 Apr 2005 Posts: 50 Location: Poland	Posted: Thu Jun 30, 2005 9:56 pm
Belegdol Joined: 27 Apr 2005 Posts: 50 Location: Poland	Hmm, the triple buffering option in linux version of zsnes is nonexistent, same in nintencer. Running exupdate 3 and trying to run X11 in fullscreen returns the message: Quote This driver does not support triple buffering I guess the linux nVidia driver, allegro or X.org itself does not support triple buffering. Double works ok. I'll investigate further. [edit] I don't know where to look, but here is what I've found. There is an option to enable triple buffering in America's Army. It either works or does nothing (presumably the first one), but definitely does not crash the game.

DJRobX Joined: 04 May 2005 Posts: 23	Posted: Fri Jul 01, 2005 5:47 am
DJRobX Joined: 04 May 2005 Posts: 23	Ah, that explains it. If exupdate can't do it, nor can we. Like the other issues, we just need to add some error reporting and bomb out gracefully when the user supplies an unsupported configuration. Since we know your card can do it, and NVidia is generally well supported by Linux, it would be interesting to find out what component is missing support. -- Rob

Bock Site Admin Joined: 08 Jul 2001 Posts: 8653 Location: Paris, France	Posted: Sat Jul 02, 2005 8:49 am
	Thanks for the info on the thread, guys. Don't worry too much about compatibility. I enabled triple buffering by default to get this kind of results (and I'd like to get more under Windows). I'm now in the process of switching MEKA to hi-color modes and blitters should be overhauled along the way.

Forums

View topic - WIP 2005-06-25 aka 0.71 and new blit options