How can I see number with using library Allegro ?
I have got code in c++ but I don't know how can I see it using allegro?

int eye;
srand (time(0));
eye = 1+rand()%6;
cout<<eye;

I think this is a good place for a "RTFM". I suggest looking under "text output".

text output<<eye it doesn't run

You could use something like:
textprintf_ex(screen, font, 100, 100, makecol(255, 255, 255), -1, "Number: %i", eye);

Don't use iostream anyway ( << and >> and cout and cin), instead, use stdio (printf("hello"); )

But in Allegro, use textprintf_ex

OH noooo !!!

this is similar to language c but this is not similar to language c ++ - why ?

What does that even mean?

Allegro is a C library.

Because iostream style stinks, and I use C++.

So I have to use language C and I can not use c ++ ? So I will not can use classes, heirdom etc. It is so sad........

C++ is backwards compatible with C.

a b, you really need to go watch what is C and what is C++, after what go back to allegro library.

Tons of people here use allegro with C++ or C.

You can use all C functions in a C++ program.

What ? hahem ! Weird...

I know c++ very well but library allegro is strange

Has the definition of "very well" changed since i last checked?

Why can't I use cin and cout with using library allegro - it is strange ?

Those are for the CONSOLE and not for the Allegro window.

You can, but they output to the console, not to the main window.

thanks you

Do not take it hard, I am just joking

My english isn't so good.

Could you say me what is wrong :

I have got table of size= 11. I am on field number 6, automically throw bone for example 4 and press l (left) so I am on field number 2, automically throw bone for example 3 and press l (left) so I am on field number 10, automically throw bone for example 4 and press r (right) so I am on field number 3 - my code in c++ is good but programm print very unattractively text - so what is vrong ??:

maybe this is (just a little bit) better?

It is still quite ugly.

what i think that you were forgetting is that you were NOT clearing the screen before you wrote to it again.

So every time through that while loop, you were printing on top of the text that was still on there from last time.

thanks, but can't I clearing screen easier ?

yes, you could just
clear_bitmap(screen);
i suppose. It's just that people normally use a double buffer to negate any chances of tearing, which usually looks pretty bad.

You don't clear the 'screen', you should clear the 'backbuffer' which should be as big as the screen.

Why are you clearing the backbuffer to white? Usually you just clear_bitmap and put it to black.

And, as Archon said, you don't need to clear the screen.

Guys, this is a lost cause. Just... do something better.

THANKS !! I study library from one day (today) and I almost write my first game But something in run my pawn (checker ?) is wrong - please see - it is my board (chart ?):
http://img474.imageshack.us/img474/7083/planst5.png

and it is my pawn (checker?):
http://img381.imageshack.us/img381/121/pawnjg7.png

Could you tell me what is wrong - I am so excited

You should be passing NULL to load_bitmap, NOT default_palette.

WTF is that? *index? Is that even valid code?

BAF 0,0,*index,400

*index is my "x" and "400" is my "y" because I have
int tab[11]={30,130,230,330,450,550,690,820,900,1000,1150}; // <- "x" in pixels
int *index=&tab[5];

so my pawn is starting (x,y) (550, 400) so it is field number 6 on board (chart ?) :
http://img474.imageshack.us/img474/7083/planst5.png

Ah, okay.

THANK YOU A LOT - it is my code:

My code is yet full mess and chaos, but it runs - this my first game !
YESSSSSS !!!!!!!!!!! hurrrrra

A couple of things.

Why are you using a pointer to point to an array of the numbers 1..11 when you can just use the numbers 1..11?

Instead of:

int tab2[11]={1,2,3,4,5,6,7,8,9,10,11};

int *index=&tab2[5];
int *start=&tab2[0];
int *end=&tab2[10];

You can use:

int index = 5;
int start = 0;
int end = 10;

And then replace any instances of *index, *start and *end in your program with index, start and end. This is simpler and will not effect the way your game works.

It's also not a good idea to hardcode in pixel values like this:

If you change the width of your bitmap, you need to rewrite every value. Try to encode a formula instead. Something like:

for (n = 0; n < 11; n++)
    tab[n] = START + ( width * (n - 1) ) + (GAP * n);

where START and GAP are #DEFINE values.

LennyLen thank You very much for your advices - I will use it - thank you

I have some more advice... read a god damn C book! Learn proper code indentation. Lean the difference between C and C++ (your code is not C++ besides the fact you included some C++ headers and a namespace which are completely unused anyway). Once you grasp those concepts you can begin to learn the difference between 8-bit and high color depth concepts, they do work in very different ways and you should not mix the two. Lastly learn what a double buffer is and use it.

Steve Terry:
"I have some more advice... read a god damn C book! Learn proper code indentation. Lean the difference between C and C++ (your code is not C++ besides the fact you included some C++ headers and a namespace which are completely unused anyway)."

I know c++, I don't use classes because I wanted only to see use library allegro.

"Once you grasp those concepts you can begin to learn the difference between 8-bit and high color depth concepts, they do work in very different ways and you should not mix the two."

Where in my code is mix two ways ?

Well, if you knew the difference, you wouldn't have to ask that

set_color_depth(32); //High bit-depth.
set_palette(default_palette); //Only useful in 8bpp mode...
...
textout_ex(screen,font,"ESC - The end of program",10,990,2,-1); //You can't really use "2" as a color. Use makecol(redpart,bluepart,greenpart)

I change my code according with your hands WHAT ARE YOU THINKING NOW ABOUT MY CODE

Don't use "goto" statements.

Use "break"s and while(...) loops.

a b: if you are comfortable with classes there is nothing that is stopping you from writing classes. C++ is an extension of C and is backwards compatible. You just can't use some C/C++ functionality like cin/cout/printf/scanf/etc. These only work on console windows. Your indentation needs some work as well.

I will do this with classes but first I would like you check my code if everything is ok because it is the most important (if everything is ok I will wrote this and other thing using classes) I am starting write with allegro and you are masters in using allegro so

C++ is more than just "C with classes".
Here are some key features of C++ over C:
- Stronger type checking.
- Templates.
- Exception handling ( try { ... } catch (exception) { ... } )
- Function overloading
- Operator overloading
- new and delete replacing the tedious and error-prone malloc()
- "smart" cast operators (e.g. dynamic_cast<>() )
- References
- STL (though not a core language feature)

Nonetheless, a proper C program usually passes C++ compilation just fine.

a b: You'll get better responses if you present your code properly. I went through with Notepad and did some basic indentation. I also added a timer in, and separated your logic from your drawing. I got rid of that strange goto statement.

People have suggested reading up more on C/C++. I suggest you do that, and also stop copy and pasting code without considering it. You had a while loop checking: !key[KEY_ESC] and then an if statement checking for the exact same thing, later on.

I haven't tested this code, so I've probably made errors. But I hope it helps.

EDIT: I also added a check for problems when setting the graphics mode. Check for errors!

Another tip: Modularize your code. Split code into dedicated functions. I suggest:
init() to set up everything: allegro, globals, the game itself
logic_update() to update the game logic
draw() to update the screen
main_loop() for, well, the main loop; this should call logic_update() and draw()
cleanup() to clean up everything you have allocated, exit allegro, etc.
...and of course the ones you already have.
Ideally, each function should be no longer than 25 lines. If it is, divide some more.

This is useful for several reasons:
1) You can clearly separate different parts of the program, like logic and drawing code; each goes into a separate function, and if the logic function touches any drawing routines, you know instantly something is wrong.
2) You may end up re-using code before you know
3) The style is easy on the eye, and it's easier to see what each function does.
4) The compiler has an easier time optimizing your code when your functions are shorter.

Oh, and clearing the buffer bitmap right before you destroy_bitmap() it is pretty useless...

Tobias and Nial thank you for help my. VARY THANK !!;D

I don't agree with one thing - you wrote:
"Oh, and clearing the buffer bitmap right before you destroy_bitmap() it is pretty useless..."
" /* I moved this call to clear_to_color into the rendering loop.
I assume you want it to clear the buffer bitmap before each render,
rather than when the user decides to quit?*/"

I want that: first player see map (not black screen), throw bone, player decide if he want to go on left or on right and he press <- or ->, map is cleared and player see new map with pawn on definite field after moving about definite number of fields on left or right, throw bone, press <- or ->, clearing screen and again .... so I think it is good:

(before this code I didn't use "blit" so my screen is black so I first must use "blit")

I don't understand what you're asking here. As far as I can see: you render everything each frame (chart, etc, etc). By adding the call to clear_to_color before you do your rendering, you basically make the buffer bitmap totally white. Imagine starting a painting with a blank canvas. Once you've made the buffer totally white, you can then render everything onto it.

As far as having the clear_to_color call where you initially placed it: there is no point. You destroy the bitmap right after making it white.

EDIT: Of course, if your chart bitmap is >= the set resolution, you wouldn't need to clear the bitmap. It is still good practice, though.