Recent

Poll

Vote: What's the best project of this year?

"ball" by raw
1 (3.7%)
"bgragraphics" by j-g (pocket watch)
2 (7.4%)
"duplo6" by bylaardt
7 (25.9%)
"glslideshow" by handoko
2 (7.4%)
"mariocronch" by ericktux
0 (0%)
"movingdots" by lainz
1 (3.7%)
"movingdotsgl" by lainz
0 (0%)
"relogio" by bylaardt
5 (18.5%)
"starsfieldshooter" by turrican
0 (0%)
"steampunkclock" by bylaardt
1 (3.7%)
"sudoku" by user137
5 (18.5%)
"furiouspaladin" by handoko
3 (11.1%)
"educrace" by lulu
0 (0%)

Total Members Voted: 26

Author Topic: Graphics Contest 2017, please vote now!  (Read 199604 times)

Akira1364

  • Hero Member
  • *****
  • Posts: 561
Re: Graphics Contest 2017, please vote now!
« Reply #405 on: September 16, 2017, 05:07:25 am »
Ok, I'm here:

What User137 said is correct. You need to use mipmapped filtering, which essentially means that OpenGL generates a series of gradually smaller pre-scaled versions of a texture that it then automatically chooses from when rendering, based on the current coordinates of the current OpenGL matrix as well as the texture coordinates you supply it with. This prevents the ugly flickering that you would normally get otherwise using simple linear filtering (which can only do an "approximate" filter pass on the full size image in real time.)

To enable it in your version, you would first need to change the gls_PrepareOpenGLForPainting procedure to look like this:

Code: Pascal  [Select][+][-]
  1. procedure gls_PrepareOpenGLForPainting;
  2. begin
  3.   glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
  4.   glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);
  5.   glTexParameteri(GL_TEXTURE_2D, GL_GENERATE_MIPMAP, GL_TRUE);
  6.   glClearColor(BackgroundR, BackgroundG, BackgroundB, 1);
  7.   glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);
  8.   glLoadIdentity;
  9. end;

Your version also has a function called TextureFromBitmap that would need to be changed to look like this:

Code: Pascal  [Select][+][-]
  1. function TextureFromBitmap(Image: TBitmap): GLuint;
  2. var
  3.   Texture:  GLuint;
  4.   ATexture: array[0..0] of GLuint absolute Texture;
  5.   Viewport: array[0..3] of GLint;
  6. begin
  7.   glGenTextures(1, ATexture);
  8.   glClearColor(BackgroundR, BackgroundG, BackgroundB, 1);
  9.   glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);
  10.   glMatrixMode(GL_PROJECTION);
  11.   glScalef(1, -1, 1);
  12.   DrawScene(Image);
  13.   glLoadIdentity;
  14.   glBindTexture(GL_TEXTURE_2D, Texture);
  15.   glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
  16.   glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);
  17.   glTexParameteri(GL_TEXTURE_2D, GL_GENERATE_MIPMAP, GL_TRUE);
  18.   glGetIntegerv(GL_VIEWPORT, Viewport);
  19.   glCopyTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, 0, 0,
  20.     Viewport[2], Viewport[3], 0);
  21.   glBindTexture(GL_TEXTURE_2D, 0);
  22.   Result := Texture;
  23. end;

A note about the TextureFromBitmap function though: generating an entirely new texture every frame with glGenTextures is extremely slow. This is why my version creates all the textures before any rendering is done, and simply stores their handles as well as the filename, aspect ratio, width and height of the original image in a record. (Meaning, the TBGRABitmaps that they're created from are never stored anywhere, and only exist temporarily during the loading procedure.) From there, the records are passed to the rendering methods, which then just call glBindTexture on the handles to switch between them.

If you want to get an idea of the speed difference, load an image of around 3072x3072 or larger in your version and then try to use it with any of the Wipe, Blind, or Matrix transitions. Then do the same thing in mine.

I also added another checkbox to my version today that allows you to toggle instantaneously between mipmapped and non-mipmapped textures, to allow for easy comparisons. I've attached two screenshots below that pretty much recreate the last one you posted of J-Gs Snowflake images: one with mipmapping turned on, and one with it turned off. (The difference is more noticeable in the actual application when it's actually moving, of course, but it still comes through pretty clear in the PNGs.)

Lastly, I've uploaded a new zip file (which is also attached to this post) with the updated project files and source files for my version, for anyone who wants to get a better idea of how to go about implementing any of what I've just described. (One other thing I did today was add some Carbon and Cocoa widgetset specific defines/implementations throughout the code, and as far as I can tell it should now compile/work on those platforms. So if any Mac users specifically want to give it a test as well, that would be quite helpful!)
« Last Edit: September 17, 2017, 11:05:59 pm by Akira1364 »

Handoko

  • Hero Member
  • *****
  • Posts: 5122
  • My goal: build my own game engine using Lazarus
Re: Graphics Contest 2017, please vote now!
« Reply #406 on: September 16, 2017, 06:12:04 pm »
Thank you. I'm now busy with a website project (I'm a web designer too  :D), I saved your code and will study it later.

Akira1364

  • Hero Member
  • *****
  • Posts: 561
Re: Graphics Contest 2017, please vote now!
« Reply #407 on: September 17, 2017, 10:41:36 pm »
A note for anyone who already downloaded the zipped project files from my last post:
 
I just replaced the zip file with a new one, as I realized there were some mistakes in the defines I added for the Carbon and Cocoa widgetsets. I ended up noticing a few minor issues (affecting all widgetsets) related to pausing and playing the slideshow as well though that I've now fixed, so I'd recommend you re-download the file regardless of what platform/widgetset you're using.

Edit: Also, to specifically address the issue J-G was having loading his 1-bit "3-4.tif" image: I looked at the github history of FPReadTiff, and found that it was last updated in October 2015 (as in, after the release of FPC 3.0.0). I temporarily replaced the copy of FPReadTiff in my trunk source tree with the one from the next earlier update than that (which was in April 2015), and received the exact same error message he did upon trying to load the file.

So as I suspected, the problem originates in FPReadTiff but has been fixed in the time since FPC 3.0.0 was released. The only way anyone using FPC 3.0.0 or lower will be able to load 1-bit TIFF files in glSlideShow (or any Lazarus application really, as TPicture, like TBGRABitmap, also uses FPReadTiff to load them) is to either update to a minimum of FPC 3.0.2, or at least replace their copy of FPReadTiff with one from any source tree released later than October 2015.
« Last Edit: September 18, 2017, 02:07:49 am by Akira1364 »

J-G

  • Hero Member
  • *****
  • Posts: 953
Re: Graphics Contest 2017, please vote now!
« Reply #408 on: September 18, 2017, 12:19:25 pm »
Edit: Also, to specifically address the issue J-G was having loading his 1-bit "3-4.tif" image: I looked at the github history of FPReadTiff, and found that it was last updated in October 2015 (as in, after the release of FPC 3.0.0). I temporarily replaced the copy of FPReadTiff in my trunk source tree with the one from the next earlier update than that (which was in April 2015), and received the exact same error message he did upon trying to load the file.

So as I suspected, the problem originates in FPReadTiff but has been fixed in the time since FPC 3.0.0 was released. The only way anyone using FPC 3.0.0 or lower will be able to load 1-bit TIFF files in glSlideShow (or any Lazarus application really, as TPicture, like TBGRABitmap, also uses FPReadTiff to load them) is to either update to a minimum of FPC 3.0.2, or at least replace their copy of FPReadTiff with one from any source tree released later than October 2015.

Again, you've come up trumps Akira and solved the problem. I'm sure there are many readers who (like me) forget that FPC/Lazarus are - like Easter - a moveable feast  :D

This only matters when you have programmers using different stages of development providing code fragments to all and sundry  -  ie. this 'Graphics Contest'  -  which is great for disseminating programming ideas but can also bring 'issues' to the fore which may or may not need addressing in 'local' code. The chance of me wanting to display 1-bit images in any program I write is practically zero.

The only reason I have those music time signature images at all is that they were used in some Concert Poster design work and should I need to use them again it would be in CorelDRAW! which doesn't need to use hardware display techniques.

FPC 3.0.0 - Lazarus 1.6 &
FPC 3.2.2  - Lazarus 2.2.0 
Win 7 Ult 64

User137

  • Hero Member
  • *****
  • Posts: 1791
    • Nxpascal home
Re: Graphics Contest 2017, please vote now!
« Reply #409 on: September 18, 2017, 01:24:33 pm »
In the future the troubleshooting for specific projects should be put in its own thread in my opinion. We have strayed far offtopic from the graphics contest.

Akira1364

  • Hero Member
  • *****
  • Posts: 561
Re: Graphics Contest 2017, please vote now!
« Reply #410 on: September 18, 2017, 07:14:15 pm »
In the future the troubleshooting for specific projects should be put in its own thread in my opinion. We have strayed far offtopic from the graphics contest.

Well, the contest is over for one thing... and we're discussing an application originally written by Handoko for the contest, that I've since "forked"/largely rewritten for the purposes of providing examples of better/faster ways to use OpenGL to implement the rendering effects it does. (Any of which could be taken and applied to any other project for the most part, which is why I've been posting the project files for my version.) Wasn't the whole purpose of the contest education?

Also, J-Gs TIFF issue was an issue that anyone else could just as easily have in a large variety of other Lazarus-based applications, so I thought it was worth pointing out what the exact cause of and solution for it were.
« Last Edit: September 19, 2017, 01:24:28 am by Akira1364 »

J-G

  • Hero Member
  • *****
  • Posts: 953
Re: Graphics Contest 2017, please vote now!
« Reply #411 on: September 18, 2017, 07:53:21 pm »
Wasn't the whole purpose of the contest education?
Yes  -  and I've certainly learned a great deal.

Quote from: Akira1364
Also, J-Gs TIFF issue was an issue that anyone else could just as easily have in a large variety of other applications, so I thought it was worth pointing what the cause of and solution for it were.
I hadn't previously thought to test the same images after converting to .PNG since I was hung up on the 1-bit issue but I've just converted one of the time signature files to a 1-bit .PNG and it both loads to thumbnail and displays in the slide show. Another lesson learned  :)
FPC 3.0.0 - Lazarus 1.6 &
FPC 3.2.2  - Lazarus 2.2.0 
Win 7 Ult 64

lainz

  • Hero Member
  • *****
  • Posts: 4449
    • https://lainz.github.io/
Re: Graphics Contest 2017, please vote now!
« Reply #412 on: September 19, 2017, 05:13:59 pm »
Well this was really a success this year!

The next year we can focus on OpenGL only.

And maybe we can create the categories at first, like a new post for each category:
- Games
- Animations
- ...

Maybe also we can create a proper github organization for the contest, and put everything there, all the current and old repositories with all the projects (I will do that soon).

I need to grab all the sources for Handoko's project, the most popular this year.

I enjoy a lot this kind of participation, I feel really good with all the comments and feedback for each project.

Handoko

  • Hero Member
  • *****
  • Posts: 5122
  • My goal: build my own game engine using Lazarus
Re: Graphics Contest 2017, please vote now!
« Reply #413 on: September 19, 2017, 06:59:56 pm »
I learned a lot from this contest. Game/graphics codes written in Pascal are hard to find, learning different coding styles is good for improving my skills. I can learn not only Akira's OpenGL tricks but also how he rewrote my code using OOP approach. I know OOP but not as good as him. I especially interested with nxPascal and the graphics engine behind Educrace, I will spend some time to study them.

About the source code of Furious Paladin, I just received an email from Nuno some days ago:
Quote
Hi,
Thanks for the fix.  I had a busy summer and I hadn't had time to look at this until now.

You can get Furious Paladin's source code from Nuno's Allegro.pas website. But because he is busy, he hasn't checked the code, so the code has not published yet. After he make the source code available then I will write the tutorial about it.

May I suggest a new category?
Android graphics effects and games.

Actually I wanted to submit 3 programs for this contest. The third one was graphics effect using jmpessoa's LAMW. It already works on my Android phone, it is a 2D OpenGL ES2 effect. But it still has some minor bugs and I did not have time to fix it so I did not submit it to the contest.
« Last Edit: September 19, 2017, 07:12:29 pm by Handoko »

Ñuño_Martínez

  • Hero Member
  • *****
  • Posts: 1186
    • Burdjia
Re: Graphics Contest 2017, please vote now!
« Reply #414 on: September 20, 2017, 01:53:40 pm »
Hi people,

this summer was too much busy for me and I'm still recovering my life-after-summer or something. %) Anyway I miss the contest (may be next time :() and I had 15 pages of unread messages:  too much for me.

@Handoko: I've replied your e-mail.
Are you interested in game programming? Join the Pascal Game Development community!
Also visit the Game Development Portal

Akira1364

  • Hero Member
  • *****
  • Posts: 561
Re: Graphics Contest 2017, please vote now!
« Reply #415 on: September 21, 2017, 01:39:10 am »
I learned a lot from this contest. Game/graphics codes written in Pascal are hard to find, learning different coding styles is good for improving my skills. I can learn not only Akira's OpenGL tricks but also how he rewrote my code using OOP approach. I know OOP but not as good as him. I especially interested with nxPascal and the graphics engine behind Educrace, I will spend some time to study them.

I'm not familiar with the EducRace code, but I can definitely attest to nxPascal being a fantastic library (with probably the most impressive example demos out of any similar Pascal-based OpenGL library.) However... everything about it would perform far better than it already does if the author (User137, I think) didn't use immediate mode (which again mean glBegin/glEnd style rendering) everywhere!

That's one of the main things I was trying to demonstrate with my version of glSlideShow: that there are much faster and more efficient (and easier to code in my opinion) ways to implement things with OpenGL than immediate mode (meaning glBegin/glEnd), without even going above OpenGL 1.2 / 1.3 / 1.4 or so (such as glVertexPointer/glTexCoordPointer/glDrawElements and such, as I made use of). So just as a general note/"thing to keep in mind" for anyone reading this:
 
Remember that anytime you use glBegin/glEnd, you are using the absolute earliest, slowest possible method of OpenGL rendering! It is functionality that's literally without exaggeration straight out of 1994. Please please don't use it in any new projects that you're writing from scratch right now, as doing so places a pretty severe "hard limit" on how far your application can scale up performance wise (as in if you ever wanted to introduce higher-resolution textures, more complex particle systems, and so on and so forth.)
« Last Edit: September 21, 2017, 02:09:07 am by Akira1364 »

User137

  • Hero Member
  • *****
  • Posts: 1791
    • Nxpascal home
Re: Graphics Contest 2017, please vote now!
« Reply #416 on: September 21, 2017, 02:08:08 am »
I'm not familiar with the EducRace code, but I can definitely attest to nxPascal being a fantastic library (with probably the most impressive example demos out of any similar Pascal-based OpenGL library.) However... everything about it would perform far better than it already does if the author (User137, I think) didn't use immediate mode (glBegin/glEnd) everywhere!
There is easy to use support for vertex arrays and VBO's. I believe the pixel shader demo wouldn't even be possible with immediate mode rendering. You can also speed it up by using TCamera to manually calculate camera matrix. You can save up thousands of matrix multiplications per second by storing the matrix and reusing it. There is simple 2D rendering that uses VBO aswell if i remember right for rotation, scaling, patterned textures and so on. This was done by caching triangles in an array and them draw them all in 1 pass.

Akira1364

  • Hero Member
  • *****
  • Posts: 561
Re: Graphics Contest 2017, please vote now!
« Reply #417 on: September 21, 2017, 02:19:21 am »
There is easy to use support for vertex arrays and VBO's. I believe the pixel shader demo wouldn't even be possible with immediate mode rendering. You can also speed it up by using TCamera to manually calculate camera matrix. You can save up thousands of matrix multiplications per second by storing the matrix and reusing it. There is simple 2D rendering that uses VBO aswell if i remember right for rotation, scaling, patterned textures and so on. This was done by caching triangles in an array and them draw them all in 1 pass.

Not sure which demo you're referring to exactly... What was the project name for it? There's definitely nothing that's "impossible without immediate mode".... and while yes, the library does have support for vertex arrays (although it seems somewhat incomplete in the case of VBOs), you definitely don't use it in most of your core rendering methods.

Also I wasn't even really talking about VBOs and other "current" functionality here. (It's true they're the only correct way to do things nowadays along with VAOs and shaders, and certainly what I would normally use myself, but at the same time they're definitely somewhat far outside the OpenGL experience level that most people in this forum seem to have.)

One thing at a time, as they say! IMO for gradual learning purposes it makes more sense to start with client-side vertex arrays, as the general concepts there can be easily applied to VBOs and shader uniforms later on (and client-side vertex arrays are still a lot faster than glBegin/glEnd in the meantime.)
« Last Edit: September 21, 2017, 03:09:06 am by Akira1364 »

User137

  • Hero Member
  • *****
  • Posts: 1791
    • Nxpascal home
Re: Graphics Contest 2017, please vote now!
« Reply #418 on: September 21, 2017, 03:24:54 am »
Not sure which demo you're referring to exactly... What was the project name for it? There's definitely nothing that's "impossible without immediate mode".... and while yes, the library does have support for vertex arrays (although it seems somewhat incomplete in the case of VBOs), you definitely don't use it in most of your core rendering methods.
I meant "impossible with immediate mode". And i'm not even sure, just something i vaguely remember...

Not sure if we can call them "core methods". It gives alternative ways to render, and if using TRenderer, it definitely isn't immediate mode. One example was from Walker_shader code:
https://github.com/Zaflis/nxpascal/blob/master/demos/fpc/walker_shader/GraphicsUnit.pas#L73
But that demo wasn't made to use TCamera, which was instead shown in the Model demo:
https://github.com/Zaflis/nxpascal/blob/master/demos/fpc/model/Unit1.pas#L76
Neither of the demos are internally using glBegin...

As for being incomplete, i don't really know. Everything i tested so far worked, only what it lacks is more actual GLSL shader code examples. I'm not that good in writing shaders.
« Last Edit: September 21, 2017, 03:28:40 am by User137 »

Akira1364

  • Hero Member
  • *****
  • Posts: 561
Re: Graphics Contest 2017, please vote now!
« Reply #419 on: September 23, 2017, 01:37:50 am »
I meant "impossible with immediate mode". And i'm not even sure, just something i vaguely remember...

Ah, makes more sense, haha.

Not sure if we can call them "core methods".

Well, when I said "core rendering methods" I was referring to all the methods in the "TNXGL" and "TParticleEngine" classes and so on and so forth, which do indeed amount to a whole lot of glBegin(GL_QUADS) and essentially nothing else.

Again though, my overall point wasn't really about nxPascal specifically at all... What I was getting at basically boils down to "there's essentially no advantage to using OpenGL over a software rendering library, if you're going to use slow deprecated OpenGL from the early 1990s."

Like I said before, nxPascal is an awesome library that technically does what it's supposed to do, but it's not a good example of the right/ideal/best/fastest way to write OpenGL code in 2017 (or 2007, for that matter...)

So my initial response to Handoko about it was basically just trying to prevent him (or other users who are relative OpenGL beginners or slightly more than beginners) from looking at the nxPascal codebase and thinking "oh, well, this must be exactly how you're supposed to do it then, since that's how it's done here!" when they come across the various immediate mode parts.
« Last Edit: September 23, 2017, 01:44:00 am by Akira1364 »

 

TinyPortal © 2005-2018