Mail Archives: djgpp/2000/07/04/18:46:38
> >I found the original program refused to page flip, simply because 640 x
960
> >seems too big for it to handle.
> How much video memory does your card have? I think Allegro comes with
> an `info' program in it's standard distribution that can tell you
> this.
> BTW, what version of Allegro are you using?
The zip is alleg312, which I just downloaded, so it should be fairly recent.
> >No prob compiling, big prob running.
> There are a few problems with your code; see below.
>
> >set_color_depth(16);
> >
> >set_gfx_mode(GFX_MODEX, 320, 240, 320, 480);
> 16 bit colour doesn't normally work in VGA modes, such as mode X, so
> you'll need to change to 8 bit colour if you want to do mode X.
> Also, your program doesn't check if set_gfx_mode() failed. Checking
> the result of a function that can fail is usually a good idea and
> helps to make you program more stable. It's also easier to track down
> bugs later if you make a habbit of it.
Originally I use AUTODETECT, but I'm unsure whether MODEX is my only option.
I need 16-bit, but the way Allegro's docs read, triple-buffering is Mode-X
exclusive. The only commands necessary to do triple-buffering it seems are
request_scroll() and poll_scroll(), don't they work in other modes?
> >page1 = create_sub_bitmap(screen, 0, 0, SCREEN_W, SCREEN_H);
> >page2 = create_sub_bitmap(screen, 0, SCREEN_H, SCREEN_W, SCREEN_H);
> >active_page = page2;
> While not a real error, I use
>
> page1=screen;
> page2=create_video_bitmap(SCREEN_W, SCREEN_H);
> ...
> show_video_bitmap (page1); or show_video_bitmap (page2);
>
> which works just fine. Still, your code should be fine in this regard.
> I wrote a couple of routines that make it easy to support multiple
> screen update methods (pageflipping/double buffering/dirty
> rectangles), but they contain rather a lot of game-specific code that
> doesn't make sense when taken out of context.
> If you're interested, I can try to pull them out of the program and
> make a small demo program to illustrate their use.
> >ship = get_rle_sprite(load_bitmap("Ship.bmp", pal));
> You still have the memory leak.
I tried to fix it, how should I do it?
> > // Move the sprite according to the controls
> > if(key[KEY_LEFT])
> > {if(sx > 0) {sx = sx - 5;} else {sx = 0;};};
> > if(key[KEY_RIGHT])
> > {if(sx < 595) {sx = sx + 5;} else {sx = 595;};};
> > if(key[KEY_UP])
> > {if(sy > 0) {sy = sy - 5;} else {sy = 0;};};
> > if(key[KEY_DOWN])
> > {if(sy < 425) {sy = sy + 5;} else {sy = 425;};};
> Since you set your resolution to 320x240, any coordinates outside that
> space are outside the screen. Since RLE sprites can't be clipped, this
> could do Bad Things to your program. If at all possible, don't use
> hard coded constants like this, but use #defines or make things
> relative to the dimensions of the screen.
Sorry, my fault. I got rid of all extra code for posting, and have it in 320
x 240 because mode-x doesn't support the 640 x 480 I want. Those
co-ordinates I missed when posting. They're correct; I want 640 x 480
ultimately, but I want to work on getting the triple-buffering done first
(hence playing in mode-x).
> Finally a warning about page flipping. It's a great way for doing
> screen updates, but my own experience shows that it is incompatible
> with the Allegro GUI routines. Maybe that's because I'm doing
> something illegal by setting `page1=screen;', I'm not sure, but I'd
> thought I'd warn you about this anyway.
No prob, no GUI's.
> Hope this helps,
>
> Evert Glebbeek
- Raw text -