Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » CPU family compilation of allegro?

This thread is locked; no one can reply to it. rss feed Print
CPU family compilation of allegro?
Thomas Fjellstrom
Member #476
June 2000
avatar

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...

--
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

Bob
Free Market Evangelist
September 2000
avatar

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.
- Allegro has a funny way of rotating things.

Since you have absolutely no idea what you're talking about, lemme paste the rotation code from AllegroGL:

1static void allegro_gl_screen_pivot_scaled_sprite_flip(struct BITMAP *bmp,
2 struct BITMAP *sprite, fixed x, fixed y, fixed cx, fixed cy, fixed angle,
3 fixed scale, int v_flip)
4{
5 double dscale = fixtof(scale);
6 GLint matrix_mode;
7 AGL_LOG(2, "glvtable.c:allegro_gl_screen_pivot_scaled_sprite_flip\n");
8
9#define BIN_2_DEG(x) ((x) * 180.0 / 128)
10
11 glGetIntegerv(GL_MATRIX_MODE, &matrix_mode);
12 glMatrixMode(GL_MODELVIEW);
13 glPushMatrix();
14 glTranslated(fixtof(x), fixtof(y), 0.);
15 glRotated(BIN_2_DEG(fixtof(angle)), 0., 0., -1.);
16 glScaled(dscale, dscale, dscale);
17 glTranslated(-fixtof(x+cx), -fixtof(y+cy), 0.);
18
19 do_masked_blit_screen(sprite, bmp, 0, 0, fixtoi(x), fixtoi(y),
20 sprite->w, sprite->h, v_flip ? V_FLIP : FALSE, FALSE);
21 glPopMatrix();
22 glMatrixMode(matrix_mode);
23 
24#undef BIN_2_DEG
25 
26 return;
27}

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.

--
- Bob
[ -- All my signature links are 404 -- ]

soniCron
Member #5,721
April 2005
avatar

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
avatar

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.

--
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:

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.

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

soniCron
Member #5,721
April 2005
avatar

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
avatar

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.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Bob
Free Market Evangelist
September 2000
avatar

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.

--
- Bob
[ -- All my signature links are 404 -- ]

soniCron
Member #5,721
April 2005
avatar

I concede. Have a nice day.

Evert
Member #794
November 2000
avatar

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.
If you want to lend a hand, then by all means do so. Allegro sorely lacks developers.

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.
Does it make sense to replace the asm code with C code if that works better and is easier to maintain? Hell, yes - in fact my personal interest in the asm code is zero since I can't use it anyway. But you do not change that overnight. There are subtleties in Allegro's source you and I are not aware of. There's a reason there is no real support for building a pure C version in Windows. The reason is that the resulting DLL will be incompatible with the DLL containing the asm code.
Does it make sense to have faster and better blenders in Allegro? Hell, yes. But someone has to write the code for that, test it and make sure it integrates well.
Shawn said, and I agree with him, that in order to properly adminster a project is that you have to be a complete and utter nazi when it comes to changing things. If you start doing a lot of big changes without carefully considering what you do and how it affects other things you will end up breaking the code, which is doing everyone a disservice.
Change and improve things, but always be careful and sceptical about what you're trying to do.

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.
At the very least, Elias, Peter, Kitty Cat and I read the 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.
Also, for future reference, you should check if anything has been going on and if so how much before giving the impression that the developers don't actually do anything. As it is, we're all extremely busy.

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?
When Allegro5 finally died completely it left Allegro itself in a rather dangerous situation. About a year ago, it was practically dead and development had slowly grinded to a halt. All things considered, I think we've managed to get things going again fairly well. Better than I would have hoped for, actually.
But I will tell you that we will not try to make the same mistake again. The code will be evolved rather than recreated from scratch from 4.2 to something like the proposed 5.0, and work has already started on this. To focus fully on that, 4.2 has to mature though. That, for me, is the top priority at the moment.

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.
As for corrosive comments and attitudes, you may want to screen your own posts for some of that as well.

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.
It would be a bad sign if whatever you come up with were to be accepted without criticism.

And now I'm going to sleep.

Michael Jensen
Member #2,870
October 2002
avatar

Quote:

Bob said:
You can phase things in, but you can't phase things out. Allegro 4.x still needs to be source-compatible with 1.0.

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?

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

Milan Mimica
Member #3,877
September 2003
avatar

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.

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

Evert
Member #794
November 2000
avatar

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.
If you mean a repository of actual patches and diffs against Allegro itself, I recommend against that.

Milan Mimica
Member #3,877
September 2003
avatar

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. ;D Of course, this would work only if someone is willing to maintain these patches. Anyway, I would like to see a flblend integration patch.
And maybe some day we could merge this patches into a new AllegroProUltraSepcialEdition :P

Evert
Member #794
November 2000
avatar

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.
That would be far more useful.

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 :)

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

Evert
Member #794
November 2000
avatar

I have one that adds triple buffering to the plain X11 driver that was rejected.
It uses the scrolling API but uses a seperate thread to scroll the screen to not block the user programme. This is probably a bad idea in general, but it helped me test some things related to triple buffering at some time.

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 :)

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

Evert
Member #794
November 2000
avatar

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.
It has no real benefit otherwise, ie, animations are not smoother than when using double buffering (for obvious reasons) as would be the case on other platforms.

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.
It has no real benefit otherwise, ie, animations are not smoother than when using double buffering (for obvious reasons) as would be the case on other platforms

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 :)

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



Go to: