|
Allegro 4.9.2 has been released! |
OICW
Member #4,069
November 2003
|
Quote: A new (and better) input system for keyboard, joypad and the mouse (please!) would be great. As would a more powerful and flexible sound system. As for the former it's already in as I lurked through the documentation. The latter was somehow promised, if I am not mistaken. [My website][CppReference][Pixelate][Allegators worldwide][Who's online] |
Evert
Member #794
November 2000
|
Quote: I discovered that I would need to install the DirectX SDK on my PC, is that right? To compile DirectX based applications/libraries (eg, Allegro), that sounds right to me. However, I won't pretend to understand how Windows works. Quote: It also seems that the build instructions are not up to date, and neither is the documentation
Quite possibly. It's a WIP release for something that changes the entire API. Give it time. Quote: A new (and better) input system for keyboard, joypad and the mouse (please!) would be great. Please elaborate: do you mean a new system compared to 4.{2,3,4} or something that replaces the new system that's already in 4.9? |
Richard Phipps
Member #1,632
November 2001
|
Something better than in 4.3.0
|
Evert
Member #794
November 2000
|
I don't remember if 4.3.0 still had the old <=4.2 input system or wether it already had the new input system (I know, I could check), so could you elaborate a bit more still? |
Elias
Member #358
May 2000
|
4.3.0 does not exist. And never did. At least let's pretend so, it's not that hard, is it? The versions we have are:
4.9.x has an input system where you receive an event for any input, e.g. a key press or release or mouse movement or anything else. Also non-input things like pressing the window close button or resizing the window or timer ticks are handled that way. Those events are delivered within a few µs of the actual event, so should be as accurate as it can get. There are also some helper functions looking at the current state (like currently pressed keys, current mouse positions and so on) in 4.9.x, those will work just like the 4.2.x ones apparently, but I don't know why you would want to use them. -- |
Peter Wang
Member #23
April 2000
|
Quote: There are also some helper functions looking at the current state (like currently pressed keys, current mouse positions and so on) in 4.9.x, those will work just like the 4.2.x ones apparently, but I don't know why you would want to use them. For some types of programs (e.g. action games) it's easier just to check what the current state of the keys are. Otherwise you would end up reimplementing the same thing on top of events anyway.
|
Richard Phipps
Member #1,632
November 2001
|
Sorry I might have meant 4.2.0+ Issues I remember: Keyboard - Would be better with a way to have a key registered in a key[] array, but only cleared once 'read' by a program. This would stop some keys being missed if not looked at in a frame when the key was held, and be easier than implementing a read key queue system. Mouse - Long term issues with mouse acceleration under windows in fullscreen/windowed modes. Never properly addressed and source code was very kludgy. Joypad - Errors in reading stick information. Dual analogue sticks sometimes read as 2 axis, 2 axis, and other pads as 3 axis, 1 axis (but read correctly in other windows programs). Callibration code is legacy from DOS? Needed still? Sound - Limited control over specific sounds played, including priority system and deciding which sounds are replaced. I know there is a priority system, but it just doesn't work properly IMHO. No manual control over sound and voice channel to be used, which is neccessary for advanced sound work (IMHO). |
Elias
Member #358
May 2000
|
Quote: For some types of programs (e.g. action games) it's easier just to check what the current state of the keys are. Otherwise you would end up reimplementing the same thing on top of events anyway. True. But still, e.g. in a simple platformer running at 30 ticks per second, it means you have a chance to miss e.g. the jump key, which makes things really annoying. Quote: Keyboard - Would be better with a way to have a key registered in a key[] array, but only cleared once 'read' by a program. This would stop some keys being missed if not looked at in a frame when the key was held, and be easier than implementing a read key queue system. Yes, something like that can be easily done. Keep an array of all keys, then for each press event, increase a counter for that key. Then in each game tick you can read how often the key has been pressed, and then clear the array again. It's actually possible to do this with Allegro 4.2.x as well, it's what I do usually. Instead of key[] you have to use the keyboard callbacks though. -- |
Richard Phipps
Member #1,632
November 2001
|
I agree it can be done in 4.2.x, but I think some nicer system should be implemented into the new API so a key[] kind of system can be used. |
Edgar Reynaldo
Major Reynaldo
May 2007
|
What about a manually cleared key[] array where all the keys that have been pressed since the last time the array was cleared are all still counted as having been pressed? Then when the user is done with the input , they just clear the persistence buffer? That way if a key has been pressed , it won't be missed , and that way the number of times a key is processed by the user is reduced. My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
Peter Wang
Member #23
April 2000
|
Quote: What about a manually cleared key[] array where all the keys that have been pressed since the last time the array was cleared are all still counted as having been pressed? Then when the user is done with the input , they just clear the persistence buffer? That way if a key has been pressed , it won't be missed , and that way the number of times a key is processed by the user is reduced. It's likely each program will want its own variation of this kind of thing. I think the best thing is what we aim for: the events system provides the most general approach, and the application can implement whatever it likes on top. We also provide the current-state approach, because is the simplest possible thing and comes essentially for free.
|
Edgar Reynaldo
Major Reynaldo
May 2007
|
It's too bad keyboard hardware doesn't follow the same bitfield approach and send the computer a 256 bit value telling which of all the keys are pressed. Then we could use more than three buttons at a time. My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
Richard Phipps
Member #1,632
November 2001
|
What is the 4.9/5.0 API for the keyboard? |
Matthew Leverton
Supreme Loser
January 1999
|
Richard Phipps
Member #1,632
November 2001
|
How does the al_key_down function tie in with the use of an event queue system? |
Matthew Leverton
Supreme Loser
January 1999
|
They work independently of each other. |
Richard Phipps
Member #1,632
November 2001
|
Ok. Any plans to add in a key array system similar to what we discussed in this thread earlier? |
Elias
Member #358
May 2000
|
Yes, likely we will add in some completely trivial function, maybe as example program, or as addon. Just like 10 lines of code required to have a fixed or variable frame rate program, with mouse/keyboard/gamepad/sound pre-initialized, and a function called each game tick (with time delta for variable rate) and another one called for rendering. But, there's really no reason to plan this in, as again, it is trivial. Can write it in 5 minutes, once we get anywhere near close to an A 5.0 release -- |
Richard Phipps
Member #1,632
November 2001
|
Goalie Ca
Member #2,579
July 2002
|
Quote: Any plans to add in a key array system similar to what we discussed in this thread earlier? It should be trivial to add. Make a key_up and key_down function and provide a global "key" array as an add-on if people want. Create a key array. On key_down event set key "true" and on key_up set key to "false". ------------- |
FMC
Member #4,431
March 2004
|
Didn't manage to compile. Quote:
[ 5%] Building C object CMakeFiles/alleg_shared.dir/src/win/d3d_bmp.obj Fresh copy of Mingw (3.4.5), plus the directX files from http://trent.gamblin.ca/dx/ (btw most of those files had to overwrite newer versions of some files) System is WinXp Pro Sp2. I did Cmake (version 2.4) notified some missing files, but did ok. Let me know if other info are needed. [FMC Studios] - [Caries Field] - [Ctris] - [Pman] - [Chess for allegroites] |
Trent Gamblin
Member #261
April 2000
|
Thanks, it's a known problem with the 4.9.2 release, but it's fixed in SVN.
|
FMC
Member #4,431
March 2004
|
Good to know. [FMC Studios] - [Caries Field] - [Ctris] - [Pman] - [Chess for allegroites] |
Hyena_
Member #8,852
July 2007
|
Wow! This is just the thing I need! Window resizing, yeah!
|
Trent Gamblin
Member #261
April 2000
|
FMC, well it depends where you got your original files from. DirectX 9.0 though, goes back to around 2003-2004, so there really isn't anything newer available.
|
|
|