That's great! Yes, indeed there's quite a few files of... historical
interest still on SourceForge. I think some of them would appropriately
be put inside the website perhaps.
-SL
On 08/14/2015 07:51 PM, Peter Wang wrote:
Hi,
I uploaded our files to Gna:
http://download.gna.org/allegro/
It
While posting to it a few times, I've noticed that things went into the
moderation queue. I'm not sure what
alleg-develop...@lists.sourceforge.net is doing right now, but I was
under the impression that it was not moderated. Could we turn that off
for gna as well (if sourceforge is moderated, t
Here's the IRC transcript from around the time this bug was added:
Hmm... keyboard events are messed up in A4.9 for me...
instead of it going _KEY_DOWN -> _KEY_REPEAT -> _KEY_UP it just
alternates down/up when the key is pressed
SiegeLord: something else is doing key rep
My opinion on this was that when this starts hitting you, you stop using
`al_draw_bitmap`. I made a library based on primitives addon that avoids
this pre-transformation issue: https://github.com/SiegeLord/FastDraw,
and it routinely draws things 2-3x faster.
It's too late now, but
who do that and flush the
bitmap cache every time the transformation changes.
-SL
On 08/17/2015 07:35 PM, SiegeLord wrote:
My opinion on this was that when this starts hitting you, you stop using
`al_draw_bitmap`. I made a library based on primitives addon that avoids
this pre-transformati
Whoops, dropped gna.org.
On 08/17/2015 07:40 PM, SiegeLord wrote:
That library is based on `al_draw_prim`. In fact, it's actually faster
to use `al_draw_indexed_prim` (the library supports both options). These
days I'd even try using vertex buffers, which should be even faster.
-SL
It is a little strange to provide this feature, since as you say, you
can just draw it yourself. Is there some advantage to this code rather
than manual drawing in terms of speed or something? I guess it makes our
mouse-driven examples 'just work'.
-SL
On 08/18/2015 02:14 PM, Trent Gamblin wr
Thanks, applied. The best way to send patches these days is through github.
I'd prefer to fix the aliasing bugs, rather than disabling the aliasing
optimizations, but if that's not possible, it'd be ok by me to add that
flag.
-SL
On 09/01/2015 01:46 PM, Boon947 wrote:
Hello,
I've posted th
to do mass relabelings like that.
-SL
On 08/26/2015 11:55 AM, Beoran wrote:
Today I spent sometime reading all the bugs that SiegeLord imported from
Sourceforge to Github, and I commented on some of them.
I was only able to close one bug because I saw it had been resolved by
studying the sourc
*(short *)&_seqbuf[_seqbufptr+6] =
(w14);\
_SEQ_ADVBUF(8);}
*(short *)&_seqbuf[_seqbufptr+6] is an aliasing rule violation, AFAIU.
What course of action do you suggest?
Regards.
On 02/09/2015 03:15, SiegeLord wrote:
Thanks, applied. The best way to send patches these days is
So I've fiddled a bit with the video addon, and here's my conclusions
about what needs to be done with it before we can consider it stable in
terms of API/semantics.
First, the API. I think it's basically good as is. I want to make the
following modifications:
- Remove al_get_video_aspect_ra
On 09/13/2015 06:22 AM, Elias Pschernig wrote:
How do you control the number of frames the backend decodes? It
shouldn't decode 1000 frames before the first one is shown, that just
would waste memory. But it also should not just decode a single frame
and risk not being done reading the next frame
On 09/13/2015 07:49 AM, Polybios wrote:
If I understand correctly, with your redesign, you'll know the
dimensions of the bitmaps you'll be getting only after you ... have got
the first frame. As they'll all be the same size and because it's
actually a property of the video, why not (re-)add some
On 09/14/2015 12:13 PM, Beoran wrote:
Sounds good, but how will we synchronize audio and video? And how does
the front end indicate the desired FPS/frameskip if needed (for slower
systems)?
There's no additional allowance for synchronization than what can be
done by the backend alone (i.e. mor
ns do.
-SL
On 09/13/2015 01:03 PM, SiegeLord wrote:
On 09/13/2015 07:49 AM, Polybios wrote:
If I understand correctly, with your redesign, you'll know the
dimensions of the bitmaps you'll be getting only after you ... have got
the first frame. As they'll all be the same size and bec
I'm thinking it might be good to release 5.1.12 soon. I'll want to merge
https://github.com/liballeg/allegro5/pull/504 for it (please take a look
if you can), but is there anything else that should be done there? I
note Beoran made a little milestone for it:
https://github.com/liballeg/allegro5
Oh yeah, and this release will hopefully have statically linked
dependencies for MSVC, as Trent suggested.
-SL
On 09/21/2015 09:31 PM, SiegeLord wrote:
I'm thinking it might be good to release 5.1.12 soon. I'll want to merge
https://github.com/liballeg/allegro5/pull/504 for it (ple
On 10/02/2015 05:54 AM, Peter Hull wrote:
What do you think? I can add it to a fork of SL's scripts and then
everyone can have a look at it.
Pete
Yeah, that'd be great. I forget, does Nuget have a central repository,
or will we have to host the packages?
-SL
__
Heya,
Sure thing, although I think a better spot for these might be the
wiki.allegro.cc.
-SL
On 11/08/2015 05:58 AM, Daniel Dawson wrote:
Hi ,
Are you still updating this page? - http://liballeg.org/links.html - I
came across a few resources that you might like to include on your list.
They
Err... were those commits in a position to be merged? Do we need to
revert them and remerge with the fixes?
-SL
On 11/21/2015 02:42 PM, Elias Pschernig wrote:
On Sat, Nov 21, 2015 at 2:56 PM, Peter Hull mailto:peterhul...@gmail.com>> wrote:
OK I have fixed that last bug, the PR is still
de work OK on MinGW (is there
such a thing as 64-bit MinGW?)
Thanks,
Pete
ps, Siegelord when I fix this I can send in the final Nuget package
script for your allegro_winpkg repo! Promise!!
___
Allegro-developers mailing list
Allegro-developers@gna.o
On 12/01/2015 10:43 AM, Peter Hull wrote:
Am i correct in saying it *is* specific to MSVC?
Pete
That's a hard question. We technically have 2 flavors of MinGW to
support: the classic one and mingw-w64. The former typically only works
with an external SDK, be that the hacked up one from libal
Still builds fine for me. The few cmake commands I use are:
cmake .. -G "Visual Studio 12 2013" -T v120_xp -DWANT_MONOLITH=off
-DSHARED=on -DWANT_STATIC_RUNTIME=on -DWANT_ACODEC_DYNAMIC_LOAD=off
-DFLAC_STATIC=on -DCMAKE_BUILD_TYPE=RelWithDebInfo
cmake --build . --target INSTALL --config RelWi
Please check out https://github.com/liballeg/allegro5/issues/548
In particular, are there any objections to removing the DirectSound
dynamic loading code?
-SL
___
Allegro-developers mailing list
Allegro-developers@gna.org
https://mail.gna.org/listin
information is still there, but moved elsewhere) and clean up the
downloads page. I also played around with the sidebar a bit.
See
https://github.com/SiegeLord/allegrowww2/commit/e82f0829878e3b91b5423aac1f6bec75f33d25ff
for the actual commit
Downloads page: http://siegelord.github.io/allegrowww2
1/09/2016 05:34 PM, Trent Gamblin wrote:
The Contributors page is pretty out of date... maybe we could do something with
that.
-Original Message-
From: Allegro-developers [mailto:allegro-developers-boun...@gna.org] On Behalf
Of Trent Gamblin
Sent: January 9, 2016 6:22 PM
To: 'S
Unless there are objections, I'm going to try releasing 5.1.13 today or
tomorrow. There have been quite a few bug fixes and it's been 3 months
since 5.1.12, so it seems like a good time to do so.
-SL
___
Allegro-developers mailing list
Allegro-develo
phics:
- Add `al_get_opengl_program_object` (SiegeLord).
Input:
- Fix spurious triggering of the mouse grab key when it wasn't
otherwise set
(SiegeLord).
Android port:
- Avoid multiple HALT/RESUME events on Android (Max Savenkov).
- Implement `al_get_monitor_info` for Android (Reuben Bell).
-
On 01/24/2016 03:09 AM, Peter Hull wrote:
There were a couple of things on a.cc - the missing glyphs and OS X
fullscreen. Are these activities for 5.1.14?
Yeah. In general, there are always bugs (sometimes even found on the day
of the release!). If we waited for them all to be fixed, we'd neve
The last message on this topic was this one:
http://sourceforge.net/p/alleg/mailman/message/34204065/ , and basically
everything there still applies (even the bugs I mentioned, they are hard
to fix). The main difference is that since then, the video addon is
gotten in a reasonable shape.
A co
Just a minor announcement. https://github.com/SiegeLord/allegro_winpkg
is the repository containing the patched sources + scripts for the
Windows packages. Currently it resides under my username, but I'm going
to transfer it to the liballeg organization so it's easier to contribute
I wrote up an unstable API proposal with a sample implementation in this
pull request: https://github.com/liballeg/allegro5/pull/569. Please
check it out and tell me if that seems like a good idea.
-SL
___
Allegro-developers mailing list
Allegro-deve
o do this within the next few months. I think it can be
done without going too crazy about it.
-SL
On 01/25/2016 06:58 PM, SiegeLord wrote:
The last message on this topic was this one:
http://sourceforge.net/p/alleg/mailman/message/34204065/ , and basically
everything there still applies (eve
I'm going to release 5.1.13.1 today (a bug fix release for 5.1.13,
fixing this: https://github.com/liballeg/allegro5/issues/575). Typically
I wouldn't bother doing bug fix releases for 5.1.x, but this seems like
an annoying regression and I wanted to explore the general procedure for
creating s
So I spent the past 4 days trying to fix the various issues with the
ffmpeg backend (firstly, it doesn't compile due to being so out of date,
but even if that's fixed, it produces static for most videos due to
broken audio handling, seeking doesn't work, pausing doesn't work, etc.)
and I came t
Wow, thanks a lot! That looks great, committed as is.
I filed a bug about al_set_sample_instance_length, eventually we'll fix
it. It does seem like a useful function to have, but it needs to be
implemented properly (it's reminiscent of al_set_audio_stream_loop_secs)
except half as useful.
I
So I tried this on my Ubuntu and got this error:
X Error of failed request: BadValue (integer parameter out of range for
operation)
Major opcode of failed request: 132 (XInputExtension)
Minor opcode of failed request: 46 ()
Value in failed request: 0xd
Serial number of failed reques
Applied as is. Thanks a lot!
-SL
On 03/23/2016 09:27 PM, Aldo Nunez wrote:
Hi Allegro developers,
I've attached a patch that fixes the bug reported in #593. I ran some
tests on it.
Please consider it for inclusion. Let me know if there's anything I
should change.
Thanks,
Aldo
__
ise?
-SL
On 02/26/2016 11:15 PM, SiegeLord wrote:
Alright, so I gave this a bit more thought, and filled out the milestone
thingie on github: https://github.com/liballeg/allegro5/milestones/5.2
As always, it's just a way to keep things organized, we can add/remove
as necessary. There are
So once 5.2 is released, it won't make sense to develop on the 5.1
branch anymore. Since we'll have to make a new branch anyway, any
opinions on what to call it? The two logical options are:
5.2 - this would just follow the usual pattern. As per the unstable API
proposal, there won't be a 5.3
Alright, 'master' it is. Elias, could you update your documentation
generation scripts accordingly?
-SL
On 03/27/2016 11:03 AM, Elias Pschernig wrote:
On Sun, Mar 27, 2016 at 4:50 AM, Peter Hull mailto:peterhul...@gmail.com>> wrote:
Aren't there some features of Github that work better (o
e refactoring, but I resolved it for my
particular case.
On what line of code did the error occur?
Was it with any specific allegro example?
Was it just with mouse input that it failed or was touch input installed
or both?
On Wed, Mar 23, 2016 at 11:43 PM, SiegeLord mailto:siegelor...@gmail.com>&
Thanks a lot!
On 04/11/2016 11:15 AM, Jon Rafkind wrote:
Siegelord requested that I make a 5.2 ppa on launchpad, so here it is!
https://launchpad.net/~allegro/+archive/ubuntu/5.2
___
Allegro-developers mailing list
Allegro-developers@gna.org
https
Allegro 5 isn't compatible in any way with Allegro 4, which is why there
are several Devpak versions of it (AGUP in particular is only for
Allegro 4 as you've discovered). Allegro 4 isn't at all supported these
days, so if you opt to use it, you're a bit on your own.
In general, though, DevCpp
I'm confused about this. The reason why transformations are applied as
they are is so that you can change them in the middle of drawing
multiple bitmaps. Does this change essentially remove that feature?
Also, it doesn't seem like this completely fixes mixing primitives and
bitmaps, as if ther
using al_draw_prim and I've gone
from ~12 FPS to 60 in the menu...
On Wed, July 13, 2016 10:59 pm, SiegeLord wrote:
I'm confused about this. The reason why transformations are applied as
they are is so that you can change them in the middle of drawing
multiple bitmaps. Does this change essentia
That's pretty cool, thanks for sharing!
-SL
On 07/29/2016 08:13 AM, Ponomarenko Andrey wrote:
Hello,
The API/ABI changes analysis report for the latest Allegro releases is now
included to the Linux ABI Tracker project:
http://abi-laboratory.pro/tracker/timeline/allegro/
Hope it will be help
I think the time is nigh to release 5.2.1. Unless there are objections,
I'll do it sometime during the next week.
-SL
___
Allegro-developers mailing list
Allegro-developers@gna.org
https://mail.gna.org/listinfo/allegro-developers
Is it possible to run this on an unreleased binary to verify that it's
backwards compatible before it is released?
-SL
On 07/30/2016 07:49 PM, SiegeLord wrote:
That's pretty cool, thanks for sharing!
-SL
On 07/29/2016 08:13 AM, Ponomarenko Andrey wrote:
Hello,
The API/ABI change
Looks like I'll probably have to make a patch release to 5.2.1.
- 5.2.1 broke the ABI of al_get_opengl_extension_list (fixed in
https://github.com/liballeg/allegro5/commit/5ec135051693664aa8168bfdabb9e8882d6dbefc).
That API doesn't seem like it can handle any OpenGL extension additions,
so we
On closer inspection (running ex_joystick_events) my Xbox controller doesn’t
have any buttons at all with the new joystick code. Left and right stick are
combined into one and that’s the only feature of the joystick. So not sure how
this is even useful...
On Aug 9, 2016, at 8:21 PM, SiegeLord
nt Gamblin
Sent: August 9, 2016 9:01 PM
To: 'SiegeLord' ; allegro-developers@gna.org
Subject: Re: [AD] 5.2.1.1
If it's easy to do, it would be beneficial to make the left stick #0 in the
alternate mapping. I don't know the specifics of the driver or changes though.
-O
generate it instead?
Either way, for 5.2.1.1 it probably should stay reverted and we can
figure out a solution for 5.2.2.
Sound good?
-SL
On 08/13/2016 06:24 AM, Elias Pschernig wrote:
On Tue, Aug 9, 2016 at 10:21 PM, SiegeLord mailto:siegelor...@gmail.com>> wrote:
Looks like I'll
Sounds like the proper solution is to define _POSIX_C_SOURCE then,
perhaps guarded by a check for ALLEGRO_GCC.
-SL
On 10/08/2016 06:31 PM, Edgar Reynaldo wrote:
Hello,
I started a thread about this on a.cc :
https://www.allegro.cc/forums/thread/616526
Basically, when you compile an allegro
A little while ago I sent out a patch to revert Elias's addition of the
various multisampling/depth buffer additions to gl_ext.h (and the
associated headers) as it broke ABI compatibility. Those additions were
obviously useful, and it'd be a terrible state of affairs if we couldn't
ever add any
m very
suspicious, and most likely currently Allegro 5 will break if it
is ever compiled on a system where off_t is only 32 bit.
On Sat, Oct 8, 2016 at 9:59 PM, SiegeLord mailto:siegelor...@gmail.com>> wrote:
Sounds like the proper solution is to define _POSIX_C_SOURCE
additional function pointers.
Anyway, wrapping it in ALLEGRO_UNSTABLE sounds good enough to me.
On Sun, Oct 16, 2016 at 2:59 PM, SiegeLord mailto:siegelor...@gmail.com>> wrote:
A little while ago I sent out a patch to revert Elias's addition of
the various multisampling/dept
Yes, that's what is happening. Yes, that'd be a reasonable addition to
the documentation (this is documented inside al_use_transform right now,
but perhaps it makes sense to have this mentioned in
al_set_target_bitmap too).
-SL
On 10/20/2016 09:49 AM, Edgar Reynaldo wrote:
Hey people,
I was
Thanks, committed.
-SL
On 10/23/2016 04:31 PM, Edgar Reynaldo wrote:
On 10/20/2016 8:29 PM, SiegeLord wrote:
Yes, that's what is happening. Yes, that'd be a reasonable addition to
the documentation (this is documented inside al_use_transform right
now, but perhaps it makes sense to
It's not obvious to me what this code is meant to look like, as there
are quite a few separate draw calls. In my case, e.g. the only thing I
see is the color-cycling rectangle in the top left corner and a white
rectangle on the bottom right corner.
-SL
On 10/24/2016 12:18 PM, Edgar Reynaldo w
I'm kind of leaning on not having these included, as they seem just
simple wrappers over the existing (rarely used) functions, but I can be
swayed. Style-wise, you'll want to add spaces around your operators, and
name the functions with '_f' rather than just 'f' (e.g. following the
'al_map_rgb_
It could be your mail provider, e.g. gmail filters such emails itself.
-SL
On 11/18/2016 02:17 PM, Edgar Reynaldo wrote:
I've tried several times several different ways to receive my own posts
to the AD mailing list.
I've tried setting this option to on via the Web interface.
I've tried sendi
The website is hosted by GitHub, so unless they're being ddosed it seems
unlikely that it is at fault. Maybe it's a DNS issue? Perhaps try going
to liballeg.github.io when you observe slowness.
-SL
On 11/18/2016 01:51 PM, Edgar Reynaldo wrote:
I've been noticing this for a long time, but when
I still feel that they don't provide enough benefit for them to be added.
-SL
On 11/18/2016 01:53 PM, Edgar Reynaldo wrote:
Hey guys, just wondering if anyone has had any time to look at my
proposed patches. SiegeLord, you still want to commit these? Are they
okay as is?
Forw
Seems like a fine idea. The un-maximize behavior sounds like a bug, it
certainly doesn't do that on Linux at least.
-SL
On 11/26/2016 01:04 PM, Edgar Reynaldo wrote:
Hello guys,
I was wondering if it would be possible to add a member to the
ALLEGRO_DISPLAY_WIN struct called 'preferred_window_
On 11/27/2016 12:50 PM, Edgar Reynaldo wrote:
It's not the unmaximize behavior, it's the switch from fullscreen window
to window (al_set_display_flag(display , ALLEGRO_FULLSCREEN_WINDOW ,
false). The restore behavior (al_set_display_flag(display ,
ALLEGRO_MAXIMIZE , false) works fine. There is co
We could replace the check with a compile test to be sure (see, e.g. the
check for ALLEGRO_HAVE_PROCFS_ARGCV).
The way the check works is that it tries to find it at link time, but
perhaps it's in a different header or needs some macro defined to be
enabled.
If the second is true, we'll need
On 12/01/2016 01:12 PM, Edgar Reynaldo wrote:
As per cppreference.com it's a C11 function included by string.h. Isn't
Allegro supposed to comply with C90 or C99? C99 is the new default
compile language for MinGW.
C89 is the official requirement, but these days we have quite a few gnu
extension
On 12/01/2016 07:13 PM, SiegeLord wrote:
The issue with strerror is that it's not thread safe. We'd need to wrap
it up in a mutex.
Actually, that's nonsense. There's nothing we can do to make it safe,
hence the code not doing anything when the safer variants are not
detec
A better spot for these bug reports is on github, as things tend to get
forgotten here.
As for this specific bug, have you tried downgrading to an older version
of Allegro (looks like pre 5.1.11). I'll try to get around to
reproducing this locally as well at some point.
-SL
On 12/01/2016 02
So what would the preferred course of action be then?
We can allow a user to set a preferred full screen window adapter, or we
can choose to go full screen window on the monitor that the window is
currently over. Which would be prefereable? Perhaps both?
I think both sound good, but at least th
ed to come off as if I was telling anyone what
to do. I hadn't received a reply in over a week so I felt I should add
in a small reminder that I was waiting on an answer. SiegeLord did
originally say he could be swayed to include the functions, so I didn't
feel that the issue had been
Merged, thanks!
-SL
On 01/19/2017 08:27 PM, Edgar Reynaldo wrote:
Hey guys,
Here's a small patch to fix a bug in the docs. There were some missing
newlines which caused the events doc to display incorrectly on the
ALLEGRO_EVENT_TOUCH_BEGIN event. Patch attached.
__
Merged, thanks!
-SL
On 01/19/2017 08:33 PM, Edgar Reynaldo wrote:
Hi guys,
In latest git, system.html fails to build correctly due to a bug in
make_doc.c. The allegro5.cfg file is opened in "r" mode and not "rb"
mode, so ftell does not correctly report the length of the file and it
causes it
So apparently gna.org will be shutting down soonish, see
https://mail.gna.org/public/project/2016-11/msg1.html for the
announcement.
Right now we use gna.org for the downloads and the file hosting, while
Github contains the website, repository and the bugs.
For the downloads, in principl
requirements are
somewhat low (and gna doesn't really give us good speed to begin with).
2GB is also about how many files we have in total at this time.
-SL
On 03/04/2017 01:36 PM, Trent Gamblin wrote:
On Sat, March 4, 2017 1:52 pm, SiegeLord wrote:
So apparently gna.org will be shutting down so
Hmm, I kinda forgot about Savannah. It does look somewhat more active
than GNA ever did, and I suppose it claims to host a whole bunch of
active projects.
Let me look into it.
-SL
On 03/09/2017 07:45 AM, Andreas Ronnquist wrote:
On Sat, 4 Mar 2017 12:52:43 -0800,
SiegeLord wrote:
So
Hello folks,
So after a bit of searching for a new home for Allegro's mailing lists,
I settled upon TuxFamily (https://www.tuxfamily.org/), a nice France
based FOSS hosting site. It seems moderately active, and has some
reasonably big projects hosted on it (e.g. Eigen). It's perhaps more
acti
On 04/10/2017 06:26 PM, SiegeLord wrote:
(Actually, I could perhaps migrate people who are subscribed over at
GNA.org, but perhaps this should be opt in? Either way, I don't have
access to the GNA.org admin interface. Along the same lines, I probably
can't close the GNA's mailing
79 matches
Mail list logo
