In Allegro 4, I am used to doing this, for example:
set_gfx_mode(GFX_AUTODETECT_FULLSCREEN, 320, 200, 0, 0);

I just jumped into the new API of Allegro 5 and am getting my bearings. Considering the code I whipped up below, how would I get this to full screen?

Lastly, I'm using the HTML version of the Allegro 5 manual and just want to make sure there isn't a better guide available. I'm used to Allegro 4's slightly more thorough documentation. I hate bothering the forums with petty questions.

Appreciate any insight.

al_set_new_display_flags(ALLEGRO_FULLSCREEN); before display = al_create_display(320, 200);

Thanks.

I get an Access Violation, and guess it has to do with the mode I am requesting. 320 x 200 is preferred, but I could live with 320 x 240. Both throw the violation.

With 640 x 480 being a commonly supported resolution, is a good method of getting my preferred 320 x 200 to stretch the bitmap to 640 x 480? Nothing fancy and want to avoid anti-aliasing. Anything else I should consider?

I'm attempting to rewrite a program that used mode 13h with a reduced 4-bit color set. Trying to get to that point before I dive into it further.

Thanks for any follow-ups.

I think the best way to do fullscreen is to do al_set_new_display_flags(ALLEGRO_FULLSCREEN_WINDOW) the same size as the main resolution, and then manually resize/letterbox your game to fit. You can stretch the bitmap or use transformations to accomplish the latter (I'm sure there are a few threads with the required code).

This smells like tutorial worthy material!

I imagined before each screen update, I could do the resizing. Can you explain why you suggest ALLEGRO_FULLSCREEN_WINDOW and not ALLEGRO_FULLSCREEN?

It's easier to alt-tab away from the windowed fullscreen mode in my experience.

With FULLSCREEN_WINDOW you're also guaranteed the mode is supported. A lot of monitors these days (ie: LCDs) have a native mode. Setting anything else will either fail, or get resized by a potentially crappy scaler. My old LCD has probably one of the crappiest scalers ever. It looks so awful its not even funny.

You don't need to resize at each screen update. Depending on the monitor resolution you can resize all of your images, load different ones (bigger/smaller) or both.

I have always wanted to make a tutorial about this, but I really don't have the time right now.

You can use transformations which I don't know anything about, or you can resize your images individually depending on the screen resolution. Resizing it's the most easiest approach after the raw ALLEGRO_FULLSCREEN display option. But you won't notice the difference at least you add black bars in the left and right part of the screen to make the game keep its aspect ratio.

Now, the ideal way would be to not resize the images at all, and show more or less depending on the monitor resolution. A good example would be to play Angry Birds for PC, which resizes the view depending on your monitor resolution, or in case you want a resizing example the card game Spiders which comes with Windows.

The unique one in which you don't need to think about anything but just resize the windows is when using the ALLEGRO_FULLSCREEN flag. With the rest of them the first thing that comes to mind is collision detection, which obviously needs to change when the image increase or decrease. Now if you go with the "ideal" approach in which you don't change any image, the collision detection still the same, but the layout of the game will be your nightmare.

Neither of them are really difficult, the thing is if you're just used to set a flag... Obviously this will be something new that will take you some time.

I don't clearly understand everything you were suggesting and am assuming it is lingo related to this library. It seems you are suggesting a lot of resource use in the manipulation of sprites/tiles on an image by image basis. Why wouldn't it be best practice to work on the 320x200 bitmap in the buffer and on each update expand it to a fullscreen size?

The code/logic has already been produced btw. But even if I wasn't attempting a port of sorts, I'm trying to imagine why I would use such unnecessary complication when making this from the ground up...

Hopefully a follow-up will clear things up. I must be misunderstanding something.

Basically what he's saying is, why not scale ALL of your images on startup (so in your case double the size of ALL the bitmaps on startup) rather than stretching the screen every frame.

I hope that helps!

Wow, got nothing of the sorts from what he said. Great idea though, as the collision routine would work on the same multiplier applied to the graphics.

Thanks

If you already have everything working for 320x200, then just set an ALLEGRO_TRANSFORM to scale everything up to the screen, letter boxing as appropriate. You don't need to manipulate your world coordinates at all, except to translate between screen coords and world coords.

I think the steps to build your transform would be :
1) Translate to center on the camera center
2) Scale up to screen dimensions
3) Set this as your transform

(Never tried this before, could be wrong...)

Then you can invert that transform and use al_transform_coordinates to map coordinates back.

Thanks everybody.