Graphics Contest 2017, please vote now!

[J-G]

I don't have a nVidia card to test. Or knowledge to see how much video card usage it does.
Too many problems revealed in this fun contest!

There are just so many 'Standards' available

The basic object of the contest - to improve the knowledge of participants  -  has been well served though.  I am certainly wiser.

[Thaddy]

There are just so many 'Standards' available

No, for the drums alone.. And I need two at least two for the voice and guitars.... Same with "other" standards....

[lainz]

OpenGL or DirectX: both failed BTW, missing libraries is just a bad readme. But crashing..

[Handoko]

Furious Paladin still complains that I don't have allegro-5.2.dll even though that is in the .exe folder,

I managed to find a Win7 64-bit computer today for testing. When starting Furious Paladin, an antivirus said the program may cause harm on the computer. I simply click the allow button and it ran perfectly.

Because I am still using BGRABitmap < 9.5 I can't re-compile the latest version but at least I can now appreciate what the program does AND I can confirm that the original program does handle 8 bit  (B & W) .JPG images.

The newer version of glSlideshow will not use BGRABitmap. I found a better solution, tested, and so far it passed my tests. The 'better' I mean is easier to compile, no need to download/install any new package. Please give me some days, it has many bug fixes, minor improvements and better UI. After I make sure all of them working correctly, I will release it.

[lainz]

I made the official logo (too late?) the race is almost over and the competition right now is between 2 users: bylaardt and user137, with 5 votes each one. Two games "duplo6" and "sudoku" are the most voted this year. We never had too much entries like this year, because that you can also vote your favourite like a lot of users did in the latest pages, that votes will be counted the last day.

And the last day is the question, we wait to finish this month or we can close it right now with 2 winners?

[Handoko]

glSlideshow version 0.95

Features:
- Main transitions: SlideIn, Wipe, Blind, Fade, Scale, Matrix, Ribbon, Rotate
- Total 23 transitions + random
- Support .bmp, .cur, .icns, .ico, .gif, .jpeg/jpg, .png, .tif/tiff, .tga
- Low hardware requirement, only OpenGL version 1.2

Limitations:
- No full screen preview, no sound, no text support
- Cannot save project,  cannot export to avi/mpeg

Changes on version 0.95:
- New transitions: Wipe, Blind, Matrix, Random
- Some cosmetic improvements
- Let OpenGL to handle BGRA images (Thanks Akira1364)
- Better support for PNG and TIFF images (Thanks J-G)
- Replace TOpenPictureDialog with TOpenDialog
- Support more than 10000 slide count
- The form now is resizeable
- Slides can be removed and reorder
- Adjustable delay time before changing slides
- Smoother movement for slow animation
- Support 4x multisampling
- Fix thumbnail preview issue
- Fix sluggishness when animating large images

More info can be found on Readme.txt.

It now can handle graphics files better. TImage cannot fully support .bmp, .png, .tga, .tif/tiff files, so it uses FCL-Image when opening those files. Tested and passed on all the samples provided by J-G.
http://wiki.freepascal.org/fcl-image

Nothing wrong with BGRABitmap but I want more people can easily compile and test the code. FCL-Image library is included on Lazarus default installation. And I carefully chose the OpenGL commands used in the code. I have not tested but any hardware that support OpenGL version 1.2 should be able to run the program. On Windows system, you have to make sure the VGA driver is installed properly. To be able to compile this code on Linux, your computer needs libgl1-mesa-dev library installed.

It's no longer use TOpenPictureDialog when opening file, because it will crash on some 'rare' graphics file.

I haven't tested but it should be able to open more than 10k slides, because it uses TFPList as the container.

Previously, it used TTimer to slow down the animation. But the movement was noticeable ugly if the frame rate is below 20fps. Now frame rate is fixed on ± 62 fps because it now increases/decreases the total frames per slide when changing the speed.

I noticed some slow down when animating extra large images. To solve it, it will automatically scale them down to the size of user monitor's resolution.

I should mention Akira1364 has done many improvements on the code (using BGRABitmap, Advance Record, Matrix Transformation, Vertex Array). But because Vertex Array is only supported on OpenGL 3.0 or above and also I am not good on Maxtrix, so I didn't adopt them. If you're interested to see the code that using more modern version OpenGL, download here:
https://forum.lazarus.freepascal.org/index.php/topic,35313.msg255447.html#msg255447

glslideshow_by_handoko
- Can it be a component for Lazarus? Maybe on OPM?

Good suggestion. I will do it, but I can't make any commitment now. If anybody have time, please do it. I have further split the UI section and graphics/animation code.

--- edit ---
Almost forget to mention, the code needs LazOpenGLContext package to compile. To enable it:
Lazarus main menu > Package > Install/Uninstall Packages > select: LazOpenGLContext 0.0.1 > click: Install Selection > Save and rebuild IDE.

[Lulu]

Good job Handoko !

[Pascal]

Very impressive Handoko! 
If i could vote again i would vote for glSlideshow

[bylaardt]

If i could vote again i would vote for glSlideshow

A big extra large annoying "i told you"

Deadline is september 21, right?
glslideshow and educrace still evolving. Give them some time to finish. Both are nice projects.

[lainz]

If i could vote again i would vote for glSlideshow

A big extra large annoying "i told you"

Deadline is september 21, right?
glslideshow and educrace still evolving. Give them some time to finish. Both are nice projects.

The deadline was September 1. Then I did it faster since no one was adding more projects. The last was in that time educrace. The voting deadline was September 21. But maybe we can do it before since a lot of users already voted and now you're the winner

And most people not voted by message. So maybe until end of month is the new deadline for voting. A month for voting is a lot.

[bylaardt]

But maybe we can do it before since a lot of users already voted

1/5 of total votes in the last 48h and one project was updated.
An early end can stop new updates.

[lainz]

Ok. Just end 21 Sept.

Hopefully we can get more comments with votes, and also in the poll.

[bylaardt]

(Sep 21) Or (when all projects are stable) and (votes are stuck)

[Akira1364]

But because Vertex Array is only supported on OpenGL 3.0 or above and also I am not good on Maxtrix, so I didn't adopt them.

The rendering code in my modified version uses client-side vertex arrays (meaning they exist in application memory, not GPU buffer objects, but still perform a lot better than pure immediate-mode glBegin/glEnd.) Client-side vertex arrays are not a "modern" feature at all and have been available in every version since OpenGL 1.1 (released in 1997!) I certainly could have introduced OpenGL 2.0/3.0+ style GPU-buffered arrays and shaders (which are the actual modern way of doing things), and my code was definitely designed to be easily adapted to that, but I was specifically trying not to make the hardware requirements too high. As it stands, anyone with a GPU that can run your version should also be able to run mine without issues.

Also, the TCamera advanced record I added (which uses the TMatrix advanced record internally) is a direct drop-in replacement for and reimplementation of the set of functions you had been using. All you really need to know in order to use it is:

-TCamera.LoadIdentity replaces glLoadIdentity
-TCamera.Zoom replaces glScaleF
-TCamera.Roll replaces glRotateF
-TCamera.Move replaces glTranslateF
-All of the functions have an "Upload" boolean parameter which defaults to false, but should be set to true whenever you want to send the camera's matrix to OpenGL. (For example, whenever you're doing multiple Zoom/Roll/Move operations directly one after another, only the last one needs to be uploaded as the matrix at that point is the result of all the operations combined.) 

The whole point is just that it's much faster in general to have the matrix exist application-side and do your math operations on it application-side (and only upload it to OpenGL immediately before rendering, which I used glLoadMatrixF for) than it is call the built-in matrix functions from the OpenGL library, which are typically not particularly well optimized and add quite a bit of overall "latency" to the rendering loop.

Very cool changes in your latest update, though! Looks like you've added quite a few new features. Might spend some time merging them into my version if I have the chance at some point.

Because I am still using BGRABitmap < 9.5 I can't re-compile the latest version but at least I can now appreciate what the program does AND I can confirm that the original program does handle 8 bit  (B & W) .JPG images.

Not sure what exactly you're referring to here... as far as I know Handoko never uploaded a release of the original project that included BGRABitmap as a requirement in the LPI, or used BGRABitmap at all. The zip files of my modification (that does use BGRABitmap) that I've been uploading have only included two PAS files and an LFM (meaning no particular version of BGRABitmap has ever been specified anywhere.) My initial post about it just says to "add BGRABitmap to your project requirements" to be able to compile the project with the changed files.

[J-G]

Because I am still using BGRABitmap < 9.5 I can't re-compile the latest version but at least I can now appreciate what the program does AND I can confirm that the original program does handle 8 bit  (B & W) .JPG images.

Not sure what exactly you're referring to here... as far as I know Handoko never uploaded a release of the original project that included BGRABitmap as a requirement in the LPI, or used BGRABitmap at all. The zip files of my modification (that does use BGRABitmap) that I've been uploading have only included two PAS files and an LFM (meaning no particular version of BGRABitmap has ever been specified anywhere.) My initial post about it just says to "add BGRABitmap to your project requirements" to be able to compile the project with the changed files.

I have tested so many 'Versions' - and still have the source code of 4 of them in my '2017 Contest' folder, re-testing to find the issue has been problematic !   I have now found the version that gave rise to my statement 'using BGRABitmap < 9.5'  -- it is Your source time-stamped at 13/8/2017 11:40 and it fails to compile with an error at line 228 of uniGraphics.pas - viz. (starting at line 210  therefore the fail line is 19 on '.width')

Code: Pascal  [Select][+][-]

1. procedure UpdateButtonImage(Button: TBitBtn; FileName: String);
2. var
3.   BaseImage, ThumbNail: TBGRABitmap;
4.   Rect: TRect;
5. begin
6.   BaseImage := TBGRABitmap.Create(FileName);
7.   Rect.Left := 0;
8.   Rect.Top := 0;
9.   if (BaseImage.Width > BaseImage.Height) then
10.   begin
11.     Rect.Right := Button.Width;
12.     Rect.Bottom := (Button.Width * BaseImage.Height) div BaseImage.Width;
13.   end
14.   else
15.   begin
16.     Rect.Bottom := Button.Height;
17.     Rect.Right := (Button.Height * BaseImage.Width) div BaseImage.Height;
18.   end;
19.   Thumbnail := TBGRABitmap(BaseImage.Resample(Rect.Width, Rect.Height));
20.   BaseImage.Free;
21.   Button.Caption := '';
22.   Button.Glyph.Clear;
23.   Button.Glyph.Assign(ThumbNail.Bitmap);
24.   ThumbNail.Free;
25. end;

The error being 'identifier idents no member "Width"' - there is another error noted for "Height" as well - which I assumed to mean that BGRABitmap V9.5 differs from V9.2.1 by adding a 'width' and 'height' property.

Although - on reflection - in the same message window I also see many 'Hints' referring to Duplicate Unit "bgrawritepng" etc.   so that may indicate some other cause based on the number of copies I have in nested folders.