Allegro new style???

Allegro new style???

Thomas Harte

Member #33

April 2000

That article certainly clears up any concern over a busy wait ever being necessary to implement the existing timer spec. I'm a little confused though - have you linked your MsgWaitForSingleObject to a timer object or are you making creative use of the timeout parameter? If the latter, will the (Allegro) timer not be expected to very slightly lose time on account of its own processing overhead?

[My site] [Tetrominoes]

Peter Wang

Member #23

April 2000

Creative use of the timeout parameter. The MsgWaitForSingleObject is mainly there to wait on a "stop this thread" object, so that another thread can tell the timer thread that it needs to terminate. However, time will not drift because we always check what the current time is (using QueryPerformanceCounter or timeGetTime) after waking up. You'd have to do this regardless of what method you use to do the sleeping.

Thomas Harte

Member #33

April 2000

Quote:

You'd have to do this regardless of what method you use to do the sleeping.

Only once the question of whether an internal OS object is providing a timer signal is answered in the negative. However I do see that my question was very badly worded, it was merely intended to obtain some sort of assurance to the effect that such matters were being taken into consideration.

Anyway, the main point for posting again - if there is to be no official way for a user to produce their own event sources, would it be possible to add a single function allowing messages to be pushed onto event queues? E.g.

bool al_post_event(AL_EVENT_QUEUE *queue, AL_EVENT *event)

And to obtain an absolute guarantee that queues are thread safe regardless of platform?

[My site] [Tetrominoes]

Peter Wang

Member #23

April 2000

Yes, that should be fine.

Thomas Harte

Member #33

April 2000

Quote:

Yes, that should be fine.

Are the future API proposal docs at sourceforge being updated?

If not is there somewhere else (presumably wiki flavoured) that hosts the new API?

If not would it be beneficial to start it somewhere (Tomasu's server maybe?), and if so would it be acceptable for a non-dev (such as me) to kick it off by transcribing the material on sourceforge?

[My site] [Tetrominoes]

Peter Wang

Member #23

April 2000

The `future' docs aren't being updated. I think Tomasu's wiki is the best place to do that work now. Go right ahead.

Thomas Harte

Member #33

April 2000

Quote:

The `future' docs aren't being updated. I think Tomasu's wiki is the best place to do that work now. Go right ahead.

I am doing this now. I have the first of what will probably be several requests for clarification.

This concerns al_map_yuv422 and al_unmap_yuv422. Why are the 422 appended? It is my understanding that 422 means "in every 4 pixels Y is sampled 4 times, U twice and V twice". It's therefore nothing whatsoever to do with these functions, which are merely creating single colours suitable for an RGB buffer from YUV sources. I also note that the function description of al_map_yuv422 refers to it purely as al_map_yuv.

[My site] [Tetrominoes]

Wil Renczes

Member #5,921

June 2005

(Without knowing anything about the code, mind you)

I'm guessing that it's probably labelled 422 since there are different types of YUV color spaces - 422, 411 (ie DV), YUVA (for compositing), etc. If it's a color lookup conversion function, it would make sense to specify the source color space precisely.

Bob

Free Market Evangelist

September 2000

Quote:

This concerns al_map_yuv422 and al_unmap_yuv422. Why are the 422 appended?

Where do you see this? I can't find "422" in http://awiki.tomasu.net/bin/view/Main/Graphics

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

Thomas Harte

Member #33

April 2000

Quote:

I'm guessing that it's probably labelled 422 since there are different types of YUV color spaces

Admittedly the 422 suffix appears twice (on map and unmap) whereas the version without 422 suffix appears only once (in the comments for map), so it does seem more likely that there is a reason I'm just ignorant of rather than that there is no reason and someone else was having a bad brain day.

Am I also to take it that an AL_DISPLAY * is castable to an AL_BITMAP * with no possible ill side effects?

Quote:

Where do you see this? I can't find "422"

Yes, that'll be my non-perfect transcription. I was waiting to append 422 to those if someone confirmed it was correct, feeling that since the API proposal includes both forms I was not being untrue to the document to pick that one. I naturally intend to double check everything I write and obviously will not deliberately alter anything.

422 occurs in http://alleg.sourceforge.net/future/gfx-api.txt. It seems that the map function once had an x parameter (which would make sense if 422 means what I think it means) but that it has been removed as "useless".

EDIT: And another one for the developers - why are hline and vline retained? In the modern world either all line drawing will be accelerated or else the CPU will be doing the work, meaning that memory bandwidth is the bottleneck rather than how quickly the CPU can work out where the next pixel should go.

[My site] [Tetrominoes]

Evert

Member #794

November 2000

Quote:

Am I also to take it that an AL_DISPLAY * is castable to an AL_BITMAP * with no possible ill side effects?

No.
The current implementation makes a clear distinction between an AL_DISPLAY and an AL_BITMAP. Briefly, a DISPLAY is like a window while a BITMAP is a drawing surface that can be associated with a window. There are some slight differences in the current implementation of parts of the graphics API and the draft, some of which will disappear as the system matures (such as the global al_main_display, which is mainly there as a quick way to get things working). Personally, I don't think the seperation between a DISPLAY and a BITMAP will be one of them.

I'll post an updated description of the distinction and the current implementation of the graphics API when I have time, for now I can only refer you to the headerfiles with the prototypes:
display.h
draw.h

Quote:

Consider it an outdated part of the draft then. As you've seen, none of it was updated recently. If you're transcribing it, don't bother transcribing the part about source clipping surfaces and the complicated interplay between different clipping areas in the draft. According to Bob, it's more trouble than it's worth, and I belief him on that.

Bob

Free Market Evangelist

September 2000

Quote:

You're right, it shouldn't be there. The YUV mode can be inferred from the bitmap parameter.

The "x" parameter was removed because we can form two pixels of data from one call to al_map_yuv(), and have the various drawing routines pick whichever of the two pixels they need from that.

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

Thomas Harte

Member #33

April 2000

Quote:

No.

Then inevitably I have to ask, how do you ever draw anything to an AL_DISPLAY? All the drawing functions only operate on AL_BITMAPs. I know it is much more likely that I'm missing something rather that the spec is deficient, but because I'm missing something I must ask.

Quote:

don't bother transcribing the part about source clipping surfaces and the complicated interplay between different clipping areas in the draft. According to Bob, it's more trouble than it's worth, and I belief him on that.

Okay, thanks for the warning. I'm transcribing very slowly, so please warn me if you think of anything else, even if it isn't for quite a while...

Quote:

The "x" parameter was removed because we can form two pixels of data from one call to al_map_yuv(), and have the various drawing routines pick whichever of the two pixels they need from that.

Clever!

[My site] [Tetrominoes]

Evert

Member #794

November 2000

Quote:

As I said, there are differences between the draft and the current implementation. It's in the headerfile I linked to, but I can understand you missed it:
AL_FUNC(BITMAP *, al_get_buffer, (const AL_DISPLAY *display));
It returns a BITMAP (will be AL_BITMAP in due time) that refers to the current drawing surface of a DISPLAY. If you;ve set up the DISPLAY to use something like triple buffering, it won't be the visible page, but a page in the background.

Have a look at the exupdate using the new display API:

..
2 
3int main(int argc, char *argv[])
4{ 
 PALETTE pal;
 int card = GFX_AUTODETECT;
 int w, h, bpp, i;
 int flags = 0;
 int update_flags[] = { AL_UPDATE_DOUBLE_BUFFER, AL_UPDATE_PAGE_FLIP,
                        AL_UPDATE_TRIPLE_BUFFER, AL_UPDATE_DOUBLE_BUFFER };
11 
 if (allegro_init() != 0)
    return 1;
14 
 /* check command line arguments */
 if (argc == 2)
    num_pages = atoi(argv[1]);
 else
    num_pages = 0;
20 
 if (num_pages)
    flags = update_flags[num_pages-1];
23 
 if (num_pages == 4) {
    num_pages = 1;
    use_system_bitmaps = TRUE;
 }
 else
    use_system_bitmaps = FALSE;
30 
 if ((num_pages < 1) || (num_pages > 3)) {
    allegro_message("\nUsage: 'exupdate num_pages', where num_pages is   "
33[...]
      "    - drawing to system bitmaps is sometimes slower than memory bitmaps\n\n");
    return 1;
 }
37 
 /* set up Allegro */
 install_keyboard();
 install_timer();
 install_mouse();
42 
 if (al_create_display(GFX_SAFE, 0, 8, 320, 200) == NULL) {
    allegro_message("Unable to set any graphic mode\n%s\n", allegro_error);
    return 1;
 }
 set_palette(desktop_palette);
48 
 w = SCREEN_W;
 h = SCREEN_H;
 bpp = bitmap_color_depth(screen);
 if (!gfx_mode_select_ex(&card, &w, &h, &bpp))
    return 0;
54 
 al_destroy_display(al_main_display);
 if (al_create_display(card, flags, bpp, w, h) == NULL) {
    allegro_message("Error setting graphics mode\n%s\n", allegro_error);
    return 1;
 }
60 
 generate_332_palette(pal);
 pal[0].r = pal[0].g = pal[0].b = 0;
 set_palette(pal);
64 
 /* install timer handlers to control and measure the program speed */
 install_int_ex(timer_proc, BPS_TO_TIMER(60));
 install_int_ex(fps_proc, BPS_TO_TIMER(1));
68 
 /* main program loop */
 while (!keypressed()) {
71 
    /* draw the next frame of graphics */
    draw_screen(al_get_buffer(al_main_display));
    al_flip_display(al_main_display);
75 
    /* update the program state */
    while (update_count > 0) {
 do_update();
 update_count--;
    }
81 
    frame_count++;
 }
84 
 al_destroy_display(al_main_display);
 return 0;
87}
88 
89END_OF_MAIN()