Finally! Time for the 1.91 release.

Download 1.91, Update 1.9 to 1.91 (No precompiled demo), the Demo .exe only and the source only distribution

• Fixed away the diagonal lines which crossed the Bitmaps with some hardware

• Included the correct version of Loadpng in the package

• Fixed the header files to work in Linux without modifications

void Print( const std::string &text, int x, int baselineY, const RenderMode &mode);
//RenderMode would need rotate() and stretch())

Fix that with demo programs and screenshots? or... maybe BlitRotated would call Blit(,, + Rotate(angle))? But having 2 ways of doing the same thing is just asking for work and confusion.

Are all OL angles CCW positive(including transforms)?
Might want to mention that arc and ellipse angles can be positive or negative.

GfxRend: Ok, I'm converted. The only thing left is EllipticalArcGradient- the mother of them all. (j/k!);D

I'm hopeless I know I always just think that for a source distribution I have to include all the sources and headers from the original package...

Well, I haven't thought that's necessary.

Well, that's possible with the new system in fact. It requires some extra work in the TextRenderer's side, but still.

That's what I thought as well.

Yeah, I should indeed.

Hi,

i have created a Bitmap-object from an Allegro BITMAP, but when i try to blit it to the screen nothing appears!

I think that i have detected the reason in line 868 of file "Bitmap.cpp":

bool Bitmap::
Load( BITMAP *bmp, bool hasAlphaChannel, bool convertMagicPink ) {
   Destroy();
   
   this->bmp = bmp;
   this->isSolid = !hasAlphaChannel;
   width = width;
   height = bmp->h;

Instead of 'width = width' it should be 'width = bmp->w'.
Otherwise 'width' remains zero.

Yes, GUI was what I had in mind.

Hmm, sorry to say: it seems you broke the demo in 1.92. Fix below:

EDIT: forgot to say, I used to 1.91->1.92 upgrade zip

Demo crashes for me. Last line in the log is loading the background. Also, does it compile for MSVC? Have you considered not using uppercase in your filenames?

[edit]
I'll have some time to work on a nice demo I'm thinking of in a few hours. But I'd need to be able to use OpenLayer to be able to use OpenLayer

I could make life easier to newcomers (

1 .a + 1 .dll

-VS-

8 .a + 3 .dll

).

Speaking of DLLs, they must be in same folder as exe in order to be found, ie putting them in "DLLs" won't work.

Yeah, I originally had them in the base folder of OpenLayer but then I thought everything would be better organized if the were in a Dlls -folder instead. Of course this may cause many "Why doesn't this demo run?" problems if I introduce OpenLayer in Gamedev where few have Allegro (or GZip) installed and not everyone would think that if a dll is not found it can be found in the dlls folder. So maybe I'll move them to the same folder as the demo.

Maybe, maybe. I hadn't thougth that I could include the other dlls inside OpenLayer's dll file.

I've got rid of those in 1.92.

I always use Windows as if the file system would be case-sensitive and I don't find that so annoying. But maybe that's just me, I like starting all the names with an uppercase letter.

Allegro's angles are CCW negative. Traditional Angles are CCW positive. I don't care which standard OL uses as long as it's consistent throughout the api; I'm making myself float d2r(float); //degrees to radians anyway.

Is OL z-negative into the screen? If it is, great. Without changing the projection, I could render 3d stuff in a layered 2d overhead world. UP = z_positive. No worries about render order.

No, no! I'm wrong! "Regular" gfx_rend functions provide instant syntax checking for coders, which prevents bugs. A "StartupStuff" function may reduce the GfxRend function list by 60%. Unfortunately, coders may forget to add all of the parameters for what they want to do, and end up cursing over why their circles are all 1 pixel at (0,0).

What about this code for SetOrthographicProjection (instead of the current code of course):

void Settings::
SetOrthographicProjection(int w, int h) {
  glMatrixMode( GL_PROJECTION );
  glPushMatrix();
  glLoadIdentity();
  glOrtho( 0, w, 0, h, -1, 1000 );
  glScalef( 1, -1, 1 );
  glTranslatef( 0, -h, 0 );

  glMatrixMode( GL_MODELVIEW );
  glLoadIdentity();
  glDisable( GL_DEPTH_TEST );
}

To preserve API compatibility add default arguments
SetOrthographicProjection(int w = SCREEN_W, int h = SCREEN_H);
to the declaration.

It allows you to write a program designed for 800x600 and run it in any resolution with all graphics automagically rescaled by OpenGL, by passing the real resolution to SetupScreen and the design resolution to SetOrthographicProjection.

There are some issues with GK though which cause text to appear in different size. These can be solved by adding

gfx_driver->w = DESIGN_W;
gfx_driver->h = DESIGN_H;

after SetOrthographicProjection. This causes SCREEN_W and SCREEN_H to return the design resolution to GK.

Note: I grepped through Allegro's source and it appears to be quite safe to change these. Of course, it is still a dirty hack which might be less portable than normal Allegro code. So use it at your own risk!

For example, demo in 1280x1024 fullscreen by changing the call to SetupScreen to:

   // Open the game in a 800 x 600 window //
   if( Setup::SetupScreen( 1280, 1024, FULLSCREEN ) == false ) {
      allegro_message( "Error while trying to set graphics mode!" );
      //exit( -1 );
   }

   Settings::SetOrthographicProjection( 800, 600 );

   gfx_driver->w = 800;
   gfx_driver->h = 600;

Sounds good, but I think I'll change the OpenGL port of Glyph Keeper instead of changing any internal values of Allegro. An another way to get the same effect would be Transforms::SetStretch( 800.0/1280.0, 600.0/1024.0 ) but then SetStretch couldn't be used to anything else (without multiplying the parameters with those parameters).

I believe I just write Bitmap::SetAsDestination() or a similiar function. Of course I have to add a function to set the screen as the destination. In fact as it's possible to use the screen contents as a texture I could include a global screen variable as in Allegro. I'm not sure about this yet, though.

Pixel shaders, for example. I've been designing a system I call ShaderLayer and it's intended to be an easy-to-use tool to make 2D shaders.

And I've also thought about making an gui library for OpenLayer and then there's the rendering to Bitmaps.

Well, new stuff is always new stuff. The final API will just include more and do everything better but thus far the API looks fine for me...