|
Allegro 4.9.20 released |
Max Savenkov
Member #4,613
May 2004
|
Allegro 4.9.20 crashes when I start to use primitives addon. It happens in different places, but always related to operations with default_shader. The following code, which combines video mode change and drawing primitives crahses after first change on al_draw_filled_rectangle. 1#include <allegro5/allegro5.h>
2#include <allegro5/allegro_direct3d.h>
3#include <allegro5/allegro_image.h>
4#include <allegro5/allegro_primitives.h>
5
6int main()
7{
8 al_init();
9 al_init_primitives_addon();
10 al_install_keyboard();
11
12 al_set_new_display_refresh_rate(60);
13 al_set_new_display_flags( ALLEGRO_FULLSCREEN | ALLEGRO_DIRECT3D );
14 ALLEGRO_DISPLAY *disp = al_create_display(1024, 768);
15
16 if (!disp)
17 return -1;
18
19 bool fullscreen = true;
20
21 while( true )
22 {
23 ALLEGRO_KEYBOARD_STATE state;
24 al_get_keyboard_state( &state );
25 if ( al_key_down( &state, ALLEGRO_KEY_ESCAPE ) )
26 break;
27
28 al_draw_filled_rectangle( 200,200,300,300,al_map_rgba(255,255,134,45));
29 al_flip_display();
30
31 if ( al_key_down( &state, ALLEGRO_KEY_ENTER ) )
32 {
33 fullscreen = !fullscreen;
34 al_set_new_display_flags( (fullscreen ? ALLEGRO_FULLSCREEN : ALLEGRO_WINDOWED) | ALLEGRO_DIRECT3D );
35
36 al_destroy_display( disp );
37 disp = al_create_display( 1024, 768 );
38 al_set_current_display( disp );
39 }
40 }
41
42 return 0;
Crash callstack: > allegro_primitives-4.9.dll!_al_setup_default_shader(void * dev=0x001c1f00) Line 713 + 0x12 bytes C allegro_primitives-4.9.dll!_al_draw_prim_raw(ALLEGRO_BITMAP * texture=0x00000000, const void * vtx=0x0012fd74, const ALLEGRO_VERTEX_DECL * decl=0x00000000, const int * indices=0x00000000, int num_vtx=4, int type=5) Line 224 + 0x6 bytes C allegro_primitives-4.9.dll!_al_draw_prim_directx(ALLEGRO_BITMAP * texture=0x00000000, const void * vtxs=0x0012fd74, const ALLEGRO_VERTEX_DECL * decl=0x00000000, int start=0, int end=4, int type=5) Line 440 + 0x26 bytes C allegro_primitives-4.9.dll!al_draw_prim(const void * vtxs=0x0012fd74, const ALLEGRO_VERTEX_DECL * decl=0x00000000, ALLEGRO_BITMAP * texture=0x00000000, int start=0, int end=4, int type=5) Line 91 + 0x1f bytes C allegro_primitives-4.9.dll!al_draw_filled_rectangle(float x1=200.00000, float y1=200.00000, float x2=300.00000, float y2=300.00000, ALLEGRO_COLOR color={...}) Line 298 + 0xc3 bytes C A5_FullScreenTest.exe!main() Line 37 + 0xa5 bytes C++ A5_FullScreenTest.exe!__tmainCRTStartup() Line 582 + 0x19 bytes C A5_FullScreenTest.exe!mainCRTStartup() Line 399 C Final crash place: void _al_setup_default_shader(void* dev) { IDirect3DDevice9* device = (IDirect3DDevice9*)dev; setup_transforms(device); IDirect3DDevice9_SetVertexShader(device, default_shader); } On line "IDirect3DDevice9_SetVertexShader(device, default_shader);" If it's my code, can you tell me what am I doing wrong? And if it's a bug... Well, it's a bug
|
Michał Cichoń
Member #11,736
March 2010
|
Thomas Fjellstrom said: If you read a little more carefully, you'll see that it supports a deps directory in the BUILD folder as well. So you can put a deps dir inside \build\win32_vc8, and inside \build\win32_vc10 etc. You are right. There are also non-variable dependencies, for example D3D SDK. Those although can be copied in some pre-build action into deps. I can rearrange my build directories to take advantage of deps. "God starts from scratch too" |
SiegeLord
Member #7,827
October 2006
|
Max Savenkov said: If it's my code, can you tell me what am I doing wrong? And if it's a bug... Well, it's a bug Yeah, it's a bug. I'll work on a solution today. For now, a workabout should be to re-init the primitives addon after the mode change, I think. Do that by calling these: al_shutdown_primitives_addon(); al_init_primitives_addon(); Incidentally... is it in our spec to be able to call al_init_whatever multiple times with no error? "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
Max Savenkov
Member #4,613
May 2004
|
Thanks, SiegeLord! Also, my other program crashes with 4.9.20 when I exit it without even changing video mode in void _al_destroy_default_shader(void) { if(default_shader) { IDirect3DVertexShader9_Release(default_shader); default_shader = 0; } } at "IDirect3DVertexShader9_Release(default_shader);". I can't reproduce it now, because I reverted back to 4.9.19 for release of my own version, but I will try to supply more details later if you need them.
|
wiseguy
Member #44
April 2000
|
Heya folks, I've been working on getting back into things and I'm messing around with Allegro 5. I have been working on a simple window for some tests, and up until today everything was compiling fine. Actually it compiles just fine, except that I started getting some warnings that I did not get before. The thing is I moved my files over to a new project, and I'm thinking I just missed something in the project settings. I'm using VS 2008 on windows Vista, and have built allegro and installed from SVN. kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib allegro_image-static.lib allegro-static.lib allegro_main-static.lib allegro_dialog-static.lib winmm.lib psapi.lib "C:\Program Files\Microsoft DirectX SDK (August 2009)\Lib\x86\dxguid.lib" "C:\Program Files\Microsoft DirectX SDK (August 2009)\Lib\x86\d3d9.lib" "C:\Program Files\Microsoft DirectX SDK (August 2009)\Lib\x86\dinput8.lib" opengl32.lib glu32.lib $(NOINHERIT) I also define ALLEGRO_STATICLINK the warnings I'm getting are: 1>user32.lib(USER32.dll) : warning LNK4006: __NULL_IMPORT_DESCRIPTOR already defined in kernel32.lib(KERNEL32.dll); second definition ignored I pulled the libraries for input out of one of the examples, so I am thinking I don't need the allegro_dialog lib, and if I do not need that do I need GLU32? My project is a small library that I will import into my bigger project. I must have missed something when I moved everything into a new project. Appreciate any ideas. By the way, I notice on the wiki there isn't a page for installing Allegro 5 from SVN using cmake for VS, but I had absolutely no problems with it here. thanks WG |
Oscar Giner
Member #2,207
April 2002
|
wiseguy: if I understood you correctly, your project is just a static library, isn't it? In that case you don't have to put anything in the input area of the linker. You link against all libraries you use when you create an executable (or a dll). So when you use you lib in a project that generates an executable, it's then when you put all those libraries (and your) in the linker input. -- |
wiseguy
Member #44
April 2000
|
Ah, man now I feel stupid. Like I said I'm just getting back into things after having a lot of time off from programming. Thanks for the help. WG |
Dario ff
Member #10,065
August 2008
|
Well, I was able to solve my problem with the D3D driver and CG. Apparently, calling CGD3D9BindProgram(NULL) doesn't do what I thought it did. It doesn't set the actual vertex/pixel shader program as NULL, unlike the CGGL call with NULL. The Shader program was being used throughout the whole program, which provoked really weird behaviour. You need to manually set the actual VertexShader and PixelShader program by hand with the D3D9Device with al_get_d3d_device(). Just letting people know about that, and I don't know if TrentG ran into a similar problem. TranslatorHack 2010, a human translation chain in a.cc. |
Trent Gamblin
Member #261
April 2000
|
I use effects in the shader addon, they're easier to work with I think. You just do something like this: // set shader variables UINT required_passes; effect->Begin(&required_passes, 0); effect->BeginPass(0); // draw effect->EndPass(); effect->End(); Of course if you actually have an effect which requires multiple passes you just loop from BeginPass to EndPass (including drawing). But since OpenGL shaders don't work like that (it's a higher level abstraction and you can get the same effect, though), neither does the shader addon.
|
Dario ff
Member #10,065
August 2008
|
Trent Gamblin said: Of course if you actually have an effect which requires multiple passes That was one of the main reasons I didn't use the effect in the first place. Since there was no "pass" concept on the GLSL shader and it needed to maintain platform AND display driver neutrality, I ditched that off. I gave support for taking the Vertex/Pixel shader program out of the effect file, and using it individually. To solve your problem, well, you could provide an specific function, like al_use_shader_pass(int) or something like that. You should just need to document that it only works for CG effects, and are provided in case the user wants them. I don't think there's really a point in keeping things as neutral as possible between CG and GLSL. It should be neutral depending on the display driver, but not between different shader formats. Mostly, because CG users can use it for both Direct3D and OpenGL(I just did this with Arkab, now it works well on both drivers). Just my 2 cents. It's your own add-on after all, unless you need it, you don't really need to do this. TranslatorHack 2010, a human translation chain in a.cc. |
Erin Maus
Member #7,537
July 2006
|
It seems to me that in OpenGL, locking bitmaps does not work properly. For example, take this code: 1#define ALLEGRO_NO_MAGIC_MAIN
2#include <allegro5/allegro5.h>
3#include <allegro5/allegro_opengl.h>
4#include <stdio.h>
5
6int main(void)
7{
8 ALLEGRO_BITMAP * bitmap;
9 ALLEGRO_DISPLAY * display;
10 ALLEGRO_LOCKED_REGION * region;
11
12 al_init();
13
14 al_set_new_display_flags(ALLEGRO_OPENGL);
15 display = al_create_display(640, 480);
16
17 bitmap = al_create_bitmap(64, 64);
18 region = al_lock_bitmap(bitmap, ALLEGRO_PIXEL_FORMAT_ABGR_8888_LE, ALLEGRO_LOCK_READONLY);
19
20 printf("%d", region->pitch);
21
22 al_unlock_bitmap(bitmap);
23 al_destroy_bitmap(bitmap);
24 al_destroy_display(display);
25
26 return 0;
27}
This prints -256 for region->pitch, which does not seem sensible to me! In Direct3D it works fine and prints 256. At first I thought it was a problem with my wrapper, but it's not. Sorry if it's fixed in SVN.... I don't have any SVN tools on this computer. --- |
Elias
Member #358
May 2000
|
-256 is the correct pitch. OpenGL textures are upside down (i.e. pixel 0/0 is the bottom-left pixel instead of the top-left pixel). So to avoid a CPU intense flip of the whole texture, we point region->data to the end of the buffer and use a negative pitch. Accessing the pixels with data[x + y * pitch] will still work. -- |
Slartibartfast
Member #8,789
June 2007
|
I've always wondered why Allegro bitmaps are upside down (0,0 being top left instead of bottom left), it is always annoying because you would generally want the bottom to be 0 (so that someone starting on the bottom of the screen [which is where you usually start] can start at 32,0) ---- |
Erin Maus
Member #7,537
July 2006
|
Elias said: -256 is the correct pitch. OpenGL textures are upside down (i.e. pixel 0/0 is the bottom-left pixel instead of the top-left pixel). So to avoid a CPU intense flip of the whole texture, we point region->data to the end of the buffer and use a negative pitch. Accessing the pixels with data[x + y * pitch] will still work. I see! Sorry for the confusion on my part then --- |
Evert
Member #794
November 2000
|
Slartibartfast said: I've always wondered why Allegro bitmaps are upside down (0,0 being top left instead of bottom left), it is always annoying because you would generally want the bottom to be 0 (so that someone starting on the bottom of the screen [which is where you usually start] can start at 32,0) (PC) computer graphics memory addresses the top left pixel as 0,0. Has for the past 30 years at least. |
Arthur Kalliokoski
Second in Command
February 2005
|
That's because the old time PC people were used to starting at top left for text screens, where it made sense. They all watch too much MSNBC... they get ideas. |
Michał Cichoń
Member #11,736
March 2010
|
I just want to bump one bug. Currently D3D driver crashes while closing display. Elias said something about revisiting destruction order. I'm don't know internal Allegro design, so I don't think I'm good man for the job. You can find more info there. "God starts from scratch too" |
SiegeLord
Member #7,827
October 2006
|
I haven't forgotten about that one It's next on my list as soon as the primitives issues are taken care of. "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
Trent Gamblin
Member #261
April 2000
|
I got around to building some 4.9.20 binaries for MSVC tonight. They're up at http://allegro5.org.
|
Mark Oates
Member #1,146
March 2001
|
I tried swapping in this latest build (MSVC) and am getting some unique compile errors: 1>------ Build started: Project: A5Template, Configuration: Release Win32 ------ 1> main.cpp 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/file.h(27): error C2059: syntax error : '__cdecl' 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/file.h(27): error C2091: function returns function 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/file.h(27): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/file.h(27): warning C4183: 'int64_t': missing return type; assumed to be a member function returning 'int' 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/file.h(28): error C2061: syntax error : identifier 'int64_t' 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/file.h(58): error C2143: syntax error : missing ';' before '__cdecl' 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/file.h(58): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/file.h(58): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/file.h(59): error C2061: syntax error : identifier 'int64_t' 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/file.h(63): error C2143: syntax error : missing ';' before '__cdecl' 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/file.h(63): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/file.h(63): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/altime.h(17): error C2146: syntax error : missing ';' before identifier '__pad1__' 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/altime.h(17): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/altime.h(17): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/altime.h(18): error C2146: syntax error : missing ';' before identifier '__pad2__' 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/altime.h(18): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/altime.h(18): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/events.h(173): error C2146: syntax error : missing ';' before identifier 'count' 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/events.h(173): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/events.h(173): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/timer.h(58): error C2143: syntax error : missing ';' before '__cdecl' 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/timer.h(58): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/timer.h(58): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\allegro5/timer.h(59): error C2061: syntax error : identifier 'int64_t' ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
-- |
Trent Gamblin
Member #261
April 2000
|
I'm sure I've heard that MSVC 10 can't build or use Allegro 5 yet, without difficulty... I haven't tried it yet myself.
|
Mark Oates
Member #1,146
March 2001
|
I haven't had problems with any previous A5 builds. Should I just stick with 4.9.19? It worked pretty well. -- |
Trent Gamblin
Member #261
April 2000
|
Are you using the binaries or did you compile it yourself?
|
Mark Oates
Member #1,146
March 2001
|
I'm using those binaries from allegro5.org -- |
Trent Gamblin
Member #261
April 2000
|
Wow that's weird. I didn't do anything differently. I've compiled with MSVC 9 2008 all along. I need to install 2010 and see what's wrong.
|
|
|