Next3D

[azrael11]

This is very interesting...

I hope you have a stable version soon with gui components and others.
Do you plan to target in three platforms win,linux,macosx ?
Do you plan to make vcl for this engine like glscene... ?

[User137]

This is very interesting...

I hope you have a stable version soon with gui components and others.

It is stable but much work to be done. I did buttons and panels first to test the tree-structure and that is all working perfectly even in editor. Changing properties, moving, resizing, deleting objects and sub-objects and rendering is all finished. What remains is saving/loading from files, rest of the UI components, font and texture tools.

Do you plan to target in three platforms win,linux,macosx ?

I code this in Win32 but none of my units uses Windows, so it should not be dependant on platform.

Do you plan to make vcl for this engine like glscene... ?

No. I don't actually know all what GLScene can do, when i tried it last it tended to crash my Delphi and i got rid of it. But this is a Lazarus project now which is not going to be compatible with Delphi without additional coding. Things like TRawImage only exist in freepascal.

[wodzu]

Looks like you put onto it a large amount of work User137. I have some questions if you don't mind about the TGLFont class.

How do you handle fonts? I mean do you use specific OS function to convert a given font into the texture \ bitmap and put it onto the display list?

Or do the user must manually prepare a texture font?

[User137]

I create a TBitmap and use canvas font function to draw it, that should work on different platforms. There is another function that converts TBitmap into OpenGL readable data format and then loads it in.
Edit: simply put i create a font-map, a single big texture containing alot of characters. No displaylists are involved.
I posted the function earlier at:

http://www.pascalgamedevelopment.com...50120#msg50120

But you can also see it in the full source. Programmer just has to decide what font size and texture size to use. They are stored in font specific class and renderer will adapt to the values. Canvas font system has the nice feature TextWidth() which lets you also save size of each character.

[wodzu]

Thanks, that is an ellegant solution

So you are relaying on the Lazarus crosplatform font functions.

[User137]

News from UIEditor again: http://i42.tinypic.com/11bnjvc.png
- Figured out file format and done saving and loading.
- Added Label and Edit components.
- Editor has now snapping option which was needed for more professional looks.
- Absolute and relative coordinates now working. By default components are created relative, which means that they scale with window size. Can be changed on_the_fly in editor.
Note: Even though loading and rendering will already work in game there are no mouse events yet.

Some minor changes in the engine itself which made me update demos slightly. I wanted to support DelphiX-like simplicity so i added SetColor function, making it now not necessary to include OpenGL header in simple 2D games at all. Pathfind unit has GetBetterPath function which looks path from "start to end" and "end to start" and returns path that was shorter. There is now a class TDisplayList, much code was changed due to this.

Updating first post with new links today...

[WILL]

Very nice. Would you be able to include the UI as a separate library later on? A full-blown RTS is out of my capabilities for game dev, but I have an other game which I'd love to have a nice GUI to handle my window/menu functions. Custom self-made menus being a must for it as it would have heavy use of menus and status screens.

Oh and what effect would Delphi Mode set in Lazarus have on compiling these units with my existing projects?

[User137]

The UI is sort of standalone. Only thing that atm ties it to nxGL is automatic resizing (this happens only in TUIPanel.Draw()). It is possible to make a function do that manually by values, but it's very fast to check window sizes from nxGL itself.
And another thing is textures and fonts. Neither of these propably need the engine, but depend on the base units.

All i'm saying, OpenGL is almost same no matter how you create window, with minor changes you would be able to integrate whole Next3D in your current engine. It is overall light package. If i was to detach UI separately aswell they wouldn't necessarily stay updated same way and it would conflict with the structure of Next3D...

Menus did cross my mind and they are possible to make. So far i have skipped them though, being not so much needed feature and a bit complex thing to do. After making dropdown-list it may become more clear how to do it, they are similar.

The units seem to have their own modes set at beginning so your project wouldn't effect them. nxGL uses objfpc at the moment, which if changed to delphi seems to (at least) enrage about procedure pointers done differently ^^ (i have later become to like delphi mode more though, old relics these things...)

Edit: About menus i might add that, as seen in the screenshot the normal Lazarus menus work well with it. Popup menus won't have issues either. Still i may add them later for they can be more graphical.

[Vinzvega]

User137 : This is very impressive ! The rts shown on youtube was made with this lib ?
Very speed !

[User137]

I'm spending way too much time playing games

Anyway, UI Editor had its file format still rewritten cause i wanted it to be more dynamic. More properties can be added later with old files still be readable without any changes to the engine.

But important change to Next3D today when i was updating my Ubuntu linux system; all demos compiled and run perfectly! Exception to Networktest which throws access violation and crash on Server.Connect. Pre-compiled .exe runs fine with wine though but OpenGL is slower like that.

nr.2 on important changes is Delphi support. I added alot of IFDEF's here and there so same units now run in Delphi, Lazarus both in Windows and Linux. I made Delphi versions of all 4 demos and they are working, including synapse network (well minor glitch with 1 server thread staying open...).

At this point there are some plans for multipurpose particle engine. Challenge is to make it use only as much memory as particle type needs, i think the solution needs multiple records or sub-classes. Still little bit unsure if class object would be fast enough.

Files updated cause it's first version that supports Delphi too.