|
This thread is locked; no one can reply to it. |
1
2
|
Allegro 5.0.9 released! |
simast
Member #12,668
March 2011
|
Matthew Leverton said: But this page ... shows Windows XP support... To get your executable to run under Windows XP with Visual Studio 2012, you need to: 1) Build with Visual Studio 2012 (Update 1 installed and required for XP support) and to run.. a) Statically link with MSVC 11.0 runtime I take it the allegro binary builds that were posted above had the default "v110" Platform Toolset selected - which requires Vista+ to run. Edit: See this blog post for more info. MS had the idea they can silently drop Windows XP support.. but then got lots of heat based on their decision and that's why now you have this whole separate Platform Toolset and Update 1 fiasco
|
Matthew Leverton
Supreme Loser
January 1999
|
That's helpful. I'm just trying to answer somebody's question on Stackoverflow. I would guess that the Allegro binaries weren't built that way, and thus do require Vista. |
Neil Roy
Member #2,229
April 2002
|
Many thanks for posting the binaries. It's much appreciated. Edit: Michał Cichoń said: If you think version for some toolchain is missing, let me know. I don't suppose binaries for 4.7.1 TDM would be possible? It's what comes with Code::Blocks by default now and I wouldn't mind upgrading my 4.6.1 to it. (ie: allegro-5.0.9-mingw-4.7.1-tdm.7z) I would compile it myself but I always seem to have problems. Maybe I'll try again. --- |
beoran
Member #12,636
March 2011
|
You know, maybe we should convince he code blocks people to package allegro 5 , it's mature enough.... |
david nickson
Member #15,015
March 2013
|
Hi, I can't seem to get ALLEGRO_MIN_LINEAR and ALLEGRO_MAG_LINEAR to work with allegro 5.0.9 and Direct3D. Thanks |
Trent Gamblin
Member #261
April 2000
|
That was a long time ago. It should be working now. What do you mean by "it doesn't work"?
|
david nickson
Member #15,015
March 2013
|
Thanks for the reply, It looks like that the allegro_min_linear/allegro_max_linear is not taken into account with direct3d rendering. I attached an image to show the differences. I'm using allegro 5.0.9 (precompiled versions) |
Trent Gamblin
Member #261
April 2000
|
Can you either 1) post your code or a small example that demonstrates this or 2) try running ex_filter (since you're using the binaries you may have to download the 5.0.9 source and compile it.)
|
david nickson
Member #15,015
March 2013
|
Thanks for the suggestions, it was very helpful I compiled the ex_filter sample and it didn't have the bug. I updated the ex_filter sample to use al_draw_prim and could reproduce the issue. I also uploaded a screenshot : top is opengl, bottom is direct3d Thanks. |
Trent Gamblin
Member #261
April 2000
|
I guess the primitives addon may change some state, thought not sure why it would change that particular state. Don't even have Allegro on this computer to check. My initial guess is the shaders primitives uses get it wrong?
|
SiegeLord
Member #7,827
October 2006
|
Looks like in OpenGL the sampler state is a bitmap property, while in D3D it is a display property... i.e. you need to re-set it before every draw call. I fixed this in 5.1. I think this also affects the shader stuff (I didn't see if the sampler states are set anywhere for textures other than the first one). It's a little late, so I won't be able to fix this myself. EDIT: Incidentally, a workabout that might work (untested) is to draw the affected bitmaps with al_draw_bitmap_region (just use a 0 width destination, so nothing is actually drawn). Allegro doesn't bother to reset the sampler states, so they will remain set correctly when the primitives code runs. The proper fix will be in 5.0.10 though (and is already in 5.1 branch and will be in the 5.1.6 snapshot). "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
david nickson
Member #15,015
March 2013
|
The workaround with an empty al_draw_bitmap_region works! Thanks a lot Trent and SiegeLord!;) |
|
1
2
|