liballeg / allegro5 Goto Github PK

Originally reported by: vladr

Original Ticket: alleg/feature-requests/10

Hello,

Observed two small (but very noticeable!) issues with
Allegro under Win2k with DX8.1 on a Matrox G450 card
(running AMD T-Bird @ 1.4GHz):
- software mouse cursors filcker like nuts (i.e. if I
enable the shadows for my mouse cursors they flicker
no matter where on the screen they are even if Allegro
is running in a small 320×200 window). If I disable
the shadows (=> Windows uses hardware cursors) the
flickering disappears.
- weird clipping is perfomed when running Allegro in a
window! Any tool-tips (e.g hover over the Allegro
window’s "Minimize"/"Maximize"/"Close" buttons) will
appear for a fraction of a second but will
disappear/be overwritten as soon as another frame is
drawn. Other windows are clipped more or less right.

Are these two mandatory side-effects of using a
hardware surface? I have a software DVD player
(PowerDVD) that uses hardware surfaces alright (YUV
Overlay) but the cursor does not flicker and tool-
tips are properly clipped. To play a DVD in a window
or full-screen it eats up ~25% CPU (including MPEG2
deconding and sound decoding), and Allegro also takes
~20% just to draw (when running in a window), so… :)

V.

Originally reported by: *anonymous

Original Ticket: alleg/bugs/19

With both 3.9.34 and 3.9.35, when a call to
clear_keybuf() is issued, at least the key[] entry for
KEY_F11 resets itself for around 80 ms even though the
F11 key is still being held.

Originally reported by: chag

Original Ticket: alleg/bugs/13

using RedHat 7.0, allegro-3.9.33-1.i386.rpm. i ran make as per readme.uni. i think this is a configure(ation) problem.

gcc -DHAVE_CONFIG_H -Iinclude -Iinclude/allegro -I./include -I./include/allegro -I. -I/usr/X11R6/include -O3 -ffast-math -fomit-frame-pointer -Wall -fPIC -DALLEGRO_SHARED -c ./src/unicode.c -o obj/unix/shared/alleg/unicode.o
./src/unicode.c: In function `uvsprintf’:
./src/unicode.c:2644:`short int’ is promoted to `int’ when passed through`…’
./src/unicode.c:2644: (so you should pass `int’ not`short int’ to `va_arg’)
./src/unicode.c:2650:`short int’ is promoted to `int’ when passed through`…’
./src/unicode.c:2677: `short unsigned int’ is promoted to`int’ when passed through `…’
./src/unicode.c:2695:`short unsigned int’ is promoted to `int’ when passed through`…’
./src/unicode.c:2701: `short unsigned int’ is promoted to`int’ when passed through `…’
./src/unicode.c:2708:`short unsigned int’ is promoted to `int’ when passed through`…’
make: \ [obj/unix/shared/alleg/unicode.o] Error 1

Originally reported by: gfoot

Original Ticket: alleg/bugs/1

This is a test

Originally reported by: *anonymous

Original Ticket: alleg/bugs/26

The DirectX sound panning code is still incorrect in
Allegro 3.9.37. I submitted this to an ‘Allegro bugs
mailing list,’ but it was ignored.

The problem is: DirectX sound playback locks the
panning to Left/Center/Right, rather than making
sounds pan smoothly from one speaker to another. This
is due to DirectX’s decibel panning attenuation, which
does not have a linear relationship with Allegro’s
integer panning values. It is easy to fix:

1. src/win/wdsound.c

Under linear_to_millibel (line 148), place the
following declaration:

static float pan_attenuation²⁵⁶;

Initialize the panning array (line 422) inside
digi_directsound_init(int, int):

/\* setup allegro panning to decibal speaker

attenuation table /
for (v = 0; v < 256; v++) {
double pan = v;
if (pan > 127) {
pan = 255 – pan;
if (pan != 0) {
double mul = pan / 128.0;
pan = -log10(mul) \ 1000;
if (pan > DSBPAN_RIGHT) { pan = DSBPAN_RIGHT; }
} else {
pan = DSBPAN_RIGHT;
}
} else {
if (pan != 0) {
double mul = pan / 128.0;
pan = log10(mul) \* 1000;
if (pan < DSBPAN_LEFT) { pan = DSBPAN_LEFT; }
} else {
pan = DSBPAN_LEFT;
}
}
pan_attenuation[v] = (float) pan;
}

Under digi_directsound_set_pan(int, int) (line 968),
change ds_pan = DSBPAN_LEFT… to the following line:

int ds_pan = pan_attenuation[pan];

---

Now DirectX sound should pan smoothly from one speaker
to another, as it is supposed to do.

Thanks for fixing this,
Connelly Barnes

"This is the Eternal Kingdom of Zeal, where dreams can
come true! But at what price?"

Originally reported by: *anonymous

Original Ticket: alleg/bugs/24

I compiled allegro 3.9.36 under Linux (2.4.5) using the SVGALib driver. I noticed that my game works correctly (sometimes 1px wide blitting problems, but maybe they are my fault), but the level editor sharing the same initialization code causes local echo to be switched off in my tty.
I currently work around this by typing ‘stty sane’ after running the editor.

Later I noticed that the example program exxfade is also affected by this, but only when called with at least 3 arguments (at least with the PCX images I tested). Also it does only occur with the SVGALib driver.

What I cannot detect, however, is if it is a bug in allegro or in svgalib. I have libvga.so.1.4.2, if that helps. But it seems to be allegro’s fault because it also does appear when pressing ESC at the first image, so no blit of the second/third image has occured.

Originally reported by: joe_programmer

Original Ticket: alleg/feature-requests/6

GFX_SAFE should select a windowed mode (GDI?) under Windows.

Originally reported by: *anonymous

Original Ticket: alleg/bugs/27

when compiling allegro for msvc the compiler returns
errors when trying to build the dibsound ans srcsave
object files. commenting the definition lines and
taking the two programs out of makefile.vc fixed this
for some reason.

Originally reported by: peterhull90

Original Ticket: alleg/bugs/36

In Windows (MinGW, WinME) and allegro 3.9.40, creating
a sub-bitmap of a sub-bitmap doesn’t work the same as
DOS (djgpp), the new bitmap is offset. Please see
example program below – the output should be a cross
in the centre of a box.

Peter

Originally reported by: dhedin

Original Ticket: alleg/bugs/15

OS – Mandrake 7.1
Latest allegro from CVS

I have both Microtouch and ELO graphic touchscreens working
OK on the KDE desktop. When I run exmouse in GFX_DGA2 and
use the mouse it’s OK also. The touchscreens will not work.

I have modified xdga2.c to incorportate the "some DGA servers are buggy" as found in the old DGA1 code.

This improves the situation, however coords are way off
and it seems to be running in relative mode with y axis inversed.

This may be an issue in DGA2 itself. Presently looking for
non-allegro DGA app to isolated problem.

Dean Hedin
[email protected]

Originally reported by: n_abing

Original Ticket: alleg/bugs/30

This was a bug that was revealed by the changes in
the latest WIP.

This happens when one passes NULL as the section name
to a get_config_\* function with the exception of
get_config_string. For instance when one calls
get_config_int with a NULL section name, it would
call get_config_string — but it will pass an epmty
string as the section name. Then get_config_string
calls prettify_section_name with the empty string.
prettify_section_name would then blindly place the
braces in the empty string. This results in a string
containing ‘[]’.

The patch fixes this by having prettify_section_name
check the length of the string. It will not modify
the string if it is empty, which I hope is TRT. As
Eric Botcazou puts it, an insane user might pass a
‘[]’ as the section name. This is indeed insane,
though it would be useful to have the config routines
place variables under a ‘[]’ section in the global
section. Hence ‘[]’ would stand for ``NULL section’’,
and therefore allow one to specify global variables
anywhere within the config file.

Under the current circumstances I’ve had instances
where this bug caused a segfault—surprisingly with
no core dump so I couldn’t bt with GDB :-(

Originally reported by: *anonymous

Original Ticket: alleg/bugs/33

On Redhat 7.1, alleg 3.9.37 fails to create the
/obj/shared/unix/alleg directory during install.
Also the /obj/unix/module dir is not created

Make fails. Creating the dirs manually allows
make to continue.

Originally reported by: mrmoj

Original Ticket: alleg/feature-requests/3

I’m using config files for many purposes in my current
project, from encrypted username/password combos to
inventory statuses and stock quantities. When changes
are made, I want to be able to call a function like
flush_config_files() to write them back to the disk,
without having to stumble across an allegro_exit() and
allegro_init() combo first.

Originally reported by: elias-pschernig

Original Ticket: alleg/bugs/20

In my latest Allegro project, i store all my gfx as 24
bit bitmaps in datafiles. I want to make the program
independent of the existing video hardware, i.e. it
should support all color depths from 8 to 32. For this
purpose, i load the datafiles with set_color_conversion
(COLORCONV_NONE) and then blit the loaded bitmaps onto
output-device specific bitmaps, letting blit to the
conversion. However, if the bitmaps contain pink
colors, they get sometimes transparent. And, if i use
COLORCONV_DITHER, at the borders between transparent
and non transparent areas of my bitmaps, i get a lot
of pink pixels.
I have this behaviour at least when converting to
16bit and 8bit – and looking at the source code in
blit.c shows that blit() doesn’t care about
transparency, even in the opposite conversion from
8bit to 32bit.

Originally reported by: *anonymous

Original Ticket: alleg/bugs/22

This seems to be somewhat random..
If it crashes trying to draw a particular bitmap,
it will do so next time.
This doesn’t occur if I use blit() instead..
don’t know what it does different?

I think the problem is with xwin_write_line..

Originally reported by: *anonymous

Original Ticket: alleg/feature-requests/1

I don’t have MSVC at the moment. I understand the
problem with getting Borland’s compiler to build…
it’s preprocessor doesn’t like function parameter
defines passed as parameters to #defines… However,
alternative compile environments may include:

Cygwin – http://sources.redhat.com/cygwin
(cygwin may be associated with Mingw32 – but using
fixming.bat does not immediately provide make
functionality – no MING32 export )

lcc – http://www.cs.virginia.edu/~lcc-win32/
(somewhat uses gcc’s inline assembly…)

Alternative assembler -
NASM – http://www.web-sites.co.uk/nasm/
(has patches for the Unix LCC version to use this as
the backend assembler)

Originally reported by: tomstdenis

Original Ticket: alleg/bugs/14

All 3d rasterizers should use the rgb_map table to compute the correct colors. Currently only POLYTYPE_GRGB and POLYTYPE_GCOL do. Fixing this would make the 8bpp code work much better and kinda standerdise it.

Tom St Denis
[email protected]

Originally reported by: gfoot

Original Ticket: alleg/bugs/1

This is a test

Originally reported by: robander

Original Ticket: alleg/bugs/38

The mousepointer seems to be lagging sometimes
(WinAlleg)

It floats around perfectly fine except for a few
milliseconds every now and then.. this is also the
case for most of the exampleprgs, espacially when
using windowed gr.drivers.

I don’t know what’s causing it but perhaps someone
else has a clue?

Originally reported by: *anonymous

Original Ticket: alleg/bugs/4

blah blah

Originally reported by: gau_veldt

Original Ticket: alleg/bugs/10

Some USB mice, particularly the one that comes with my USB Wacom tablet does not work at all in Allegro under Windows (mouse pointer completely still).

The Wacom tablet mouse works everywhere else including DirectPlay/DirectInput apps such as Flight simulator 2000 (though not in DOS windows).

Originally reported by: javs

Original Ticket: alleg/bugs/23

Any new controller with at least two or more analog
outputs for axises will not work with what I believe
is code for the standard Windows joystick input code.
Unless Allegro uses Direct Input, Allegro made games
made for Windows may need to use the hat as the X/Y
axises or at least support that option. Who is in
charge of the joystick routines for the Windows part
of Allegro?

Originally reported by: halifaxab

Original Ticket: alleg/feature-requests/8

I’m writing an MMORPG using Allegro, and I’d love to
have an intro screen that would show the world that
I’m using Allegro. Something like allegro_displogo
(screen) would work quite nicely.. Allegro is a real
nice GPL that allows me to write what I want without
learning DX, and then going and writing a
lot more code for it to work on Linux/BSD, and I thank
everyone that’s worked on the project. Also, I’d be
more than happy to write full networking functions.. I
see games going more towards multiplayer and massively
multiplayer modes as opposed to single player, and I’d
like to see more intermediate programmers being able
to write games like this, so I’ll do whatever is in my
power to implement things like that if you’d wish.

Originally reported by: *anonymous

Original Ticket: alleg/bugs/21

missing demo.dat file in the all3936.zip

Originally reported by: *anonymous

Original Ticket: alleg/bugs/3

bleah

Originally reported by: *anonymous

Original Ticket: alleg/bugs/8

If I open demo.dat with the grabber, and I simply select element ENGINE1 (and RLE bitmap), the program crashes.

Originally reported by: marcelouy

Original Ticket: alleg/feature-requests/2

I’d like to be able to sort the items in the grabber
insted of having the items alphabetically sorted by the
grabber.

Also I’d like to have a text editor in the grabber.

BYE

Originally reported by: dj_jl

Original Ticket: alleg/bugs/29

In DOS with Soundscape driver at half of the volume (127) I have full volume, then at 128 it drops
back to silence and rises again. Most likely it’s something wrong with soun volume shifting.

Originally reported by: lwithers

Original Ticket: alleg/bugs/6

The setup utility crashes. This is most likely because it uses dat2s on its font file. Again, if dat2s is fixed, this will most likely be fixed.

Originally reported by: gfoot

Original Ticket: alleg/bugs/1

This is a test

Originally reported by: *anonymous

Original Ticket: alleg/bugs/28

I tried to include xalleg.h in my C++ program and it even didn’t compile. I also tried to include it in
C program and it works fine. With some workarounds C++ program also compiled fine. Here are 2
bugs that I found.

Bug # 1: allegro/aintlnx.h line 73
private is a C++ keyword, the structure field must be renamed to some other name.

Bug # 2: xalleg.h lines 142-147
These variables must be declared with AL_FUNCPTR. With AL_METHOD they are declared as global
variables, and in C++ linker will link to these variables that will have a NULL pointer values that
causes a crash at startup and not to the variables in library where they have initialized to the
default values. Even more – if I will include xalleg.h in multiple C++ files, my program will not link at
all. In C linker links to the declarations with initializations and redeclared global variables without
initialization will be treated as prototypes.

Originally reported by: stwerff

Original Ticket: alleg/feature-requests/9

Most of the modern games have features to enable multi-
play by TCP-IP. This is not very hard to implement
using the socket library under linux but as always the
different C implementations all have their own unique
way of communicating.

The communication should include a central server for
a game that lists other available servers. Also a
uniform way for LAN play with the server software
avaible with the binaries.

Do you think it an improvement to you API to include
generalised communication between games:
- comm_init_server(server_id, game_id)
Initiate a new server of the game to the central
server.
- comm_poll_clients
Server scans for new clients.
- comm_close_server
Stop the server.
- comm_available_servers(game_id)
Check the central server for a list of servers of
this specific type of game.
- comm_init_client(to_server)
Logon to a specific server.
- comm_close_client
Logoff a session on the current server.
- comm_message(link)
Send a message to the server or to a client.
- comm_poll_message
Scan for messages.
- comm_init_central(game_id)
Initiate a central server.
- comm_poll_server
Scan for servers that wish to join.
- comm_close_central
Close the central server

Originally reported by: *anonymous

Original Ticket: alleg/feature-requests/5

To greatly simplify ‘press any key’ and ‘release all
key’ moments without relying on ‘keypressed’ which
ignores modifiers, how about something like
‘getkeystotal’ – a function which returns how many
keys are currently pressed in total, or else a global
variable with the same meaning. Strikes me as
ridiculously easy to implement.

Originally reported by: jrueppel

Original Ticket: alleg/bugs/35

When using Allegro under X, the keys RALT ( ALT-GR ),
RWIN and TILDE don’t work, when starting Allegro
without X, they work. I got the TILDE key working
when I changed my X keyboard mapping from German to
US, but RALT and RWIN are still dead. I use XFree
4.1.0 and Allegro 3.9.39 currently.

Originally reported by: marcelouy

Original Ticket: alleg/bugs/25

OK, I want to use a type of item called TEXT in the
grabber.
I use the menu Object->New->Other and then I write the
type "TEXT". I have added this line to allegro.cfg
"TEXT=vim" so when I want to edit it vim is called.
It works all right but when I close vim and the grabber
is opened again it doesn’t work ok because when I click
on an BMP item it crashes before showing the preview.

I’m using allegro 3.9.36 on Linux Red Hat 7.09 highly
modified.

THANKS

Originally reported by: lwithers

Original Ticket: alleg/bugs/5

When I rewrote the font system, I didn’t have time to sort out dat2s. I am working on this at the moment, but would appreciate some help (current effort is at http://www.lwithers.demon.co.uk/prog/allegro/patches/ but it doesn’t seem to work).

Originally reported by: ndavies

Original Ticket: alleg/bugs/18

I just downloaded version 3.9.35 of Allegro and the
MIDI playing funcions do not work (at least under
windows). It worked with version 3.9.34, but now it
seems to be broken. I entered setup.exe and tried
every single driver available and none of them produce
any output at all. Normal MIDI file playing still
works using WinAmp and Windows Media Player. I am
using the C-Media MIDI Synthesis driver under windows.

Originally reported by: *anonymous

Original Ticket: alleg/feature-requests/7

It would be nice if Allegro supported hardware
acceleration under DirectX for set_trans_blender() and
set_add_blender() and set_alpha_blender().

In a test case done by myself, Allegro runs at 250 fps
in Windows/DirectX with triple buffering and a simple
bitmapped background. If I add a small amount of
alpha-blended text to the screen (Ten or so letters,
being the name of the level), the framerate drops to
40 fps. Clearly, this is unacceptable.
- Connelly Barnes

Originally reported by: *anonymous

Original Ticket: alleg/bugs/32

I use MSVC under windows 98 and i hade some problems
with file_select_ex of the 3.9.37.
The problem is the edit box on top of the dialog…
Often it only contains 2 characters and clicking on
the directory list only modifies these characters.
Before i was using 3.9.33 and i had no problems with
file_select.

Originally reported by: *anonymous

Original Ticket: alleg/bugs/11

Compiling in MSVC gives the following warnings due
to const (in)correctness. I don’t think I’d be able to correct them, but I’ve listed them just for reference.

obj/msvc/runner.exe cl @ -nologo -DALLEGRO_SRC -DDEBUGMODE=1 -W1 -Gd -Zi
-MTd -I
. -I./include -Foobj/msvc/alld/glyph.obj -c src/glyph.c
glyph.c
src/glyph.c(144) : warning C4090: ‘initializing’ : different ‘const’
qualifiers
src/glyph.c(158) : warning C4090: ‘initializing’ : different ‘const’
qualifiers
src/glyph.c(172) : warning C4090: ‘initializing’ : different ‘const’
qualifiers
src/glyph.c(186) : warning C4090: ‘initializing’ : different ‘const’
qualifiers

obj/msvc/runner.exe cl @ -nologo -DALLEGRO_SRC -DDEBUGMODE=1 -W1 -Gd -Zi
-MTd -I
. -I./include -Foobj/msvc/alld/modesel.obj -c src/modesel.c
modesel.c
src/modesel.c(243) : warning C4090: ‘initializing’ : different ‘const’
qualifiers
src/modesel.c(244) : warning C4090: ‘initializing’ : different ‘const’
qualifiers
src/modesel.c(258) : warning C4090: ‘initializing’ : different ‘const’
qualifiers
src/modesel.c(259) : warning C4090: ‘initializing’ : different ‘const’
qualifiers
src/modesel.c(260) : warning C4090: ‘initializing’ : different ‘const’
qualifiers

obj/msvc/runner.exe cl @ -nologo -DDEBUGMODE=1 -W1 -Gd -Zi -MTd -I.
-I./include
-Foobj/msvc/alld/setup.obj -c setup/setup.c
setup.c
setup/setup.c(1802) : warning C4090: ‘initializing’ : different ‘const’
qualifiers
setup/setup.c(1814) : warning C4090: ‘initializing’ : different ‘const’
qualifiers

obj/msvc/runner.exe cl @ -nologo -DDEBUGMODE=1 -W1 -Gd -Zi -MTd -I.
-I./include
-Foobj/msvc/alld/datgrid.obj -c tools/plugins/datgrid.c
datgrid.c
tools/plugins/datgrid.c(367) : warning C4090: ‘initializing’ : different
‘const’ qualifiers
tools/plugins/datgrid.c(369) : warning C4090: ‘initializing’ : different
‘const’ qualifiers
tools/plugins/datgrid.c(203) : warning C4700: local variable ‘dat’ used
without having been initialized

Originally reported by: *anonymous

Original Ticket: alleg/feature-requests/4

This is a specific optimization for z-buffering.

It would be nice if clear_zbuffer(bmp, 0.0) would be a
special case that would toggle a flag in the bitmap
structure. Then when the _poly_zbuf_**\* functions are
called, draw the z-buffered polygon normally if the
flag is NOT set. If the flag IS set, make all the
polygon’s z-coordinates negative and compare using a <
operation instead of a > operation when testing
whether a pixel is occluded.

This way, all polygons can be drawn normally with
positive z-coordinates in one frame, and then drawn
with negative z-coordinates in the next frame, without
needing to actually reset the values in the z-buffer.

Every frame, the clear_zbuffer() function toggles the
positive/negative flag, rather than setting each pixel
in the ZBUFFER to a specific value.

Implementing this would speed up z-buffered programs
moderately, depending on how many polygons are being
drawn. In exzbuf.c, 320×240×8 mode is 6% faster using
this method, and 640×480×8 mode is 28% faster, on my
machine.
- Connelly Barnes

Originally reported by: *anonymous

Original Ticket: alleg/bugs/7

I’ve tried severeal allegro-windows programs so far and they all exhibit the same problem.

What happens is that the software will run, and then it will get stuck repeating the last function over-and-over-and-over (infinite) they almost always seem to be in direct relation to input (keyboard/mouse)

If, for example the software was playing a midi and scrolling the screen to the left, it will get jammed scrolling to the left untill the midi runs out and then the midi stops playing. Then you are left with the assumption that it locked up.

In just about every case, it seems to be related to sending input into the program.

Originally reported by: *anonymous

Original Ticket: alleg/bugs/31

allegro_init() segmentation faults when compiled under gcc-3.0. It seems to happen because src in ustrzcpy isn’t a copy of resource as it should be, but this could mean it’s a gcc-3.0 bug. resource contains "allegro.cfg", but src is random. I don’t know enough of what’s supposed to be going on to really be sure – if one of you could look at it that would be really handy, as I need some of the features of gcc-3.0, and so it would be useful to know whether there was a real problem here.

Originally reported by: peterhull90

Original Ticket: alleg/bugs/34

With the example program below, I get flicker on dX
fullscreen, but it is OK in Windowed mode. I posted
this to Allegro.cc and at least one other person gets
this problem, and can’t see any problem in my code.
I’m using WIP 3.9.38, MinGW 1.1(?) gcc 2.95.3-5,
Windows ME.

Thanks,

Pete

Originally reported by: *anonymous

Original Ticket: alleg/bugs/17

The problem is very easy to describe:

There are many functions like

void SOME_FN (char *filename);

which do not work in C++ when called like

std::string s;
// …
SOME_FN (s.c_str ());

but need

SOME_FN (const_cast <char *> (s.c_str ()));

because of the C++ const handling.

This should be very easy to fix by just adding const’s
in the header and all source files (or better a define
named CONST which is defined as const when the
compiler supports it).

Ex:
void SOME_FN (const char *filename);

Normally fixing the allegro.h file would be enough (as
I did with many of those functions) but generates
warnings when compiling allegro, so the source files
have to be changed, too.

Originally reported by: *anonymous

Original Ticket: alleg/bugs/12

When I try to execute any program compiled with allegro (allegro examples included), i get a message that says: ‘Error: couldn’t set GFX_SAFE’ or ‘Error: there’s not an apropriate device for the resolution specified’ or something like that (i’m sorry i cannot remember the exact messages :(.

As I noted that I could reach that resolution (tested with DirectX SDK samples and even with allegro itself) I wondered why the heck did that happen. I have tracked the bug, with a debug version of allegro and gdb, down to the function ‘gfx_directx_create_surface’ after being called by ‘create_primary’. The problem seems to arise when the function tries to create the primary surface for the display. In fact I get the DDERR_NODIRECTDRAW message, which means that I do not have a DirectDraw capable driver.

I am using a rather old graphic card (and computer :( but every other program seems to work perfectly with that card.

My computer is an AMD 5×86 133Mhz with 32Mo RAM, 4GB HD, 70MB of swap partition, and a Trident TGUI9440 with 1 MB of video memory.

Originally reported by: javs

Original Ticket: alleg/bugs/9

Every test program that relates to the joystick does not work well with my USB WingMan RumblePad controllor. One of the programs that list the values of the joysticks says each axis is at -128 no matter where the stick is. The hat varible and the buttons are the only thing that at least seem to respond. This is with the MingW complier.

In case you don’t know about the spec’s of this control and would like to know, it has two sticks and a trottle (five axises total) and a d-pad that is used for POV (The hat) and 9 buttons. Not relating to Allegro, it has force feedback. The D-pad and the left stick can be switch for what is the POV control and the X- & Y-axis control.

Originally reported by: joe_programmer

Original Ticket: alleg/bugs/37

Hello, there was a bug reported a while ago about readkey() crashing under Dos-boxes in Windows. The bug is still present in WIP 39 (can’t say about WIP 40). Here’s the original e-mail, with the conversation on IRC attached:

[quote]
I can not seem to reproduce the problem in a modified exkeys.c, modified to
use my callback (which sets up a char key_released[KEY_MAX] block to detect
when previously pressed keys have been released).

In the program with the problem, however, I stripped all C++ objects with
constructors out of my program, and put the following lines:
allegro_init();
install_keyboard();
while ((readkey & 0xFF) != 27);
as the first lines of main() (the callback is NOT even being used), and it
consistently crashes before escape is pressed. though the time before it
crashes is not consistent. When it does crash, it brings down the DOS box,
with Windows giving the following message:

The program encountered a general protection exception.
Fault location: 0028: C0002B0C
Faulting component: VMM + 00001B0C
Interrupts in service: None

This is the message it brings up upon crashing, consistently, every time.

It’s not a system-specific issue, as it has occured on every other machine
that has tried to use it.
I’m using gcc version 2.95.3 20010315/djgpp (release), tried both -c -O6
-march=i486 -mpentium -fno-rtti -fno-exceptions -fomit-frame-pointer, which
are my usual build settings, and -c alone, on both the modified exkeys (which
has no problem) and the stripped version of my program (which has the
problem).

Short of the size of the program, nothing else is being called, and I can’t
determine the cause… any ideas, anyone?

Charles Bilyue’

[/quote]

[quote]
<TRAC> that one was linked to yield_timeslice() being called in readkey(), which calls __dpmi_yield()
<Bob> and __dpmi_yield() screws up the keyboard?
<TRAC> if yield_timeslice() (and hence __dpmi_yield()) isn’t called, then it doesn’t crash
<TRAC> it screws up smth tho
<Bob_> hmm ok
<TRAC> I don’t know. as of 3.9.34 it was still in
<TRAC> er
<TRAC> 3.9.39
<TRAC> I think
<TRAC> some .39 CVS
<Bob_> I’ll post it on SF to get everyone’s attention
<Bob> including the __dpmi thing
<TRAC> using keypressed() to wait instead of readkey()
<TRAC> eliminates the crash
<Bob_> that’s a workaround?
<Bob_> hm ok
<Bob_> I see
<TRAC> the standard Allegro tests use that
<TRAC> and tools
<TRAC> so they don’t crash
<Bob_> yeah, and they don’t crash
<Bob_> I know
<TRAC> right.
<Bob> so this is really weird
<TRAC> yeah, I know.
<TRAC> but
<TRAC> if I made a large exe that had no entry point to anything except main()
<TRAC> and no constructors
<TRAC> and just did allegroinit()/installkeyboard()/while((readkey() >> 8) != KEYESC) then it eventually crashed
<TRAC> personally, I believe it’s a Windows bug
<TRAC> I believe the odd circumstances when it appears
[/quote]

Originally reported by: gfoot

Original Ticket: alleg/bugs/2

will this show up?

Originally reported by: kryten2

Original Ticket: alleg/bugs/16

I don’t know for how long this has been going on (since I haven’t worked much with palettes in the past), but something is seriously wrong with the palette grabber. First, make a test bitmap using a wide variety of colors (try and make them "odd" colors to better exemplify the problem) and be sure you include bright pink (transparency) somewhere. Now open up the grabber and add a new palette object. Grab the palette from the image you just created and it may, at first, seem as though nothing’s wrong. If you look closely, however, you will notice that there are two pinks (assuming you only used one pinkish color in the image). One is in index 0 (as it should be) and the other is somewhere else within the set of colors, but it looks kind of off-color. Upon dumping the palette to a file and viewing it with your editor of choice, you will see that those suspicions were correct – there really are two! The one at index 0 is color FF00FF (as it should be), but the other one is color F200F2 (it is for me, at least). Upon further investigation, you will find that the second color (the off-pink one) is being used for all your pink colors instead of the correct one. Upon even further investigation, you will find that ALL the colors are off. Color CD59BD, for example, is now C250B2. The grabber also appears to make an attempt to use only 60 colors at most and will throw out any beyond that. I’ve tested this with both the DOS and Windows versions and gotten the same results. The Grabber is running in 640×480×32 on both platforms.