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.

Looking good!

But change the BOOL type to char to make it work with C.

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.

// comments were adopted as part of the c99 standed (I think), anyway I use them and they are ok.

Sunday is always a bit quiet..

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).

axilmar: bad puppy. If you want to present your api, create your own thread. Stop that BAFism now.

23: You should check if cplusplpus is not defined:

#ifndef __cplusplus
    extern "C" {
#endif

// ...

#ifndef __cplusplus
    }
#endif

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?

Change to:

?

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.

If you want to be able to compile .c and .cpp files in a same project, just have this in your makefile:

$(OBJ_DIR)/%.o: src/%.cpp
  g++ $(CFLAGS) -o $@ -c $<

$(OBJ_DIR)/%.o: src/%.c
  gcc $(CFLAGS) -o $@ -c $<

works for me

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

/me sees the following:

#define TRIPLEBUFFER 1
#define PAGEFLIP     2
#define SYSTEMBUFFER 3
#define DOUBLEBUFFER 4

<C0CKS SHOTGUN>
Try this before I blow your brains out:

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

After that, I'm going after Matthew and his censorship filter.

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.

You might as well drop the values then as you're not using them.

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

All hail Barry, King of the Kode!

Nice work 23, this resource will prove useful to many.

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.

RB: No good.

Okay, here's draft 2. The screen.cpp file is now a .c file, and I'm including no makefile, so if you can't compile it without error yourself, tell me why.

If the code is all good, the subject of naming conventions may be introduced ...

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.

Hooray!

That did it. main.cpp and screen.c compile and link perfectly; thanks.

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.

Ok, if that's the proper way.

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?

..edit..

Oh, and it just looks cooler to boot

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

You should think more before posting; too many edits to save your donkey, lately

Uhm that still doesn't answer it... other than what I already knew about #define...

With defines your error messages often won't match you code.

Pfft I NEVER get errors

It's mainly a style question. It also allows you to see the name of the constant instead of it's name in case of any errors. Another reason is that if you use enums, you have a better compile time control.

If you use defines, your constants could change values (by using defines and undefs).

But mainly style. The discussion started as part of the C vs C++ vars.

It's not mainly style! Macros can silently change the behavior of your program without the compiler giving a peep!

The API should be consistant with Allegro's if you want it to be considered an "add-on" lib. (Ie, underscores instead of MixedCaps.)

Yup; that was the first thing that occured to me. Just curious if anyone else had any ideas ...

The only thing I can think of is a change_update function which acts as a wrapper around the shutdown and the setup update functions. It would only take 4 lines, but I use something similar..

Hmmm. It's true that it's trivial ... I wouldn't have to worry about video bitmaps getting destroyed or any crap like that, would I?

Nah. Just make the end user call two functions instead of one.

Don't you have the option to change the screen update system ingame in TMS?

I don't think it's trivial, when you have a function to toggle the vsync variable, or return it.

Sure, and then you restart, and forget the option ever existed. It's not like you have to switch between update methods 20 times per game or something.

The vsync setup is mostly for testing. Besides, since the waitforvsync variable is static, I really have no choice there.

Well it's up to you, people would only use it once in a program, but I personally would include it.

Looks good Chris (from what I saw in the headerfile at least)!
Depending on what is going to happen with Allegro's GFX API in the near future, I'd say this could be merged with Allegro rather than being offered as an add-on.

Okay, here's the final version AFAIAC. I've added support for triple buffering and page flipping with a memory bitmap buffer, for those who might be reading from said buffer and don't want it to be a video bitmap. If triple buffering fails, it tries for page flipping. If triple buffering with a buffer fails, it tries for page flipping with a buffer. If either page flipping setup fails, it tries for system buffering, and then double buffering. I had to change the internals a bit to make that work, but I don't think I introduced any bugs.

Also, I switched to allegro_naming_conventions.

I guess that's that then. Anything else?

Again, looks good. I'll forward this to AD to see if we want it included. This depends on where we want to go with the graphics API I guess...

Some nitpicking in case it is merged with Allegro (not saying I have issues with your coding style, just pointing out where Allegro's conventions differ).
I won't comment on indentation and other source layout issues because those are not as important unless it actually is included.

#ifndef __cplusplus
  extern "C" {
#endif

That actually is an error. It should be #ifdef __cplusplus

enum {
I think that'd have to be changed to use #defines. Maybe change the names too.

char initialize_screen_updating(char i);
char -> int, in all three functions.

alert("Well ... crap!", NULL, NULL, "dsjkd", "sdkffd", 1, 1);

Well, a popup box when a function fails is evil. It should probably also return NOUPDATEMETHOD on error. Better yet, in your code you could use a named emum instead of int for the return or argument type.

if(active_page) active_page = EraseBitmap(active_page);
You can lose the if(...) on this one and it's brethern.

Oops. I just copied spellcaster's post above.

Aw, right. I was having a bit of trouble last night and was trying to get it to tell me why. That shouldn't still be in there; I'll remove it ...

Does it matter?

It's cleaner, looks better, and is more CPU friendly. The memory difference is negligible.

Like I said before, there's no need to set the values explicitly with the enum. Otherwise, it might seem those values are somehow relevant in some way possibly leading to confusion and/or errors:

enum {
        NOUPDATEMETHOD,
        TRIPLEBUFFER,
        PAGEFLIP,
        SYSTEMBUFFER,
        DOUBLEBUFFER,
        TRIPLEBUFFERWMB,
        PAGEFLIPWMB
};

Yeah; I'm just being paranoid, I guess. I'm assuming enum's are guarenteed to start at 0? If so, I'll remove that bit ...

What happens if I destroy_bitmap() on a NULL pointer?

Emphasis mine.

Okay, I fixed everything but changing the enum back to defines. Rash said he'd blow my brains out above.

Anything else?

Yes, add a dummy value at the end of the enum and use that for comparison. Makes the code clearer and less error prone.

Could you be a little clearer? Comparing what?

Something like this:

// in screen.h
enum {
        NOUPDATEMETHOD,
        TRIPLEBUFFER,
        PAGEFLIP,
        SYSTEMBUFFER,
        DOUBLEBUFFER,
        TRIPLEBUFFERWMB,
        PAGEFLIPWMB,
        LASTVALUE
};
// in screen.c
if(i <= NOUPDATEMETHOD || i >= LASTVALUE) i = TRIPLEBUFFER;

I guess it's worth the effort. Last attachment updated.

Anything else?

A couple of style issues:

do { } while (poll_scroll());

Is this deliberately chosen instead of just a while statement?

active_page = active_page == pages[0] ? pages[1] : pages[0];
buffer = active_page = active_page == pages[0] ? pages[1] : pages[0];

I would have put the RHS between parentheses.

That while (poll_scroll()); with just a terminator at the end always looks suspicious to me. Sorry; that's just me. I implemented both style suggestions, even thought the RHS evaluates just fine (I guess it's clearer now). Updated attachment.

Actually I was looking for the parentheses being put around the assigned expressions instead.

... Why?

Also, I caught a bug; destroying all the bitmaps like that in shutdown_screen_updating() is a bad move because buffer and active_page could be pointing at the same bitmap. Calling destroy_bitmap() on both would be bad, yes? Fixed up.

The way I see it, you would want to draw attention to the fact that the statement is in fact an assignment.

Just like calling delete or free twice on the same value.

If you are assuming the first update method is 0, I'd suggest for clarity, simply explicitly setting the first item in the enum:

enum {
        NOUPDATEMETHOD = 0,
        TRIPLEBUFFER,
        PAGEFLIP,
        SYSTEMBUFFER,
        DOUBLEBUFFER,
        TRIPLEBUFFERWMB,
        PAGEFLIPWMB,
        LASTVALUE
};

And personally I'd add underscores in those, cause they're kinda hard to read. Or in this case, since they're global constants, perhaps:

enum {
        UPDATE_NONE = 0,
        UPDATE_DOUBLE_BUFFER, // Or take out _BUFFER?
        UPDATE_TRIPLE_BUFFER,
        UPDATE_PAGE_FLIP,
        UPDATE_SYSTEM_BUFFER,
        UPDATE_TRIPLE_WMB,    // WMB is a bit odd... maybe MEM or MEMORY instead
        UPDATE_PAGEFLIP_WMB,
        UPDATE_MAX            // this is just personal style for me when doing enums
};

Marcello

Allegro tends to use

do {
} while (...);

though I personalyl prefer doing

while(...)
   ;

Personal preference, though.

And I thought *ptr++ was bad. I'd clarrify that to:

active_page = ((active_page == pages[0]) ? pages[1] : pages[0]);
buffer = active_page = ((active_page == pages[0]) ? pages[1] : pages[0]);

The ?: operators are generally quite anal when it comes to operator precedence, so I prefer to leave little room for errors (I would even put parenthesis around the two "return" values, though when it's just a single word like that I usually omit it).

I like Marcello's enum name suggestions. I'm gonna keep the WMB (With Memory Buffer) though.

New update; you can now toggle vsync by pressing 2, and cycle through screen update methods by pressing 1 (that's a change to the example code, not the API). Calling the initialization function now let's you switch update methods with a single function call (it calls the shutdown function internally if there's already an update method in operation). Also streamlined main.cpp a bit and added more comments. I think it's bulletproof now ...

EDIT: Oddly, Double Buffering is twice as fast as System Buffering for me. I thought the latter was supposed to be faster ... maybe I should omit it?

I'm a bit skeptical about the idea of falling back to triple buffering in case an illegal value is supplied by the user. I guess it depends on whether you're "defensively" or "offensively" minded programming wise.

How about implementing dirty rectangles too?

Maybe, maybe not. I know that for me, page flipping nets worse results both in terms of tearing and flicker than double buffering does. (Disclaimer: I didn't write the programs referred to here. They might have used some dodgy methods.)

The return value can be checked, if the programmer definitely wants to avoid triple buffering. Perhaps more wisely, let the user determine what's best for their system themselves (dirt easy now, isn't it? )

Firstly, I don't want to bloat the API too much. Screen updating is fine, especially since a seperate DRS could probably be built seperately. Secondly, I have no need or use for a DRS, so a) I personally won't waste my time and b) I wouldn't know where to start anyway.

Let's just worry about problems with the current setup. Does all look good?

X-G: Yeah, but page flipping isn't as comparable to double buffering as system buffering is.

One comment of yours fails the spell checker test.
Yes, "pedantic" is my middle name.

omg "seperately"

Marcello

Can't see it.

"self-explanitory"

Huh. Thought it was spelt with an 'i'.

Oh well. If that's my worst bug I'm happy.

Well to be perfectly honest, I haven't bothered delving into the semantic aspect of the program as I'm not familiar with this aspect of Allegro.

Final call ...

Add comments?

One thing I noticed that could be added is documentation ... even though it's simple it's needed anyway for reference whenever you need to use a function, that way you don't have to go diggin through source code or header files to find something. Also in screen.h it is best to add:

This keeps it from being defined twice if it's included in multiple files in a project
I had to use SCREEN_UPDATE_H because I think allegro already uses SCREEN_H therefore it refused to compile the header file

I utilized your screen update code into my little game, which works well since it has the *_WMB ability and I use fades, etc. That way I get ultra smooth motion with Triple buffering fullscreen and fast fades. However for some odd reason in windowed mode triple buffering is actually a bit choppy and not smooth, double buffering is excellent windowed and somewhat ok fullscreen, but at least you get to choose

tripple buffering in windowed mode doesn't exist. You're probably getting page flipping (it depends on 23 implementation).

Ooh just noticed that UPDATE_PAGEFLIP_WMB doesn't work like it should, somehow I'm getting a video bitmap to draw to, this makes it extremely slow at times.

You can page flip in windowed mode?

I haven't checked to see how the lib reacts to windowed modes. I should check that tomorrow. But like you said, at least you get to choose. Glad to hear it works for you.

Well, yeah. But right now it's pretty easy to read from the code. I'll make docs once it's done, fully and completely.

Huh? That shouldn't be ... from the code that's impossible. is_video_bitmap() == true?!

if(is_video_bitmap(get_buffer())){
  allegro_message("OMG VIDEO BITMAP!!!!!DIEKTHXBYE");
  exit(1);
}

You can guess what pops up on the screen
That's using the update method of page flip WMB so somehow I'm getting a video buffer

In chris's code it's :

buffer = create_bitmap(SCREEN_W, SCREEN_H);
And so it should work. I don't know why it doesn't. However buffer itself is not being checked to see if it was created properly. Or indeed cleared of any old data..

    buffer = create_bitmap(SCREEN_W, SCREEN_H);
      
    if(pages[0] && pages[1] && buffer)
    {
      clear_bitmap(pages[0]);
      clear_bitmap(pages[1]);
      clear_bitmap(buffer);

      ...

Anyway, I'm going to check this now ...

In the zip I downloaded it is:

So I must have an earlier version. Sorry about that..

That's both old, and the triple buffering code.

But you still have:
buffer = create_bitmap(SCREEN_W, SCREEN_H);
In the middle of there.

Your new code looks much better.

I'll be buggered. Steve was right; something I copied and pasted over from PAGE_FLIP to PAGEFLIP_WMB assigned a video bitmap to the buffer (after it had already been assigned the memory buffer) in the drawing code. The main program now reports the type of buffer for any given mode, but now that it's working correctly it's kind of not necessary.

Fixed and attached.

Page flipping is indeed choppy for me in windowed mode too, but I don't think you can get away from that ...

I think page flipping in a window is just choppy what ever you do. Glad to see you fixed the code.

Cool it works now I still suggest doing the #ifndef UPDATE_SCREEN_H part for multiple file projects... otherwise you are going to get errors.

Hey do I get to go on the beta tester list now I found and helped fix a bug

Right; I forgot that. Added.

List? There's a list?

Chris, would you be prepared to add in a DRS system if Axilmar or someone else was to code it?

You need at least a README in there for those who wish to use it, not everyone is inclined to dig through .c files to figure out how to use it

Depends on how its done. I have no idea what a DRS system entails and I don't know what it'll do to the API. If can be written to work alongside my API, bodacious. I'm definitely open to the idea.

Well, yeah. But that's when it's ready to be "released", and especially after a bug like you found, it ain't. Plus a DRS might muck up the API, so ...

It shouldn't mess up the API or your system at all if done right. Maybe Axilmar can help with this. I'm going to be a bit busy setting everything up..

Yes, a DRS system is completely independent from what Chris does. It is only conceptually that they belong together.

EDIT: as for me doing it, come on people! activate yourselves! I am busy designing the gui! I can't do it all!

I've had my say. I don't know how and I don't care how.

Haven't a few of you guys already made DRS systems? Clean it up and post it ...

There are plenty of people here who unlike me aren't busy.. cough X-G, cough..

I have mine, axilmar has his, both are completely independent of a screen update API, however if you want mine just copy nas_drs.h and nas_drs.c from the NAS library

DOKUMINTASHUN!!1

Anything to add?

Excellent!

You've been busy.

Ah yes, I meant to ask about this:

What's the advantage over using a plain double buffer for this case? I don't see any, to be honest.

I have yet to merge the code with the current Allegro tree and API, although I have integrated it with a start for an improved graphics API (with a few changes - the initialization fails if a mode isn't supported rather than trying another one, for instance).

Neither do I. I just put it in at the request of others, and the more I think about it the dumber it seems.

What?! I was so proud of that!

PS: Would it be safe to install shutdown_screen_updating() as one of those atexit() function calls?

I use it. Trust me it's very good. Especially with a scrolling screen as you have the advantages of a memory bitmap with smooth updating without flickering.

Well, it went into what is basically a replacement for set_gfx_mode(), and it felt a bit too complicated. My take here was to have the function do what it's asked to do and not try to be smart if it can't do it.
Anyway, for the curious, my initial draft sitting on top of Allegro's current API is attached. This'll be post 4.2 material though.

I still don't really see the advantage over a plain double buffer, actually...

Oh, okay. You've made some huge changes there.

I'll submit it as is to the code resource then.

I plan to backport it to 4.1 though. Don't let that stop you anyway.

If you scroll with a double buffer you sometimes get tearing, even with vsync which can sometimes make it worse. Normally you would use page flipping or triple buffering but then normally you would have to use video memory which would slow down some kinds of gfx.

With a memory buffer and video memory you have the advantages of a memory bitmap without tearing.

You're going to have to trust me on this one. Don't drop it, it's very useful.

Ah... I see. With normal double buffering, you can still get tearing when you draw the backbuffer to the screen. By drawing the backbuffer to a second screenpage and using page flipping, you don't get tearing at all.

Ok, guess I'll put it back in for page flipping. I still don't see the use with triple buffering though...

Triple Buffering doesn't force you to wait for an update to complete like page flipping does.

Actually, I don't see the use with page flipping (my update API doesn't have this one). since page flipping usually works worse than double buffer (specially in windowed mode).

But with tripple buffer you have the advantage RP just mentioned.

I agree here. I'd suggest an autodetect mode (however, without any extra info, it wouldn't know if it should use *_WMB or not, that's why mine has the hw_accel flag).