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.

1169

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

[phibermon]

A few more screenies of the water/terrain :

117011711172

[laggyluk]

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

[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 (http://www.aseprite.org/assets/images/screenshot05.png).

[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).

[laggyluk]

When you release this engine you plan to make it commercial or open source or neither?

[phibermon]

Yes, Object Pascal. Only FreePascal supported atm, can't afford Delphi so haven't made any effort to retain compatiblity. I've used objfpc style operator overloading extensivley for example so support for any delphi old enough to lack that feature would require extensive changes right across the engine.

but newer versions should be fine, maybe a bit of different syntax here and there wrapped up in ifdefs and maybe a few fcl funcs to ifdef with some delphi funcs, should only take me a day or so (if I actually owned delphi).

The only part that's commercially viable is the cross platform GUI so if I get an offer that might go but it's unlikely.

the rest of it, engine etc will have a suitable open source license that allows for games written using it to be sold.

If any engine devs are thinking about merging projects/efforts; and it's clear that by doing so would produce a superior engine, then obviously that's a decision that should be tabled with shared stakes.

--

There's aspects of my engine that I might rip out and replace with 3rd party libs. For example my audio library is functional and working cross platform but audorra (might of spelt that wrong) is wrapped up / tested and ready to roll. So I might just wrap up audorra instead.

Same goes for the custom loaders I've written for some image formats, might replace them with proven image lib solutions/ eg my PNG loader only handles the very basics, it's not as good as BeroPNG and you may come across unsupported files etc (currently support tga,bmp,jpg,png,raw,quake1 images and DDS (but only on supported hardware, does NOT currently decompress dds in software. But since you're pretty much garunteed to have compressed texture support on GL3.x+ hardware, it doesn't matter. If it does then tell me and I'll extend it)

But no dynamic libs, only native compiled solutions. The only dynamic lib I've allowed so far (other than system stuff like OpenGL) is the Newton Physics Lib. I don't use SDL or anything like that. Everything from window creation to mouse/key input, sound, networking etc is done using the respective OS API's on each platform or via cross platform abstractions provided by free pascal.

I don't use GLScene but I've undoubtly copied or referenced some VectorGeometry.pas funcs here and there when dealing with more exotic mathematics so that's included (I'd just wrap up funcs into my naming convention but didn't want the added call overhead and don't use it directly as I prefer a different style/naming convention and have my own types for things like vectors/matricies with swizzle like properties that differ from GLScene types)

[phibermon]

Another screenshot, there's a lot more than meets the eye. The editors interface is driven with context menus and utils. The resource manager allows you to see what's used, loaded, view images etc and you can also browse resources per node. When it's finished it will let you calculate GPU/System memory usage so you're not cache thrashing on your minimum target hardware.

1173

Here's a bunch of actors on a basic planar surface, they have one objective (to wander). they they are using a steering algorithm to avoid one another and to also follow a path (which is not rendered, testing) here they have cube models which have also been defined as physics objects in newton. the output of the steering algorithms are processed to produce forces that get applied in newton to actually move the actor (so newton is in control and we're telling newton what we'd like the actor to do, and newton tries to do just that, but applies physics along the way) So they will colide, slide past each other etc as they're going on they're merry way if they are unable to avoid one another. They don't have to be cubes of course, for basic collision in a fallout style game the newton representation of your animatied character could be a cyllinder (you can define/tweak the collision mesh for actors etc)

1174

The collision geometry for the planar surface (near the camera or visible) is sampled from the planar region. If you had a terrain or BSP map, it'd be that data that would get sampled and sent to physics and the actors would then walk on the terrain, map etc. (Obviously if you have two regions that overlap, say a BSP map on a terrain, or some water and terrain, then the geometry from both region types is sampled, allowing physics to work seamlessly across region types (water region surface sampling for use with buoyant newton objects is something I'm working on atm)

Restraining newton to the minimum possible amount of geometry / objects is very tricky so there is some basic collision detection and region height sampling for simple or grow your own solutions you can use as well.

[Mirage]

Nice job, phibermon!
I guess it is the result of many man-months of hard work.
I hope you have more enough to finish this work.

BTW, is the GUI on the screenshots the one included in the engine?

[phibermon]

Nice job, phibermon!
I guess it is the result of many man-months of hard work.
I hope you have more enough to finish this work.

BTW, is the GUI on the screenshots the one included in the engine?

Thank you very much :) yes, the GUI is part of the framework which the engine sits inside but isn't required to compile the engine, only the engine tools. Parts are the result of a few years work in other disciplines - GUI, networking, audio engine etc but as a complete package with the intention of a game engine + toolset perhaps for the past two years. Although there have been many months where I worked on it every day full time due to a medical situation so that'd probably be another year or two working in my spare time. It was the only good thing that came out of that situation!

[paul_nicholls]

@phibermon (http://www.pascalgamedevelopment.com/member.php?1653-phibermon): That's awesome mate! Glad you are still working on this project :)

cheers,
Paul

[phibermon]

I wanted to add : Mirage - your Cast 2 game engine is, in my humble opinion; the best engine in terms of design and expandability currently available for pascal :) I'd of made efforts to join your engine if I didn't want the experience of developing a design.

I am in fact, utterly shocked that your engine isn't used a lot more!


--

Let me add there are some excellent 3D engines available for pascal and they all have their merits! my opinion is one based upon design qualities I favor and is by no means a reflection on capabilities or qualities of other engines - which each in turn has some notable aspect or quality that sets it apart from the rest.

Which is why I really believe that merging of some engine projects would be a fantastic idea, the skill set and engine capabilities across the board would easily equal that of the Ogre3D or Unity teams.

After my first release I'll be looking at some form of project to either drop modules of mine into Cast2 or Castle etc or to drop parts into mine, just something that can demonstrate viable ways of combining the engines available to us. Certainly I'd like to support importing and exporting of cast, castle etc scene definitions, properties into my WYSIWYG tool.

If I can't get mergers then I'll settle for some interoperability :)

--

Just think of all the great mergers and how awesome the resulting project was - ScummVM when it merged with the AGI/SCI interpreters, brilliant! the efforts of the WINE team and the ReactOS teams on the windows API, fantastic!

And all those other great examples that escape me for now ;)

[WILL]

I am in fact, utterly shocked that your engine isn't used a lot more!

I would second that. There are so many game engines and frameworks on PGD that it sort of feels like there are more projects of this type than actual game projects. I would love to see some projects based around some of these engines. Too much "proof of concept" and not enough "Look what we made!"

There also aren't as many updated being posted here about The Cast 2 engine either. At least none that I've seen since over a couple years ago. (hint hint!) If there is further development and/or usage the community would love to hear about it.

[phibermon]

UPDATE

I'm currently working with an artist friend of mine on a game using the engine and WYSIWYG game/scene editing tool, this will help to iron out work-flow (with input from the artist) and smoke out any show stopping bugs that may exist. As soon as this is done I'll be releasing the engine and tool in it's first form : pre-compiled frameworks for all target platforms along with the scene editing tool for OSX/Windows/Linux. All features of the engine will be available via the built in pascalscript scripting and exhaustive engine bindings.

This will allow anybody to create a game using every aspect of the engine which will work without modification on any target platform by including the created game files with the platform binaries.

It's a high level game engine, whilst it's possible to load maps/terrains/models and code the rest yourself - there are built in 'Actor' objects that make use of the internal path finding and steering algorithms along with a selection of general behaviours, all customizable through script hooks. So irrelevant of what you want to achieve or what skills you currently have, there's a path for everybody.

A few more technical details :

Supported file system drivers : Native OS directories, Quake1/2 PAK, ZIP/PK3/PK4, BSP(direct load of some internal contents) and internal .Juice format (file system can mount any type, progressive mount things like pak0,pak1 overriding filenodes etc. maps,images,materials etc that are loaded from inside driver trees use the mount point root to find the files, so easy mounting of game resources and hassle free paths)

Supported image formats : BMP, TGA, RAW, JPG, PNG, DDS (hardware supported), Quake1 Images, Quake2 WAL images.

Supported model formats : 3DS, OBJ, LWO, IQM/IQE, MDL, MD2, MD3, MD5 and the internal 'catch all' format.

Supported map formats : Quake 1 BSP + variations, Quake 2 BSP + variations, Quake 3 BSP + Variations, Doom3/Quake4 Maps.

No supported Terrain formats as such, but can create terrains using internal generator, load from heightmap, supports mega-sized terrains - grid chunks or otherwise and supports many combinations of normal maps, detail textures etc in fact anything that the amazing L3DT can produce. Textures can be from entire images or can be dependant on zone maps, elevation, slope angles etc Basically everything you need to match the quality of skyrim - should you have the time.

Extensive animation systems, switch between cameras, keyframe/path based tweening of any node type (cameras, models, particle systems etc) trigger scripts etc

configurable/scriptable Input control and layout, along with presets for First Person shooter style (eg quake) 3rd person track style (eg tomb raider) multi perspective mouse control (eg RTS games, Red alert, RPG games such as neverwinter knights etc), 2D side on (platformers) top down (chaos engine) all ties in with the actor system and physics, so with a few clicks you can be driving a car GTA style in a 3rd person tracking perspective, or controlling your mario rip off side on platformer style. 3D mouse driven styles provide scriptable callbacks for any user defined type of actor/entitiy etc as well as multi-select widgets for user use, so basically you can have the basics of an RTS like starcraft up and running without writing a single line of code.

Sound engine is basic, supports WAV/MP3/OGG, trigger samples, DFD streaming of samples/music etc

Networking code works great for LAN but needs more work to be suitable for internet use. Works at the messenger level inside the engine. A perfect example of it's capabilities is thus : The game editing tool (with a few bugs atm) supports network client/server mode allowing for multiple people to work on the same map/game placing objects, writing scripts etc while the engine handles synchronization of all properties. Perfect for creating huge GTA or Skyrim style worlds! a filter mechanism allows the same functionality to be used for gaming.

I'll post screenshots of the games development when it reaches a suitable stage

Johnny

[SilverWarior]

This sound verry interesting.
You say this is a High level game engine right. So I'm wondering if it is still posible to some low level programming?
For a few game ideas I have I would need to use Heuristic Pathfinding Algorithm which would be optimized for each game (in one game idea it will be directly integrated with AI so that it would also afect decision making). BTW which pathfinding algorithm have you implemented?

EDIT: Another question.
Does your engine alows procedural mesh generation. For instance can I proceduraly generate road mesh?

[phibermon]

The engine stores meshes in a low level class with full access to the data, if the mesh is cached to the hardware then changes made are updated in the hardware buffer in a more or less efficient manner. There are several helper functions for creating various primative types in meshes as well as tesselation functions which can be used to aid in direct mesh manipulation, if you were constructing small pieces you could construct the mesh before it's cached to the hardware for max efficiency. Any system for generating roads in a 3D environment would perform much better if your roads were constructed out of pre-calculated pieces but the performance is as good as you'd expect from the available solutions if you choose to construct your roads as one big mesh or pieces thereof.

GL calls must be made in the render thread so for realtime streaming of resources to GPU memory I have a system for buffering the data over many frames that's used by the various plugins that load maps, models etc I've not really thought about how this would function from script land, probably fine if I provide access to all the mesh helper functions that can be triggered in faster native code, but with the framework+engine sources it's trival.

[paul_nicholls]

Looking forward to screenshots and versions we can test :)

cheers,
Paul

[SilverWarior]

Any system for generating roads in a 3D environment would perform much better if your roads were constructed out of pre-calculated pieces but the performance is as good as you'd expect from the available solutions if you choose to construct your roads as one big mesh or pieces thereof.

Yes I know tha it is probably best to construct roads from "standardized" pieces as it alows grephical engine to simply make several copies of single mesh on different locations. This way you can greatly reduce the memory requirements to store the road mesh.
But for my idea I'll probably use combination of prebuild pieces and proceduraly generated pieces.


Anywhay I will give it a try when it gets out.

[AirPas]

hi Johnny , sounds interesting , seems will be the best pascal 3D engine ever .
few questions if you don't mind :)
1 - you did all things by your self (no team ?)
2 - dose your engine use directx api ?
3 - whats the minimum hardware requirement to play a game made by your engine ?


keep up the good work , hope to see a release soon .

[Mirage]

Sounds fantastic, phibermon! It's very close to what I wanted to achieve with CAST2.
The ability to create/edit all game content on the fly in WYSIWYG mode. As in "big" gamedev studios.
Looking forward for the release!

[phibermon]

hi Johnny , sounds interesting , seems will be the best pascal 3D engine ever .
few questions if you don't mind :)
1 - you did all things by your self (no team ?)
2 - dose your engine use directx api ?
3 - whats the minimum hardware requirement to play a game made by your engine ?


keep up the good work , hope to see a release soon .

1. I've written all of it by myself except for required dependencies (Pascalscript, DelphiGL GL Header, OpenAL, Ogg, ASIO, ALSA, Pasjpeg headers) and optional dependencies (Newton GD, Graphics32, clipper) but have learnt much from various projects and people over the years so can't claim it's a sole effort!

2. No DirectX, although if some solution is released that would allow me to target the XboxOne then I'd add it no problem. Supported 2D API's : Graphics32 (windows/linux) Quartz (OSX) supported 3D API's (OpenGLES2, OpenGL2, OpenGL3, OpenGL4)

3. That's a tricky question, I've got an Intel HD laptop (GL2) running 3 shadow casting lights (lower res shadow map) on a quake 2 BSP with 20 actors at over 100 potential frames per second, optimization is all I'll be doing after I finish the feature list, specifically focusing max speed on an android tablet I have access to. There's a lot of optimization that can yet be done! but the engine is geared towards a desktop hardware, I lack sufficient mobile devices to benchmark / optimize. I suspect there's much work to be done there.
--

Mirage - I would never of even started my engine if it wasn't for Cast2 :) the insperation for the project is this : What I thought GLScene should of been and as close to the basic structure, goals and quality of Cast2 as I could manage so it's a Cast2 tribute engine really :) I was hoping to support exporting of resources to Cast2 and possibly the Castle engine as well - I feel that the high level scriptable game style I expose to the user is for more inexperienced game devs and the more capable would simply use my tool to construct maps/worlds etc for use in more hardcore engines like Cast etc

To clarify, writing a game in my engine as intended is like writing a mod for grand theft auto or half-life etc there are fixed, abstracted gaming concepts that you bend to your will but it leaves you a little limited in what you can do IE some game structures might feel a bit hacky.

I've tried to accomodate all styles of game I've played (sadly I gave up on elite style universe, planet rendering etc maintaining useful abstractions in that context would of made the implementation of smaller scale games seem cumbersome, not to mention good performance of such engines is in a class of it's own! you really want to hard-code an engine like that, avoid a lot of the abstraction I've implemented)

[SilverWarior]

I've expanded the GUI to improve recursive containment and moved scrollbar functionality into the base element class. This lets you add windows inside windows inside windows inside windows etc

How do you handle rendering of this?
Do you use similar approach as FireMonkey where each window is its own texture which is then rendered onto its parent window? FireMonkey losses a lot of performance becouse of this.

[SilverWarior]

If you might have goten impression that I'm recomending/advertising FireMonkeys approach in any way I asure you that my intention was exactly oposite.
One of the reasons why I even started thinking about designing my Silver GUI library in a way so that it could also be used for normal applications and not just for simple ingame UI is great dissapointment about FM performance.

When I was planning design for my Silver GUI I have given it a lot of though about posible optimization. So I belive I have come out to verry good idea which should work great but I haven't got a chance to implement it yet fully.
The idea uses child/parent relations between different "components". These "components" can either be visual or nonvisual (group controls for other components). Any of the visual "components" can be chached (rendered to seperate texture so it can be easily reused in future). And I belive that best part is system for monitoring changes which provides you with information about which chached components need to be updated/rerendered to reflect latest changes.

Anywhay I'm thinking about sharing more information about my idea with you. It would be best if we could got a live chat sometime since I'm afraid that I won't be able to easily explain my idea to you othervise.

[phibermon]

Yeah sure that'd be great :) I've not had chance to discuss GUI design before and sounds like you're on the right track. Yes the system for tracking potential visual changes and updating buffers / rendering is essential if performance is one of your goals (it's known as 'region invalidation' in the GUI world)

There's so many different approaches, multi-threaded designs, message or chain based input etc and loads of interesting directions I've not gone in myself due to time constraints, so maybe between us we can form some ideas to make Silver GUI the definitive choice!

I'd happily switch my engine tools over to your GUI if it does what I need, the less I have to concentrate on the better plus it'd be a nice way to collaborate without stepping on each others toes, you'd get testing / bug reports / exposure for the GUI and I'd get more time to focus on my engine :)

[SilverWarior]

Fist of all I should probably remind you that Silver GUI is intended to be more like an addon library to be used with existing graphic engines (I think we talked a litle about this in the past) but I'm still designing it in a way that maybe I could integrate necessary OpenGL calls and make it a standalone graphical engine (not planned but I'm still leaving myself an option for this). So when talking about optimization I'm not talking about low level optiization but instead of high level optimization:
- eficient managing of "components" and their data
- ability to reuse certain data (buffered regions, multiple copies of same components, etc.)
- reduce the number of draw calls per scene as much as posible. This heavily depends on whether the final UI is designed in smart way (nonchangable or rarely changable parts chached to buffered textures so they can be easily reused)
- ability to use full multithreading suport. This will be hardest to achieve as you either need to use existing multithreading designs that developers use (might not be best for Silver GUI) or you integrate your own mutithreading system and alow developers to use it (might not suit developer needs).
Some other features I would like to implement:
- two different ways of texture positioning:
- absolute position (texture positon is defined as 6 pixels right from left edge)
- relative position (texture position is defined by position of parent "component" so you get ability to sort of synchronize texture positions of different "components" so they feel as being one)
- ability to have real nonrectangular controls
- posibility to us shaders to improve the look even further.

Currently my intention is to make it work with most graphical engines (you need suitable header made for each graphical engine).

What I need to do right now is make suitable class which will be able to store pointers to all "components" in a tree based maner and still alow me to acces each level of this tree as a seperate list. This is needed so I'm able to implement work distribution and therefore include multithreading support.

[phibermon]

Hi People,

Quick update, Jink now officially supports IOS and Android targets including multi-touch support. No doubt some tweaks needed here and there for Android as I only have a single device with which to test.

The framework is now complete and will be production ready at the end of the bug list. I only have to complete a clipmapping terrain implementation before all engine features are available for all targets as well.

I am committed to releasing the engine under an open license in the next few months, I hope the engine will serve you well.

Which will be my last act I'm afraid, I'm giving up my regular involvement with the community as from pretty much now :) It's been a great few years and I've gained a lot from PGD and the Pascal community as a whole hence why I'm giving my code back to you and all those that would use or learn from it.

JUI (the GUI) will *not* be released I'm afraid, my services are under negotiation with a certain well known company in a related context.

I wish you all good fortunes in all your Pascal game development endeavors, I hope you crush C++ into the dirt and FPC becomes the default compiler for the next generation of consoles :)

All the best everyone!

Johnny.

[paul_nicholls]

Sorry to hear that you are giving up with the community :(
I wish you well with your GUI, and look forward to trying out the Jink Framework :)

Best wishes,
Paul Nicholls

[de_jean_7777]

Which will be my last act I'm afraid, I'm giving up my regular involvement with the community as from pretty much now :) It's been a great few years and I've gained a lot from PGD and the Pascal community as a whole hence why I'm giving my code back to you and all those that would use or learn from it.


Sorry to hear this. Your efforts are appreciated though.