|
|
|
| New Allegro Funtions / Layout |
|
Kitty Cat
Member #2,815
October 2002
 |
Quote: Currently, as is KittyCat, when updating the definition of the BITMAP vtable, won't the loader also change? Yes, they will So, if we release imgldrs-4.4.0 (first stable), then release core-4.5.5 (5th WIP), we'd have to imediately upgrade to imgldrs-4.5.0. However, something breaks in imgldrs, causing us to bump to 4.5.1. The core is stablized and we release core-4.6.0 (first stable). But, we just found out how to fix imgldrs right! We'll have to change the core vtable a bit, though.. so we release imgldrs-4.5.2 and core-4.7.0 (first WIP; can't reuse 4.6 since it wouldn't be ABI compatibile). Now, imgldrs is stable so we release imgldrs-4.6 and core-4.8. But crap, now something in sndldrs isn't working, so we upgrade to core-4.9... Watch as those version numbers fly from constantly fighting over inter-compatiblity, all the while breaking ABI compatibility left and right. Fun... -- |
|
guilt
Member #2,553
July 2002
 |
Well, according to your argument, there's just one little thing: You don't update your core to make it compatible with the loaders, which use the core-interface Karthik Kumar Viswanathan |
|
tobing
Member #5,213
November 2004
 |
That's what I called versioning-hell. |
|
guilt
Member #2,553
July 2002
|
versioning hell exists in WIP releases. that's why we removed the ABi section out of the manual, didn't we? Karthik Kumar Viswanathan |
|
Kitty Cat
Member #2,815
October 2002
|
Quote: You only update the loaders and enrich their functionality because you've realized that the base format lacks something and it needs an update. Surely you're not naive enough to think that any and every problem that pops up in image loaders won't require changes in the core. Or that when you update the core to add the potential for future expandability will require an update in the effected extension modules (even if nothing is actually added to the modules). It would be so much easier if it was all in one library. Quote: versioning hell exists in WIP releases. that's why we removed the ABi section out of the manual, didn't we? Versioning hell isn't compatilbity problems with multiple versions of one DLL. It's compatibility problems with multiple versions of multiple DLLs. -- |
|
Evert
Member #794
November 2000
 |
Quote: And even this definition of the reason allegro is in a DLL is rather flawed. True, you can try to use a new DLL with an older version of the executable, but so many things are changing (especially with WIP releases) they are bound to be broken. True between different branches (4.0 vs 4.2) and for WIP releases (4.1.x/4.3.x). Not true for releases within one stable branch, 4.0.x or 4.2.x. Quote: The problem right now is that while certain parts of the library are maturing at a decent rate, other parts are lagging behind, pushing back "stable" release dates for other features. I don't think this is true. If major changes in one part of the library warrant a new release, there is a new release. The need to do as much as possible from one WIP to the next is that releasing and testing a WIP takes a fair bit of time, something none of us have in abundance. Quote: 3. DLLs increase file clutter : you mean to say, I have 300 Allegro games and there will be 300x alleg4x.dlls or 300 x 3 = 900 DLLs? So where did all that code sharing go? So tell people not to always distribute the DLL already, especially if it's a stable release. Quote: Try running a 4.1.18 compiled game with a 4.1.16 dll, did it make any difference? Read the bloody manual. WIP releases are not intended to be ABI compatible. If they were, we couldn't add new features to the WIP releases. If you care about ABI compatibility, stick with a stable release. If you want or have to use a WIP, staticlink. Quote: Now, if the makefile could somehow be tweaked to automatically detect the plugins and compile them, that would be one sweet setup. I could go for that. Yeah, I'll try to have a look at that for the 4.2 release, but I may not have enough time to resolve all the difficulties. What it would need is a well-defined Allegro plugin buildsystem interface: files that need to be there to describe how the plugin should be build. In a UNIX system, I suppose Allegro's top level configure script could take care of that... but that leaves Windows. Maybe the best platform-neutral approach would be a seperate programme that is build by Allegro's makefile (a la makedoc) and then run to configure and build the addons. Hmm... yeah, that could work. Quote: Also, how many times do we test the blit() and loadBMP() code when we update the BITMAP vtable definitions? load_bmp() doesn't care, blit() is inside the vtable and you get a warning if you somehow messed up the vtable because functionpointers are initialized with an incompatible function pointer. The real pain is checking this for all drivers, which involves recompiling Allegro on all supported platforms. Ideally, we would have a programme/script that scans Allegro's source tree for all instances of a driver/vtable and checks that it has the correct number of initializers and function prototypes. |
|
guilt
Member #2,553
July 2002
|
@Evert: that 4.1.16 thing, I was telling the people who mentioned WIP specific DLL problems. Karthik Kumar Viswanathan |
|
RK Patnaik
Member #5,623
March 2005
|
lemme join the versione manic.. @carrus85 Quote: Starcraft w/ Broodwar - 5 Dlls in the root directory DLL clutter is VERY common, and really isn't a problem, unless you like to browse your program directory daily and on a regular basis. Here, try this for a rule of thumb: if the user has to be messing around in the program directory to get things working, there is something wrong besides the DLLs in the directory.
Ok as far as ur thumb rule DLLs can be cluttered !!!.. how?? and do u think openoffice.org is developed my amatures?? and if it would have been a problem if the Dlls of this suite been located at the program dir?? |
|
spellcaster
Member #1,493
September 2001
 |
Um. You seem to miss some characters. You can copy and paste them from mine: Also, most of the time one punctuation mark is perfectly fine. Just remember to hold down the shift key for the character following such a mark. This will result in a so called "upper case letter". That being said, having just a single lib for the stuff almost everbody will need is a very good thing. I would even go so far and remove the DLL completely and make static linking the default on windows platforms. You'll normally provide the DLL with your game anyway so you'll actually save size by static linking. This will also make distributing the windows binary more easy. The normal overhead by a statically linked allegro lib is in the 100k area, in other words, it's not that big in comparison to your gfx and sound/music anyway. The question shouldn't be how many DLLs do we need? The question should be what are the benefits of a single / multiple DLL distribution for the user (as in coder of the game). The answer is: Most won't care. Allegro should be an easy to use, quick to learn library. Installation seems to a problem for many window users right now anyway, if you now start to add multiple libraries (leading to a couple of libs that need to be linked in the correct order) I see a lot of trouble ahead. Easy of use is the big strength of allegro (once it has been installed, that is) so we should try to focus on that aspect. IMHO that is, of course. -- |
|
guilt
Member #2,553
July 2002
|
ok.. about that ease of use.. static linking or not, i'm just insisting that the library be split up so it's easy to maintain a generic, robust extensible interface for all other libraries and itself .. no other point was touched. this internal architecture may not make much of a difference to the end user as-is Karthik Kumar Viswanathan |
|
spellcaster
Member #1,493
September 2001
|
Again: multiple libs -> multiple libs the user needs to link against in the correct order. -- |
|
guilt
Member #2,553
July 2002
|
well yeah spellcaster.. the link order is to be maintained.. on Linux, there's no problem ( we can re-do the allegro-config file) .. but on Windows, for static linking, there's already one particular order followed Karthik Kumar Viswanathan |
|
Kitty Cat
Member #2,815
October 2002
|
Quote: i'm just insisting that the library be split up so it's easy to maintain a generic, robust extensible interface for all other libraries and itself .. But it won't. It'll make things more complicated and harder to keep track of as I have been saying and shown. Quote: You'll normally provide the DLL with your game anyway so you'll actually save size by static linking. This will also make distributing the windows binary more easy Well, distribution of the final product isn't the #1 main concern here. There is a difference between 1 exe and 1 exe plus 5 dlls plus game data files, yes.. but having 1 exe and 1 (or even 2) dlls and game data files isn't that big a deal. Quote: The normal overhead by a statically linked allegro lib is in the 100k area Funny thing.. I once thought this too, but after doing some testing, I found that the entire lib does get included in the exe when you staticlink, even when using the -s option. The reason, I'd guess, is that because even exe's can be dynamicly loaded, all the functions and symbols need to be there in case something tries to (in Unix, you can pass NULL to dlopen to get a handle to the program and use dlsym to get the address of any symbol you wish; I'm pretty sure Windows has a similar method). In DOS this may not be true since there isn't really any dynamic linking, but this isn't DOS.. -- |
|
guilt
Member #2,553
July 2002
|
ohh? when was it shown? look at Ogg Vorbis: libogg, libvorbisfile, libvorbisenc and libvorbis Karthik Kumar Viswanathan |
|
Kitty Cat
Member #2,815
October 2002
|
Quote: when was it shown?
Read the thread. Specificly, my posts. Quote: look at Ogg Vorbis
Yes, look at Ogg Vorbis: Each library handles completely seperate tasks that do not depend on any of the others to operate (with the exception of the last, which I never was fond of). -- |
|
guilt
Member #2,553
July 2002
|
yeah i did. i never felt that it was "reason" enough and, it isn't a matter whether you liked it or not, but for the fact that they did put autonomous parts of Ogg Vorbis into different sub libraries proves my point it's ideal that there's a certain level of abstraction, and it's easier when separating implementions from generic routines. (I'd like to quote Elias' e-mail to AD in here.. but I won't do that!!) Karthik Kumar Viswanathan |
|
Elias
Member #358
May 2000
|
Well, I'm not going to catch up on this thread, but yes, I think different from Chris that more modules are better. For example, look at something like glyph keeper. It's much better to be on its own, so someone completely independent of the Allegro devs can develop it. The same would be possible e.g. with other drawing primitives, e.g. there might be a library for lines/circles/arcs and so on. They are less basic functionality than display of text in a game, many games actually don't need them. Of course, they should be in the standard download (as should be the possibility to render text) - but there's no need to have it all inside Allegro. -- |
|
Kitty Cat
Member #2,815
October 2002
|
Quote: yeah i did. i never felt that it was "reason" enough Creating more problems by having to keep track of multiple packages, each with its own version and compatibility issues, isn't reason enough? Quote: and, it isn't a matter whether you liked it or not, but for the fact that they did put autonomous parts of Ogg Vorbis into different sub libraries proves my point You didn't read my post. With the exception of 1 (libvorbisfile, which is nothing more than a simple helper lib; it doesn't do anything you can't easilly do yourself, and better), those libs are completely seperate from each other and do not require any of the others to be used to full potential. Meaning, there is no reason to mix them together since they work 100% independant of each other. Quote: For example, look at something like glyph keeper. It's much better to be on its own, so someone completely independent of the Allegro devs can develop it. Except, he's talking about Allegro itself. Others wouldn't be independantly developing it. It would all be worked on by the Allegro developers. Quote: The same would be possible e.g. with other drawing primitives, e.g. there might be a library for lines/circles/arcs and so on. They are less basic functionality than display of text in a game, many games actually don't need them. Of course, they should be in the standard download (as should be the possibility to render text) - but there's no need to have it all inside Allegro. Why externalize it? What will putting it into a seperate library accomplish to make the package seperation worth it? "Why yes, Allegro is very good with graphics. Oh, you want to draw circles and lines? You'll need this external lib for that." -- |
|
Elias
Member #358
May 2000
|
Quote: Why externalize it? What will putting it into a seperate library accomplish to make the package seperation worth it? "Why yes, Allegro is very good with graphics. Oh, you want to draw circles and lines? You'll need this external lib for that." Yes, I see the dependencies problem, so there should be a distribution containing it all. But it just feels cleaner to me to have it separate. There could be different developers, different mailing lists and so on, all just would be more organized and more progress could be made. That's how I feel at least. Something else - we simply won't be able to put everything into Allegro, so there will always need to be addons. But since Allegro would contain a lot of stuff, the things that are outside get a disadvantage. If things are separated, then it would be easy to switch e.g. from one official GUI addon to another at some point (the end-user distribution just would contain the other). If one would be fixed in Allegro, then all others would have a disadvantage. And if you look at the current addons, there are many that aren't developed anymore and were replaces by others, e.g. ogg or ttf addons. Now if we would have put ogg and ttf support into Allegro - Allegro users would be shut out from using the new ones. -- |
|
Evert
Member #794
November 2000
|
I think we need to seperate the idea of having modular code and seperate libraries here. Having modular code would mean that for all intend and purposes, graphic primitives (say) are an addon and could be build and seperated as such, except that it is build into Allegro automatically. That means graphics primitives are logically and internally a seperate entity from the rest of the library. This, I think, is good. I think this is also what Elias is refering to. The second issue is if this would mean that the graphics primitives should be a seperate library, irrespective of wether or not this gets distributed with Allegro. This, I think, is a `no' for the reason Kitty Cat has pointed out: there isn't much of a point to it and it has the danger of suffering from bitrot if the rest of Allegro is updated but the graphics primitives are not (except if Allegro's build mechanism would automatically compile all subsystems as seperate libraries - then there would be no difference from a developer point of view). Regardless, cluttering things up with too many DLLs is a bad idea IMO. I think we will eventually want to discuss what to do with the 4.0/4.2 compatibility layer in 4.3: will it be in the `normal' Allegro library so that everyone is forced to have it and use it? I think not, because that defeats the purpose of Allegro's new namespace cleanup due to al_ prefixes and is just unnescessary weight for people who don't want the compatibility. At that point, I'd consider having an alleg-new-44.dll/so and an alleg-compat-44.dll/so (names just given for illustrative purposes and not meant to be taken literally or as a serious suggestion), where the latter contains the backward compatibility API. Linking against -lalleg would make the old API available (and link in the new one, obviously) and linking against -lalleg-whatever-we-want-to-call-it-that-hasn't-got-the-old-api will only include the new API and not cause the user code to pick up a dependence on alleg-compat44.dll/so. So, in short, my thoughts on the subject: PS: I disagree that primitives should be an addon because the average game doesn't need them anyway: I tend to use rect and rectfill fairly often, and putpixel() is quite useful for some particle effects. In any case, I use them for making a quick interface before I plug in bitmaps and things like that. Well, different discussion again. |
|
Kitty Cat
Member #2,815
October 2002
|
Quote: Yes, I see the dependencies problem, so there should be a distribution containing it all. But again, having a distro that has all the packages (which more than likely most people would use) defeats the seperate packages argument. You want seperate packages, but you want them all packaged together? I agree with Evert. Write modular code in a way that it could be seperated. But that doesn't mean it should be seperated. -- |
|
guilt
Member #2,553
July 2002
|
Hi, I don't see where this is getting anyway... @Evert: If you can just trash away with the current DLL system, why not do away with any DLL system? agreed that the current system isn't flexible enough to give us the in-library addons ... @KC: It isn't enough. Separation of libraries enables us to strongly resist an impulse to play with global variables and function vtables. It is strongly condemned. People, the method of maintaining different routines should be kept independantly... It becomes easier to fix and improve certain parts of the library. If i'm not using the Allegro 3D routines, why should I bother to link it up? I noticed there were lots of dependancies in the symbols and compilation when I tried to remove the 3D out of the library (I shoved out 200 kb in my static executable that way) .... If i'm not using the LBM or VOC routines, why should it be part of load_sample()? As such, these things only contribute unnecessary overhead for the library. The base library system is best left clean, powerful and fast. Karthik Kumar Viswanathan |
|
Kitty Cat
Member #2,815
October 2002
|
Quote: @KC: It isn't enough. Separation of libraries enables us to strongly resist an impulse to play with global variables and function vtables. It is strongly condemned. You don't need to seperate the library to not use global variables (and there's nothing stopping you from using global variables with multiple libraries). Plus, global variables are fine.. it's cross-object global (ie. non-static) variables that you have to watch out for. And what's wrong with function vtables? Quote: If i'm not using the Allegro 3D routines, why should I bother to link it up? Because it's part of Allegro. If you're so worried about linking functions you don't use, why don't you just put every function in it's own library? That way you only link with the functions you use. Quote: I noticed there were lots of dependancies in the symbols and compilation when I tried to remove the 3D out of the library (I shoved out 200 kb in my static executable that way) .... If i'm not using the LBM or VOC routines, why should it be part of load_sample()? Because some people may (or used to; no one's arguing certain functions aren't "dead weight", but we can't remove them yet for compatibility reasons), and the extra code is negligible, as well as it doesn't get in the way of anything else by being there. Quote: The base library system is best left clean, powerful and fast. Which has nothing to do with the library being in one file or ten files. -- |
|
guilt
Member #2,553
July 2002
|
Quote: Plus, global variables are fine.. it's cross-object global (ie. non-static) variables that you have to watch out for. Inference: for non const variables, use local variables in files, and if there's an external dependancy, use functions / attach functions to vtable and execute. Quote: Because some people may (or used to; no one's arguing certain functions aren't "dead weight", but we can't remove them yet for compatibility reasons), and the extra code is negligible, as well as it doesn't get in the way of anything else by being there. Why don't you separate the not-so-dead-weight code out? Abstract it to the base. That's all anyone wants to use the Allegro system minimally, nothing more. This is what we are asking for. Quote: Which has nothing to do with the library being in one file or ten files.
As for DOS, there's no hope that there might be any DL mechanism Ok, agreed that a certain level of controversy is in determining what the "not so needed" stuff are ... But what is being proposed reduces these things to a good extent... BTW, can we start a general poll for getting feedback on Allegro (multiple questions on how far they rate the features of Allegro, what people use it for etc..) ? One example of such a poll: [url http://www.zoomerang.com/survey-start.zgi?p=WEB2244Z7UMEDS] Karthik Kumar Viswanathan |
|
Kitty Cat
Member #2,815
October 2002
|
Quote: Why don't you separate the not-so-dead-weight code out? Abstract it to the base. It is abstracted. ALl you'd have to do is remove the function, the line that "locks" the function (which is only needed because of DOS), and the line that "installs" it. Nothing else in Allegro is bothered. Quote: Let's say I just want to use my very own DDraw7 / Dinput8/ DSound9 driver Write vtable entries for them, and put it into a struct for Allegro. Quote: I wouldn't want to have anything more than just the base, to which I can plug in my own implementation/drivers .... The others will just be dead-weight to me.. That's just you, though. Most everybody else will still need/want it. The cost in seperating the library as such would be too great for a few people that may want to do something like that. Quote: Ok, agreed that a certain level of controversy is in determining what the "not so needed" stuff are ... But what is being proposed reduces these things to a good extent... No it doesn't. Because if Allegro's going to support it, Allegro's going to support it. Even if the packages was seperated, the developers would still maintain it and release it with the "full" package. -- |
|
|
|
Then anyway, the binary compatiblity is "lost" in the WIP releases.. won't they?
