Jink framework and game engine

[phibermon]

Hi All,

As some of you know I've been working very hard for the past few years on my cross platform GUI and game engine. I've had to change the name a few times due to conflicts with other projects but the final name is "Jink"

The GUI and 2D parts of the framework (intended for both application and game interface use) can currently render using the following :

OpenGL 2.x / 3.x / 4.x
Graphics32 (Win,Linux)
Quartz (OSX)
(I also have a VESA version compiled under GO32 but that's just for fun)

It's a full region invalidating GUI but can also work in a double buffered manner with per window RTs.

The 3D game engine requires a minimum of OpenGL 3.0 but to use all the features you need GL4.x.

I will give a full list of capabilities soon, I may decide to remove unfinished parts for the first version in order to get it released at some point this decade

But just to give you an idea, it's equivilent to GLScene in feature set, exceeds it in many ways and utilizes some of the very latest features on GPUs in it's various modules. It's 3D model support and animation capabilities are very advanced.

It would go a lot quicker if one of you other snazzy engine devs would merge projects with me so we can finally have a reference engine to raise bar to that of our C++ rivals

It's my hope that people will either use it to create cross platform apps/games or use it as a reference to bring their own engines out of the GL 2.x dark ages.

Here's a screenie to whet your appetite - a Quake 1 map with an active particle system, and a GL4.0 tesselated terrain engine with fresnel water simulation, it's basically a port of the Nvidia Islands DX11 demo to GL4 but I've abstracted it into my 'region' concept so it can be used in a game (you can have multiple regions, nested if you desire, so you could for example walk from a BSP map out onto the terrain.. well if there were some doors. Portal rendering optimizations from BSP -> terrain/voxel/planet etc are in place but requires more development) I shall be releasing before autumn hopefully.

LatestScreen3.jpg

(apologies for the poor compression ratio, having problems uploading larger files)

[phibermon]

A few more screenies of the water/terrain :

JinkScreen1.jpgJinkScreen2.jpgJinkScreen3.jpg

[laggyluk]

Good work, I like the water. Hope to see a release

[Cybermonkey]

Wow, this looks awesome. I hope I can try it soon ...

[pstudio]

Looks interesting though your screen shots are too small to get a proper view of your engine.
Does the first image showcase a variety of tools/inspectors included in your engine?

[Darkhog]

Hm, I see you have some Unity-like map editor. Is that true? Also what with performance, is that good?

Anyway IMO you should consider changing name once more - "Jink" is far too close to "Junk" and while it seems to be great engine, this makes me feel not so good.

Anyway I'll give it a spin once its released. If it would provide functional equivalent to Unity Pro (mainly render to texture and dynamic reflections/shadows) for free it'd be great. Hopefully you'd start some sort of open source foundation - we really lack engine which is as capable and as easy to use like Unity is.

//edit: Also you could try to make GUI part of your engine talk to Allegro.pas, maybe some wrapper unit. Algui shows its age and is really ugly. And there is little you can do without developing your own widget library as it doesn't offer any reskinning abilities whatsoever and all apps using al_gui ends up looking like... like... like THIS.

[phibermon]

The rendering portions of the gui allow you to create a plugin fairly easily, you just need to be able to draw lines, rectangles of any size/colour and have some form of bitblit operation (preferably with transparency support) for icons/fonts (or in the case of GL, textures are uploaded to graphics memory)

You can create a plugin for font rendering, wrapping up any font functionality provided by Allegro - assuming that you can query the graphical dimensions of a given output string.

The internal font rendering uses bitmap fonts for easy OpenGL rendering, but adding vector font support such as truetype should be fairly trivial providing you can either render the vector geometry (so polygons) on your target (Allegro) or can otherwise access the pixels of some rasterised output for blitting to the display or window render target. There's no reason you can't have a render target for every single widget if you so desire, it's only a flag that gets turned off past the window level in the TJUIElement tree hierachy and the rendering / invaldiating etc will use it accordingly.

I might change the name anyway, I suppose they're more like milestones atm


Edit : It's not a map editor no, but perhaps one day. At the moment I have one tesselated terrain technique for rendering tiled datasets (outputs from various terrain generators) and what you see in the screenshots is a procedurally generated terrain as implemented from the nividia islands DX11 demo source, it has many paramaters and great scope for customization. as it outputs textures ready for rendering that define the height, texture used etc then creating an editor will be trivial, the engine provides all of the screen mouse -> world space position calculations required and then it's only a case of modifying the texture data at the retranslated coordinates, shift values up/down with a customizable linear/quadratic falloff from the mouse position for a smooth terrain raise/lower tool, whatever etc

[Darkhog]

Hm, too bad. We really need some true open alternative to Unity. JMonkeyEngine is getting there but still doesn't have map editor. Also, JME is in Java.

[phibermon]

it's nowhere near unity don't have the people power, even projects like Ogre3D struggle to keep up with the features that the commercial might of unity can offer. For terrain editing / creation there exists a number of tools, some free and others available for purchase that are great for the task. It would be nice to have some ability to tweak terrains within the scene editor so when I'm happy with the core and I've nailed down the exposed scripting API, I'll focus on padding out the scene editor into a viable tool for constructing levels / defining the world for game code to utilize. All the essentials are there - it's more a case of UI and application development to allow control / tweaking the aspects of the engine / scene. Something which will progress very rapidly given during the course of GUI development I created all manner of layouts / tools / snippets with this goal in mind.

Oh just in case anybody has misunderstood, it is a map editor in the sence that you can define a terrain, or load a BSP map etc and place models, actors, particle systems etc around the world and save / load that constructed world. it's all as you'd expect, spatial partitioning schemes, culled rendering etc all the trimmings. With a landscape, actor entities and the scripting functionality you could create an RPG along the lines of Fallout quite easily. it's less suited to BSP style first person shooters but that's always improving. It's tricky to get the right abstactions and structure to the engine to allow collision detection, path finding and so on to work across different region types in a suitably optimized fasion. Yes it would of been a lot easier to allow only one region type at a time. Region types currently include terrain, water, map (bsp), voxel (minecraft etc) and a basic planar surface. There is basic voxel world generation / editing. Also allows for a single layer of 'voxels' so you can create games like dungeon keeper. That region could exist alongside a terrain, so you could do something like evil genius.

The basic idea of the engine is to offer high level abstractions such as the Actor object that handle animation, script execution etc in a customizable way. you can define the camera in the world etc. keyboard/mouse input into the actors/camera/cursor, etc where all the entities have various things such as collision detection, path finding available in a generic manner that works transparently with whatever region(s) that entity happens to be within.

Then when it's set up how you like, a game client simply inits the engine and loads the scene. You can control or trigger things from your game code or do things in scripts tied to generic functionality, or both of course.

[Darkhog]

Cool! And assume its being on this site means it is Pascal engine?

Anyway, check this Quake map editor and maybe you could base map editing on it: http://kristianduske.com/trenchbroom/. It's IMO the only good quake editor out there (Radiant and its variants SUCKS).