Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Allegro 4.9.7

This thread is locked; no one can reply to it. rss feed Print
Allegro 4.9.7
Matthew Leverton
Supreme Loser
January 1999
avatar

Library order doesn't matter in MSVC...

Thomas Fjellstrom
Member #476
June 2000
avatar

Quote:

Library order doesn't matter in MSVC...

But the order of each symbol in a DLL matters. Also the combined dll and regular setup will be incompatible (most likely).

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Matthew Leverton
Supreme Loser
January 1999
avatar

I'm not in favor of creating a huge DLL anyway. I'm okay with a monolithic static library, but I think doing that with the DLL is asking for trouble.

Elias
Member #358
May 2000

Quote:

And furthermore, I don't see how an A4 compatibility layer will solve a lot of problems, as you'll still have to go through your code and make sure it all works. I think a better use of time would be to write a conversion upgrade guide.

I agree, but as always with open source projects, you have to wait for contributors to spend time on what they like, and you never can tell them what to best spend time on. Someone even re-worked the A4 auto-tools build for example :)

--
"Either help out or stop whining" - Evert

Evert
Member #794
November 2000
avatar

Quote:

When, perhaps a native solution could simply be:

#include <allegro5/allegro.h>

int main()
{
while (!al_keypressed(NULL)) al_poll_keyboard();
}

Now we've eliminated the need for a compatibility crutch by just making A5 easier to use.

I have no problem with that.

In case it wasn't clear: the purpose of a compatibility layer is not to make A5 easier to use.
If there is a situation where "it was much easier to do X in A4 than it is in A5" the fix is to improve A5. The audio API is a clear example.

Quote:

I don't see how an A4 compatibility layer will solve a lot of problems, as you'll still have to go through your code and make sure it all works.

It's not meant to solve "a lot of problems" and people are not supposed to mix and match A4 and A5 functions; whether it works or not is not in the hands of whoever wrote the code using it, but in the hands of whoever writes the addon. The purpose is (mainly) some support for legacy code.

Quote:

I think a better use of time would be to write a conversion upgrade guide.

Don't worry, you don't have to write the addon.
Yes, a guide "A5 for A4 users" would be very useful.

CGamesPlay
Member #2,559
July 2002
avatar

Quote:

But the order of each symbol in a DLL matters. Also the combined dll and regular setup will be incompatible (most likely).

Do you have any information to back this up? I'm pretty sure you're wrong about the first point, however Allegro's stance on binary compatibility has always been that you can add symbols with no problem, but not remove or change them.

Quote:

I'm not in favor of creating a huge DLL anyway. I'm okay with a monolithic static library, but I think doing that with the DLL is asking for trouble.

What sort of "trouble" are you anticipating? If the combined dll has a separate name, there should be no trouble at all.

--
Tomasu: Every time you read this: hugging!

Ryan Patterson - <http://cgamesplay.com/>

Matthew Leverton
Supreme Loser
January 1999
avatar

Don't worry, it won't hurt my feelings if somebody (else) writes an A4 compatibility layer. I'm just offering my perspective on its usefulness.

Quote:

What sort of "trouble" are you anticipating? If the combined dll has a separate name, there should be no trouble at all.

Maybe "trouble" isn't the right word, but we are talking about newbs here. They won't be able to build Allegro anyway.

I have no problem offering a standard, official binary DLL called allegro-4.9.7-everything.dll that nobody but the Windows binary distributor ever creates or distributes. But asking the newb to get all those libraries together and build it using the Allegro build system is not going to do any good (regardless if its all-in-one or not).

That is, I don't see this as a core Allegro issue, but simply as a distribution one.

Thomas Fjellstrom
Member #476
June 2000
avatar

Quote:

Do you have any information to back this up?

Its how Windows DLLs work. Symbols are linked to by an integer index, if the symbol at an index changes or is removed, bad things happen. You are indeed right though, you can add, but new symbols have to be added to the end of the monolithic DLL, so new symbols for each addons have to be managed in some way as to make them fall into place in the right place. If any symbol moves in that monolithic DLL it will break binary compatibility. You'll start seeing symbols from various addons interleaved with the core lib in the .def file. I imagine it wouldn't be the easiest thing to manage.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Evert
Member #794
November 2000
avatar

Quote:

I'm just offering my perspective on its usefulness.

That's ok. I have a specific use for it myself. That alone is reason enough for me to make it useful.
If someone else finds it useful, good for them.

EDIT

Quote:

Its how Windows DLLs work. Symbols are linked to by an integer index, if the symbol at an index changes or is removed, bad things happen.

As I remember, this came up a while back. From what I remember, there are actually two ways to do symbol lookups in DLLs in Windows. One is as you describe, the other is by name.

Milan Mimica
Member #3,877
September 2003
avatar

Quote:

I'm pretty sure you're wrong about the first point, however Allegro's stance on binary compatibility has always been that you can add symbols with no problem, but not remove or change them.

Yes, thanks to misc/fixdll.sh script. It's ugly and all, and yes, it will be extended to addons if we want to keep them ABI compatible too.

Thomas Fjellstrom
Member #476
June 2000
avatar

The problem with the fixdll.sh script is if you ever re run it, it potentially breaks the order. its only supposed to be run once for major releases and symbols are to be added manually to the def file afaik. At least thats what the very large warning it prints out leads me to believe.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Milan Mimica
Member #3,877
September 2003
avatar

Uh? No. I think fixdll.sh does it all for you.

Thomas Fjellstrom
Member #476
June 2000
avatar

Ah, you are right, but make sure you don't tell it to regenerate the reference list ;D And don't use fixdll.bat.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Elias
Member #358
May 2000

Quote:

What sort of "trouble" are you anticipating? If the combined dll has a separate name, there should be no trouble at all.

Best would be to simply have a completely separate DLL for each release I think. Something like: allegro-big-5.0.1.dll. There would be no possibility for any version problems then. If someone makes another DLL of the same version but which includes even more addons, like some external networking library, they should name it differently again, something like allegrozilla-5.0.1.dll.

[edit:] And if one of the external addons has a new version and the big DLL is recreated, maybe indicate that as well, so in the previous case if the networking library releases a new version, the re-compiled DLL would be named allegrozilla-5.0.1b.dll. It would not allow any compatibility like the standard A5 DLLS, but the use of the big DLL would be to distribute it with the .exe anyway so it should be fine.

--
"Either help out or stop whining" - Evert

Thomas Fjellstrom
Member #476
June 2000
avatar

Quote:

It would not allow any compatibility like the standard A5 DLLS, but the use of the big DLL would be to distribute it with the .exe anyway so it should be fine.

Unless all you wanted was to update the dll. Now you have to update the DLL and exes using it.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Elias
Member #358
May 2000

Quote:

Unless all you wanted was to update the dll. Now you have to update the DLL and exes using it.

True. But it would get clear from the version numbers contained in the filenames, so at least nothing would be confusing about it.

--
"Either help out or stop whining" - Evert

lemranger
Member #10,003
July 2008
avatar

Quote:

int main()
{
  // lalala, use Allegro 5 normally.

  // boy this function sure was a simple way to wait for a key press,
  // let's bring in the compatibility layer!
  while (!keypressed()) { }
}

I hesitate to wade into this important discussion, but I might be a typical newbie/intermediate user of Allegro. For me there is a threshold where an API is too complicated and I am spending most of what little extra time I've got to use navigating the tool rather than expressing the action I need my program to follow. Allegro 4 is wonderfully easy to use. If the graphics were as fast as OpenGL, I'd just use it now. I'm even considering abandoning that high performance eye-candy, just so I can concentrate on the sim part and let the user's imagination fill in the craters with rocks (it's a lunar landing sim).

while (!keypressed()){... } is like breathing.
while (!al_keypressed(NULL)) al_poll_keyboard(); is like breathing through scuba gear.
while (al_get_next_event(&event) && event.type != ALLEGRO_KEY_UP) {} is like using an iron lung.

I just want to breathe - but not at the expense of the serious game programmers for whom the latter >is< breathing. I know that's your dilemma but here's a vote for perhaps ease of use over >super< high-performance.

--Paul

CGamesPlay
Member #2,559
July 2002
avatar

Quote:

while (!keypressed()){... } is like breathing.

No, it's like running a marathon that doesn't end no matter how far you go. From the CPU's perspective. Try readkey().

It's pretty easy to make a readkey function in a compatibility layer, actually. You just need to create an input queue, attach the keyboard, and wait for an event. 10 lines if you're judicious with spacing :)

--
Tomasu: Every time you read this: hugging!

Ryan Patterson - <http://cgamesplay.com/>

Elias
Member #358
May 2000

There could be an addon which provides simple shortcuts functions - anyone can write one. Just like there hopefully will be things like a C++ wrapper. It is not what the compatibility layer is for at all.

The addon could have a function like this:

al_wait_for_key();

--
"Either help out or stop whining" - Evert

Matthew Leverton
Supreme Loser
January 1999
avatar

Again, add-ons (compatibility layer or otherwise) shouldn't be used as crutches to simplify the core API. It's silly to put something like polling based input in an add-on if it is trivial to add to the core, not very high level, and likely to be used by a lot of people.

Do you really want allegro-polling-keyboard.dll? :P

There comes a time when ease-of-use trumps modular purity.

Elias
Member #358
May 2000

Well, I don't really think it matters where the function resides, as long as I can use it without any additional hassle. Maybe a file simple.c in src/ instead of addons/ would do.

I think we actually said on the mailing list some time ago that there should be something like:

ALLEGRO_EVENT_QUEUE *q = al_simple_init(640, 480);

And it would call al_init(), create a display with the given size, install mouse/keyboard/joystick and initialize all possible addons.

The main loop of:

while (1) {
    al_wait_for_event(q, &event);
    ... examine event and react ...
}

is easier to remember for me personally than all the various ways to get a mainloop going with A4, so I feel no urge for adding "polling" wrappers.

--
"Either help out or stop whining" - Evert

Evert
Member #794
November 2000
avatar

Quote:

Again, add-ons (compatibility layer or otherwise) shouldn't be used as crutches to simplify the core API.

I agree.
The core API should offer power and flexibility for advanced users as well as simplicity for beginners/people who don't want or need the extra complexity.

And again, I think (the reworking of) the sound API is a good example of making the API simple for those who don't want or need the extra flexibility and yet offer the flexibility for those who want it without requiring them to jump through hoops to get it.

lemranger
Member #10,003
July 2008
avatar

Quote:

It's pretty easy to make a readkey function in a compatibility layer, actually.

For this smart bunch, no question. I couldn't do it without a lot of RTFM-ing and cutting and pasting which I don't want to do. I'm not a tool-maker (a hard job) so I lean on you folks!

--Paul

Evert
Member #794
November 2000
avatar

Quote:

It's pretty easy to make a readkey function in a compatibility layer, actually.

Sure. Here's what it looks like at the moment:

int readkey(void)
{
   int ret;
   while (!keypressed()) al_rest(0.001);

   ret = readkey_buffer[readkey_buffer_start];
   readkey_buffer_start = (readkey_buffer_start + 1) % READKEY_BUFFER_SIZE;
}

with

int keypressed(void)
{
   return readkey_buffer_start != readkey_buffer_end;
}

;)

lemranger
Member #10,003
July 2008
avatar

Here's a quick (ugly) test I did with Allegro and OpenGL - I just hacked out a version of a NeHe tutorial with the rotating pyramid and cube but multiplied them by 750 (7500 polygons) all rendered in immediate mode without proper depth tests. (I was thinking of exscn3d). However. I managed to get FTGL and SOIL (Simple OpenGL Image Library) working with it and they are remarkably easy to use. The saved images are only in .bmp, .tga, and .dds, so I converted this to a .png.

Ideally, it would be great to figure out how to incorporate the ttf and image addons to do this, but there is at least an easy solution if you're using allegro with opengl and you need text and image capture.

--Paul



Go to: