Quick Question about MSAA

codetricity

I'm working on a game library for Delphi using Allegro5 and have a question about this. Does the window suppose to jiggle like this on startup when MSAA is enabled?

https://youtu.be/jYX1VMIn_2s

Thanks

Edgar Reynaldo

~~I've watched your video several times now, and I'm just not seeing it. Maybe it's too quick for me to notice, but I don't see any jiggling.~~

Correction, I see it now. The window position noticeably stutters on window creation.

Well, never seen that before. Can you post some system details? For instance I don't know what Delphi is.

Please post your OS, compiler and version, allegro version, and some code that can demonstrate this. Posting source code is best, but a binary that demonstrates it built in debugging mode might suffice.

codetricity

Ok sure:

Delphi 10.3.1
Allegro 5.2.5.0
Windows 10 Pro - Version:1809, Build:17763.379

This is the code I use to open a window and set MSAA:

#SelectExpand
   1procedure TDisplay.Open(aPosX: Integer; aPosY: Integer; aWidth: Integer; aHeight: Integer; aFullscreen: Boolean; aVSync: Boolean; aAntiAlias: Boolean; aTitle: string);
   2var
value: Integer;
flags: Integer;
PosX: Integer;
PosY: Integer;
   7
procedure ShowHideWindow(aShow: Boolean);
var
  wh: HWND;
begin
  wh := al_get_win_window_handle(FHandle);
  if aShow then
    ShowWindow(wh, SW_SHOW)
  else
    ShowWindow(wh, SW_HIDE);
end;
  18
  19begin
if FHandle = nil then
begin
  flags := ALLEGRO_PROGRAMMABLE_PIPELINE;
  FSize.Assign(0, 0, aWidth, aHeight);
  if aVSync then
    value := 1
  else
    value := 2;
  al_set_new_display_option(ALLEGRO_VSYNC, value, ALLEGRO_SUGGEST);
  al_set_new_display_option(ALLEGRO_CAN_DRAW_INTO_BITMAP, 1, ALLEGRO_SUGGEST);
  30
  PosX := gEngine.DefaultWindowPos.X;
  PosY := gEngine.DefaultWindowPos.Y;
  33
  if aPosX > -1 then
    PosX := aPosX;
  if aPosY > -1 then
    PosY := aPosY;
  38
  al_set_new_window_position(PosX, PosY);
  40
  if not aTitle.IsEmpty then
    al_set_new_window_title(PAnsiChar(AnsiString(aTitle)));
  if aFullscreen then
    flags := flags or ALLEGRO_FULLSCREEN_WINDOW;
  al_set_new_display_flags(flags);
  FTitle := aTitle;
  if aAntiAlias then
  begin
    al_set_new_display_option(ALLEGRO_SAMPLE_BUFFERS, 1, ALLEGRO_SUGGEST);
    al_set_new_display_option(ALLEGRO_SAMPLES, 8, ALLEGRO_SUGGEST);
  end;
  52
  FHandle := al_create_display(aWidth, aHeight);
  if FHandle <> nil then
  begin
    LoadDefaultIcon;
    TransformScale(aFullscreen);
    al_register_event_source(gEngine.Queue, al_get_display_event_source(FHandle));
    FIsFullscreen := aFullscreen;
  end;
  FVSync := aVSync;
end;

  64end;
  65
  66function TDisplay.TransformScale(aFullscreen: Boolean): Single;
  67var
screen_x, screen_y: Integer;
scale_x, scale_y: Single;
clip_x, clip_y: Single;
Scale: Single;
  72begin
Result := 1;
if FHandle = nil then
  Exit;
  76
screen_x := al_get_display_width(FHandle);
screen_y := al_get_display_height(FHandle);
  79
if aFullscreen then
begin
  scale_x := screen_x / FSize.Width;
  scale_y := screen_y / FSize.Height;
  Scale := min(scale_x, scale_y);
  clip_x := (screen_x - Scale * FSize.Width) / 2;
  clip_y := (screen_y - Scale * FSize.Height) / 2;
  // writeln('clip-y: ', clip_y:5:2);
  al_build_transform(@FTrans, clip_x, clip_y, Scale, Scale, 0);
  al_use_transform(@FTrans);
  al_set_clipping_rectangle(Round(clip_x), Round(clip_y),
    Round(screen_x - 2 * clip_x), Round(screen_y - 2 * clip_y));
  FTransSize.Assign(clip_x, clip_y, screen_x - 2 * clip_x,
    screen_y - 2 * clip_y);
  Result := Scale;
  FTransScale := Scale;
  96
end
else
begin
  al_identity_transform(@FTrans);
  al_use_transform(@FTrans);
  al_set_clipping_rectangle(0, 0, Round(screen_x), Round(screen_y));
  FTransSize.Assign(0, 0, screen_x, screen_y);
  FTransScale := 1;
end;
 106end;
 107
 108procedure TDisplay.LoadDefaultIcon;
 109var
wnd: HWND;
hnd: THandle;
ico: TIcon;
 113begin
if FHandle = nil then Exit;
hnd := GetModuleHandle(nil);
if hnd <> 0 then
begin
  if FindResource(hnd, 'MAINICON', RT_GROUP_ICON) <> 0 then
  begin
    ico := TIcon.Create;
    ico.LoadFromResourceName(hnd, 'MAINICON');
    wnd := al_get_win_window_handle(FHandle);
    SendMessage(wnd, WM_SETICON, ICON_BIG, ico.Handle);
    ico.Free;
  end;
end;
 127end;

Oh, in my testing, setting ALLEGRO_SAMPLES higher than 3, will result in the window stuttering.

Thanks

Edgar Reynaldo

First, let's see if we can replicate it in C alone.

Here is some test code that enables multisampling on Windows 10 using MinGW-W64 gcc 8.1 :

#SelectExpand
  1
  2
  3#include <allegro5/allegro.h>
  4#include <allegro5/allegro_color.h>
  5#include <allegro5/allegro_primitives.h> 
  6#include <allegro5/allegro_direct3d.h>
  7
  8#include <cstdio>
  9#include <climits>
 10
 11int main(int argc, char **argv) { 
 12
 13   if (!al_init()) {return 1;} 
 14   al_init_primitives_addon(); 
 15   al_install_keyboard();
 16
 17   ALLEGRO_EVENT_QUEUE* queue = al_create_event_queue();
 18   if (!queue) {return 2;}
 19   al_register_event_source(queue , al_get_keyboard_event_source());
 20
 21   al_set_new_display_option(ALLEGRO_SAMPLE_BUFFERS, 1, ALLEGRO_REQUIRE);
 22   al_set_new_display_option(ALLEGRO_SAMPLES, 8, ALLEGRO_SUGGEST); 
 23
 24   bool use_opengl = false;
 25   if (use_opengl) {
 26      al_set_new_display_flags(ALLEGRO_OPENGL);
 27   }
 28   else {
 29      al_set_new_display_flags(ALLEGRO_DIRECT3D); 
 30   }
 31   ALLEGRO_DISPLAY *display = al_create_display(1024, 600); 
 32   if (!display) {return 2;}
 33   if (use_opengl) {
 34      al_set_window_title(display , "OpenGL window");
 35   }
 36   else {
 37      al_set_window_title(display , "Direct3D window");
 38   }
 39   al_register_event_source(queue , al_get_display_event_source(display));
 40
 41
 42   al_clear_to_color(al_color_name("black")); 
 43   al_draw_circle(500, 300, 200, al_color_name("white"), 5.0); 
 44   al_draw_line(200, 200, 700, 300, al_color_name("white"), 5.0); 
 45   al_flip_display(); 
 46
 47   bool quit = false;
 48   while (!quit) {
 49      ALLEGRO_EVENT ev;
 50      al_wait_for_event(queue , &ev);
 51      if (ev.type == ALLEGRO_EVENT_KEY_DOWN && ev.keyboard.keycode == ALLEGRO_KEY_ESCAPE) {quit = true;}
 52      if (ev.type == ALLEGRO_EVENT_DISPLAY_CLOSE) {quit = true;}
 53   }
 54   return 0;
 55}

However, I can't get it to jiggle. The window comes up directly. OpenGL takes longer, but still doesn't flicker.

I'm using Allegro 5.2.5

codetricity

Hmmm. Interesting. Welp, looks likes something weird on my end. I will keep digging around and see what I can find.

Thanks so much for the help with this. Respect!

Update: If I add al_set_new_display_flags(ALLEGRO_OPENGL) and use OPENGL, I don't get the jiggle at all. Can you try Direct3D on your end? This may be the culprit.

Edgar Reynaldo

Direct3D works for me with the code I posted above.

Try compiling with MinGW first, and then Delphi, to rule out any funny business on Delphi's part.

Edit, try this static exe that runs in D3D mode :

Multisampling.7z

codetricity

Hey, thanks for the sample to test. Yes, I get the jiggle with it as well. Maybe it's my NVIDIA drivers? I am using the latest versions, however. Sigh. Weird too that it only happens if it's > 3.

Hmmm, looking in the log file, I see some D3D format fails, I wonder if this has anything to do with it? I attached the log.

Edgar Reynaldo

If it jiggles on your system and not mine, then it's some kind of difference between the two of our machines.

We're both using Windows 10, so that shouldn't be it assuming you are up to date.

I've got an older NVIDIA driver. That may be it, and I'm also running an onboard integrated Intel card.

By Jove, that's it. I don't get the flicker with my integrated Intel, but I do when I run it with the NVIDIA.

EDIT
yeah, your log is messed up. It's creating and destroying the display multiple times. I'll try it with the NVIDIA and see what is going on in my log.

EDIT2
My log has many of the same failure entries. Looks like D3D and NVIDIA don't play nice together right now.

codetricity

Ahh, ok then. I'm not crazy, hehe.

Bro big props to you for your help with this. Thank you.

RESPECT!

Edgar Reynaldo

I would need to debug this to investigate further, but I've never even looked at the D3D code. It might take me some time to figure out what's going on where.

For now, I would ask that you report this as a new issue on Github :

https://github.com/liballeg/allegro5/issues

codetricity

Ok, thanks.

Issue #1030

Edgar Reynaldo

codetricity said:

RESPECT!

Ah, gratitude is always appreciated, and seldom given. You're welcome.

So if you want, you could try debugging with gdb, if you have the knowledge necessary to navigate threads and frames, get a backtrace, print values, go to the 'next' line or 'step' into a function call, set breakpoints, etc...

It looks like Delphi comes with a pretty nice Debugger, or was that just Rad?

codetricity

Yup, so true. It is what we need more of, especially this day and time — common courtesy and gratitude. The world has certainly changed in the past 20 years. I remember a time when "word was bond." Nowadays, people can be shaking your hand and stabbing you in the back, at the same time, haha! Crazy but true.

Yes, Delphi (part of RAD Studio, include C++ Builder also) has a fantastic debugger. C++ Builder can consume Delphi code, and Delphi can consume C++ Builder/Visual Studio C OJB files (to a certain degree), but to use Allegro with Delphi the C headers had to be converted, and I dynamically link to the Allegro DLL (using the 32-bit monolithic one from the release page).

I managed to compile the previous version using VS2017, but it was a lot of work and could not get some of the dependencies to compile. I eventually gave up. The reason I tried to compile myself was that at the time, the MinGW version (VS does not include a monolithic version) had some dependencies (something thread and one or two more), even on the monolithic one. I reported it and now seems this is now corrected, and allegro_monolith-5.2.dll in the latest release does not suffer from that problem. Just have to keep the headers updated now.

So far, other than this issue, I've got 98% of my library ported from SDL2 (so many DLLs you have to include, 18+, sigh) and managed to fix/include/improve features that I've been looking to do for some time now. I am delighted to be using Allegro5.

Edgar Reynaldo

codetricity said:

I've got 98% of my library ported from SDL2 ... I am delighted to be using Allegro5.

Ah, revenge is sweet.

EDIT
To really debug this, I need to use VS, but I just broke it beyond repair by getting it stuck in a 22GB update loop that will never complete. >:(

EDIT2
There's another similar issue here : https://github.com/liballeg/allegro5/issues/922

If I ever manage to fix VS, I'll try to debug it.

codetricity

Ok cool, thanks. Oh yea, I recently came across that similar issue as well.

Ahh, that sucks bro, I know about updating hosing your working install all too well. Sigh.

Edgar Reynaldo

I got Visual Studio fixed I'll look into this shortly.

My laptop power adapter died a week ago and I've been without a computer.

EDIT
Back in black!!!!

So, there's some funny business going on.

The workhorse of d3d device creation is d3d_create_device and it keeps returning D3DERR_INVALIDCALL and I can't figure out why. That's why it flickers, because the window is being created and destroyed multiple times before it succeeds.

I've enlisted the aid of Stack Overflow here :

https://stackoverflow.com/questions/55693511/d3derr-invalidcall-in-d3d-createdevice-causing-window-flicker-on-startup-in-all

Hopefully someone can help me enable debugging output in DirectX because I haven't had any luck so far.

EDIT2
I've posted a bounty for 50 reputation on StackOverflow if anyone can help me solve this ----

https://stackoverflow.com/questions/55693511/d3derr-invalidcall-in-d3d-createdevice-causing-window-flicker-on-startup-in-all

Thanks

EDIT3
It was due to an off by one error in the format list generation code. It should be fixed shortly after I finish up and make a patch. If anyone wants to help test, you can fork the 'test' branch of my allegro 5 fork here :

https://github.com/EdgarReynaldo/allegro5
https://github.com/EdgarReynaldo/allegro5/tree/test

GullRaDriel

Wooo Edgar, you finally got it !!
I'm gonna test it Sunday when I'll be back home :-D

codetricity

Edgar Reynaldo said:

It was due to an off by one error in the format list generation code. It should be fixed shortly after I finish up and make a patch. If anyone wants to help test, you can fork the 'test' branch of my allegro 5 fork here :

I can confirm that it works. Many thanks!

Edgar Reynaldo

So the code worked? And it was multisampled? In D3D mode on Nvidia?

It's kind of tricky, because to get multisampling, you need D3DMULTISAMPLE_NONMASKABLE instead of D3DMULTISAMPLE_#_SAMPLES, which is really misleading. And quality levels in no way indicates the number of samples afaics, just the number of settings that are possible. :? ?

codetricity

Here is a demo:
https://tinybiggames.com/temp/testbed.zip

1. run tbtestbed for no MSAA, run tbtestbed -msaa to enable msaa
2. also, using the scaled ttf change. toggle between window/fullscreen to see the quality is good in both

Edgar Reynaldo

MultiSamplingAntiAliasing is only good for primitives. Transformed bitmaps are not affected, so that doesn't really work.

EDIT
I can't really tell the difference between tbtestbed with or without msaa

Even running them side by side they look pretty dang similar if not the same.

codetricity

yes, I understand this. my point is that the fonts rendered on screen are the new scaled change from the other thread. if you do not use -msaa, toggling between window/fullscreen they look good in both is what I'm getting at.

Edgar Reynaldo

see my edit - my eyes are not good enough to see a difference - where do you say it's visible?

codetricity

1. run the tbtestbed with and without -msaa
2. position the console window so it slightly overlaps the window
3. click between the console window and the main window to pause and unpause
4. you can see a striking difference in jaggies without -msaa as it rotates

GullRaDriel

It's crashing when I run it with -msaa in fullscreen.

Edit: it's not compiled in debug mode. Or not with something readable for my gdb:

Thread 1 received signal SIGSEGV, Segmentation fault.
0x0000002b in ?? ()
(gdb) bt
#0  0x0000002b in ?? ()
#1  0x09bf8238 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

The crash occur when I try to use fullscreen mode, when pressing F11.

codetricity

GullRaDriel said:

It's crashing when I run it with -msaa in fullscreen. Edit: it's not compiled in debug mode. Or not with something readable for my gdb:

Ahh, sorry about that. I updated a new build (same link).

1. Now you can press 'P' key to pause the rotating polygon. To compare, pause with/without -msaa at angles where jaggies are most extreme, and you can see the difference.

2. As far as the font, it has nothing to do with MSAA, but I just wanted to point out that with the scaling that suggested in another thread, for me, I'm getting good looking fonts in both windowed and fullscreen.

3. I decided to mention the fonts here since this in my general testbed app and I was testing scaleable fonts, MSAA, and speech at the moment.

4. I added a Allegro5.cfg file and set to debug.

Edgar Reynaldo

I think I can see the difference now. It does look smoother with -msaa.

The fonts in windowed mode do look a little blurry, but not too bad.

codetricity

Another small update. Now if you click on the [more] button, you can select startup options (VSync, antialias, Direct3D/OpenGL). Pick the polygon test to check MSAA.

GullRaDriel

Confirmed to be smoother here with the latest version.

Edgar Reynaldo

I'll submit a patch for this soon.

codetricity

Hmm... question, I had only noticed that OGL startup took a bit longer but it wasn't until I added logging that I see why. It's ripping through a lot of failed modes which seems to be the cause. Is this normal behavior?

https://tinybiggames.com/temp/testbed.zip

You can see what I mean if you redownload testbed example. At startup click the more button and set render api to OpenGL, then click run and select any demo. You will see logging in the console as well a .log file in the folder.

Edgar Reynaldo

I'll say this, it's not a fair measure of startup time when you run it with a logging console enabled. printf et al take a lot of overhead pumping output through the console.

Check out Eagle's time routines

I hacked their guts out here : https://www.allegro.cc/forums/thread/617840/1042341#target They're attribution open source license. MIT if you like or BSD.

Use them to measure time before and after al_create_display using

 double start = ProgramTime::Now();
 display = al_create_display(...);
 double diff = ProgramTime::Now() - start;

codetricity

Oh, sure I understand this. I mention it because I thought it might be another situation like what you discovered with the DirectX. There are a lot of failed modes like before your fix. If this is normal then fine, but just thought I would bring it up only in case it was.

Edgar Reynaldo

I didn't say it was normal, and I didn't say it wasn't also a performance issue to be addressed. I just wanted the test to be accurate, and see if the kind of delay being experienced is enough to cause discomfort.

codetricity

Starting up from the command-line
al_create_display timing:
-milliseconds: 1591.91
-seconds : 1.59

In doing this I noticed also there may be an issue with al_draw_tinted_scaled_rotated_bitmap_region. When using OGL, it does not seem to honor the color. In an example, I load in a white bitmap and dynamically change the color. In OGL, they stay white. Hmm. You will see what I mean if you select OGL and run the ChainAction Test.

Edgar Reynaldo

1.59 seconds is a noticeable delay. I will look into it.

Here's a quick static win32 binary and source of a simple test program that measures startup and shutdown time.

Distro1.7z

Arguments to the program :

W H { [DX|dx|DirectX] | [FS|fs|fullscreen] | [MSAA|msaa] | NSAMPLES }

These are the times reported :

I am running Allegro 5.2.5 on Win10 on a 2.7GHz i7-5700HQ with two different adapters. An integrated Intel HD and an NVIDIA

What hardware are you using?

OpenGL and NVIDIA are just not getting along well.

When I enable multisampling and select OpenGL for the driver, it takes around 2150 MS, just over 2 full seconds in windowed mode and fullscreen took around 644 ms.

DirectX is blazing fast for fullscreen, taking only .1 seconds on the Intel HD. NVIDIA sucks again, with 576 ms for fullscreen OGL MSAA with 8 samples.

al_destroy_display takes anywhere between 4 and 6 seconds in fullscreen, which sucks. And sometimes with the NVIDIA driver, al_destroy_display hangs...???

This is with the Intel HD :

c:\ctwoplus\progcode\allegro5\test\CreateDisplay>display_test.exe 1920 1080 FS MSAA 8
Creating GL fullscreen 1920 x 1080 with 8 sampled MSAA display...
al_create_display returned 0098DCF8
al_create_display took 0.097252 seconds (97.252380 ms)
al_destroy_display took 5.984846 (5984.846273 MS) seconds.

c:\ctwoplus\progcode\allegro5\test\CreateDisplay>display_test.exe 1920 1080 DX FS MSAA 8
Creating DX fullscreen 1920 x 1080 with 8 sampled MSAA display...
al_create_display returned 0094D8E8
al_create_display took 0.093484 seconds (93.484095 ms)
al_destroy_display took 5.988315 (5988.314631 MS) seconds.

c:\ctwoplus\progcode\allegro5\test\CreateDisplay>display_test.exe 1920 1080 DX FS MSAA 8
Creating DX fullscreen 1920 x 1080 with 8 sampled MSAA display...
al_create_display returned 0285E0E0
al_create_display took 0.576954 seconds (576.954277 ms)
al_destroy_display took 5.440986 (5440.985844 MS) seconds.

c:\ctwoplus\progcode\allegro5\test\CreateDisplay>display_test.exe 1920 1080 FS MSAA 8
Creating GL fullscreen 1920 x 1080 with 8 sampled MSAA display...
al_create_display returned 000DE4F0
al_create_display took 0.438442 seconds (438.442356 ms)
al_destroy_display took 4.443937 (4443.937217 MS) seconds.

c:\ctwoplus\progcode\allegro5\test\CreateDisplay>

This is with the NVIDIA FX :

c:\ctwoplus\progcode\allegro5\test\CreateDisplay>display_test.exe 1920 1080 MSAA 8
Creating GL windowed 1920 x 1080 with 8 sampled MSAA display...
al_create_display returned 029ED528
al_create_display took 2.041416 seconds (2041.416157 ms)
al_destroy_display took 0.126034 (126.033589 MS) seconds.

c:\ctwoplus\progcode\allegro5\test\CreateDisplay>display_test.exe 1920 1080 MSAA 8
Creating GL windowed 1920 x 1080 with 8 sampled MSAA display...
al_create_display returned 008CD528
al_create_display took 1.881896 seconds (1881.895660 ms)
^C
c:\ctwoplus\progcode\allegro5\test\CreateDisplay>display_test.exe 1920 1080 DX MSAA 8
Creating DX windowed 1920 x 1080 with 8 sampled MSAA display...
al_create_display returned 0093D558
al_create_display took 2.094915 seconds (2094.915306 ms)
al_destroy_display took 0.048418 (48.417875 MS) seconds.

c:\ctwoplus\progcode\allegro5\test\CreateDisplay>display_test.exe 1920 1080 DX MSAA 8
Creating DX windowed 1920 x 1080 with 8 sampled MSAA display...
al_create_display returned 0298D558
al_create_display took 1.886072 seconds (1886.072211 ms)
al_destroy_display took 0.079688 (79.687833 MS) seconds.

c:\ctwoplus\progcode\allegro5\test\CreateDisplay>

So just using the NVIDIA makes it take 2 seconds to start. That seems wrong somehow. I better try to update my drivers and see if that makes a difference.

Here's the code :

#SelectExpand
   1
   2
   3
   4
   5#include <stdio.h>
   6#include "allegro5/allegro.h"
   7#include "allegro5/allegro_font.h"
   8#include "allegro5/allegro_ttf.h"
   9#include "HighPerfTimer.hpp"
  10
  11
  12
  13int main(int argc , char** argv) {
 
 bool use_gl = true;
 bool fs = false;
 bool ms = false;
 int sw = 800;
 int sh = 600;
 int rw = 0;
 int rh = 0;
 int NSAMP = 0;
 int ns = 0;
 if (argc > 1) {
    if (argc > 2) {
       if (sscanf(argv[1] , "%d" , &rw) == 1) {
          sw = rw;
       }
       if (sscanf(argv[2] , "%d" , &rh) == 1) {
          sh = rh;
       }
    }
    if (argc > 2) {
          
       for (unsigned int i = 3 ; i < (unsigned int)argc ; ++i) {
          
          if (strncmp(argv[i] , "DX" , 2) == 0) {
             use_gl = false;
          }
          if (strncmp(argv[i] , "DirectX" , 7) == 0) {
             use_gl = false;
          }
          if (strncmp(argv[i] , "dx" , 2) == 0) {
             use_gl = false;
          }
          if (strncmp(argv[i] , "FS" , 2) == 0) {
             fs = true;
          }
          if (strncmp(argv[i] , "fs" , 2) == 0) {
             fs = true;
          }
          if (strncmp(argv[i] , "fullscreen" , 9) == 0) {
             fs = true;
          }
          if (strncmp(argv[i] , "MSAA" , 4) == 0) {
             ms = true;
          }
          if (strncmp(argv[i] , "msaa" , 4) == 0) {
             ms = true;
          }
          if (sscanf(argv[i] , "%d" , &ns) == 1) {
             NSAMP = ns;
          }
       }
    }
    
 }
 
 if (!al_init()) {return -1;}
 if (!al_init_font_addon()) {return -2;}
 if (!al_init_ttf_addon()) {return -3;}
 
 if (!al_install_keyboard()) {return -10;}
 
 
 if (ms) {
    al_set_new_display_option(ALLEGRO_SAMPLE_BUFFERS , 1 , ALLEGRO_REQUIRE);
    al_set_new_display_option(ALLEGRO_SAMPLES , NSAMP , ALLEGRO_REQUIRE);
 }
 
 al_set_new_display_flags(fs?ALLEGRO_FULLSCREEN:ALLEGRO_WINDOWED | use_gl?ALLEGRO_OPENGL:0);
 
 ALLEGRO_DISPLAY* d = NULL;
 
 char buf[1024] = {0};
 char buf2[1024] = {0};
 
 sprintf(buf , "Creating %s %s %d x %d with %d sampled %s display...\n" , use_gl?"GL":"DX" , fs?"fullscreen":"windowed" , sw , sh , NSAMP , ms?"MSAA":"NonAliased");
  89
 printf("%s" , buf);
 
 double start = ProgramTime::Now();
 d = al_create_display(sw , sh);
 double diff = (double)ProgramTime::Now() - start;
 printf("al_create_display returned %p\n" , (void*)d);
 sprintf(buf2 , "al_create_display took %lf seconds (%lf ms)\n" , diff , 1000.0*diff);
 printf("%s" , buf2);
 
 if (!d) {return 1;}
 
 ALLEGRO_EVENT_QUEUE* q = al_create_event_queue();
 al_register_event_source(q , al_get_display_event_source(d));
 al_register_event_source(q , al_get_keyboard_event_source());
 
 ALLEGRO_FONT* f = al_load_ttf_font("Verdana.ttf" , 20 , 0);
 if (!f) {
    f = al_create_builtin_font();
 }
 if (!f) {return 2;}
 
 al_set_target_backbuffer(d);
 al_clear_to_color(al_map_rgb(255,255,255));
 al_draw_textf(f , al_map_rgb(0,0,0) , sw/2 , sh/2 - al_get_font_ascent(f)/2.0 , ALLEGRO_ALIGN_CENTRE , "%s" , buf);
 al_draw_textf(f , al_map_rgb(0,0,0) , sw/2 , sh/2 + al_get_font_ascent(f)/2.0 + 10, ALLEGRO_ALIGN_CENTRE , "%s" , buf2);
 al_flip_display();
 116
 ALLEGRO_EVENT ev;
 al_wait_for_event(q , &ev);
 
 if (d) {
    start = ProgramTime::Now();
    al_destroy_display(d);
    diff = (double)ProgramTime::Now() - start;
    
    printf("al_destroy_display took %lf (%lf MS) seconds.\n" , diff , 1000.0*diff);
    d = 0;
 }
 
 
 
 
 return 0;
 133}

codetricity

I'm running a GT1030, and my numbers are a bit better than yours but way slower than your Intel. Agreed with, something afoot with NVIDIA. I do have the latest drivers. Maybe its a result of them optimizing for specific games which then effect more general use?

Edgar Reynaldo

I'm guessing its a difference in the number of modes available, and the number of extensions supported, between the Intel HD and the NVIDIA.

Because each enumeration of a display mode and each time an extension is loaded, that adds up. I'll have to dig deeper into the code tomorrow or in a few days. Maybe I can update my patch to fix NVIDIA gpus or just window creation in general.

EDIT
<anti_lock_bump>
How can I tell if the GFX card is NVIDIA?
</bump>

Thread #617793. Printed from Allegro.cc