this is daft.

Limiting yourself to 320x200 and 16 colors is interesting, but...QBASIC? Ew.

I think it sounds like your looking for a magic bullet to make game programming easier. I don't think that's possible. Games represent alot of complexity no matter what language; c, qbasic, assembler whatever. For example GDR is running a coding challenge right now to write a dig dug clone. Sounds easy right? Not until you really analyze how that old game works.

It looks like your list of proposed functions merely wrap existing allegro functionality. Why not just use allegro as is and limit your design? That's just my .02....

I think you cannot limit a game to the screen resolution it runs with.

Now that you've all had your laugh on something i didn't quite think through that night... i've decided to modify things.

1) Square wheels. Well.. more like hexagonal

2) I am gonna keep the text printing system as a state machine with rows, columns, etc. it may be worthwhile to have ncurses style for some types of games. That is where a window is a region, and print causes it to eventually scroll up. Those of you who've used ncurses before would get it. Would make a good console.

3) A new input class. It will be one of those "highscore" style inputs that arcade machines used to have.

4) I will include all of the classic modes like 320x200x16 and 640x480x255. Since computers like my mac can only run modern resolutions, I will stretch blit the draw surface to the screen (which can be whatever) when the user calls FLIP(). The blit doesn't distort, it will center vertically for example, if the game has a widescreen ratio (like 320x200). The draw surface itself will be 32-bit. When color number is passed into the drawing functions it is converted into the 32-bit and draws on draw surface automatically. Palette system basically. Idea is to create a super-thin wrapper on the allegro primitive and blitting functions.

5) sound? well never really used sound in allegro before. Will have to figure out that one still

6) Pixel Perfect collision detection. Will look to see what others have provided or write it my self.

edit:
I've decided to make a "window" class. It's not a gui window, just an area of the screen where i can do things to sprites or clear text or whatever. The idea is that there's a tree with the root node being the background. Then there may be a game window, or two game windows, a status window, a game stats window (level, points, highscore, lives, etc), or other windows that become active during certain parts of the game like game over or intro screen. I'm gonna have some pre-made and ready-to-inherit classes of common things to slap into my game as needed. Each window has a draw surface and wrapped allegro functions to it, basically the primitives and blitting.

The stretch idea works nice for me; what my buffering code does is this: In fullscreen, if a native low-res (I'm using 400x300 now) mode is available, it uses that, otherwise it falls back on twice the size (800x600) and stretches; if that is not available, it uses 640x480 and creates ugly (but playable) graphics.
In windowed mode, it uses 800x600 for any desktop resolution that can hold it, otherwise 400x300.
Big advantage is that it runs super-fast on older machines (which can usually do low-res natively), but also works on newer ones that don't have native low-res anymore. It also look nice in windowed mode, when 400x300 would be too small.

BTW, I had quite some fun coding for the BackHack virtual machine; limiting yourself to a platform like that forces you to keep it small and not go overboard with ideas that require way too much manpower and produce nothing but abandonware.

Hey! That idea was mine .

May be you want to colaborate (just tell me what do you think about it). Anyway, a bit of healthy receipt would be nice.

I certainly have it somewhere, but I'd really have to dig deep into my zipped back-ups.

A few thoughts:
a) Scale to 640x400, draw onto a 640x480 screen, leaving two black stripes. Cons: Skews the aspect ratio. Pros: Cheap (integral stretch), low-tech, no extra libs except allegro.
b) Anti-aliased stretch. No idea if this is feasible in real-time. Maybe through OpenGL; render to a memory buffer, upload as texture, draw a quad filling the while screen. Not very efficient in terms of bus usage etc, but since there will only ever be one texture per frame, it might work.
c) OpenLayer. Use it and be done with it. Gives you the benefits of b, but since you upload each sprite only once, and leave most of the rendering to the gpu, you'll achieve superior performance.
d) Run windowed if the desired res is unavailable. This way, you're not tied to screen resolution, but can use whatever makes sense (320x200 or 640x400 with 2x stretch or 960x600 with 3x stretch).

There are quite some differences. For a start; b) renders everything to a RAM surface using allegro, then uploads that as a texture to OpenGL hardware and finally uses some gl calls to render a quad. c) uses openlayer to render everything using opengl; this means that all graphics are uploaded as gl textures; sprites are then drawn as opengl primitives. The cpu has little to do with this; most work is done by the gpu. The performance is very likely to skyrocket, although the potential is a gazillion times larger than any oldschool game will ever need.
Apart from that; b) uses opengl directly, and doesn't require openlayer. c) does, but you can use it without knowing much opengl.

Anti-aliasing refers to any algorithm that reduces or eliminates "aliasing" effects, which result from a single pixel value used as an "alias" for a subpixel position (upsampling) or a group of pixels (downsampling).
Bilinear filtering is the anti-aliasing algorithm usually used when upsampling. For downsampling, a weighted sum is a good algorithm. Both are anti-aliasing techniques. Multi-sampling is another one; it involves rendering the same scene, aliased, but with slightly different sub-pixel offsets, then averaging the resulting images.
Yet another approach for primitive edges is to calculate appropriate alpha values for each pixel, to mix it with the destination color.

I've always thought QBASIC was the worst BASIC. It's a slightly rubbish BASIC on a platform where much better languages are available and just as convenient. That said, as it's a nostalgia and deliberate limitation exercise that isn't really a valid complaint concerning the main project goal.

My only other interesting comment is that this topic has inspired me to dust off my Atari Lynx development tools and have a bash at a complete game. I'll probably fail miserably, but there you go. I've dusted off my old Mode 7 code, maybe I'll do something with that...