allegrogl-general

Re: [AGL] Can't open midi dev file. Strange error.

[David N. <do...@ma...>]

Sorry to trouble you. Your project is the allego opengl project and I
need the allegro plain old project.

Thanks!

On Sun, 12 Jul 2020 13:27:52 -0400
David Niklas <do...@ma...> wrote:
> Hello,
> I'm using allegro 4 on Devuan (Debian) Linux. I need a bit of advise
> regarding how to trouble shoot this.
>
> % worminator
> ALSA lib rawmidi_hw.c:233:(snd_rawmidi_hw_open) open /dev/snd/midiC0D0
> failed: No such file or directory
>
> To debug, I started by confirming the existence of the file and that I
> have permissions to access it.
>
> % ls -l /dev/snd/midiC2D*
> crw-rw----+ 1 root audio 116, 25 Jul  6 21:56 /dev/snd/midiC2D0
> crw-rw----+ 1 root audio 116, 26 Jul  6 21:56 /dev/snd/midiC2D1
> crw-rw----+ 1 root audio 116, 29 Jul  6 22:19 /dev/snd/midiC2D2
> crw-rw----+ 1 root audio 116, 30 Jul  6 22:19 /dev/snd/midiC2D3
> % groups
> me cdrom floppy sudo audio video users bluetooth
>
> I'm using apparmor as my security suite. I run my own kernel and
> compiled out SELinux.
>
> Thanks,
> David

[AGL] Can't open midi dev file. Strange error.

[David N. <do...@ma...>]

Hello,
I'm using allegro 4 on Devuan (Debian) Linux. I need a bit of advise
regarding how to trouble shoot this.

% worminator
ALSA lib rawmidi_hw.c:233:(snd_rawmidi_hw_open) open /dev/snd/midiC0D0
failed: No such file or directory

To debug, I started by confirming the existence of the file and that I
have permissions to access it.

% ls -l /dev/snd/midiC2D*
crw-rw----+ 1 root audio 116, 25 Jul  6 21:56 /dev/snd/midiC2D0
crw-rw----+ 1 root audio 116, 26 Jul  6 21:56 /dev/snd/midiC2D1
crw-rw----+ 1 root audio 116, 29 Jul  6 22:19 /dev/snd/midiC2D2
crw-rw----+ 1 root audio 116, 30 Jul  6 22:19 /dev/snd/midiC2D3
% groups
me cdrom floppy sudo audio video users bluetooth

I'm using apparmor as my security suite. I run my own kernel and compiled
out SELinux.

Thanks,
David

Re: [AGL] D bindings and the extensions mechanism

[Elias P. <all...@gm...>]

On 8/28/07, to...@te... <to...@te...> wrote:
> The only set of D headers for openGL that is currently maintained,
> DerelictGL[1], contains its own extension loading mechanism.  So I'm
> wondering if I should just use that, instead of AllegroGL's system.  My
> understanding of AllegroGL is that it contains two more or less
> independent parts: the Allegro/OpenGL interoperability, and the
> extension loading.  Since I'll be needing only the former, I wonder if
> it would be possible to disable AllegroGL's extension loading.  Would
> that be a simple feature to add to AllegroGL?

AllegroGL uses extensions itself, so you will have to allow it loading
them. I'm not very familiar with this part of AllegroGL myself, so I
have no idea what "loading" of extensions involves.

If you are just talking about exposing the extensions to the user,
that's different of course - maybe you can automatically do the calls
required with DerelictGL, so users can just check for and use the
extensions, in a similar way as with AllegroGL. I hope this makes
sense, as I don't know much about OpenGL extensions.

exext.c for example has things like this:

if (allegro_gl_extensions_GL.ARB_multisample) {
    glEnable(GL_MULTISAMPLE_ARB);
}

How would you do the same in D?

[AGL] D bindings and the extensions mechanism

[<to...@te...>]

The only set of D headers for openGL that is currently maintained,
DerelictGL[1], contains its own extension loading mechanism.  So I'm
wondering if I should just use that, instead of AllegroGL's system.  My
understanding of AllegroGL is that it contains two more or less
independent parts: the Allegro/OpenGL interoperability, and the
extension loading.  Since I'll be needing only the former, I wonder if
it would be possible to disable AllegroGL's extension loading.  Would
that be a simple feature to add to AllegroGL?

So far, using derelict's extension loading system doesn't seem to
conflict with AllegroGL's.  So it's probably possible to just have both
enabled.  Just seems like a waste to load the extensions twice, though.

I'm not completely sure that I'll end up using Derelict's extension
loading instead of AllegroGL's yet.  But since it can reduce DAllegroGL
to only one or two files, it's a tempting option.  The downside is that
the users have to add an extra function call (DerelictGL.load()) to
their initialization code, plus DerelictGL.loadExtensions() if they want
extensions, and DerelictGLU.load() if they need GLU stuff.  In return
for that, they get the DLL file automatically loaded at runtime,
exceptions thrown if the DLL itself or any extensions they are importing
are missing, etc.

Whether I should keep the allegro_gl_extensions_* structs or not, is
another question.  DerelictGL has something like it, but it could be a
bit confusing that something mentioned in AllegroGL's docs doesn't work
in DAllegroGL.  So maybe I should keep that part.

Any opinions are welcome. :)


[1] http://www.dsource.org/projects/derelict

Re: [AGL] 0.4.2 is ready

[Elias P. <el...@us...>]

On Sat, 2007-07-21 at 11:14 +0200, Milan Mimica wrote:
> Since allegro 4.2.2 is about to be released soon, and allegrogl 0.4.1 
> cannot be built with it, we're bound to release 0.4.2 too.
> 
> I've just upped the version number to 0.4.2 and allegrogl is ready to be 
> packed and uploaded. Unfortunately, I don't have the time&resources to 
> do this right now and I'll be gone for about a week. Feel free to 
> release AGL whenever you feel comfortable. There are no special 
> precautions by me, it should be easy, it's been done without me 
> gazillion times before ;).
> 

Ok, I ran the zipup.sh and uploaded the resulting files as 0.4.2 RC1 - I
hope that's everything that needs to be done. Going to post it on
allegro.cc.

-- 
Elias Pschernig <el...@us...>

[AGL] 0.4.2 is ready

[Milan M. <mil...@gm...>]

Since allegro 4.2.2 is about to be released soon, and allegrogl 0.4.1 
cannot be built with it, we're bound to release 0.4.2 too.

I've just upped the version number to 0.4.2 and allegrogl is ready to be 
packed and uploaded. Unfortunately, I don't have the time&resources to 
do this right now and I'll be gone for about a week. Feel free to 
release AGL whenever you feel comfortable. There are no special 
precautions by me, it should be easy, it's been done without me 
gazillion times before ;).


-- 
Milan Mimica
http://sparklet.sf.net

Re: [AGL] allglint.h and the D bindings

[Milan M. <mil...@gm...>]

to...@te... wrote:
> Is allglint.h part of the public API?  It contains some structs with the 
> same name as variables.  allegro_gl_display_info is one example.  This 
> isn't allowed in D.  So if this stuff is supposed to be public, I wonder 
> if you would consider renaming either the structs or the variables.
> 

allglint.h and glvtable.h are internal


-- 
Milan Mimica
http://sparklet.sf.net

[AGL] allglint.h and the D bindings

[<to...@te...>]

Is allglint.h part of the public API?  It contains some structs with the 
same name as variables.  allegro_gl_display_info is one example.  This 
isn't allowed in D.  So if this stuff is supposed to be public, I wonder 
if you would consider renaming either the structs or the variables.

Re: [AGL] Small patch for recent allegro changes.

[Milan M. <mil...@gm...>]

Milan Mimica wrote:
> 
> Then I'm going to apply such patch that keeps AGL compatible with 
> allegro version < 4.2.2.
> 

Commited this one:

--- trunk/include/alleggl.h	2007-06-05 08:30:07 UTC (rev 1240)
+++ trunk/include/alleggl.h	2007-06-25 13:13:08 UTC (rev 1241)
@@ -68,8 +68,14 @@
  #include "allegrogl/gl_ext.h"

  #ifdef ALLEGRO_WITH_XWINDOWS
-#ifndef HAVE_LIBPTHREAD
-#   error AllegroGL requires Allegro to have pthread support enabled!
+#if (ALLEGRO_SUB_VERSION == 2) && (ALLEGRO_WIP_VERSION < 2)
+#   ifndef HAVE_LIBPTHREAD
+#      error AllegroGL requires Allegro to have pthread support enabled!
+#   endif
+#else
+#   ifndef ALLEGRO_HAVE_LIBPTHREAD
+#      error AllegroGL requires Allegro to have pthread support enabled!
+#   endif
  #endif
  #include <alleggl_config.h>
  #endif


-- 
Milan Mimica
http://sparklet.sf.net

Re: [AGL] Looking into D bindings for allegroGL

[<to...@te...>]

to...@te... wrote:
> to...@te... wrote:
>> All examples work, except for two.  The exext exsample segfaults at what 
>> is line 249 in the C version: 'glGenProgramsARB(1, &pid);'.  I have no 
>> idea how this happens, so I'm hoping one of you knows what can cause 
>> this function to crash.
>> 
> 
> I've made some progress on this.  If I print the address of 
> glGenProgramsARB, and then print what 
> wglGetProcAddress("glGenProgramsARB") returns, they are NOT equal. 
> Shouldn't they be?  Any idea how this can end up being set to the wrong 
> address?
> 
> If I just call the functions I get from wglGetProcAddress, exext runs a 
> few lines further, and stop with the message "Error compiling the vertex 
> program: character -1".  So at least I've made some progress. :)
> 

I fixed it now.  It was just a stupid mistake that caused dallegroGL not 
to link with allegroGL's definitions of the function pointers.  That's 
why they were wrong.  Now it crashes somewhere else, but that can wait 
for tomorrow. :)

Re: [AGL] Looking into D bindings for allegroGL

[<to...@te...>]

Robert Ohannessian wrote:
> *glGenProgramsARB == wglGetProcAddress("glGenPrograms")
>  glGenProgramsARB != wglGetProcAddress("glGenPrograms")

glGenProgramsARB is a function pointer, so with or without * doesn't 
matter.  They are the same.

Re: [AGL] Looking into D bindings for allegroGL

[<to...@te...>]

"Your message to AllegroGL-general awaits moderator approval".  That's 
for a reply I posted yesterday.  Does anyone let those posts through?

Re: [AGL] Looking into D bindings for allegroGL

[Robert O. <ROh...@nv...>]

*glGenProgramsARB =3D=3D wglGetProcAddress("glGenPrograms")
=20glGenProgramsARB !=3D wglGetProcAddress("glGenPrograms")

Note the *.


> -----Original Message-----
> From: all...@li...
[mailto:allegrogl-
> gen...@li...] On Behalf Of Milan Mimica
> Sent: Friday, June 22, 2007 6:30 AM
> To: General discussion about AllegroGL
> Subject: Re: [AGL] Looking into D bindings for allegroGL
>=20
> to...@te... wrote:
> >
> > I've made some progress on this.  If I print the address of
> > glGenProgramsARB, and then print what
> > wglGetProcAddress("glGenProgramsARB") returns, they are NOT equal.
> > Shouldn't they be?  Any idea how this can end up being set to the
wrong
> > address?
>=20
> I don't know. AGL should do the same.
>=20
> > Is it possible to build a debug version of agl.dll?  Maybe it would
help
> > to see the log output.
>=20
> Sure. "make DEBUGMODE=3D1". "make DEBUGMODE=3D1 LOGLEVEL=3D2" will give=
=20you
> some more info in allegro.log. Or you can choose "debug" configuration
> if you are building with MSVC project files.
>=20
>=20
> --
> Milan Mimica
> http://sparklet.sf.net
>=20
>
------------------------------------------------------------------------
-
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> AllegroGL-general mailing list
> All...@li...
> https://lists.sourceforge.net/lists/listinfo/allegrogl-general
-------------------------------------------------------------------------=
----------
This email message is for the sole use of the intended recipient(s) and m=
ay contain
confidential information.  Any unauthorized review, use, disclosure or di=
stribution
is prohibited.  If you are not the intended recipient, please contact the=
=20sender by
reply email and destroy all copies of the original message.
-------------------------------------------------------------------------=
----------

Re: [AGL] Small patch for recent allegro changes.

[Elias P. <el...@us...>]

On Fri, 2007-06-22 at 09:36 -0600, Thomas Fjellstrom wrote:
> Recently autoheader was dropped in allegro, and all the HAVE_* defines were 
> renamed to ALLEGRO_HAVE_* to work around other libraries defining them as 
> well.
> 

Ok, I see.

-- 
Elias Pschernig <el...@us...>

Re: [AGL] Small patch for recent allegro changes.

[Milan M. <mil...@gm...>]

Thomas Fjellstrom wrote:
> 
> Its 4.2.2 (4.2.1-svn) and older. The change was made earlier this week.
> 
>> like:
>> #ifdef ALLEGRO_WITH_XWINDOWS
>>     #if GET_ALLEGRO_VERSION() <= MAKE_VER(4, 2, 1)
>>        #ifndef HAVE_LIBPTHREAD
>>        #   error AllegroGL requires Allegro to have pthread support
>> enabled! #endif
>>     #else
>>        #ifndef ALLEGRO_HAVE_LIBPTHREAD
>>        #   error AllegroGL requires Allegro to have pthread support
>> enabled! #endif
>>     #endif
>> #endif
> 
> Probably is necessary.

Then I'm going to apply such patch that keeps AGL compatible with 
allegro version < 4.2.2.


-- 
Milan Mimica
http://sparklet.sf.net

Re: [AGL] Small patch for recent allegro changes.

[Thomas F. <tfj...@st...>]

On June 22, 2007, Elias Pschernig wrote:
> On Fri, 2007-06-22 at 09:19 -0600, Thomas Fjellstrom wrote:
> > On June 22, 2007, Milan Mimica wrote:
> > > Thomas Fjellstrom wrote:
> > > > Yup. AGL source is now broken on allegro svn and any future releases.
> > >
> > > Is with this patch AGL broken on allegro 4.2.1 and older? Should we
> > > keep both HAVE_LIBPTHREAD and ALLEGRO_HAVE_LIBPTHREAD?
> >
> > Its 4.2.2 (4.2.1-svn) and older. The change was made earlier this week.
>
> Hm, what change is this? We can just undo it, 4.2.2 will be the latest
> 4.2.x release, and if everything goes by plan, 4.3.5 will have AGL
> included - so I don't see much point breaking AGL compatibility now -
> but I have no idea what this is about..

Recently autoheader was dropped in allegro, and all the HAVE_* defines were 
renamed to ALLEGRO_HAVE_* to work around other libraries defining them as 
well.

-- 
Thomas Fjellstrom
tfj...@st...

Re: [AGL] Small patch for recent allegro changes.

[Elias P. <el...@us...>]

On Fri, 2007-06-22 at 09:19 -0600, Thomas Fjellstrom wrote:
> On June 22, 2007, Milan Mimica wrote:
> > Thomas Fjellstrom wrote:
> > >
> > > Yup. AGL source is now broken on allegro svn and any future releases.
> >
> > Is with this patch AGL broken on allegro 4.2.1 and older? Should we keep
> > both HAVE_LIBPTHREAD and ALLEGRO_HAVE_LIBPTHREAD?
> 
> Its 4.2.2 (4.2.1-svn) and older. The change was made earlier this week.
> 

Hm, what change is this? We can just undo it, 4.2.2 will be the latest
4.2.x release, and if everything goes by plan, 4.3.5 will have AGL
included - so I don't see much point breaking AGL compatibility now -
but I have no idea what this is about..

-- 
Elias Pschernig <el...@us...>

Re: [AGL] Small patch for recent allegro changes.

[Thomas F. <tfj...@st...>]

On June 22, 2007, Milan Mimica wrote:
> Thomas Fjellstrom wrote:
> > Index: include/alleggl.h
> > ===================================================================
> > --- include/alleggl.h   (revision 1240)
> > +++ include/alleggl.h   (working copy)
> > @@ -68,7 +68,7 @@
> >  #include "allegrogl/gl_ext.h"
> >
> >  #ifdef ALLEGRO_WITH_XWINDOWS
> > -#ifndef HAVE_LIBPTHREAD
> > +#ifndef ALLEGRO_HAVE_LIBPTHREAD
> >  #   error AllegroGL requires Allegro to have pthread support enabled!
> >  #endif
> >  #include <alleggl_config.h>
> >
> >
> > Yup. AGL source is now broken on allegro svn and any future releases.
>
> Is with this patch AGL broken on allegro 4.2.1 and older? Should we keep
> both HAVE_LIBPTHREAD and ALLEGRO_HAVE_LIBPTHREAD?

Its 4.2.2 (4.2.1-svn) and older. The change was made earlier this week.

> like:
> #ifdef ALLEGRO_WITH_XWINDOWS
>     #if GET_ALLEGRO_VERSION() <= MAKE_VER(4, 2, 1)
>        #ifndef HAVE_LIBPTHREAD
>        #   error AllegroGL requires Allegro to have pthread support
> enabled! #endif
>     #else
>        #ifndef ALLEGRO_HAVE_LIBPTHREAD
>        #   error AllegroGL requires Allegro to have pthread support
> enabled! #endif
>     #endif
> #endif

Probably is necessary.

-- 
Thomas Fjellstrom
tfj...@st...

Re: [AGL] Small patch for recent allegro changes.

[Milan M. <mil...@gm...>]

Thomas Fjellstrom wrote:
> Index: include/alleggl.h
> ===================================================================
> --- include/alleggl.h   (revision 1240)
> +++ include/alleggl.h   (working copy)
> @@ -68,7 +68,7 @@
>  #include "allegrogl/gl_ext.h"
> 
>  #ifdef ALLEGRO_WITH_XWINDOWS
> -#ifndef HAVE_LIBPTHREAD
> +#ifndef ALLEGRO_HAVE_LIBPTHREAD
>  #   error AllegroGL requires Allegro to have pthread support enabled!
>  #endif
>  #include <alleggl_config.h>
> 

> Yup. AGL source is now broken on allegro svn and any future releases.

Is with this patch AGL broken on allegro 4.2.1 and older? Should we keep 
both HAVE_LIBPTHREAD and ALLEGRO_HAVE_LIBPTHREAD?

like:
#ifdef ALLEGRO_WITH_XWINDOWS
    #if GET_ALLEGRO_VERSION() <= MAKE_VER(4, 2, 1)
       #ifndef HAVE_LIBPTHREAD
       #   error AllegroGL requires Allegro to have pthread support enabled!
       #endif
    #else
       #ifndef ALLEGRO_HAVE_LIBPTHREAD
       #   error AllegroGL requires Allegro to have pthread support enabled!
       #endif
    #endif
#endif


-- 
Milan Mimica
http://sparklet.sf.net

Re: [AGL] Looking into D bindings for allegroGL

[Milan M. <mil...@gm...>]

to...@te... wrote:
> 
> I've made some progress on this.  If I print the address of 
> glGenProgramsARB, and then print what 
> wglGetProcAddress("glGenProgramsARB") returns, they are NOT equal. 
> Shouldn't they be?  Any idea how this can end up being set to the wrong 
> address?

I don't know. AGL should do the same.

> Is it possible to build a debug version of agl.dll?  Maybe it would help 
> to see the log output.

Sure. "make DEBUGMODE=1". "make DEBUGMODE=1 LOGLEVEL=2" will give you 
some more info in allegro.log. Or you can choose "debug" configuration 
if you are building with MSVC project files.


-- 
Milan Mimica
http://sparklet.sf.net

Re: [AGL] Looking into D bindings for allegroGL

[<to...@te...>]

to...@te... wrote:
> All examples work, except for two.  The exext exsample segfaults at what 
> is line 249 in the C version: 'glGenProgramsARB(1, &pid);'.  I have no 
> idea how this happens, so I'm hoping one of you knows what can cause 
> this function to crash.
> 

I've made some progress on this.  If I print the address of 
glGenProgramsARB, and then print what 
wglGetProcAddress("glGenProgramsARB") returns, they are NOT equal. 
Shouldn't they be?  Any idea how this can end up being set to the wrong 
address?

If I just call the functions I get from wglGetProcAddress, exext runs a 
few lines further, and stop with the message "Error compiling the vertex 
program: character -1".  So at least I've made some progress. :)

Is it possible to build a debug version of agl.dll?  Maybe it would help 
to see the log output.

[AGL] Small patch for recent allegro changes.

[Thomas F. <tfj...@st...>]

Index: include/alleggl.h
===================================================================
--- include/alleggl.h   (revision 1240)
+++ include/alleggl.h   (working copy)
@@ -68,7 +68,7 @@
 #include "allegrogl/gl_ext.h"

 #ifdef ALLEGRO_WITH_XWINDOWS
-#ifndef HAVE_LIBPTHREAD
+#ifndef ALLEGRO_HAVE_LIBPTHREAD
 #   error AllegroGL requires Allegro to have pthread support enabled!
 #endif
 #include <alleggl_config.h>

Yup. AGL source is now broken on allegro svn and any future releases.

-- 
Thomas Fjellstrom
tfj...@st...

[AGL] FBO patch

[Milan M. <mil...@gm...>]

Here is it. A patch that enables drawing to video bitmaps using FBO 
extension if available. Implements: blit(), masked_blit(), 
draw_sprite(), pivot_scaled_sprite_v_flip().
It does not change functions for drawing primitives, i'm not sure if 
it's wroth it atm. Except for clear_bitmap() which was easy to do.
New tests added to dumbtest.
Various other unrelated fixes and corrections.

There are issues. This is what I wrote in bugs.txt:

* Functions that do masked drawing to video bitmaps do not work
   correctly if EXT_framebuffer_object extension is not supported.
   The resulting image will not be masked. A fix would be a to write a
   memory -> video masked blit function.

* Functions that do rotating and/or flipping to video bitmaps do not
   work correctly for bitmaps that have textures in segments. Bitmap is
   made segmented if the texture of the size of the bitmap is not
   supported by the GFX driver (too large or non-power-of-2). The
   work-around is obvious.

* Functions that do rotating and/or flipping to video bitmaps do not
   apply rotation and scale to the memory copy. Thus reading from such
   bitmaps may return unexpected images.

* Before any drawing to the video bitmap occurs, when using FBO
   feature, at least one call to allegro_gl_set_allegro_mode() must be
   made. This is needed in order for __allegro_gl_pool_texture texture
   to be created, which is used for FBO drawing.


... the good thing is plain blit() works.

All the issues regard the new features.
I can fix the first one by using munge_bitmap() and draw_trans_sprite() 
which involves a temporary bitmap and is slow. Is there a way to tell 
glTexSubImage2D() to skip magenta pixels maybe?


-- 
Milan Mimica
http://sparklet.sf.net

[AGL] 0.4.1 released

[Milan M. <mil...@gm...>]

AllegroGL 0.4.1 is released. There haven't been many changes compared to 
last RCs, just some minor bugfixes and minor API tuning.


-- 
Milan Mimica
http://sparklet.sf.net

Re: [AGL] D3D

[Milan M. <mil...@gm...>]

Dustin Dettmer wrote:
> Can agl use textures for video_bitmaps?

Yes. That's what it does.
Moreover, if the texture of such size that it is not supported by GFX 
driver (it too large or non-power-of-2) then the bitmap can be 
represented with multiple, concatenated, textures.


-- 
Milan Mimica
http://sparklet.sf.net