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.

@all

ScummVM is now being uploaded to Os4depot. The engines that are still causing issues are located in Plugins/Beta/. For now, my priority was to have a stable version with engines that work really well. Enjoy!

If you run into any problems or if there’s an engine you’d like me to add, we can discuss it here in the forum.

@Maijestro

Mmm does it works with MiniGL? (for example sam440 with R200)
Just installed clib4 from archive, then double click on the exe but nothing happens!

Btw, game folder icon is missed in the archive, maybe you can pick the old one from the Raziel archive

@samo79

Quote:

There was another upload; I uploaded the wrong build the first time. Unfortunately, I could only test it on my X5000/RX580 and with Qemu/Wazp3d, and it works fine there. It seems it isn't switching to MiniGL properly. Hmm

The correct build is now available on Os4depot. Sorry for my mistakes. Let me know if it's working for you now.

@samo79 @Maijestro

The "Executable" bit was missing on the file.
It seems ok now.

Thanks for your work.

I just downloaded it directly from Os4depot and ran it on my X5000, and it works. Please download it again and test it. The old build has since been replaced by a new one.

And if it doesn't work, please specify the system you tested it on; it seems you're missing something.

@Maijestro
That all good but we have problem now :) you replaced good old well tested version by Raziel by AI port which wasnt tested properly, but just you do some tests, and even then ppls complain they have issues with basics like missing executable bit.. now, where old version from Raziel ? In your archive ? Or we can say buy buy to his version ? If that the case that not very good, you for sure shouldnt consider replacing good tested version by fast AI ports that for sure. Maybe create it like scummvm-ai or scummvm_majestro

Strange that it was allowed to be replaced.. It needs to be uploaded back and your version renamed, IMHO, so everything will be fine for everyone. Because its like you rush few years of Raziels work :( sure you didnt want to, but you can same way upload anything over ppls work and buy buy :) Even if Raziel say ok to replace because he dont care anymore it still not good for all who know and test his verdion and want exactly his version...

Anyway keep it up, just let it be not overwrite others work, etc :)

@kas1e
Fortunately, the latest binary version from Raziel is still available at
https://www.scummvm.org/downloads/

but the source files ‘scummvm-src.tar.xz’ that were on so4depot ... are gone.
Not even the web archive copy has them. Unless they’re somewhere in the depths of GitHub
https://github.com/raziel-/scummvm

EDIT:
Perhaps there isn't should be any problems with the source files.
the “https://github.com/scummvm/scummvm/archive/refs/tags/v2.9.0.tar.gz” tag contains “amigaos4” tags
and there is a compilation description
https://wiki.scummvm.org/index.php/Compiling_ScummVM/AmigaOS4

@kas1e

It was never my intention to undermine Raziel's work. My build clearly had a different version number—specifically, ScummVM-2026.1.1—and of course I wanted to keep it separate from Raziel's latest public build because I greatly appreciate his work.

In both uploads I made, the version number was clearly included to avoid overwriting the existing files. However, my AI build was then renamed and released as scummvm, which led to the overwrite.

And of course, I’d like to resolve these issues and not take credit for someone else’s work—the hard work on ScummVM was clearly done by Raziel.

So if anyone still has the latest source code and the original target build 2.9.0, they should overwrite it.

And I could then try again to make my build publicly available as a separate version on Os4depot.

One more thing about the missing bits: they don’t exist. I had uploaded a faulty build where that issue appeared; the current build now available doesn’t have this problem, neither on my X5000 nor under Qemu/Peg2. Unfortunately, there has been very little feedback so far, so of course I don’t know how well it works on other machines.

So if you’d like to test it, please do so and report any bugs, and I promise I’ll look into them.

@kas1e
Quote:For example https://web.archive.org/web/2025081401 ... ile=game/misc/scummvm.lha

Quote:If you don't use the Passphrase to protect your uploads anyone can replace anything on os4depot.net by using the same file name, just like on Aminet.

@joerg

Quote:

Thanks

Quote:

Even if it uses a completely different filename? I uploaded it as ScummVM2026.1.1, not as “scummvm”.