EDIT: See posts below for the latest attached update

Keen observers may have seen this already. I want to submit my screen update API too, so I gave it a quick once-over and added some new functionality, and made it as C friendly as I can. I'd like the code checked over before I formally submit it though, since it's longer (and the possibility that I missed a bug has thus gone up), but especially since I want to make sure it's okay for use in C programs (and for the life of me, I can't get my makefile to compile C source to check for myself). I'm pretty sure some sort of extern C should be in there somewhere, but I forget what and where.

The source is pretty condensed; less than 300 lines of code total across 3 files (implementation .cpp, declaration .h, and the main .cpp example program). Just for kicks, I also set the color depth and default update method using a config file, if that sort of idea appeals to you.

Thanks for your time.

You mean the waitforvsync variable? Good point. I changed the updatemethod variable to char too, just because. Also, I assume // comments are okay? And what about extern C; do I still have to do that somewhere? I expected more feedback. Thanks for checking it, RP.

Here is my own screen update API, complete with support for DRS (with a very fast clever system that avoids blitting of the same area twice without using rectangle combining/splitting) as well as all the traditional methods for screen updating, along with a little DRS demo.

EDIT:

I forgot to say that it also includes support for writing balanced game loops (the known algorithm in the Allegro FAQ), and that it is 283 lines of code, non-condensed, containing comments for Doc++ (you can find the reference at doc/index.htm).

Right; that. So I should change the header to this?

And if the implementation file is a .cpp file (as it is now), that's not necessary, is it? If it's changed to a .c file, that's needed? I can't get my makefile to compile .c files so I can't check.

axilmar makes a good point, that my API has no DRS. But a DRS can be built on top of it easily enough. I have no need for a DRS personally.

Here's my makefile:

Here's my error:

   >make
   cc    -c -o screen.o screen.c
   process_begin: CreateProcess((null), cc -c -o screen.o screen.c, ...) failed.
   make (e=2): The system cannot find the file specified.

   make: *** [screen.o] Error 2
   >Exit code: 2

Anyone help me?

1. are all your files cpp sources or is there c source ones too?
2. im guessing you are using mingw, so set the variable CXX=g++ and CC=gcc, because it seems as if make is having trouble running cc.exe also it might help to echo out the variables like echo $(CXX) to see what file it is pointing to. you usually get the create proccess error when make can't find a file.

Same error; sorry. Maybe I just don't have cc.exe ... or gcc ... or something ...

Yeah, I considered that. Just didn't think it was a big issue; I thought everyone here loved #define.

I'd make it this though ...

enum {
        NOUPDATEMETHOD = 0,
        TRIPLEBUFFER   = 1,
        PAGEFLIP       = 2,
        SYSTEMBUFFER   = 3,
        DOUBLEBUFFER   = 4
};

... because the invalid method is handy in screen.cpp.

It isn't a big issue. But you shouldn't use defines for constant values.

23, define CXX as g++, by default it seems to be set to cc, which is a very old name of the GCC compiler (CXX = g++ at the begining of your makefile), as said above. If it stills triggers CXX, then use GCC instead of CXX, or just hardcode the compiler as Oscar suggested.

Ok, got the error. The problem is this rule:

%.o : %.cpp *.h
    $(CXX) -o $@ -c $<

Note that it tells how to compile cpp files, but you have c files, so the compiler goes to the implicit default rule for c files (which is legacy, using cc for compiling). So, change that rule to:

%.o : %.c *.h
    $(CXX) -o $@ -c $< $(CFLAGS)

And should work.

I would use some different makefile, that creates a library and/or the example, like:

Also, my mistake in your previous makefile: Use all FLAGS or all CFLAGS, otherwise it would compile and link with different flags. Convention says you should use CFLAGS for C and CXXFLAGS for C++, but in this case it is up to you.

o_O there is competiton today of screen updaters I would post mine... but nah. Anyway my question is what is the advantage/reason for using enum instead of #define?

#define is pre processor based. they get replaced inline with the values before the compiler even gets the code.