|
|
|
| create_bitmap() problem. |
|
GullRaDriel
Member #3,861
September 2003
 |
Elias: you're re-creating your bitmap each loop ? Using line in a loop is , i think, normal. EDIT: i mean in a drawing loop "Code is like shit - it only smells if it is not yours" |
|
Elias
Member #358
May 2000
|
I can do 2937779 create/destroy_bitmap pairs with a 1x1 bitmap in a second, and can do only 44555 lines from 0/0 to 1000/1000 in a second. So now, which one is speed critical? Of course, both times, the additional check would not change it noticeable at all I think. So, just want to demonstrate that it's hard to decide what is speed critical. OpenGL has error checking for every single function, so we could have it too after 4.2.0. For 4.2.0, ASSERT is simply the way that was chosen for error handling, and since it works perfectly well, no need to change it. [Edit:] Temporary bitmaps in the draw loop are needed for example if you want a stretch_trans_blit, or stretched_printf, or things like that. -- |
|
Peter Wang
Member #23
April 2000
|
So the conclusion should be that assertions should never be disabled unless absolutely critical for speed. Then create_bitmap(0,0) would always abort regardless of whether you use the release or debug version of Allegro. Great!
|
|
GullRaDriel
Member #3,861
September 2003
|
:p "Code is like shit - it only smells if it is not yours" |
|
Thomas Harte
Member #33
April 2000
 |
[ Quote: Temporary bitmaps in the draw loop are needed for example if you want a stretch_trans_blit, or stretched_printf, or things like that. Temporary bitmaps aren't necessary, they're used there because it makes implementation easier and/or are the fastest method of doing what is required. It's a circular argument. If bitmap creation were substantially slower then (hopefully) it wouldn't be done in things like stretch_trans_blit and stretched_printf (really - 'stretched'? Is someone actually on a mission to create the least orthogonal API?). Besides which, anything that relies on malloc relies on OS services, so speed is highly dependent on OS. Perhaps this is (another) reason why us OS X'ers see about 1/4 the frame rate of our PC cousins? [My site] [Tetrominoes] |
|
Elias
Member #358
May 2000
|
I wasn't talking about Allegro functions there, it was just an example why you might need create_bitmap in a draw loop (to support my argument that this can't be a criterion what needs error checking and what not). -- |
|
A J
Member #3,025
December 2002
 |
so are we in agreement create_bitmap() is not speed critical ? asserts and a check is the best option ? ___________________________ |
|
Kitty Cat
Member #2,815
October 2002
 |
Quote: I wasn't talking about Allegro functions there, it was just an example why you might need create_bitmap in a draw loop (to support my argument that this can't be a criterion what needs error checking and what not). You'd only create the bitmap when you need to, and recycle it for later. In the loop, you'd check that the bitmap exists, and that it's big enough. If not, you make a big enough bitmap, and leave it around for the next iteration. Yeah, this may cause the first iteration to lag, but it's a one-time deal.. the bitmap will stay around so you can use it as-is on subsequent run-throughs (no additional mallocs necessary). I actually did this when I was working with Allegro to do translucent (normal and additive) software polygons. Quote: I can do 2937779 create/destroy_bitmap pairs with a 1x1 bitmap in a second, and can do only 44555 lines from 0/0 to 1000/1000 in a second. So now, which one is speed critical? line is still speed critical, even if it ends up being slower. The idea is that you can use line multiple times in quick succession per frame render. The faster the better. Creating a bitmap, however, doesn't typcially get used outside of initialization (or in the manner I outlined above) where speed isn't as much of an issue.. that a few extra if checks aren't going to cause speed problems for a program. -- |
|
Carrus85
Member #2,633
August 2002
 |
Yeah, I myself was wondering why you wouldn't just create a "working" bitmap outside of the loop, and just recycle it... (and destroy/create it again if the size changes for some reason).
|
|
Michael Jensen
Member #2,870
October 2002
 |
While I think Elias's line argument is kind of bogus, I really don't think checking for NULL in drawing functions would lead to much of a slower program, in all of my draw loops, functions that take a bitmap as an argument or call create_bitmap etc I always check for null, not that I expect any of them to fail (except incase of a logic error, or file not found error) If I remove the checks my program speed difference is competley unnoticable, plus it's safer to leave them in. Quote:
No one with a brain would do that, but there are zero size arrays so who's to say you can't make a zero size bitmap. if a zero sized bitmap is allowed then it's destroyal should also be allowed. And saying "no one with a brain would do that" is a completely worthless argument, that having been said, no one with a brain would have posted what you have! Quote: Changing this in the way suggested will make code run normally (without errors) in release mode and it will cause a crash in debug mode. This is not acceptable. No it wouldn't. Quote:
so this would always work: not if create bitmap returns null -- or did I miss something? are null checks being added to everything? Actually, adding a null check to destroy bitmap isn't a bad idea, I don't think I've evern seen anyone sanley calling destroy_bitmap(bmp) without first checking if bmp is null, and if create_bitmap is not speed critical, why should destroy_bitmap be? it's usually only called when shutting down! Quote: Aren't you checking , when doing A=1/B , if B isn't zero ? i hope you do. I usually don't perform much division unless I'm using doubles... (it's Ok to divide a double by 0, and actually useful.) Quote: After 4.2.0, we could implement something like OpenGL, where every function returns an error code. Or maybe even better, provide a global error callback which is called for errors (in which you can e.g. raise an exception - or in C you could use longjmp to jump to a user exception handler). User-Defined error handlers would be SWEET! As far as create bitmap goes, to me it makes more sense to let the lib do the checking because it's one if statement, and the create_bitmap could return faster in rare instances where it can pre-determine that it doesn't even have to call malloc. If the user was required to do this, a code bloat could occur, it makes sense to put the check at the base-level so that there's absolutley no chance of it accidently not getting checked for. Edit: Quote: Besides which, anything that relies on malloc relies on OS services, so speed is highly dependent on OS. Perhaps this is (another) reason why us OS X'ers see about 1/4 the frame rate of our PC cousins? If it is, it would be neat if allegro could allocate a chunk of memory at the beginning of the program and preformed it's own memory managment/allocation on that chunk to bypass the OS's speed issue...
|
|
Kitty Cat
Member #2,815
October 2002
|
Quote: not if create bitmap returns null -- or did I miss something? AFAIK, destroy_bitmap does nothing with a NULL pointer. I simply returns. IMO, anything that create_* returns, destroy_* should accept without problems. -- |
|
Evert
Member #794
November 2000
 |
Quote: if a zero sized bitmap is allowed then it's destroyal should also be allowed. Yes. Thing is, they're not allowed. Quote: I don't think I've evern seen anyone sanley calling destroy_bitmap(bmp) without first checking if bmp is null In that case, you've never seen my code. create/destroy behaves like alloc/free: it does nothing with a NULL pointer. Quote: If the user was required to do this, a code bloat could occur, it makes sense to put the check at the base-level so that there's absolutley no chance of it accidently not getting checked for. It is the user's responsibility to pass valid, sane, arguments to a function. The library should, in my opinion, do sanity checks in debug mode but not in release mode. Compare the speed difference between the library in debug mode and release mode. It could be minor on your machine and for your programme, but that doesn't mean it would be for everyone. Quote: IMO, anything that create_* returns, destroy_* should accept without problems. Yes, no argument there. |
|
Thomas Harte
Member #33
April 2000
|
Quote: I really don't think checking for NULL in drawing functions would lead to much of a slower program It shouldn't make much odds at all, it's presumably the difference between: LD register, pointer value And: LD register, pointer value Especially with branch prediction very effectively preventing any sort of stall in close repeated calls it isn't much of a difference. Quote: If it is, it would be neat if allegro could allocate a chunk of memory at the beginning of the program and preformed it's own memory managment/allocation on that chunk to bypass the OS's speed issue... Firstly, it's wild speculation that this particular thing is a speed issue, I was just making the point that most of the time, the way things are implemented on Allegro is dictated by quick tests or by programmer intuition. Since a lot of the non-DOS/Windows versions seem to be very slow then this possibly needs addressing. Secondly, Allegro is already a 90% bloat library for most people that being DOS-centric in design eats 100% CPU at runtime, can it really justify taking an unnecessarily gigantic chunk of memory as well? Quote: It is the user's responsibility to pass valid, sane, arguments to a function. The library should, in my opinion, do sanity checks in debug mode but not in release mode. Then you definitely want to look at functions such as get_camera_matrix. Expect the user to be able to pass orthogonal 'up' and 'front' vectors or keep things normalised at their end? Nah, lets just force two sqrts and a bunch of dot products on them. EDIT: probably the smartest thing to do instead of a function by function disassembly is to work out all the anti-patterns in Allegro? I'm new to this, but I definitely spot abstraction inversion, accidental complexity, busy waiting, code momentum, continuous obsolescence, creeping featurism, procedural code and the aura of a stovepipe system. But I assume 4.3 will be a clean sweep of much of this, or at least an API that allows a clean sweep? [My site] [Tetrominoes] |
|
A J
Member #3,025
December 2002
|
Thomas can you give 1 example in allegro, of each of those anti-patterns you mentioned ? or are you just a warm-body ___________________________ |
|
Thomas Harte
Member #33
April 2000
|
Quote: Thomas can you give 1 example in allegro, of each of those anti-patterns you mentioned ? or are you just a warm-body Can do! I'd never actually heard of this stuff before, but discovered it yesterday while searching for the Gang of Four, a historical political grouping here in the UK. Turns out another Gang of Four wrote a book that expounds most of the terms on that page. Point is, I may well be misunderstanding or misapplying any quantity of the group. Anyway... abstraction inversion accidental complexity busy waiting code momentum continuous obsolescence creeping featurism procedural code stovepipe system Aside: it would be very interesting to make a virtual middle layer Allegro DLL that simply flagged which functions were used then passed calls on to the real DLL and then to run a whole bunch of Allegro programs through it and find out what proportion of the API is actually in common use. I may try that one day if I ever return to the Windows fold. [My site] [Tetrominoes] |
|
Evert
Member #794
November 2000
|
This is somewhat sidetracking the original topic, and I don't think we need another discussion on what things need to be changed in Allegro. Quote: Complexity is introduced by the array of different video techniques, as described above, as well as the way that FONTs are not composed of normal bitmaps except in 16/24bit mode Actually, I 8 bit fonts are normal BITMAPs as well. Only monochrome fonts are different, which is not that surprising considering that Allegro doesn't support monochrome bitmaps. Quote: At the minute much more work seems to go into getting every piece of Allegro to work on every platform it is meant to support than in improving the API As I'm sure you're aware, that's because we want to get 4.2 out. API improvements are post 4.2 Quote: See the huge number of OS X problems being reported (admittedly mostly by me) Yes, and do keep them coming! Afterall, we want to fix those (although it's rather hard with most of us not having a Mac). Quote: Defined as "a legacy system which cannot be upgraded or refactored and which must be built around until it can be replaced entirely". See the abandonment of Allegro 5.0 and instead the idea of building a new API over the existing one then gradually filtering out the old stuff. Not sure if you followed why this is, but the reason the `rewrite Allegro 5 from scratch' idea was dropped is that there is simply not enough manpower available to do it. No one has the time for a big undertaking like that. |
|
Thomas Harte
Member #33
April 2000
|
Quote: This is somewhat sidetracking the original topic I disagree, the topic had already begun "the current implementation decisions affecting Allegro vs the ones we'd like to see"! Anyway, since all of the concerns are already known or to be addressed after 4.2, things are looking up and as you point out, there isn't much utility in discussing them again. Just one question, the answer to which I'm sure has been made clear 1,000 times but which I never seem to grasp for very long: where can the API specs for 4.3 be found? Or are they the same as 5.0 was, but without a full rewrite underneath? [My site] [Tetrominoes] |
|
Evert
Member #794
November 2000
|
Quote: where can the API specs for 4.3 be found? Or are they the same as 5.0 was, but without a full rewrite underneath?
They're the same as for 5.0, the rationale being that a lot of work and thought was put into those and it'd be a waste not to use it, or to just start over and reinvent all that was considered before. About the `rewrite underneath', that is actually part of the plan, but it won't be a rewrite from scratch. Peter [Wang] has worked on the event subsystem, which replaces what was previously in place. There are also new keyboard drivers. I've started on the graphics API, but it still lives on top of the old drivers. Eventually, those will have to go. |
|
Elias
Member #358
May 2000
|
Quote:
abstraction inversion Yes, that's all the reason why there will be a new version. Quote: busy waiting This has two reasons. One is the current polling nature - so the only way around it is to insert rest(1). The other is that many programs simply don't put in rest(1) on purpose, fearing it will cause worse performance. The events system already implemented in new_api_branch solves this. Quote:
code momentum I don't understand.. you mean, the API has too many functions? Quote: continuous obsolescence As Evert pointed out, in the time of feature freeze before the next stable release after several years it really is wise to do nothing except fixing the existing things. Quote: creeping featurism The problem is, many included things make it easier to use. But there haven't been any much new features added in a long time. Is there any new feature in 4.2.0 we didn't have in 4.0.0? I fully would support a move towards making Allegro more modular though.. even if we then have to package up all the modules again as a single package for anyone to be happy with it. Quote: procedural code I don't see this. There's the long standing bitmap/sprite API problem, and some historic things like the 3D functions, to which this may apply - but the core drivers follow a very clean architecture. Quote:
stovepipe system Well, what is happening is, core parts are upgrade in new_api_branch, and the other code is constantly refactored.. so per your definition this doesn't apply to Allegro. Quote: Just one question, the answer to which I'm sure has been made clear 1,000 times but which I never seem to grasp for very long: where can the API specs for 4.3 be found? Or are they the same as 5.0 was, but without a full rewrite underneath? I'd like there to be a list of things which need to be done, and who is working on what.. my attemps can be seen in the wiki: http://awiki.strangesoft.net/bin/view/Main/AllegroDev There's not much there yet, but I guess that can be contributed to everyone being busy with 4.2.0 -- |
|
Michael Jensen
Member #2,870
October 2002
|
Quote: Firstly, it's wild speculation that this particular thing is a speed issue, I got that part. Quote: Secondly, Allegro is already a 90% bloat library for most people that being DOS-centric in design eats 100% CPU at runtime, can it really justify taking an unnecessarily gigantic chunk of memory as well? Why not? If people ask we could use Pacman as a scapegoat. Quote: Yes. Thing is, they're not allowed. I get that part too, but the person I was responding too didn't; he said something along the lines of "If it lets you do it..." and I said something along the lines of "well if it lets us do it, then it should work" Quote: Yes, no argument there. Umm if destroy_bitmap should destroy anything create_bitmap makes then create_bitmap should return NULL on passing (0,0) but you seem to be disagreeing on that item... not sure... -- And I was unaware of NULL not crashing destroy_bitmap...
|
|
A J
Member #3,025
December 2002
|
Quote: it would be very interesting to make a virtual middle layer Allegro DLL ... find out what proportion of the API is actually in common use . my allegro C++ wrapper does func call counting, i get a nice chart at teh bottom of the log file that tells me which functions get (ab)used. Quote: don't put in rest(1) on purpose, fearing it will cause worse performance. The events system already implemented in new_api_branch solves this "solves" or forces ? ___________________________ |
|
Evert
Member #794
November 2000
|
Quote: it would be very interesting to make a virtual middle layer Allegro DLL ... find out what proportion of the API is actually in common use I'd just use a profiler. That's (part of) what it's for, afterall. |
|
Elias
Member #358
May 2000
|
Quote: "solves" or forces ? Solves. You can always busy loop and poll for events with an event based API. It just would be stupid. Quote: I'd just use a profiler. That's (part of) what it's for, afterall. Do we provide a profiling version for MSVC? It indeed sounds like AJ simply wrote his own profiler.. -- |
|
Evert
Member #794
November 2000
|
Quote: Do we provide a profiling version for MSVC?
Not sure. I don't think so, but it shouldn't matter for call counts. By the way, Elias, is reply-by-email working for you? It stopped working for me a while back, but it might be a problem on my end (didn't have time to look into it yet). |
|
Elias
Member #358
May 2000
|
2005-08-20 at 22:31 +0000, Evert said:
Quote: Yes, I've never seen profiler comparisons. It wouldn't be the best thing anyway, since each profiler produces overhead of its own. Some things really take much longer with the profile time, in my experience. AJ: Do you know if MSVC supports profiling? And related, I actually have no idea how well the debug version works in MSVC. Can you actually step through Allegro and view variable values and so on, like you can with gdb? Quote:
By the way, Elias, is reply-by-email working for you? It stopped Not sure, I mostly click the "Go to post" link - unless I mistake it as an [AD] post and then just reply. This is an email reply, in case it arrives. -- |
|
|
|
