I've made some fairly significant progress on JuhaManninen's port of DeleD...

[Akira1364]

For anyone that isn't aware, in 2013 JuhaManninen (a moderator here, i think) ported DeleD (a simultaneously powerful and impressively easy to use 3D level editor/modeller) from Delphi to Lazarus. Originally it used dglOpenGL with a custom "TOGLForm" class that was native to the application. As far as I know he did get it 100% working with the original method of rendering, but then after beginning to attempt to move it over to use Lazarus' TOpenGLControl he stopped working on the project for one reason or another. So it's pretty much been entirely stagnant for the past few years with the TOpenGLControl implementation very much not working at all. I decided to pick up where he left off a couple of weeks ago, and I'm happy to state that I've pretty much got the entire application "working as intended" with TOpenGLControl (as in no more dglOpenGL anywhere.) I don't think I'm quite ready to post the updated codebase anywhere yet, but I certainly will once I get it cleaned up a bit more. Apart from getting it to work with TOpenGLControl at all, other significant changes I've made are:

-Replaced all of the outdated SendMessage and PostMessage stuff with proper LCL event handlers
-Fixed the Raytracer and Screenshot manager save-to-image-file functionality (the resulting files aren't just entirely black now!  )
-Fixed some weird TList-related bugs that would cause certain aspects of the applications functionality (like the Hollow and Smooth Tool) to make it crash to desktop
-Replaced all the TControlBars with TPanels (TControlBar is just extremely buggy, and isn't a unique or important enough component relative to the applications functionality to be worth spending time fixing)
-Added an anti-aliasing level control so you can make the viewport look nice!
-Other misc stuff that i'll detail more later.

Here's a  preview screenshot of the application running with eight-times multisampling:
i.imgur.com/cMVCOqz.png

EDIT: I certainly meant TControlBar, not TCoolBar. TCoolBar works fine. TControlBar does not. Bulletpoint has been modified as necessary, haha.

[JuhaManninen]

Thanks a lot Akira1364!
I answered your post in DeleD forum. I will not repeat the same things here, please read everybody:
  http://www.delgine.com/forum/viewtopic.php?t=4844

About TControlBar: The current version is made by Blaazen. I know it is not completed but I thought it is better than TPanel for its intended purpose.
What are the serious bugs? Could you please open a bug report. Maybe Blaazen or somebody else can look at it.

It is after all a Delphi compatible LCL component, part of the Lazarus base installation. It should work as well as possible.

[Blaazen]

Ad TControlBar: IIRC there were reported some bugs (in Windows) but I was never able to reproduce them on Linux+Qt or Linux+Wine. So it would be better if somene with real Windows could look on it.
BTW, currently there are no opened TControlBar issues on bugtracker now. Reporting bugs is the good beginning... 

[ChrisR]

This sounds very promising. I will be happy to help tune this once you think it is ready for others input.

[Akira1364]

Regarding TControlBar, I am in fact using Windows, so I'm likely experiencing some form of whatever those previously reported Windows bugs were. I'll try to narrow down  exactly what's going wrong in such a way that I can describe it accurately in a proper bug report.

Now, as far as a little progress update:
I spent pretty much the whole day today converting all of the "List" code over to use generics. TDeledObjectList is now defined as:

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

1. TDeledObjectList<T> = class(TFPGObjectList<T>)

Which allowed me to descend the various other list classes from it (to use TPrimitiveList as an example) like:

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

1. TPrimitiveList = class(TDeledObjectList<TBasePrimitive>)

Which in turn allowed me to remove a LOT of repetitive re-implementations of general list functions like Assign, Delete, e.t.c, and also to remove the large amounts of manual typecasting that was going on everywhere (since the Items property of each list is now viewed as the exact class it should be, not just TObject).

[JuhaManninen]

I spent pretty much the whole day today converting all of the "List" code over to use generics.

Yes, generics lists are a good idea.
You should however commit your chances into a revision control system ASAP, preferably to the DeleD SVN branch.
Committing all your changes as one big chunk makes it difficult to follow what has happened and to track potential problems.
Lots of small commits with proper descriptions are a good thing.
Do you have the changes in a local Git or Mercurial repo?

[JuhaManninen]

Ping Akira1364.
We have not heard of you in this forum nor in DeleD forum for few days.
If you need help with revision control systems, please ask.

[Akira1364]

Sorry, I've been busy both with my actual job (which unfortunately at no point includes working on Deled) and also, paradoxically, working on Deled! Apart from further genericization of the applications base classes and list-types, other noteworthy news is:

-I've dropped all use of Graphics32 in the application in favor of BGRABitmap (which as it stands today is just a much, much better library with significantly more useful/relevant functions). Graphics32 was great in the mid 2000s but in my opinion has fallen noticeably behind the competition in recent years.

-In conjuction with the above, I've massively simplified the "unit_TexureLoader" unit. Previously the application would load an image "from file", save it to a stream, re-load the stream in another function, go through a lengthy "data reading" process depending on the original image file type (complete with SetDIBits and all that fun stuff that's largely avoidable these days), and then finally pass the resulting "TTextureData" record to yet another function that actually loaded the image into OpenGL. BGRABitmap has allowed me to reduce the whole process to one function that looks like this:

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

1. function TOpenGLTextureLoader.LoadTextureIntoOpenGL(const AFileName: string): GLuint;
2. var
3.   Texture: GLuint;
4.   MaxAnisotropy: GLFloat;
5.   ABitmap: TBGRABitmap;
6. begin
7.   ABitmap := TBGRABitmap.Create;
8.   ABitmap.LoadFromFileUTF8(AFileName);
9.   ABitmap.VerticalFlip;
10.   glGenTextures(1, @Texture);
11.   glBindTexture(GL_TEXTURE_2D, Texture);
12.   glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
13.   glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
14.   glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
15.   glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);
16.   glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_LOD, 0.0);
17.   glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAX_LOD, 0.0);
18.   glGetFloatv(GL_MAX_TEXTURE_MAX_ANISOTROPY_EXT, @MaxAnisotropy);
19.   glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAX_ANISOTROPY_EXT, MaxAnisotropy);
20.   glTexParameteri(GL_TEXTURE_2D, GL_GENERATE_MIPMAP, GL_TRUE);
21.   glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, ABitmap.Width, ABitmap.Height, 0,
22.     GL_BGRA, GL_UNSIGNED_BYTE, ABitmap.Data);
23.   Result := Texture;
24.   ABitmap.Free;
25. end;

Now regarding uploading the codebase... I think I need a bit more time, both to clean up the various placeholders/test functions I've left "lying around" everywhere, and also to ensure that I've properly structured the project files so there won't be any issues loading them on computers that aren't mine. I understand what you were saying about uploading everything at once having the potential to cause issues, but honestly at this point I've deviated enough from the original code that I'm not sure it's going to matter either way.

[JuhaManninen]

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

1.   ABitmap.LoadFromFileUTF8(AFileName);

The UTF8 specific functions are not needed any more in LCL. The normal Delphi compatible functions can be used.
I am not sure what functions TBGRABitmap provides. Must check later ...

Now regarding uploading the codebase... I think I need a bit more time, both to clean up the various placeholders/test functions I've left "lying around" everywhere, and also to ensure that I've properly structured the project files so there won't be any issues loading them on computers that aren't mine. I understand what you were saying about uploading everything at once having the potential to cause issues, but honestly at this point I've deviated enough from the original code that I'm not sure it's going to matter either way.

Yes it matters. Good revision history is amazingly important. It helps other people see what is changed and how it is changed.
DeleD developers may be interested in your development, too. Maybe the code will be ported back again to Delphi later, who knows.
I believe all your changes are good but I would love to see separate commits for:
- Use generics containers
- SendMessage -> LCL events
- Fix save-to-image-file
- Fix TList-related crashes
- Added an anti-aliasing level control
- Graphics32 -> BGRABitmap
- Simplify unit_TexureLoader

You even wrote:
  -Other misc stuff that i'll detail more later.
Commit history would be the best place to detail them.
If anyhow possible, could you now please commit your changes to a local Git repo. "Git gui" lets you selects the changes that go to a single commit. You could still split it nicely into meaningful smallish commits and then write nice commit descriptions.
If that is not possible then at least commit your existing changes as one chunk and later continue with small pointed commits, either to DeleD SVN branch or somewhere else.

Please revert the TControlBar -> TPanel change. Let's fix TControlBar instead.
Reverting is easy by not committing those changes to Git, or committing them and later deleting the commit. Git lets you edit the commit history. Reordering, deleting and joining small commits is easy, splitting existing big commits is more difficult. Hence: always do many small commits.

I appreciate your work with this DeleD port. However I have learned how important a detailed commit history is for a big SW project which is studied and modified by many people.
Please look at the commit history of DeleD trunk. It has only 131 commits since they imported to SVN but those commits are well though. From their descriptions you know what they do.

Kind regards,
Juha

[aradeonas]

If I were you I used:

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

1. ABitmap := TBGRABitmap.Create(AFileName);

[Akira1364]

@Aradeonas:

Yeah, I realized the redundancy of those two first lines a few minutes after posting them. I've spent so much time working with libraries that don't have handy "create-from-type" capabilities that it just didn't occur to me to write it like that at first.

[marcov]

What is the verticalflip good for? bottom-up vs top-down can be compensated in the draw commands, doesn't need slow in memory inverting?

I have some simple texture loading objects in the code linked from this article

[Thaddy]

this article

That link is never going to work. Can you correct it Marco? Oh well, That article?

[Akira1364]

What is the verticalflip good for? bottom-up vs top-down can be compensated in the draw commands, doesn't need slow in memory inverting?

I have some simple texture loading objects in the code linked from this article

Without it the textures are displayed upside-down and mirrored. I figured it was better to do the compensation exactly once per image, within the temporary TBGRABitmap instance, before sending it to OpenGL.

[marcov]

Without it the textures are displayed upside-down and mirrored. I figured it was better to do the compensation exactly once per image, within the temporary TBGRABitmap instance, before sending it to OpenGL.

Upside down yes, because the opengl coordinate system puts 0,0 in the bottom left corner, and positive Y is up. But you have total control over the coordinate system in opengl, and this can be fixed using glortho or by having own mat4 types for coordinate transformation, and then it is a zero-time operation.

The linked example does this.