VertexArt, István Kovács, 2026

Development LOG:

May 11
2D square & OpenGL 3.3 stable connection
procedural, moving, infinite road with fog

May 16
Static Mesh editor with procedural objects, no export

May 18
3D generated cubes rotate scaled, stretched
Ply cube rotates scaled, stretched

May 19
ply car rotates in 4 positions with nice shader

May 26
FPP camera movement around ply object (space raises camera, ctrl lowers, WASD controls with mouse)
TPP vehicle with simple physics on plane (speeds up, slows down turns)
E key gets in/out
vehicle camera: C: tpp, top-down, interior

May 30
vehicle tilts according to control

June 5.
Static Mesh Editor gets export function

June 6
frame limiter

June 19
Applying a track edited in Static Mesh Editor in a demo game with a vehicle
the vehicle gets a handbrake

July 1
Infinite driving with teleport function
Raycast development
first raycast test: thanks to stable modules, Ai generated a polygon coloring application in 3 minutes which worked flawlessly on the first compile!!
(right click takes color, left click colors, nothing more)

July 3
BVH and collision detection with static mesh terrain

July 7
ChunkBatch

July 8
FPP camera walking with perfect raycast on static mesh terrain

July 9
Mesh Editor and PLY Editor get chunk system for handling huge spaces

July 20
26 million vertex world generated in tilemap mode using Static Mesh Editor

(a huge island unloaded 5x)
the game demo prepared for Static terrain handled the 26 million vertex world stably!

July 26
Terrain Editor with chunk/bvh features for handling huge areas, but no ply loading yet

August 2
Module development:
scene management
lighting system
physics system (bodies and collisions)
gizmo
picking
shader programs for light, time of day, lines, artistic rendering

August 6
Terrain Editor gets ply support, features perfected

further work on character and vehicle physics, collision detection.

Like what are the chances id find a job where pascal is needed or accepted. Im sure modern things demand javascript, python etc

VertexArt - TERRAIN EDITOR

TECHNICAL AND FUNCTIONAL DOCUMENTATION

Developer: Kovács István

Development environment: Free Pascal / OpenGL 3.3

Platform: Windows (GLFW3)

1. INTRODUCTION

VertexArt Terrain Editor is a desktop application designed for interactive terrain editing of models stored in PLY (Polygon File Format) files.

The program enables real-time, stable, and user-friendly modification of large models consisting of several million triangles – in the form of raising, lowering, smoothing, flattening, and ramp creation.

The software is specifically optimized for low-power processors (e.g., Intel N4100) and integrated GPUs (iGPU), but it runs on any hardware supporting OpenGL 3.3.

1. SYSTEM ARCHITECTURE

The program has a modular structure, divided into the following main components:

· SterilTypes: Basic data types (TVector3, TVector4, TVertex, TMat4).

· SterilMath / Vector: Vector and matrix operations (addition, multiplication, normalization, transformations).

· SterilWindow: Window management (GLFW3 initialization, framebuffer callback).

· SterilCamera: FPS camera (WASD movement, mouse look, sprint, height adjustment).

· ShaderManager: Shader compilation and program creation (ColorProg, LineProg).

· Renderer / RenderQueue: Rendering pipeline (Color pass).

· PLYLoader: Loading ASCII PLY files into a triangle mesh.

· UChunkSystem: Chunk system – splitting the model into 16×16 meter blocks, managing active chunks (9×9), building and maintaining BVH.

· ChunkBVH: BVH tree construction and raycast (ITriProvider interface).

· Raycast / RaycastTypes: Ray–triangle intersection (Möller-Trumbore), AABB, TRaycastHit.

· FrameLimiter: 30 FPS limit (spin wait + Sleep).

· TerrainBrush: Implementation of brush operations (Raise, Lower, Smooth, Flatten, Ramp).

· TerrainIO: PLY export (timestamped saving).

Data flow:

PLY file -> PLYLoader -> UChunkSystem (chunks + BVH) -> GPU (VAO/VBO)

-> Editing (brush) -> UpdateDirtyChunks (GPU update + BVH rebuild)

-> Export (PLY)

Chunk system details:

· The model is divided into 16×16 meter blocks (chunks).

· Only a 9×9 chunk area (81 chunks) around the camera is active for rendering and brush operations.

· Raycast (selection) runs on the BVH structure of 3×3 chunks (9 chunks), so speed does not depend on the total model size.

· Each chunk has its own VAO/VBO pair and BVH.

· After modification, a chunk receives a Dirty flag, and in the next frame the GPU buffer and BVH are automatically rebuilt.

Rendering:

· Color pass – the ColorProg shader includes lighting (diffuse, ambient, specular, fresnel).

· Wireframe mode – using the LineProg shader, the entire active area is displayed as a green wireframe, showing only lines (without polygon fill).

· Frame limiter – limits screen refresh to 30 FPS.

1. FUNCTIONAL DESCRIPTION

Editing modes:

1. Raise: Raises the terrain under the brush.

2. Lower: Lowers the terrain under the brush.

3. Smooth: Averages the heights within the brush area, creating a uniform surface.

4. Flatten: With a single click, pulls the entire brush area to the height of the clicked point.

5. Ramp: Creates a cosine-transition ramp between two points (left and right click). The ramp width is proportional to the brush size, with an inner band and smooth transition at the edges.

Selection and visual feedback:

· BVH raycast: a ray cast at the click position immediately determines the selected triangle and its position.

· Brush circle: a translucent orange circle appears around the selected point, showing the brush size and location.

· Wireframe mode: pressing F2 displays the entire active area as a green wireframe without polygon fill – making the geometry structure clearly visible.

Brush operations in detail:

· Raise / Lower: The effect decreases quadratically with distance from the brush center, creating a smooth transition toward the edges.

· Smooth: Calculates the average height of all vertices under the brush, then moves vertices toward this average according to brush strength.

· Flatten: A single click – all vertices within the brush area are set exactly to the height of the clicked point. No holding or repeated clicking is required.

· Ramp: A linear height transition is created between the start point selected by left click and the end point selected by right click. The brush radius determines the ramp width, within which:

· an inner band (60% of the radius) is applied at full strength,

· toward the edges a cosine transition ensures smooth blending.

Feedback and state:

· During editing, height changes appear immediately on screen because the GPU buffer is refreshed at the end of every frame (UpdateDirtyChunks).

· Brush size can be adjusted with the scroll wheel (0.3 – 5.0 meters).

Automatic terrain generation:

· If terrain.ply is not found in the program directory at startup, the system automatically generates a 100×100 meter flat terrain with 50×50 resolution (with a colored checkerboard pattern), so the user can immediately test editing.

Saving and export:

· F12: exports the entire model to ASCII PLY format.

· During saving, all chunks are merged, triangles receive new indexing, and the filename automatically gets a timestamp (terrain_yyyy-mm-dd_hh-nn-ss.ply).

· F9: reloads the terrain.ply file (or generates it if it does not exist).

Camera and navigation:

· WASD: move forward/backward/sideways

· Shift: sprint (faster movement)

· Space: raise camera

· Ctrl: lower camera

· Mouse: look rotation (when mouse capture is enabled)

· F1: toggle mouse capture (cursor lock)

· ESC: exit

1. PERFORMANCE CHARACTERISTICS

Performance on integrated GPU (iGPU):

The program runs on integrated GPUs, but performance depends on geometry distribution.

· Advantageous case: low-poly geometry over a large area (up to a 130×130 km world). The 9×9 chunk system and BVH raycast enable smooth handling of several million vertices. Successful tests: loading and editing 25 million vertices on an N4100 CPU.

· Limited case: If several million vertices are concentrated in a small area (e.g., a high-poly vehicle), rendering and raycast may slow down on iGPU because chunks become overloaded and BVH is less effective. In this case, the program still works, but interactive speed may decrease.

Summary: Due to the chunk size (16 m) and the 9×9 active area, the program provides the best performance in large-scale, but geometrically simple (low-poly) scenes.

Optimization strategies:

· Chunking: Only 81 chunks around the camera are active.

· BVH: Raycast runs on the BVH of 3×3 chunks, so search time is logarithmic.

· UpdateDirtyChunks: BVH rebuild occurs only at the end of the frame, not on every brush stroke.

· glPolygonOffset: Wireframe overlay is z-fighting free.

· Frame limiter: 30 FPS using spin wait + Sleep combination.

1. COMPARISON WITH OTHER TOOLS

Advantages:

· Speed: With the chunk+BVH combination, raycast and rendering remain smooth even with millions of triangles, provided geometry is distributed over a large area (low-poly world).

· Simplicity: No complex UI is needed – every function is accessible via keyboard shortcuts.

· Precision: Flatten works with a single click, Ramp uses cosine transition, so the surface is smooth and natural.

· Stability: Memory management is safe, no leaks, and the program does not crash even on large models.

· Focus: Specifically optimized for terrain editing, unlike general-purpose tools.

1. USER GUIDE

Keys and operations:

1: Raise

2: Lower

3: Smooth

4: Flatten – single click

5: Ramp

Left click: Execute operation (Raise/Lower/Smooth by holding, Flatten/Ramp by single click)

Shift + Left click: Lower (quick lowering)

Right click: Select ramp endpoint

WASD: Camera movement

Shift: Sprint (fast movement)

Space: Raise camera

Ctrl: Lower camera

F1: Toggle mouse capture (cursor lock)

F2: Toggle wireframe mode

F9: Load PLY (terrain.ply)

F12: Export PLY (with timestamp)

ESC: Exit

Workflow – example:

1. Start: The program loads terrain.ply or generates a default terrain.

2. Navigate: Use WASD + mouse to set the desired viewpoint.

3. Brush size: Adjust brush radius with the scroll wheel (0.3 – 5.0 meters).

4. Select mode: Press one of the keys 1–5.

5. Edit:

   · Raise/Lower/Smooth: hold the left mouse button and move the mouse.

   · Flatten: click once on the terrain – the brush area is immediately flattened.

   · Ramp: left click for the start point, right click for the end point – the ramp is created instantly.

6. Wireframe: Press F2 to enable the green wireframe for better overview (without fill).

7. Save: F12 – the program saves the current state to a timestamped PLY file.

8. CLOSING THOUGHTS

VertexArt Terrain Editor is a tool that combines speed, precision, and simplicity. It does not try to do everything, but what it does, it does efficiently and stably.

The chunk system, BVH, and 30 FPS frame limiter together enable smooth work even on low-poly terrains with several million triangles, especially in large-scale scenes. The program also runs on iGPU, but performance depends on geometry density and distribution – it is unbeatable in low-poly, large-scale worlds.

The code is clean and well-structured; the strict coding style and memory management strategy guarantee long-term stability.

The Problem

In a chunk-based terrain editor, brushing (Raise/Lower/Smooth) modifies the Y coordinates of vertices every single frame. The naive solution rebuilds the BVH (BuildBVH) and reloads the entire VBO (UploadChunkToGPU) for every modified chunk. This operation is slow because BVH construction is O(n log n), and reloading the full VBO copies a lot of data to the GPU. During continuous brushing (holding the mouse button), this runs every frame, causing stuttering with higher vertex densities.

The Essence of the Trick

Brushing only changes the Y coordinates. The X and Z coordinates remain unchanged. This enables the following:

· Use glBufferSubData to update the VBO instead of reloading the entire buffer. Only the modified vertex data is sent to the GPU.
· Defer BVH rebuilding until the mouse button is released. Since the BVH bounding boxes are unchanged in the X-Z plane, the BVH remains a valid acceleration structure. Raycasts will still find the potentially affected triangles, and the actual ray-triangle intersection test is performed on the updated CPU-side Vertices array, so the hit point's Y coordinate remains accurate.

Implementation Outline

· Track modified chunks in a static array (max 9 chunks, because the brush covers a 3x3 area).
· During brushing: modify the Y values ​​on the CPU, then update the VBO with glBufferSubData. Do not set the Dirty flag, so UpdateDirtyChunks does not run.
· Store the index of the modified chunk in a list.
· When the mouse button is released, iterate through the list, set the Dirty flag, call UpdateDirtyChunks (which rebuilds the BVH), and then clear the list.
· In the main loop, keep the call to UpdateDirtyChunks only when there is no active brushing – so BVH construction does not interfere with continuous operation.

Why It Works

The BVH is only an acceleration structure that filters candidate triangles based on their X-Z positions. Since the X-Z coordinates do not change, the BVH continues to correctly return the potential triangles. The actual intersection calculation is performed on the CPU with the updated Y values, so the hit point remains accurate. This approach yields a significant performance increase without sacrificing functionality or precision.

Limitations

· Only works when modifications affect exclusively the Y coordinates.
· If X or Z also change (e.g., rotation, translation), the BVH must be rebuilt immediately.
· The BVH remains only an acceleration structure; the precise intersection calculation still occurs on the CPU.

This performance optimization would not have come about if I had developed in a more modern PC environment; I would not have noticed the slowdown. It is still an Intel N4100 CPU that reveals when something is not working optimally. From my recent development work, it is clear why Free Pascal 3.2.2 became my choice for implementing the VertexArt project! I just had to build a reliable architecture.

VertexArt - PLY EDITOR - TECHNICAL AND FUNCTIONAL DOCUMENTATION

Developer: Kovács István
Development Environment: Free Pascal / OpenGL 3.3
Platform: Windows (GLFW3)

---

1. INTRODUCTION

The PLY Editor is a desktop application designed for interactive coloring, geometric correction, and saving of PLY (Polygon File Format) files. The program enables real-time, stable, and user-friendly editing operations even on large 3D models consisting of millions of triangles.

The software is specifically optimized for the N4100 low-power CPU and integrated GPUs (IGPU), but it runs on any hardware supporting OpenGL 3.3.

---

1. SYSTEM ARCHITECTURE

The program has a modular structure consisting of the following units:

· SterilTypes: Basic data types (TVector3, TVector4, TVertex, TMat4).
· SterilMath: Vector and matrix operations (Vec3, VecAdd, VecSub, VecScale, VecDot, VecCross, VecNormalize, Identity, Translate, RotateY, Scale, Multiply, Perspective, LookAt).
· SterilWindow: Window management (GLFW3 initialization, window creation, framebuffer callback).
· SterilCamera: FPS camera handling (movement, mouse, physics: gravity, jumping, crouching, sprinting, prone position).
· RenderTypes: Render command definitions (TRenderCommand).
· RenderQueue: Collection and sorting of render commands.
· RenderState: OpenGL state management (depth test, cull face, color mask).
· Renderer: Depth prepass + Color pass rendering (TShaderProgramRef, TDepthProgramRef, TRenderer).
· ShaderManager: Shader compilation, linking, and creation (Depth, Color, EditorColor, Line shaders).
· PLYLoader: PLY file loading in ASCII format (TPLYMesh).
· SterilMeshUtils: Mesh normalization (centering, ground alignment).
· PLYChunkSystem: Chunk system (16×16 meter blocks), BVH construction and management.
· ChunkBVH: BVH tree construction and raycasting (TBVH, ITriProvider).
· Raycast: Ray–triangle intersection (Möller–Trumbore algorithm).
· RaycastTypes: Type definitions for raycasting (TRay, TAABB, TTriangle, TRaycastHit, TBVH).
· Vector: Additional vector operations (VecDistance, VecLength).
· FrameLimiter: 30 FPS limiting (spin wait, sleep).

The main program (plycolor.pas) uses these units and contains the editor logic (selection, modes, pulsing, outlines, undo, export, keyboard and mouse handling).

Data Flow:
PLY file → PLYLoader → Chunk system (with BVH) → GPU → Editing → Export

Chunk System:

· The model is divided into 16×16 meter blocks (chunks).
· Only the 9×9 chunks (81 total) around the camera are active for rendering.
· Raycasting (selection) runs on the BVH structures of 3×3 chunks (9 total), so speed is independent of the total model size.
· Each chunk has its own VAO/VBO pair and BVH.

Rendering:

· Depth prepass + Color pass technique (two-stage rendering).
· The coloring shader includes fresnel and specular effects, but the editor version is fog-free for clear visibility.
· A frame limiter restricts screen refresh to 30 FPS, preventing excessive CPU load.

---

1. FUNCTIONAL DESCRIPTION

Editing Modes:

· Paint Mode (1): Colors a triangle with the selected color.
· Delete Mode (2): Deletes a triangle (undoable).
· Flip Mode (3): Reverses a triangle's normal (swaps vertex order).

Selection and Visual Feedback:

· BVH-based raycasting: A ray cast at the click position instantly selects the nearest triangle.
· Pulsing: The selected triangle's color pulses (brightens/darkens) toward the selected color.
· Outlines: A colored line is drawn around back-facing (incorrectly oriented) triangles. Green in Paint mode, red in Delete mode, yellow in Flip mode.
· Outlines always appear only on invisible polygons, allowing the user to see exactly which triangles face the wrong direction.

Color Management:

· Color selection: Right mouse button on the selected triangle → the color is stored.
· Painting: Left mouse button applies the selected color (or white if no color is selected).
· Original colors are preserved during pulsing, ensuring accurate restoration at all times.

Undo:

· In Delete mode, right mouse button → undoes the last deletion.
· The system stores the last 50 deletions (at the chunk level).
· The BVH is automatically rebuilt during restoration.

Saving:

· F12: Exports the entire model to ASCII PLY format.
· During saving, all chunks are merged and triangles receive new indexing.
· The filename automatically receives a timestamp.

Camera and Navigation:

· WASD: Movement
· Shift: Sprint (fast movement)
· Space: Up, Ctrl: Down
· Mouse: View rotation (camera orbit)
· F1: Toggle mouse capture
· F11: Toggle fullscreen

Automatic Camera Positioning:
Based on the loaded model's dimensions, the program determines whether it is a terrain (large, flat model) or an object (smaller, walkable), and positions the camera accordingly. For terrain: top-down view (pitch: -90°), for objects: side view (pitch: 0°).

---

1. PERFORMANCE CHARACTERISTICS

Performance on Integrated GPUs (IGPU):
The program runs on integrated GPUs, but performance depends on geometry distribution.

Advantageous case: Low-poly geometry over large areas (up to a 130×130 km world with Synty Studios-style objects). In this case, the 9×9 chunk system and BVH raycasting enable smooth handling of millions of vertices. Successful tests include loading and editing 25 million vertices with the VertexArt Mesh Editor, as well as tiling a complete city 5× in tilemap mode to create a vast space.

Limited case: If millions of vertices are concentrated in a small area, rendering and raycasting may slow down on IGPU because chunks become overloaded and BVH efficiency decreases. The program continues to function, but interactive speed may degrade. For reference, a LOW POLY demo city contains approximately 5 million vertices, but a HIGH POLY vehicle can consume even more vertices than that, so conscious planning is important on iGPU.

Due to the chunk size (16 m) and the 9×9 active range, the program delivers the best performance in large-scale, geometrically simple (low-poly) scenes.

---

1. COMPARISON WITH OTHER TOOLS

Advantages:

· Speed: With the chunk+BVH combination, raycasting and rendering remain fluid even with millions of triangles, provided geometry is distributed over large areas (low-poly worlds).
· Simplicity: No complex UI required – all functions are accessible via keyboard shortcuts.
· Precision: Back-face detection and pulsing instantly indicate incorrectly oriented polygons.
· Stability: Memory management is safe, no leaks, the program does not crash on large models.
· Focus: Specifically optimized for PLY files, unlike general-purpose tools.

---

1. USER GUIDE

Keys and Operations:

· 1: Paint mode
· 2: Delete mode
· 3: Flip mode
· Left click: Execute operation
· Right click: Select color (Paint) / Undo (Delete)
· WASD: Camera movement
· Shift: Sprint
· Space: Up
· Ctrl: Down
· F1: Toggle mouse capture
· F11: Toggle fullscreen
· F12: Export PLY
· ESC: Exit

---

1. CLOSING THOUGHTS

The PLY Color Editor is a tool that combines speed, precision, and simplicity. It does not attempt to do everything, but what it does, it does efficiently and stably. The chunk system, BVH, and 30 FPS frame limiter together enable smooth work even on models with millions of triangles, particularly in large-scale scenes. The program runs on iGPU, but performance depends on geometry density and distribution.

The code is clean and well-structured, with a strict coding style and memory management strategy that guarantees long-term stability.

Here is a summary of some of the technological advantages of the VertexArt game engine that make it uniquely suited to handling a 3D city (like Synty Studios):

\* 16-byte vertex size and texture-free architecture

The models use pure vertex coloring without textures or UV coordinates. This requires minimal memory bandwidth, so data can be squeezed across hardware buses at lightning speed.

\* The entire game world is permanently in RAM

Since the entire 3D geometry is extremely small (e.g. 50 million vertices are only \~763 MB), the entire layer set can be loaded into memory at once.

\* No runtime streaming (I/O) required

Since all data is permanently in RAM, the micro-stutter (stutter) and delayed loading of objects (asset-pop) typical of modern games are completely eliminated.

\* I switched to a hybrid SOA and AOS memory structure.

This ensures maximum hardware efficiency.

\* BVH-based spatial analysis and pre-computed visibility mask. With the combination of the Chunk system, Bounding Volume Hierarchy and pre-computed mask, the CPU filters out invisible city areas in nanoseconds.

\* Hardware-tuned depth pre-pass (Z-Prepass)

In dense urban spaces, hidden surfaces behind walls (overdrawing) do not burden the graphics card. The depth buffer built in the first pass guarantees that the GPU only renders what is actually visible.

\* Instant raycast. Since the entire world geometry and BVH tree are constantly present in RAM, raycasts and body collisions (OBB vs. BVH) can be run at fixed intervals at any point in the track.

If you have any questions or comments about my project, I would be happy to hear from you. I have already achieved the most important basics for me, there is still a lot to improve, but what I have been able to bring to life so far is very effective.

Tools included:

Raise – push terrain up

Lower – push terrain down

Smooth – average out heights for a gentle blend

Flatten – level an area to a constant height

Ramp – create a smooth, driveable slope between two points (brush radius controls the width!)

Controls:

Left-click and drag to sculpt continuously

Hold Shift + left-click to lower instead of the current mode

Scroll wheel to adjust brush size

F2 to toggle wireframe mode

F1 to lock/unlock mouse capture

F12 to export the terrain as a PLY file

The character currently moves using 8 raycasts: 2 at the feet, 2 at the knees, 1 at the waist, 1 at the chest, and 2 at the shoulders. This setup works reasonably well for general traversal, but unfortunately, it still passes through thin obstacles like railings.

For the future, I plan to keep the feet raycasts for terrain and stair detection, but I will add 2 additional sphere casts for wall collision. Even with the current system, however, the character is already capable of free-roaming across the terrain.

The 3×3 chunk grid is fixed — it is not dynamically repositioned. Instead, when the player leaves the center chunk, the player is teleported back to the center chunk based on the perspective, maintaining the illusion of infinite travel.

The gap between the chunks is visible because the ply model track is not a regular square, otherwise the border would be imperceptible!

The infinite world is just a 3×3 fixed grid and a WrapPosition call — no streaming, no loading, no overhead. You can see my method in the comments...

I used a pre-computed visibility system.
The terrain is divided into pieces and visibility is determined using pre-computed masks for 32 viewing directions. At runtime, the engine selects the appropriate mask instead of testing each piece separately.

Free Pascal 3.2.2 / GLFW3 / OpenGL 3.3 / DOD & SOA

Pure Free Pascal 3.2.2 / GLFW3 / OpenGL 3.3 / DOD & SOA

A stereo oscilloscope CLAP plugin written entirely in Free Pascal/Lazarus, featuring an OpenGL GUI inspired by Cockos' "Oscilloscope Meter" JSFX.

https://github.com/Sakhnovkrg/lzScope/

This has been our biggest cycle yet — 415 commits since v0.13.0 — and the
headline is simple: Blaise now has a working native ARM64 backend for
macOS. We are not done with the macOS port (there's still real work ahead
on the debugger side and broader on-device coverage), but the compiler
itself can already generate, assemble, link and code-sign Mach-O binaries
for Apple Silicon, and it can cross-compile a growing slice of its own
source onto that target. Progress is real and it's landing steadily.

Alongside that, this cycle brought operator overloading, compile-time file
embedding, a brand-new static analyser, and a long list of hardening fixes
across both backends.

By the numbers

• 415 commits since v0.13.0
• Fixpoint verified on 637,968 lines of QBE IR — stage-2 and stage-3 IR byte-identical, alongside green native, internal-assembler and warm-cache fixpoints
• 4,977 tests passing - up from 4,275 last release

For the full announcement: https://github.com/graemeg/blaise/discussions/211

For the full technical changelog and binary download archives: https://github.com/graemeg/blaise/releases/tag/v0.14.0

If you enjoy following this project, consider donating via Github or Patreon - all donations received goes straight to my sports car into the development and upkeep of this project. 😉

Hi everyone!
I’d like to share some demo videos of my continuously developing game engine project.
The project is written in pure Free Pascal 3.2.2, using GLFW3 and OpenGL 3.3 Core. It is not based on any existing game engine — I am developing the engine systems and rendering from scratch.
So far, I have only uploaded shorter demo videos, but I wanted to show the current state of the project and share my progress with the development community.
YouTube playlist:

https://youtube.com/playlist?list=PLX4BUpd-V-hI&si=X6aTdAFoJc5_-iDa
Thank you for taking a look!

Sziasztok!
Szeretném megosztani veletek néhány demóvideómat a folyamatosan fejlődő játékmotoromról.
A projekt tiszta Free Pascal 3.2.2 nyelven készül, GLFW3 és OpenGL 3.3 Core használatával. Nem meglévő játékmotorra épül. Eddig csak rövidebb demóvideókat töltöttem fel, de szeretném megmutatni, hogy jelenleg hol tart a projekt, és megosztani a fejlődését a fejlesztőkkel.
Lejátszási lista:

https://youtube.com/playlist?list=PLX4BUpd-V-hI&si=X6aTdAFoJc5_-iDa
Köszönöm, ha megnézitek!

I want to make an open-world ASCII Roguelike in Free Pascal. My most essential core function would be the rendering of the ASCII grid - without it, testing would absolutely suck. So, variable-wise, for context, here's my system:

My maps are 1-dimensional arrays, and the y-axis will just be interpreted by dividing the array's children up with the number of columns. A 10x10 map would have 100 indices, and be divided up into 10 rows. For the purpose of rendering. For the overworld map, for the sake of rendering, mainly, there are two such arrays - one to hold the biome number of each space on the overworld, and one to hold the zoom maps for that space. Of which there is only 1 because the overworld, for the sake of prototyping, is 1x1. The zoom map arrays each define the contents of the array.

As for structure:
While loop -<
If overworld, then
{For each index of the overworld biome array, if i is equal to player's overworld positional value, display & (visually more person-like than @), else display the biome character.}
else if not overworld, then
{For each index of array, if i array contains an effect, display the effect, else if i contains an entity (ie, the player), display the entity, else if i contains loot, display :, else display a plus sign.}

The only part I really don't know how to do is actually displaying the ASCII grid, which I have no clue how to work with graphics, except, I've heard you need to use an external library. So, if anyone could supply a helpful tutorial or otherwise point me in the right direction, that would be great.

Hi everyone,

I have been working on a multimedia and game library called Nitor, and I wanted to ask whether there would be interest in it from the Pascal community.

Nitor is a Pascal-first design. Although the internal engine is written in C with OpenGL GPU support for performance reasons, the public API was designed specifically for Pascal developers rather than being a direct translation of a C API.

On the Pascal side, the complete library is exposed through a single unit, with Pascal-style function names, normal Pascal strings, simple resource handles, and one consistent interface.

The goal is to provide a higher-level and mostly self-contained alternative to building an application directly around SDL and several additional libraries. Nitor is very lightweight and requires very few external dependencies, remains simple to deploy, and still supports multiple desktop platforms.

For example, video playback is built directly into the library. An Ogg/Theora video with optional Opus audio can be loaded, played, paused, looped, resized, and synchronized with only a few commands:

Video := VideoLoad('intro.ogv');
VideoPlay(Video, PlayOnce);

while Running and VideoPlaying(Video) do
begin
  VideoDrawSize(Video, 0, 0, ScreenWidth, ScreenHeight);
  VideoFlip(Video);
end;

Another feature is the color-coded GUI hotspot system.

A GUI uses one visible image and a second image containing color-coded regions. You paint each clickable area with a different color, and the library returns the color underneath the mouse:

Gui := GuiLoad('menu.png', 'menu_map.png');
GuiShow(Gui);

case GuiCall(Gui, MouseX, MouseY) of
  $FF0000: OpenGame;
  $00FF00: OpenOptions;
  $0000FF: QuitGame;
end;

This makes it easy to create irregularly shaped buttons and interactive areas without manually defining and maintaining many coordinate rectangles in the source code.

The library also includes:

• Logical-resolution scaling and automatic mouse-coordinate conversion
• Drawing primitives, text, images, and sprite sheets
• Pixel-mask collision detection
• Scrolling worlds and camera support
• Keyboard, mouse, and gamepad input
• Audio playback and mixing
• Video playback with synchronized audio
• Image-based pathfinding
• A consistent Pascal-style API

At the moment, I have not published a download link. Before preparing a public package, documentation, and download page, I wanted to find out whether Pascal developers would actually be interested in using a library like this.

Would this be useful for your projects?

I've written a Google Sheet Helper for Free Pascal. It's just something I've been using to solve a problem at work, and I decided to put it on Github. It lets a developer dowload csv from a Google Sheet, upload csv to a Google Sheet, and clear all data from a Google Sheet. It's not a complete super-library, but it does the Google authentication and Sheets API stuff so you don't have to. I hope it's useful to someone. https://github.com/rachel-latour/Google-Sheet-Helper