|
CPU family compilation of allegro? |
Thomas Fjellstrom
Member #476
June 2000
|
If its that big a problem for you, DO IT. I don't have the time, the AUTHOR of the addons you're complaining about doesn't have the time, and the DEVS don't have the time... -- |
Bob
Free Market Evangelist
September 2000
|
Quote: But Allegro does not. Yet again, making library authors impliment features that should be in Allegro. That's not how things happened, however. AllegroGL started out as a quick hack to prove that it was possible (and because the original AGL devs also wanted it). Slowly, we (== mostly me) started filling in the vtables. We don't implement it all yet. Some of it is diffucult, other features were impossible to implement as Allegro just didn't let us. Thankfully, this has been mostly fixed in 4.2. Quote: For one, nothing has to be implimented by the GPU. Huh? Quote: For another, sorry, but moving, rotating, scaling, etc a quad is negligible in GL.
- You wouldn't use a quad if you blit from a memory bitmap. That's just wasteful. Since you have absolutely no idea what you're talking about, lemme paste the rotation code from AllegroGL:
do_masked_blit_screen() and associated helper functions form another ~500 lines of code. Quote: The last stable fblend release was in 2001. The last stable release of Allegro was in 2003. I think, sometime after a stable release of fblend and before the 4.03 release of Allegro, something could have been integrated. In those 2 years. It's not an issue of integration. Sure, it's really easy to copy the code from FBlend, and paste it in Allegro. That's not the problem. Really, it's not. Quote: This has already been addressed. Please read my previous posts. No it doesn't. But feel free to try anyway. I'll vote against the patch when you get around to submitting it. -- |
soniCron
Member #5,721
April 2005
|
Thomas Fjellstrom said: If its that big a problem for you, DO IT. I don't have the time, the AUTHOR of the addons you're complaining about doesn't have the time, and the DEVS don't have the time... For one, there's no need to be hostile. Another thing: Daniel Kinney said: Well, I'm currently merging the Allegro blending code with fblend so they both work with the regular Allegro blend functions. I'll probably have something to submit by tomorrow. Please thoughly read the thread before getting upset. In addition, my point has nothing to do with the library not being integrated, per se, but about the development environment that prevents things like this from ever being implimented into the code. The lack of willingness to upgrade methods is counterproductive, and is the reason Allegro is well behind SDL in popularity and common usage, despite having a better written API. So, please do not tell me to "do it yourself" anymore. I am aware of that option. It's not about anybody doing it themselves, it's about a community effort to better the library, and hostile and corrosive comments and attitudes do not promote such productive activities. Just because you don't like what I have to say does not mean that it should not be done. All talk and no "do" is just as bad as no talk, no "do". |
Thomas Fjellstrom
Member #476
June 2000
|
Yeah, I read what you had to say, but really, I just sorta glossed over it all. Quote: The lack of willingness to upgrade methods is counterproductive, and is the reason Allegro is well behind SDL in popularity and common usage, despite having a better written API. Please read what others have to say Its not lack of willingness, we all want a better allegro, but allegro was committed to uber backwards and forwards compatability long ago, we can't just drop that. Which is where the All mighty Allegro 5 came in. It was supposed to be the be all end all replacement, but it died. Now 4.3+ is where we are putting our effort, it will (all beit slowly) change and reorganise allegro into something more modern. -- |
Elias
Member #358
May 2000
|
Quote: I disagree. I have a feeling it has to do with lack of project organization. There's no public roadmap that I can find. I hear about this magical roadmap all the time, and people keep referencing it, but I have yet to see it. There's enough of a roadmap to keep us busy for a year or two. With Allegro 5 (which is dead btw), the approach was to build up an advanced roadmap, with having nobody to develop it. Right now, we still have no developers with lots of time, but we're now trying to gradually implement pieces of the old Allegro 5 design, and see where it gets us. So far, we're in the progress of releasing a new major version, and already have a completely new events API and beginnings of the new gfx API in CVS. Quote: If it does exist, I would appreciate someone telling me where I can find it. I, for some time, wanted to get involved with Allegro, but I have no idea how. There's no "head honcho" to get in touch with. The website offers little information on getting involved, as well. The SourceForge page has 5 admins listed, with no indication of who to contact to help support the project. Well, 3 of them are Evert, Peter and me.. and we're all here in the forums anyway About some sort of guide to new developers, I agree that there's not much. I started collecting some information while I discovered it on the wiki: http://awiki.strangesoft.net/bin/view/Main/AllegroDev It's nothing really useful there yet.. but the one-paragraph roadmap it has is about as much as there is. -- |
soniCron
Member #5,721
April 2005
|
Bob said: - You wouldn't use a quad if you blit from a memory bitmap. That's just wasteful. You wouldn't use a memory bitmap if you wanted to move,stretch,rotate,etc sprites. Bob said: Since you have absolutely no idea what you're talking about, lemme paste the rotation code from AllegroGL: (cut) Exactly, what about this is hard? It's quite sensical, though not necessarily typical. Bob said: It's not an issue of integration. Sure, it's really easy to copy the code from FBlend, and paste it in Allegro. That's not the problem. Really, it's not. Then what is it? Bob said: I'll vote against the patch when you get around to submitting it. And yet another example of corrosive behavior. |
Kitty Cat
Member #2,815
October 2002
|
Quote: You wouldn't use a memory bitmap if you wanted to move,stretch,rotate,etc sprites. Regardless if you would or wouldn't, Allegro allows it, so AllegroGL would have to work with it. -- |
Bob
Free Market Evangelist
September 2000
|
Quote: You wouldn't use a memory bitmap if you wanted to move,stretch,rotate,etc sprites. Yes you would. You can't rotate video bitmaps in Allegro, so existing Allegro apps are already using rotated memory bitmaps. Quote: Then what is it? Maintenance, as mentioned in previous posts. -- |
soniCron
Member #5,721
April 2005
|
I concede. Have a nice day. |
Evert
Member #794
November 2000
|
Quote: Why is fblend still an external library?! If it is a highly recommended library for any Allegro developer, then why does it even exist? Why is it not in the Allegro library?
The answer to all those questions, and all questions similar to `why hasn't ... been added to Allegro?', is that we have too many people saying what should be done and what should and should not be in the library and too few people actually contributing code. Quote: lead to my developing my own software and hardware rasterizer for Allegro. This kind of stuff should be in Allegro to begin with. What are you complaining about? There was something missing in Allegro, you added it. Great. Now, if you want it to be in Allegro, submit a patch. Quote: But nobody developing SDL is saying "and you should take care before you change something that works.".
You know, there are people who think that Allegro is evil for breaking compatibility. I don't know what the hell they're talking about, as Shawn said in his big writeup, backward compatibility is one of Allegro's strengths and priorities. Part of that compatibility is a certain level of conservatism when it comes to accepting code changes. Quote: There's no "head honcho" to get in touch with. I guess Eric Botcazou is still our Dictator because no one has succeeded him in that role. Quote: The website offers little information on getting involved, as well. The SourceForge page has 5 admins listed, with no indication of who to contact to help support the project.
Either of the admins will do, but the best thing would be to just post on the mailinglist, or these forums. Quote: When most of the development progress takes place in a mail list, it makes it seem, to the public, that there's not much going on.
I used to post weekly summaries of the main topics on AD a couple of years ago, while Peter Hull did the same for Allegro5. I'm not sure if it makes sense to try to restart something like that, but I do think that the mailinglist is a better place for discussion than a public forum. Are you new to the message boards? If so, that explains a bit as well. Otherwise, you could have seen threads and discussion on Allegro development going on on and off. Quote: though it would be nice to have more frequent updates to the homepage. I think Gregorz is on vacation. I'm sure he'll update the site when he has time (at least I hope so because I don't know who else would do it...) Quote: I think, sometime after a stable release of fblend and before the 4.03 release of Allegro, something could have been integrated. In those 2 years.
What you forget or don't realize is that people were working on the big rewrite-from-scratch Allegro5, which died because no one had the time or energy to complete it. In the meanwhile, work on the Allegro 4.1 branch was going on but a lot of new features were planned for Allegro5 anyway so not implemented. Why do double work, afterall? Quote: it's about a community effort to better the library, and hostile and corrosive comments and attitudes do not promote such productive activities.
Please realize that there have been too many people talking tall about what has to be done, the net result of which has so far been zero. No one is saying that you couldn't do a good job, but you'll have to show that before we believe it. And to paraphrase Shawn again, to administer a project like Allegro is to be a nazi. If your suggestions and code are criticised, scrutinised and shot to pieces then that only means that we want to have it a bit better or integrate better with what we already have. Above all, it shows that we care about it and have taken the time to think about it. And now I'm going to sleep. |
Michael Jensen
Member #2,870
October 2002
|
Quote: Bob said:
Quote: You can phase things out, it's just a matter of wanting to. A lot of work seems to be going on with Allegro 4.x, but not so much with 5.x. And I'm assuming that 5 will break API compatability? I could be off my rocker but, dx for example, is backwards compatable, but they change things up internally all the time, while just leaving the existing api intact -- for example dx5 code works on dx9, but in dx9 it's all wrapped thru to newer functions (3d functions if I'm not mistaken)... Quote: So, please do not tell me to "do it yourself" anymore. I am aware of that option. It's not about anybody doing it themselves, it's about a community effort to better the library, and hostile and corrosive comments and attitudes do not promote such productive activities. not to be rude, but your posts seem rude, I have no problems looking at your ideas based on their own merits but you need a freaking personality adjustment... Quote: I'll vote against the patch when you get around to submitting it.
Quote: And yet another example of corrosive behavior. Bob didn't say he was voting against your patch because he disliked you, he dislikes the idea, and if anybody knows anything about what should be patched into allegro it's freaking Bob (IMHO)... Quote: If you want to lend a hand, then by all means do so. Allegro sorely lacks developers. I had no idea allegro was in such bad shape... Quote: And to paraphrase Shawn again, to administer a project like Allegro is to be a nazi. Damn allegro nazis -- you'd think we'd have more people willing to develop Umm the 4.2.0 I have is failing on the DJGPP "C only" make, so I'm going to have to download the cvs and start over... edit: I was fascinated to see the difference in speed between compiled sprite, and rle sprite earlier today tho (I'm not talking about looking at #s either, you could actually see it on the screen in modex!) btw the only video modes I seem to get are 320x200x8, 640x480x8, 640x480x24 (ModeX, VESA1, and VESA1 respectivley)
|
Elias
Member #358
May 2000
|
Quote: Umm the 4.2.0 I have is failing on the DJGPP "C only" make, so I'm going to have to download the cvs and start over... I'm not sure, but DJGPP might have its own problems with using C only. I may have missed something.. but was there already success of C only with MSVC at all? -- |
Milan Mimica
Member #3,877
September 2003
|
Quote: Well, I'm currently merging the Allegro blending code with fblend so they both work with the regular Allegro blend functions. I'll probably have something to submit by tomorrow. Even though patches like this one are going to be refused, we could create a repository of unofficial patches against (current?) allegro.
-- |
Elias
Member #358
May 2000
|
Quote: Even though patches like this one are going to be refused, we could create a repository of unofficial patches against (current?) allegro. Yes, I think it is a great idea. I'm actually planning to do something like this for some time, but never got around to it. Just a "community pack", which would be a distribution of Allegro together with the most useful addons. And ideally, wrapped up nicely, so it can be compiled/installed easily, maybe with a small installer script/program. In any case, it would not be completely trivial to maintain something like this. And if it is not maintained, then it would probably not be very useful. I'm also not sure about how it is best done technically. One way would be to e.g. start a SF project, create a CVS repository, and put allegro and all the addons into that repository, together with a set of the necessary patches, then synching with allegro/addons as necessary. Or maybe have the installer download the relevant versions of all packages, and just keep the patches in CVS. In any case, it should get easier than now (need to download every single addon from allegro.cc and build/install/integrate manually). And it shouldn't have to be maintained by the core Allegro developers, as long as there are so few. -- |
Evert
Member #794
November 2000
|
Quote: I was fascinated to see the difference in speed between compiled sprite, and rle sprite earlier today tho (I'm not talking about looking at #s either, you could actually see it on the screen in modex!) Yup. Actually, compiled sprites are the fastest way to draw sprites on modern hardware too, if I remember the benchmarks I saw correctly. This is interesting because three years ago, the fastest way to draw sprites was by using hardware accelerated blits. Quote: btw the only video modes I seem to get are 320x200x8, 640x480x8, 640x480x24 (ModeX, VESA1, and VESA1 respectivley) 320x200x8 is a standard VGA mode. There should be all sorts of other wierd ModeX resolutions you can set though, 320x240 being one of the more useful ones. Those VESA modes sound about right, although I think my old 486 was capable of more than that. Quote: Umm the 4.2.0 I have is failing on the DJGPP "C only" make, so I'm going to have to download the cvs and start over... Hmm... as far as I know it should work. Do provide some details if you still have problems with CVS. Quote: Even though patches like this one are going to be refused, we could create a repository of unofficial patches against (current?) allegro.
If by that you mean what Elias understood you to mean, basically a repository of addons, then that is a good idea but something that has been discussed so much that I'm surprised no one did it before now. |
Milan Mimica
Member #3,877
September 2003
|
Quote: If you mean a repository of actual patches and diffs against Allegro itself, I recommend against that.
Yeah, that's exactly what I meant. Unofficial patches like linux kernel has. I didn't really think allegro.cc would host them because this would be a collection of patches you (allegro developers) have rejected. You would dislike them. Of course, this would work only if someone is willing to maintain these patches. Anyway, I would like to see a flblend integration patch.
-- |
Evert
Member #794
November 2000
|
Quote: Anyway, I would like to see a flblend integration patch.
If someone integrates Allegro and fblend in such a way that fblend can work through Allegro's blending API, I'd prefer that they do it properly and use the blender vtable entry. In that case, it could be made a proper addon rather than an ugly unsupported hack. If patches are rejected, they're rejected for a reason, not because someone doesn't liek someone else (I hope). It either doesn't fit in or doesn't solve the problem it set out to solve, or has side issues. Creating a fork of Allegro based on rejected patches is, in my opinion, a very bad idea. |
Elias
Member #358
May 2000
|
Well, since the collection of such patches currently contains a total of about 0 patches, you should be more worried about someone writing such patches first -- |
Evert
Member #794
November 2000
|
I have one that adds triple buffering to the plain X11 driver that was rejected. |
Elias
Member #358
May 2000
|
Well, I wouldn't call that triple buffering, since one crucial element for triple buffering is vsync. You can't do triple buffering without vsync.. else you can as well use two pages. So yeah, the only use is to test something.. but what? I really doubt anyone but you would have a use for that patch -- |
Evert
Member #794
November 2000
|
Quote: Well, I wouldn't call that triple buffering, since one crucial element for triple buffering is vsync. You can't do triple buffering without vsync.. else you can as well use two pages. Not quite, at least not as I would define tripplebuffering. The crucial part is that you don't have to wait for vsync. There's one page displayed, one pages scheduled to be displayed at the next update of the graphics card/driver (`vsync') and one you use for drawing the next frame. Quote: So yeah, the only use is to test something.. but what?
Code doing triple buffering. The main reason I don't ever support triple buffering in any of my programmes is that I can't really test easily if it works myself. Quote: I really doubt anyone but you would have a use for that patch I don't know... sometimes people find that they want or need something when they realise that it's there. |
Elias
Member #358
May 2000
|
Quote: Not quite, at least not as I would define tripplebuffering. The crucial part is that you don't have to wait for vsync. There's one page displayed, one pages scheduled to be displayed at the next update of the graphics card/driver (`vsync') and one you use for drawing the next frame. Yes, was just going to edit when you replied - correctly would have been, there's simply no point in using triple buffering, since you could just as well use page flipping without vsync, in the case of X11. Quote:
Code doing triple buffering. The main reason I don't ever support triple buffering in any of my programmes is that I can't really test easily if it works myself. Hm, a much better patch for that would be one to add a flip() method though, so you don't need any extra code besides a flag to use triple buffering.. well, in 4.3.x, we'll have that anyway -- |
|
|