My AmigaOs4.1 projects

@Maijestro
Quote:newlib is using dlmalloc.

@afxgroup

Quote:

Runs on Amiga: clib4.library V2.1
clib4 SDK in the container: August 16–18, 2025

Should this be up to date, or not?

@joerg

Quote:

That explains why the Memory leak issue didn't occur there. Thanks for the info. Maybe this feature should be added to Clib4 as well.

The AI only came up with this because the Atari version of ScummVM handles it the same way. So she incorporated it directly into the build to solve the problem with Clib4, and I'm really glad she found such an elegant solution.

@Maijestro

Good job, any eventual fixes should be posted in the official GitHub repository

@Maijestro

Can you try the latest development branch?

small update:

# Overview

This document describes the changes made to the ScummVM GUI for AmigaOS4,
implemented between March 17–18, 2026. The goal was to provide the user with
a working 3D renderer selection in the ScummVM settings dialog.
## Problem: The Chicken-and-Egg Problem

### Initial Situation

ScummVM determines the available 3D renderer options at runtime via
`getAvailableTypes()`. This function only reports what was successfully
initialized at startup.

On AmigaOS4, `opengl_implementation=software` was the default value on
first launch. This meant:

1. ScummVM starts with the software renderer (TinyGL)
2. MiniGL/OGLES2 is **not** loaded
3. `getAvailableTypes()` only reports `TinyGL`
4. The `Game 3D Renderer` dropdown only shows `Software (TinyGL)`
5. The user **cannot select** `OpenGL` or `OpenGL with Shaders`
6. Without a selection the default remains — step 1 repeats itself

## Key Mapping: opengl_implementation ↔ renderer

Both keys must always be consistent:

| `opengl_implementation` | `renderer` | GUI Display | Meaning |
|------------------------|-----------|-------------|---------|
| `software` | `software` | Software (TinyGL) | TinyGL, no GL required |
| `gl` | `opengl` | OpenGL (MiniGL) | MiniGL / Warp3D Nova |
| `gles2` | `opengl_shaders` | OpenGL with Shaders (OGLES2) | OGLES2 / Warp3D Nova |

---

## Test Results

| Mode Selected | `renderer` in .ini | `opengl_implementation` in .ini | GUI Correct | Game Runs |
|---------------|--------------------|---------------------------------|-------------|-----------|
| Software (TinyGL) | `software` | `software` | ✅ | ✅ |
| OpenGL (MiniGL) | `opengl` | `gl` | ✅ | ✅ Alpha Polaris |
| OpenGL with Shaders (OGLES2) | `opengl_shaders` | `gles2` | ✅ | ✅ Alpha Polaris |








Next, I’d like to check out “Syberia 1” and “Syberia 2.” However, there’s a problem here: the game isn’t rendered via OpenGL, so it falls back on TinyGL (software), which is terribly slow.

## Summary

Syberia 1 (Macintosh version) starts correctly with the OGLES2 renderer on
AmigaOS4 (Warp3D Nova). The engine runs, audio plays, mouse events are
registered — but the screen remains completely black. TinyGL works correctly
and shows the full title screen and main menu.

## Key Discovery: AmigaOS4 Always Delivers GLES2

AmigaOS4 SDL **always** provides a Warp3D Nova GLES2 context, regardless of
what is requested via SDL attributes:

```
opengl_implementation=gl → SDL_GL_CONTEXT_PROFILE_MASK=0, MAJOR=1, MINOR=3
→ but SDL delivers: OpenGL ES 2.0 (Warp3D Nova 54.16)
```

This means MiniGL is effectively unused. All OpenGL rendering on AmigaOS4 goes
through Warp3D Nova GLES2.

**Log evidence:**
```
OpenGL: GLES2 context initialized
OpenGL version: OpenGL ES 2.0 3.3 on top of Warp3D Nova 54.16
OpenGL vendor: A-EON Technology Ltd. Written by Daniel 'Daytona675x' Müßener
OpenGL renderer: Warp3D Nova 54.16
OpenGL: GLSL version string: OpenGL ES GLSL ES 1.4
OpenGL: Shader support: 1

## What Works vs. What Doesn't

| Feature | TinyGL | OGLES2 |
|---------|--------|--------|
| Engine starts | ✅ | ✅ |
| Splash screens (Microids, Koalabs) | ✅ | ✅ (loaded, not visible) |
| Audio (music4.ogg) | ✅ | ✅ |
| Mouse events | ✅ | ✅ |
| Title screen visible | ✅ | ❌ black screen |
| Menu buttons visible | ✅ | ❌ black screen |
| Background video (menu.ogv) | ✅ | ❌ black screen |



## Next Steps (to be done on next session)

### Step 1: Deploy the current plugin
The plugin with the shader check is built and stripped, waiting for deploy:
```bash
# Mac Terminal
docker cp 56c5b59da1ea:/opt/code/scummvm/plugins/tetraedge.plugin \
/Volumes/Daten/Sharing/NeuerCode/ScummVM_AmigaOS4/plugins/tetraedge.plugin
```

### Step 2: Check RAM:scummvm.log for shader status
Start Syberia and check `RAM:scummvm.log` for one of:
- `TeMeshGLES2: Shader compiled successfully` → shader OK, problem elsewhere
- `TeMeshGLES2: Failed to compile/link tetraedge shader!` → shader problem on Warp3D Nova

### Step 3a: If shader fails
- Check if `OpenGL::Shader::fromStrings()` has issues with GLSL ES 1.4 on Warp3D Nova
- Try removing the `#version` directive or adjusting precision qualifiers
- Check if attrib location binding works correctly

### Step 3b: If shader succeeds
Investigate further down the pipeline:
- **MVP Matrix** — is the combined projection × modelview matrix correct?
- **Viewport** — is `setViewport()` called correctly in GLES2?
- **Texture binding** — does `applyMaterial()` bind textures correctly?
- **VBO cleanup** — VBOs are generated per draw call but never deleted (`glDeleteBuffers` missing)
- **Alpha discard** — `if (col.a < 0.01) discard;` might be discarding everything if `currentColor` alpha is 0

---

## Suspected Root Causes (in order of likelihood)

1. **Shader compilation failure** on Warp3D Nova (to be verified by log)
2. **currentColor alpha = 0** — the fragment shader discards pixels with `col.a < 0.01`;
if `currentColor` is initialized with alpha=0 this would discard everything
3. **MVP matrix is identity or zero** — nothing would be visible even if shader works
4. **Viewport not set** — `glViewport()` might not be called before first draw
5. **Texture unit not activated** — `glActiveTexture(GL_TEXTURE0)` might be missing

---

## Relevant File Overview

| File | Purpose |
|------|---------|
| `engines/tetraedge/te/te_renderer_gles2.cpp` | Main GLES2 renderer — matrix stacks, transparent mesh rendering |
| `engines/tetraedge/te/te_renderer_gles2.h` | Header |
| `engines/tetraedge/te/te_mesh_gles2.cpp` | GLES2 mesh — VBO setup, shader binding, draw calls |
| `engines/tetraedge/te/te_mesh_gles2.h` | Header |
| `engines/tetraedge/te/te_light_gles2.cpp` | GLES2 light |
| `engines/tetraedge/te/te_3d_texture_gles2.cpp` | GLES2 texture |
| `engines/tetraedge/te/te_renderer.cpp` | Factory — `makeInstance()` |
| `engines/tetraedge/te/te_camera.cpp` | Camera — `apply()`, `applyProjection()`, `updateProjectionMatrix()` |
| `engines/tetraedge/game/application.cpp` | `performRender()`, `drawBack()`, `drawFront()` |

---

## Notes

- All GLES2 renderer files (`te_renderer_gles2`, `te_mesh_gles2`, `te_light_gles2`,
`te_3d_texture_gles2`) were written from scratch on March 16, 2026 — they are
not part of upstream ScummVM (see bug #14357).
- Tetraedge upstream has no GLES2 shader renderer at all.
- The correct rendering path for Syberia on AmigaOS4 is:
`TeRendererGLES2 → Warp3D Nova → GLES2 hardware`
- `makeInstance()` is called **before** `initGraphics3d()`, so `OpenGLContext`
is not yet initialized at that point — renderer selection must use config keys,
not `OpenGLContext.type`.


@afxgroup

Let me finish this project first, and then I'll switch to the developer branch. Right now, I'm a little worried about losing my development environment and the tools I've created.

@samo79

Are you referring to the changes made to the ScummVM source code for AmigaOS 4.1? If that’s what you mean, I’ll of course publish everything—I have complete documentation detailing every step the AI took, along with all the patches, flags, etc. I need to figure out the best way to publish it on GitHub; right now, I have absolutely no plan. But I’ll do it—I promise.

@Maijestro
Quote:There is nothing like a "TinyGL" implementation on AmigaOS, that's only available on MorphOS.
AmigaOS has MiniGL, GL4ES, etc. implementations instead.

@joerg

Quote:

I had this support added for QEMU; it works very well with Wazp3d, which is why I did it, and it serves as a fallback in case of problems.

@Maijestro

I was told TinyGL (for MorphOS) fully relies on Hardware acceleration.

@Skateman @joerg

Maybe it's an AI error; I'll fix it. Thanks for pointing that out.