Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » Allegro Beginner questions

This thread is locked; no one can reply to it. rss feed Print
 1   2   3 
Allegro Beginner questions
the_cake
Member #15,594
May 2014

Hello,

I have the project to make my own FPS with my own engine (WOlF3d style) with allegro this time, in fact I am really disappointed by SDL 2.0 library so I decided due to the time waisting to move to this library, I had have mouse movement problems and I was too lazy to fix myself these bugged functions.

However before installing this library, I searched for known bugs and I saw that there are still plenty of problems with displaying (bugs seems to appear with allegro 5 and 4.22)and the same problem with mouse movement which is limited by the edge of screen...

" //Quote not from me picked on http://freecode.com/projects/allegro/releases/258252
Release note of version 4.2.2 :A new mouse cursor API is used, but it doesn't work in Windows fullscreen modes.
"

So my questions are :

with allegro :

- Which version of allegro should I use if I want that my program run under windows ?
- Which version of allegro got no mouse problems and full-screen displaying bugs ?
- or even better, what is the last version outdated but fully fonctionnal that works for sure, (I can even use dosbox to launch the game, that's not a problem ! ;D) ?
- Can i manually set my screen pixels, that is to say, allegro allows me to have a pointer to the screen pixel, then I can modify, then I imagine I must refresh the screen, can allegro do that ? (I don't want to have a fonction that modify 1 pixel, it would be too long to modify the whole_screen)

Thanks a lot, and anyway well done to all contributors of allegro even if there are some bugs

beoran
Member #12,636
March 2011

Hi! First of all, you'll be best off with Allegro 5. Allegro 4.x is and old, legacy version of Allegro and not actively developed anymore. And because you want to do 3D graphics, the latest version of Allegro 5.1 will probably be best since it has functionality that helps with drawing 3D graphics that isn't there yet in Allegro 5.0.

There is no version of Allegro without bugs since almost all software has bugs, but AFAICS both fullscreen and the mouse work fine with Allegro 5 under Windows. And if you have any problems, then please report the problem here and we'll do what we can to help you.

You can set pixels manualy to the screen, but nowadays this isn't done anymore since almost all desktop PC's and most handheld devices have a graphics processor (GPU) that can and should be used for drawing 2D or 3D graphics. To do that you use OpenGL, or use the Primitives (https://www.allegro.cc/manual/5/al_draw_prim, etc) Allegro 5 API to render (draw) the 3D world of your game. The following thread gives an example of how to do that: https://www.allegro.cc/forums/thread/614194.

the_cake
Member #15,594
May 2014

Thank for your answer but you probably misunderstanding me, I wrote :

"I have the project to make my own FPS with my own engine (WOlF3d style)"

Do you know what wolf3d refers to ? It's wolfenstein 3d 1992, it uses raycasting rendering method, there is no high level implementation like open_gl or direct_x, so the problem is that I don't want to use any 3d implentation, I will build myself one as I already begun with SDL 2.0. In fact I just want a pointer to the pixel then maybe call an allegro function to load them into the gpu and give order to refresh the screen with an allegro function. Can allegro do that ? SDL 2.0 allows that. Of course my engine will not use the power of the gpu, but that is not a problem for me.

And all software doesn't have major bugs ! By major bugs I mean that when I was SDL 2.0 programming, my project stopped only because of this library that was buggy, and as I said I was too lazy to contribute to the fix of this problem. Yeah, I am a simple studient with limited time and ressources, I got my own problems, my parents, my studies, my duties, papers managing you know :'(...

PS: Are you sure that allegro 5 is the best choice ? I mean because if I am not wrong the community with 5 version improve allegro OS targets ? isn't it ? And as I say I don't want to make a portable program, I'm only a little windows user...

PS2: I will try today with allegro 5 to see if I got the limited mouse movement in windows fullscreen mode bug. If I got this problem, I will be maybe forced to see the allegro sources to fix this bug, but I already look to the sources and I must admit that it is pretty difficult to understand the allegro library structure especially when I have never use it ;D. So if I have no bugs I will close this thread. thank again.

AMCerasoli
Member #11,955
May 2010
avatar

the_cake said:

and the same problem with mouse movement which is limited by the edge of screen...

What is that problem? I'm curios, can you elaborate a bit more? :)

the_cake
Member #15,594
May 2014

to amcerasoli : here a link to a bug with ALLegro, the same I got under SDL 2.0 but Allegro seems to have exactly the same problem :https://www.allegro.cc/forums/thread/608627/0

I have tested now allegro 5 and I can affirm that low resolution are no more taken in charge : 320*200 and 320*240 doesn't work at all in fullscreen mode, I remember that it can work but I imagine allegro 5 will not concentrate effort on it, and that is normal, anyway there is no problem because I can put a 640*480 with a 320*240 by duplicate value of the pixel, however it take a little of cpu time for that and In my case this is a little bit critical.

Polybios
Member #12,293
October 2010

the_cake said:

In fact I just want a pointer to the pixel then maybe call an allegro function to load them into the gpu and give order to refresh the screen with an allegro function. Can allegro do that ?

If this raycasting stuff is really what you're after, I think the appropriate function might be al_lock_bitmap with the ALLEGRO_LOCK_WRITEONLY flag.
You will receive a AL_LOCKED_REGION, which essentially provides raw memory access to pixel data. Note that you have to fill in the whole bitmap before uploading it to the GPU with al_unlock_bitmap. You can also use al_put pixel if you don't want do deal with raw memory access.

I don't know about its speed, but as long as you don't read back any pixel data (ALLEGRO_LOCK_WRITEONLY)and since you seem to intend to use low resolutions anyway, I don't think this'll be a problem.

If you fill in the pixels and unlock your 320x200 bitmap, you can draw it normally using al_draw_bitmap. You could even enable antialiasing (use ALLEGRO_MAG_LINEAR with al_set_new_bitmap_flags when creating) and draw it scaled to your window/screen resolution (al_draw_scaled_bitmap).

the_cake
Member #15,594
May 2014

Yeah polybios, I have searched for pixel direct acces but all the proposed mehtod are too slow, and the fonction put_pixel ? Arg, a joke this function, I just saw the sources, it is so unoptimised, and the process of locking then unlocking every frame too. SDL 2.0 system of direct acces is much powerfull. The contributors should look to SDL 2.0. In fact I think that I will be forced to program in assembly using modified versions of int 10h fonctions and launching the game via a dosbox. So I will leave you now :'(. Anyway good luck ! admin can close the trhead.

Thomas Fjellstrom
Member #476
June 2000
avatar

Low res modes just aren't supported by newer windows operating systems period. You can fake them by setting a 2x size res, and then scaling your graphics. which is easier to do with allegro 5.

Assuming Allegro 4:
Don't use put pixel for a lot of drawing. you want either _putpixelNN (8,16, 32), the things mentioned here or just access bmp->line or bmp->data instead. Most people pick bmp->line and bmp->data these days.

For allegro 5, the bitmap locking will give you direct access to the memory for memory bitmaps. but locking a video bitmap will require a texture download and upload each time you lock/unlock 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

beoran
Member #12,636
March 2011

Ok, but please don't run away yet, and try to listen to what the people are saying here... I know you're young and restless, but you should take some time to get to know the libraries you are going to use, whether it is Allegro 5 or not.

As other people are telling you can write directly to a bitmap in allegro 5 as well, and then draw that to the display. There's a thread here with more info: https://www.allegro.cc/forums/thread/612922

With contemporary systems it's normally not possible anymore to switch the screen to such a full screen low resolution. In stead, you scale up your 320x240 buffer to screen size using transformations or by rendering the bitmap scaled. SDL 2 actually does the same.

Also, a different approach might be to not draw pixels, but simply draw colored rectangles of the right size to simulate pixels.

AMCerasoli
Member #11,955
May 2010
avatar

Ohhhh the people... Sometimes because the library can't work with 4D and sometimes because the library is not able to simulate a 128X64 display... What's next?

Polybios
Member #12,293
October 2010

but locking a video bitmap will require a texture download and upload each time you lock/unlock it.

I suggested ALLEGRO_LOCK_WRITEONLY because I thought there was only an upload.

By the way, adding one/more layer(s) of indirection (DosBox, int 10h emulation etc.) won't be much faster, I guess.
But if you're after retro stuff, have fun with int 10h and 16 bit asm.

Thomas Fjellstrom
Member #476
June 2000
avatar

Polybios said:

I suggested ALLEGRO_LOCK_WRITEONLY because I thought there was only an upload.

Technically it should be that. Not 100% sure if it is enforced.

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

pkrcel
Member #14,001
February 2012

Polybios said:

By the way, adding one/more layer(s) of indirection (DosBox, int 10h emulation etc.) won't be much faster, I guess.

That was exactly my first tought.

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

beoran
Member #12,636
March 2011

Actually it will be slower because dosbox runs on SDL... Might as well use SDL or Allegro directly.

Arthur Kalliokoski
Second in Command
February 2005
avatar

If you're going to compile for DosBox, be sure to compile for 586 or less, it'll barf if you use SIMD or other more advanced instructions.

They all watch too much MSNBC... they get ideas.

the_cake
Member #15,594
May 2014

to beoran :

"
Ok, but please don't run away yet, and try to listen to what the people are saying here... I know you're young and restless, but you should take some time to get to know the libraries you are going to use, whether it is Allegro 5 or not.

As other people are telling you can write directly to a bitmap in allegro 5 as well, and then draw that to the display. There's a thread here with more info: https://www.allegro.cc/forums/thread/612922

With contemporary systems it's normally not possible anymore to switch the screen to such a full screen low resolution. In stead, you scale up your 320x240 buffer to screen size using transformations or by rendering the bitmap scaled. SDL 2 actually does the same.

Also, a different approach might be to not draw pixels, but simply draw colored rectangles of the right size to simulate pixels.
"

Sorry I know that. As I said, I have already tested the purposed methods... and this is so slow that I cannot stop laughing ;D.

" Actually it will be slower because dosbox runs on SDL... Might as well use SDL or Allegro directly. "

Oug ! What a joke ! maybe written with SDL but it will be a lot faster !

to Thomas Fjellstrom :

I suggest you to read my post again :

I wrote :
"[...]anyway there is no problem because I can put a 640*480 with a 320*240 by duplicate value of the pixel[...]" :o

to AMCerasoli

I am sorry but I don't stay with a library that allows me not to do what I want...

to polybios and pkrcel
Can you post a proof of what you are saying ? It will maybe change my opinion, because in fact I just need to display my bitmap without locking/unlocking each frame. I already tried but I admit that my previos code may be wrong but this one wroks, just tell me how much time you execute this program, it takes 45 secs on my computer and works on a single 3.00 ghz core :

#define ALLEGRO_STATICLINK
#include <stdio.h>
#include <stdlib.h>
#include <allegro5/allegro.h>

int main(int argc, char **argv)
{
ALLEGRO_DISPLAY *display = NULL;

if(!al_init())
{
fprintf(stderr, "failed to initialize allegro!\n");
return -1;
}

//al_set_new_display_flags(ALLEGRO_FULLSCREEN);
display = al_create_display(320, 200);
if(!display)
{
fprintf(stderr, "failed to create display!\n");
return -1;
}
al_hide_mouse_cursor(display);
ALLEGRO_BITMAP *my_screen = NULL;
my_screen = al_get_backbuffer(display);

const int screen_pixels = 320*200;

int i, j, w;

for(w=0;w<256;w++)
for(j=0;j<256;j++)
{
ALLEGRO_LOCKED_REGION *lr = al_lock_bitmap(my_screen, ALLEGRO_PIXEL_FORMAT_ARGB_8888, ALLEGRO_LOCK_WRITEONLY);
unsigned int *ptr = (unsigned int *)lr->data; //points to first pixel
for (i=0; i<screen_pixels; i++)
ptr[i]=i+j*256+w*65536;
al_unlock_bitmap(my_screen);
al_flip_display();
//al_rest(0.01);
}

al_destroy_display(display);

return 0;
}

I never intended to use int 10h functions, just read carefully my post...
Obiously, if there are not modified there are too slow...
I think that when I will launch my program through dosbox, I may loose 10% compared on if I boot on the programm but in fact I don't really know... And yeah 2^20 of memory is enough for me !

to Arthur Kalliokoski
Of course !

Thomas Fjellstrom
Member #476
June 2000
avatar

edit: nevermind.

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

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

It is possible the format you locked the bitmap in is not the same as the actual format of the bitmap. That would cause conversion slowdowns.

The manual entry for al_lock_bitmap says :

Quote:

'format' indicates the pixel format that the returned buffer will be in. To lock in the same format as the bitmap stores it's data internally, call with al_get_bitmap_format(bitmap) as the format or use ALLEGRO_PIXEL_FORMAT_ANY. Locking in the native format will usually be faster.

This means you would have to adjust your pixel access based on the actual format of the bitmap.

What are you trying to accomplish exactly anyway?

I rewrote your example to fix the mistakes and ran it and I got 65536 frames at 320x200 in 65 seconds. That's 1000fps, on my laptop no less. Not fast enough for you?

Here's the code I used (just the important bits) :

#SelectExpand
1 2 for (int r = 0 ; r < 64 ; ++r) { 3 for (int g = 0 ; g < 64 ; ++g) { 4 screen = al_get_backbuffer(display); 5 ALLEGRO_LOCKED_REGION* lr = al_lock_bitmap(screen , al_get_bitmap_format(screen) , ALLEGRO_LOCK_WRITEONLY); 6 for (int nlines = 0 ; nlines < SCREEN_HEIGHT ; ++nlines) { 7 unsigned int* dat = (unsigned int*)((unsigned char*)lr->data + lr->pitch*nlines); 8 for (int pixel = 0 ; pixel < SCREEN_WIDTH ; ++pixel) { 9 dat[pixel] = (nlines%256)*256 + g*4*256*256 + r*4*256*65536; 10 } 11 } 12 al_unlock_bitmap(screen); 13 al_flip_display(); 14 printf("n = %d\n" , r*64 + g); 15 } 16 } 17 printf("Total time taken : %f\n" , al_get_time() - start_time);

With this test, it took 34.66 seconds for 4095 frames, roughly 118 FPS at 800x600.

And this entire argument is moot anyway, because with A5 you could use shaders for direct pixel access, and then it would be GPU bound, and not CPU bound.

Edit
Just so you know, you can use <code>code goes here...</code> tags to make our lives easier. See https://www.allegro.cc/mockup.html for details.

Edit2
Running fullscreen instead of windowed at 800x600 it took 19.3 seconds for 4096 frames, well over 200 FPS.

Allegro is not slow. :P

beoran
Member #12,636
March 2011

the_cake, like Edgar said, the problem is that there is a logical error in your code. You are locking, unlocking and flipping the backbuffer every time you write a pixel, which is of course very slow.

In stead, you need to first lock the backbuffer, outside of your rendering loop, then do all your rendering and pixel setting, then finally unlock and flip the bitmap. Then your program will be blazing fast. So yes, you can use Allegro 5 for your purposes! :)

Edit: This goes to show that he concept of locking a bitmap is not always intuitive to everyone. I checked the documentation of al_lock_bitmap and it doesn't quite mention that you are supposed to lock the bitmap only once and then do your pixel twiddling. I'll make a patch to modify the docs of that function later on.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

There was another error as well, that of assuming pitch to be equal to pixel_size*width. Pitch can be negative or memory aligned and padded so it isn't guaranteed to be pixel_size*width. And you also can't expect the color order to be the same across systems unless you are very specific with your new display options. al_set_new_display_option

beoran said:

You are locking, unlocking and flipping the backbuffer every time you write a pixel, which is of course very slow.

No, his code doesn't do that. The inner for loop is a one liner.

beoran
Member #12,636
March 2011

#SelectExpand
1int i, j, w; 2 3for(w=0;w<256;w++) 4for(j=0;j<256;j++) 5{ 6ALLEGRO_LOCKED_REGION *lr = al_lock_bitmap(my_screen, ALLEGRO_PIXEL_FORMAT_ARGB_8888, ALLEGRO_LOCK_WRITEONLY); 7unsigned int *ptr = (unsigned int *)lr->data; //points to first pixel 8for (i=0; i<screen_pixels; i++) 9ptr[i]=i+j*256+w*65536; 10al_unlock_bitmap(my_screen); 11al_flip_display(); 12//al_rest(0.01); 13}

How so? The lock happens inside the double loop, right?

pkrcel
Member #14,001
February 2012

No, his code doesn't do that. The inner for loop is a one liner.

Yep he couldn't have done that with ALLEGRO_LOCK_WRITEONLY cause he's bound to write all pixels, as per docs.

Just so I know, what would happen if one does not write all pixels?

And this entire argument is moot anyway, because with A5 you could use shaders for direct pixel access, and then it would be GPU bound, and not CPU bound.

While is true that using shaders would accomplish this better, the argument is not moot since cake stated very clearly that he wants to use this programming technique for his engine and he's pretty much on track.

Anyway:

the_cake said:

Oug ! What a joke ! maybe written with SDL but it will be a lot faster !

You know, I don't get your going around in circles, but this doesn't stand to logic...at least to me; SDL ha sa but that prevents your pixel access to be as fast as it should be, but usign an emulated blit over SDL itself should?

I admit I am not really clear on what you are going to do since I am n00b, but still I have difficulties in grasp this.

Quote:

Can you post a proof of what you are saying ?

Of course not, mine was a speculation under the aforementioned logic.

EDIT: adding vertical spacing

int i, j, w;
for(w=0;w<256;w++){
   for(j=0;j<256;j++){ 
      ALLEGRO_LOCKED_REGION *lr = al_lock_bitmap(my_screen, ALLEGRO_PIXEL_FORMAT_ARGB_8888, ALLEGRO_LOCK_WRITEONLY);
      unsigned int *ptr = (unsigned int *)lr->data;

for (i=0; i<screen_pixels; i++) ptr[i]=i+j*256+w*65536;
al_unlock_bitmap(my_screen); al_flip_display(); } }

he is unlocking after writing all pixels in the bitmap, not after only one, thou he is locking->unlocking for 655536 frames, to my understanding...am I wrong?

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

beoran
Member #12,636
March 2011

Oh yeah, right, can't believe I missed that :P Anyway, there were other bugs, so I hope Edgar's example is helpful to the_cake.

Dizzy Egg
Member #10,824
March 2009
avatar

I like this guy! He writes code with bugs in it which cause lag, and then says "that's it, I can't write my game because no library in existence is fast enough"

Hey, the_cake, why don't you eff off. Nobhead.

----------------------------------------------------
Please check out my songs:
https://soundcloud.com/dont-rob-the-machina

Polybios
Member #12,293
October 2010

@Edgar:
You assume ALLEGRO_PIXEL_FORMAT_ABGR_8888 as native format, right? Wasn't that supposed to be 'default'/'native' on most platforms?
At least that's what I get when I use ALLEGRO_PIXEL_FORMAT_ANY.

pkrcel said:

Just so I know, what would happen if one does not write all pixels?

It's probably 'undefined', which means uninitialized memory I guess.

 1   2   3 


Go to: