Allegro.cc - Online Community

Allegro.cc Forums » Off-Topic Ordeals » Increase in Programming Questions

This thread is locked; no one can reply to it. rss feed Print
 1   2 
Increase in Programming Questions
Thomas Fjellstrom
Member #476
June 2000
avatar

kazzmir said:

You essentially cannot create bitmaps on the fly and draw to them, everything must be done to the screen.

Bullcrap. Just use memory bitmaps, and either create your own optimized software drawing routines, or wait till allegro's gets better (a5's arent quite as fast as a4s were).

Quote:

. Blending is quite different.

Yes, different is bad, we know.

Quote:

The difference between video and memory bitmaps must be well understood in A5 where as in A4 you could mostly ignore it.

At your own peril sure. In a4 you weren't supposed to read from video bitmaps, and primitives were slower on video bitmaps as well. Not a heck of a lot different from A5 if you ask me. HW acceleration really hasn't changed that much in the past 10 years. Accessing video memory from the cpu is still really slow.

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

weapon_S
Member #7,859
October 2006
avatar

Quote:

(events)

IIRC using similar mechanisms in A4 was a PITA, requiring to register a fairly complex[1] callback function. So in a way it has become more user-friendly.
If that really is a problem perhaps a ALLEGRO_KEYBOARD_STATE* al_install_keyboard_poll(), and ALLEGRO_MOUSE_STATE* al_install_mouse_poll()(and associated uninstall) helper functions could be made?

References

  1. Because it actually couldn't do much, and introduced another thread.
kazzmir
Member #1,786
December 2001
avatar

Bullcrap. Just use memory bitmaps, and either create your own optimized software drawing routines, or wait till allegro's gets better (a5's arent quite as fast as a4s were).

You cannot mix memory and video bitmaps and expect to get any reasonable performance.

Quote:

Yes, different is bad, we know.

That is a flippant remark. Recreating A4 blending modes in A5 is non-trivial, I had to work the math out with a pen and paper. Certainly the A5 blending modes give a larger range of possibilities but that is due to their complexity.

Quote:

At your own peril sure. In a4 you weren't supposed to read from video bitmaps, and primitives were slower on video bitmaps as well. Not a heck of a lot different from A5 if you ask me. HW acceleration really hasn't changed that much in the past 10 years. Accessing video memory from the cpu is still really slow.

You didn't have to use video bitmaps at all in A4 for the most part, and if you did then you probably knew what you were doing.

Thomas Fjellstrom
Member #476
June 2000
avatar

kazzmir said:

You cannot mix memory and video bitmaps and expect to get any reasonable performance.

You're just comparing a properly hw accelerated A5 program, to an unaccelerated A5 program OF COURSE unaccelerated is going to be slower. Just like an A4 program is going to be significantly slower than a well done A5 program.

Quote:

That is a flippant remark.

Yup. But thats about the only reason I can see you made the remark. It's SIGNIFICANTLY different from A4's. And its complex in that the api is similar to the underlying (D3D and OpenGL) APIs. That's just how the hardware deals with blending. You give it a source, a destination, a source op and a dest op, and it does its magic. Yes, you have to study a table to figure out some of the less used effects, but hey, them's the breaks.

Quote:

You didn't have to use video bitmaps at all in A4 for the most part, and if you did then you probably knew what you were doing.

And you don't have to in A5 either. Yes, in A5, memory bitmaps are significantly slower than regular bitmaps. Not really a surprise. Regular bitmaps are blazingly fast. A4's memory routines fairly highly optimized which makes them somewhat faster than A5's memory routines. If you have the expertise to change that, I'm sure no one would object to you working on 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

Matthew Leverton
Supreme Loser
January 1999
avatar

kazzmir said:

To get any reasonable performance you have to throw out putpixel/getpixel. You essentially cannot create bitmaps on the fly and draw to them, everything must be done to the screen. Certain effects require shaders. Blending is quite different.

Yes, it is easier to do 8-bit and raw pixel manipulation in Allegro 4. In fact, if that's what you want to do, then I would avoid Allegro 5. It's just not designed for 80's style of graphics programming.

But if we are talking about n00bs learning the library, none of that really applies. All they need to do is respond to input and blit bitmaps and play sound effects. None of that is significantly harder to do in Allegro 5.

Quote:

The difference between video and memory bitmaps must be well understood in A5 where as in A4 you could mostly ignore it.

I don't think there's much truth to that. The only "tricky" thing with A5 is that video bitmaps are lost when displays are destroyed (or they are not available when there is no display), but 5.1 takes care of that issue such that n00bs won't even have to know what is going on.

AMCerasoli
Member #11,955
May 2010
avatar

Arthur Kowowowlalaololsky

Hahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahah ahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahaha.
You mother fucker made me laugh that much that I can't even breath. I think I woke up my neighbors dammit. You should copy and paste!.

Arthur Kalliokoski
Second in Command
February 2005
avatar

His name is just as long if you paste them all together.

"The y man" Yves Van_Houtte and I think there was one more but thankfully I've forgotten.

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

― Robert A. Heinlein

Karadoc ~~
Member #2,749
September 2002
avatar

klaxxz, or something like that.

-----------

Neil Walker
Member #210
April 2000
avatar

Allegro 4 is fine for single display, unaccelerated 2D games of any complexity. The only major shortcomings are due to incompatibilities with modern operating systems. The state based input system is somewhat limiting, but probably not enough to get in the way. The API is a mess, but that doesn't really matter.

The same could be said for PHP but that manages to run 80% of websites.

Neil.
MAME Cabinet Blog / AXL LIBRARY (a games framework) / AXL Documentation and Tutorial

wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie

SiegeLord
Member #7,827
October 2006
avatar

A4's memory routines fairly highly optimized which makes them somewhat faster than A5's memory routines. If you have the expertise to change that, I'm sure no one would object to you working on it.

Is that really true? I mean the routines originally came from A4 and when they were replaced with higher quality versions (making the speed comparison a little moot) they were optimized to comparable performance. I'll have to try out some benchmarks when I get the chance...

The biggest issue of using memory bitmaps in A5 is that they are much slower to deliver to the screen than they were in A4, but that has to do with the window creation code and not the routines themselves.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Specter Phoenix
Member #1,425
July 2001
avatar

kazzmir said:

You know thats borderline trolling.


Well ML is allowed to seeing as he is the A.cc admin :p.

I don't know as to how it is unfriendly. I just know that a few said it was and even some on IRC have said it is an unfriendly API to new programmers. I think the phrase used on IRC is simply 'noob unfriendly' compared to A4. I couldn't really add anything as I never pay attention to the library specs for allegro and I haven't really bothered with any other library before until I started with Allegro 3.9.x WIP I think it was. I've tried using A5 myself and find I have issues with the API and my code so I'm not the best to discuss this with, hence me being quite the whole discussion.

"Can't a man even talk to himself without being interrupted?" -Krull(1983)
"Through vengence I was born. Through war I was trained. Through love I was found. Through death I was released. Through release I was given a purpose." -- Specter Phoenix
"Programming == AWESOME the rest is just tools to accomplish it."
END OF LINE

MiquelFire
Member #3,110
January 2003
avatar

Using it to its fullest, A5 is really hard to use compared to A4 on Windows.

If you had built stuff some source (stuff that is not included in the compiler at least), and you didn't want to learn how to compile the dependencies, you'll miss a lot of functionality. That's the only part of A5 I find unfriendly. The API itself is ok.

---
Febreze (and other air fresheners actually) is just below perfumes/colognes, and that's just below dead skunks in terms of smells that offend my nose.
MiquelFire.red | +Me
Windows 8 is a toned, stylish, polished professional athlete. But it’s wearing clown makeup, and that creates a serious image problem. ~PCWorld Article

Thomas Fjellstrom
Member #476
June 2000
avatar

SiegeLord said:

Is that really true?

It was. Now I'm not so sure. I'm not sure how drawing to the screen is slower.. Either way the contents of the memory bitmap have to be uploaded to the video card. Why would that be slower with textures, than with raw draw calls? (many newer cards and their drivers don't HAVE 2D hardware anymore, and any 2D ops are emulated via the 3D hardware meaning at some point that bitmap data is going in as a texture or at the very least some glDrawPixel(s) calls. But I'm still a n00b where OpenGL and D3D are concerned.

Using it to its fullest, A5 is really hard to use compared to A4 on Windows.

Using it to its fullest, A5 provides a lot more fancy features than A4 does. So thats kindof expected. A4 did almost no hardware acceleration of any kind. At most it'd have support for (video|system)->video blits, or on a rare occasion mem->video blits. But for the most part there was no acceleration. After that you have annoying global variables storing input state which are rather hard to properly use, compared to an event which you can just "if" on, rather than building a system to detect key releases, you just wait for the key release event. considerably easier than in A4.

Of course if you meant building A5, I can't really argue with that too much. But again there, it provides a lot more functionality in the addons than A4 ever did, so its not really a fair comparison.

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

taron 
Member #10,584
January 2009
avatar

Don't most cards still support 2d hardware acceleration?

I thought it was just so slow that using 3d calls instead of 2d ones (to actually render 2 dimensions) is faster.

james_lohr
Member #1,947
February 2002

taron  said:

Don't most cards still support 2d hardware acceleration?

Not really. Rendering 2d with OpenGL is really just a degenerative case of rendering 3D.

You can still render pixel-perfect 2D, but you have to use shaders if you want the same type of control you get with ye-old 2D graphics.

Thomas Fjellstrom
Member #476
June 2000
avatar

taron  said:

Don't most cards still support 2d hardware acceleration?

They used to. Radeons and Nvidia chips dropped the fixed pipeline and all 2D specialized acceleration hardware a generation or two (possibly three) ago. In the Radeon case, the drivers emulate the old fixed pipeline 2D work with the 3D hardware.

But even before this, GPUs had slowly started to not care about 2D performance for desktop or gamer cards. The only cards that still cared were workstation cards. But now even with that, I don't think they care, as they all share the same base chipsets.

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

Specter Phoenix
Member #1,425
July 2001
avatar

The frequency will decrease again eventually.

"Can't a man even talk to himself without being interrupted?" -Krull(1983)
"Through vengence I was born. Through war I was trained. Through love I was found. Through death I was released. Through release I was given a purpose." -- Specter Phoenix
"Programming == AWESOME the rest is just tools to accomplish it."
END OF LINE

SiegeLord
Member #7,827
October 2006
avatar

So I did some benchmarks on A5 vs A4 memory bitmap routines and here are the results:

./a4test
msec per blit to bitmap: 5.096020e-02
msec per blit to bitmap (rot): 1.822495e-01
msec per draw_trans_sprite to bitmap (alpha): 4.088342e-01
msec per blit to screen: 1.982179e+00
./a5test
msec per draw to bitmap: 5.065120e-02
msec per draw to bitmap (rot): 2.926926e-01
msec per draw to bitmap (alpha): 1.492945e+00
msec per draw to screen: 1.197950e+00

So yes, A5's memory routines are not quite as optimized as A4's were. Test sources are below. Bitmap used is attached.

a5test.cpp#SelectExpand
1#include <allegro5/allegro.h> 2#include <allegro5/allegro_image.h> 3 4#include <stdio.h> 5 6int main() 7{ 8 al_init(); 9 al_init_image_addon(); 10 11 ALLEGRO_DISPLAY* disp = al_create_display(800, 600); 12 13 al_set_new_bitmap_flags(ALLEGRO_MEMORY_BITMAP | ALLEGRO_NO_PREMULTIPLIED_ALPHA); 14 ALLEGRO_BITMAP* bmp1 = al_load_bitmap("test.tga"); 15 ALLEGRO_BITMAP* dummy = al_create_bitmap(800, 600); 16 17 al_clear_to_color(al_map_rgb_f(1, 0, 0)); 18 19 size_t N = 10000; 20 21 double start, stop; 22 23 al_set_target_bitmap(dummy); 24 al_clear_to_color(al_map_rgb_f(1, 0, 0)); 25 al_set_blender(ALLEGRO_ADD, ALLEGRO_ONE, ALLEGRO_ZERO); 26 27 start = al_get_time(); 28 for(int ii = 0; ii < N; ii++) 29 { 30 al_draw_bitmap(bmp1, 0, 0, 0); 31 } 32 stop = al_get_time(); 33 34 printf("msec per draw to bitmap: %e\n", 1000.0 * (stop - start) / N); 35 36 start = al_get_time(); 37 for(int ii = 0; ii < N; ii++) 38 { 39 al_draw_rotated_bitmap(bmp1, 0, 0, 200, 200, ALLEGRO_PI / 4, 0); 40 } 41 stop = al_get_time(); 42 43 printf("msec per draw to bitmap (rot): %e\n", 1000.0 * (stop - start) / N); 44 45 al_set_blender(ALLEGRO_ADD, ALLEGRO_ALPHA, ALLEGRO_INVERSE_ALPHA); 46 47 start = al_get_time(); 48 for(int ii = 0; ii < N; ii++) 49 { 50 al_draw_bitmap(bmp1, 200, 0, 0); 51 } 52 stop = al_get_time(); 53 54 printf("msec per draw to bitmap (alpha): %e\n", 1000.0 * (stop - start) / N); 55 56 al_set_target_bitmap(al_get_backbuffer(disp)); 57 al_set_blender(ALLEGRO_ADD, ALLEGRO_ONE, ALLEGRO_ZERO); 58 59 start = al_get_time(); 60 for(int ii = 0; ii < N; ii++) 61 { 62 al_draw_bitmap(dummy, 0, 0, 0); 63 al_flip_display(); 64 } 65 stop = al_get_time(); 66 67 printf("msec per draw to screen: %e\n", 1000.0 * (stop - start) / N); 68 69 return 0; 70}

a4test.cpp#SelectExpand
1#include <allegro.h> 2#include <stdio.h> 3 4#include <sys/time.h> 5 6time_t IniTime; 7 8void init_time() 9{ 10 struct timeval time; 11 12 gettimeofday(&time, NULL); 13 14 IniTime = time.tv_sec; 15} 16 17double get_time() 18{ 19 struct timeval time; 20 21 gettimeofday(&time, NULL); 22 23 return double(time.tv_sec - IniTime) + double(time.tv_usec) / 1000000.0; 24} 25 26int main() 27{ 28 allegro_init(); 29 set_color_depth(32); 30 set_gfx_mode(GFX_AUTODETECT_WINDOWED, 800, 600, 0, 0); 31 init_time(); 32 33 BITMAP* bmp1 = load_bitmap("test.tga", 0); 34 BITMAP* dummy = create_bitmap(800, 600); 35 36 clear_to_color(screen, makecol(255, 0, 0)); 37 clear_to_color(dummy, makecol(255, 0, 0)); 38 39 size_t N = 10000; 40 41 double start, stop; 42 43 start = get_time(); 44 for(int ii = 0; ii < N; ii++) 45 blit(bmp1, dummy, 0, 0, 0, 0, bmp1->w, bmp1->h); 46 stop = get_time(); 47 48 printf("msec per blit to bitmap: %e\n", 1000.0 * (stop - start) / N); 49 50 start = get_time(); 51 for(int ii = 0; ii < N; ii++) 52 rotate_sprite(dummy, bmp1, 200, 200, ftofix(32)); 53 stop = get_time(); 54 55 printf("msec per blit to bitmap (rot): %e\n", 1000.0 * (stop - start) / N); 56 57 set_alpha_blender(); 58 59 start = get_time(); 60 for(int ii = 0; ii < N; ii++) 61 draw_trans_sprite(dummy, bmp1, 200, 0); 62 stop = get_time(); 63 64 printf("msec per draw to bitmap (alpha): %e\n", 1000.0 * (stop - start) / N); 65 66 solid_mode(); 67 68 start = get_time(); 69 for(int ii = 0; ii < N; ii++) 70 blit(dummy, screen, 0, 0, 0, 0, dummy->w, dummy->h); 71 stop = get_time(); 72 73 printf("msec per blit to screen: %e\n", 1000.0 * (stop - start) / N); 74 75 return 0; 76}

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

 1   2 


Go to: