Visually it looks like memory trashing or missing null termination, i.e. random memory stuff. Can come from everywhere ..

@rjd324
You don't need to change opengl calls of course, you just use GL4ES includes in SDK instead of MiniGL ones , and on the linking stage (when link final binary) just add -lgl4es , or if it with sdl , then -lsdl2_gl4es, or -lsdl_gl4es (all of them in my gl4es SDK , on os4depot).

As for makefiles, changes there the same as always, gcc/ar/g++ change on ppc-amigaos-gcc/ppc-amigaos-g++/ppc-amigaos-ar if you on crosscompiler, or keep it as it if you build natively. Just add -athread=native and -lpthread on linking stage as well.

What is most matter, is how you use opengl. If you use opengl with EGL for example, then you have to recode it to remove EGL. If you use OpenGL code taken from windows where it use some win32 driver directly, also get rif of it, etc.

Basically, most of OpenGL stuff we port come with SDL1/SDL2. In this case you need to change nothing, you just use necesary includes (be it minigl or gl4es ones), and necesary linker libs on final binary linking stage.

@Afxgroup
Quote:

Wasn't it me bombing you with reports ?:)

Also, you of course can't expect anyone will use it, until it's not in mature enough form and _everything_ is better or the same as in newlib.

If you have time, we can continue diggint into minetest issues with threads , while probably they not issues with clib2/newlib per se, but with semaphores implementation or even gcc-threads-amigaos4 patch itself.

For porting OpenGL stuff to os4 you have 2 ways:

--1--
First one its ols MiniGL way. MiniGL works over old Warp3D (do not confuse it with new Warp3DNova, it's different libraries), but MiniGL is OpenGL 1.3 (yes, that old one) and have some bugs which probabaly will be never fixed.

MiniGL works on almost everything, like Radeon9250, Voodoo cards, old Bvision/CyberVision cards on permedia2 chips which used for classics back in past, or anything of that sort. For RadeonHD there also a special Warp3D SI driver (so to have old Warp3D over which MiniGL will works), and for RadeonRX, there already finished Warp3DNova bridge driver which also give you old Warp3D support so to make old MiniGL works as well, but this is not released for public currently.

Anyway, main point for MiniGL is:

-- MiniGL works almost everywhere
-- MiniGL is slow
-- MiniGL have bugs which probabaly will stay there
-- MiniGL it's only OpenGL 1.3 standard, so only for very old OpenGL games/apps.


--2---

Second way to port OpenGL apps to amigaos4 is GL4ES. GL4ES is OpenGL 2.x , with some subset of 3.X support. It works through opengles2/warp3dnova combo (exactly Warp3DNova, do not confuse it with with classic old Warp3D).

On GL4ES port for os4 we spend few years already. While the main author of GL4ES is "ptitSeb", i spend few years of bug-hunting, bug-reporting, testing and porting stuff over it. Also Daniel and Hans spend quite a lot of time to imporve/fixing ogles2 and Warp3DNova to have it all works as expected. You can see what i port over by this links:

https://www.amigans.net/modules/news/article.php?storyid=2724
https://www.amigans.net/modules/news/article.php?storyid=2778
https://www.amigans.net/modules/news/article.php?storyid=2831
https://www.amigans.net/modules/news/article.php?storyid=2945


HunoPPC also use GL4ES to port his latest stuff, including new Doom3 port on which he works now.

The drawback of GL4ES, is that it works only on RadeonHD and RadeonRX, i.e. where Warp3DNova and ogles2.library works.


So main points of GL4ES:

-- GL4ES works only on RadeonHD and RadeonRX
-- GL4ES is fast, especially when no "old" glBegin/glEnd route used. In some games it 5-6 times faster. For example, NeverBall on MiniGL give in some level 30FPS on the same hardware, and the same versin of NeverBall compiled over GL4ES give 220 FPS. But usually speed difference is not _that_ big, but still at minimum the same, but if game is written modern enough in terms of opengl, and didnt' use oldschool glBegin/glEnd route, then it will be 2-3-4 times faster.
-- GL4ES is almost bug free (At least in compare with MiniGL), and all the bugs fixed very fast if found by ptitSeb.
-- GL4ES is OpenGL 2.x , with some 3.x support, and soon probabaly will be full OpenGL 3.x support.


If you have any other questions, just ask.

@alfkil
IMHO sounds a bit vague :) What i mean, if there error/bug it can be reproduced. If there is missing feature, it can be told what one. If you not sure, how developers will be add/fix anything, if they don't know about ?:)

@alfkil
Did i got it right that you find some issue in exec, and were answered from kernel developers that you are right and there is bug which kernel's developers will fix ?

@Alfkil
Quote:

Imho at this point you have no needs to do anything about it. It can be issues with beta kernel or so.


Quote:

Nope.. I run load test case, hit bp on puts(), click start, once it drops i hit "step out" , then nothing in console, test case from gui of spotless looks like finished and GUI not operational anymore.

@Alfkil
Quote:

That one ok. I am sure it works before too, just were broken lately.


But now i tested more, and "Step Over" also buggy seems so. You need working machine for sure, or we will jump on the same bugs again and again without much progress :) Just load up a test case , then hit bp on puts() , and hit step over few times , you will have non working gui of spotless.


Btw, I also do test what Javier found, and yeah, the same for me. You enough to just load test case, run it (even without hittting any breakpoint), and then one it bring hello in console and exit, just hit close gadget. And you see in the shell that:

***Command 'Spotless' returned with hanging Disable!

But (!) i should add that this happens on the latest beta of kernel. On the previous betas of kernels and on latest public version we do not have such stuff. So chances are high that this is kernel itself and you can skip it for now. I report it to os4beta.

@redfox
New version works fine, waiting when Mattew will release new Enhancer update. When that will be done only Mattew know, but should be not that far.

@msteed
Thanks for point, i tried, but it's the same :( Only what i noticed, that when i comment out things like title and stuff, i can see on the first top 10 lines rendering happens, but other area just black, and remaining rendering happens outside of visibly area.

@Huno
Looks cool!

Is there any chance that you can made a video of the actual gameplay for a while, without debug enabled. Just to see what the speed is now

@Alfkil
I tested ": Spotless _fix_longlongint" and when i hit bp on "puts", then start, then "Step out", i didn't see "Hello" in console. And even more, after that i can't close Spotless via close gadget.

Should i check one from previous post too ?

@alfkil
Quote:

Tested. Cosmetic bug with "configure" in GUI gone.
Also defaul FPR registers looks sane after loading.

But i do find, that last entry in the registers are "trash", it show 0 and rectangle box. Like, you forget to terminate strings massive or something of that sort (maybe mislead \0 with just 0 or something).

Also "Step out" crash bug i mention seems gone, but not sure if it reacts as expected , now that what i do:

1. run spotless
2. load or test case
3. hit bp on "puts"
4. once it breaks, hit "step out"

At this point test case exit seems so, or something , but i do not have "Hello" in console.

@alfkil
Quote:

When i just click on memory surfer gadget ? No, all fine.

@Javier
Nope, it still shows ups not on top of previous window, but as another separate one.

@All

There some "real-amiga" question for developers working with amiga screens and windowses.


Let imagine we grab a screenmode which is 1920x1080x32. Then, we use this:




So we open "double screen" as do back in times some games/apps to have double-buffering or whatever reassons.

So while the real screenmode is for 1920x1080, we open a screen with 1920x2160. Then, we open the same window 1920x2160 on, to render things and have double-buffering as it was done in old days.


Now, problem is:

I need to open another window on top of it , which will overwrite first half part of content and showups on the same place where old "double-buffered" window is placed.

If we open a window on this screen of original size, like:



I.e. 1920x1080, then, we do have 2 windowses on the same screen, one original 1920x2160, and another one 1920x1080, and this second one is not overwrite first one, but instead shows ups in other window, which i can see only if i scrolldown workbench screen.

Like, the second window draws not at 0,0 of the screen, but on on the second part of 2160 size.


Question is : if we have 1920x2160 screen, how to open a window of 1920x1080 size on the same screen, but which will overwrite at top and be visibly first one.

@alfkil
Quote:

Sure, there is:

https://youtu.be/hpnqyJLxINs

See, i just run congirue, and it reate some strange gadget at bottom left area of spotless window. This one never disappear and dunno what the purposes of it are. Feels like just GUI bug, imho.

@Capehill
Have you any idea of how to deal correctly with the situation when we play the video on 8 bit screens ? As we do use all those renderers/surfaces of 16-32 bits , when we try to play it on 8bit screens we have broken colors instead. Maybe SDL2 have some funtions/tags/helpers to help handle 8bit screenmodes ?

@Raziel
Only if anyone will start to work on minigl again :)

@alfkil
Thanks! Will check.

Do you fix your x5k ?