Yes, it should be possible. You need the Intuition window pointer first. Then, call aglCreateContext and pass the window pointer. Now you should have a GL context which you can make current, draw, swap the buffers and destroy later (before window closing, probably). And in case window pointer changes it has to be refreshed.
There might be some conflicts if app calls SDL_Flip or similar. These probably should be deactivated.
Where one of flags SDL_OPENGL; then we do create MiniGL context by the SDL1 source code.
But now, if we want to draw by ogles2 to sdl1 window, we should _not_ create window with SDL_OpenGL, so to avoid creating of MiniGL context, but instead, we create non-opengl window, and then get the intuition window pointer, and then aglCreateContext and then aglMakeCurrent ?
PS. Btw, how can i get Intuition window pointer from SDL_Surface *Screen ? I see we do have some SDL_PrivateVideoData field which store window pointer among others, but how to get it from screen created by SDL_SetVideoMode ? I.e. i have now:
if (ogles_context)
{
IOGLES2->aglMakeCurrent(ogles_context);
}
And this "win" i not sure from where take. SDL_Surface structure seems do not contain it so it should be some private field or something , like maybe Screen->private_data->win ?
Edited by kas1e on 2022/9/22 13:54:34 Edited by kas1e on 2022/9/22 14:02:42
@Capehill Rigth, so i just did rigth before context-creation this:
SDL_SysWMinfo wmi = { 0 };
SDL_GetWMInfo(&wmi);
And then: {OGLES2_CCT_WINDOW,(ULONG)wmi.window}, works.
I also while waiting your answer already tested by using the same hack which i did for GL4ES (so to open ogles2 context instead,etc) and this works too.
Throuhg, by "works" i mean, no crash, and i can see that shaders are about to be compiled, but, i still have black screen, few GLSL shader program failed to link and GL_INVALID_OPERATION 176.
I will create relevant topic about all this to not flood this one.
I would like to briefly describe a problem I noticed that I thought was caused by Qemu, but it is not.
I have compared SDL under AmigaOs4.1 Pegasos 2 and AmigaOs4.1 AmigaOneXe, under AmigaOs4.1 Pegasos 2 there are many problems with SDL output that do not exist under AmigaOs4.1 for AmigaOneXe.
Both emulations are almost identical and I use the same CPU G4 7447/7457. I am now sure that it can't be a problem of the Qemu emulations, but that there must be differences internally in the SDL version of AmigaOs4.1 Peg2 and AmigaOneXe.
An example with Xrick from os4Depot:
AmigaOs4.1 AmigaOneXe:
AmigaOs4.1 Pegasos 2:
I don't know what differences there are between the Pegasos 2 version of AmigaOs4.1 and the AmigaOneXe version of SDL that cause this problem.
If it is not too much trouble, could we fix this problem?
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Was there some kind of byte swap support in northbridge? Perhaps it does something wrong.
looks like you 4 bytes swaped with next 4 bytes. (8bit GFX mode only way you get correct colors)
Perhaps its swapping 8bytes instead of swapping typical 4 bytes. Pixel 1,2,3,4,5,6,7,8 resvered as 8,7,6,5,4,3,2,1
whats expected is 1,2,3,4,1,2,3,4 revered as 4,3,2,1,4,3,2,1
If writes directly into bitmap buffer instead of using WritePixelArray, strange things can happen.
Odd things can happen with JIT, for example two 32bit instruction can be combined to from a 64bit instruction, maybe assumption is not always right. A reserved 64bit operation, vs 2 x revered 32bit operations won’t actually produce the same result.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
XRick port is from 2004 (19 years!) and it has been statically linked to whatever libSDL.a existed at time. In order to investigate, probably a newer build should be made so that nobody goes out to hunt potentially non-existing bugs.
Generally with all new SDL1 based programs there is the same problem on QEMU/Pegasos. Older programs surprisingly sometimes work. xrick is one such example. After switching from fullscreen it starts to work. It will be difficult to check because they are, as you wrote, statically compiled.
There is another example described by Falke_34 on the forum amiga-news.de . There is the game "Project Secret Maryo Chronicles". Same problem with SDL1 but after changing from 16bpp to 32bpp in preferences.ini everything works fine.
Capehill wrote:XRick port is from 2004 (19 years!) and it has been statically linked to whatever libSDL.a existed at time. In order to investigate, probably a newer build should be made so that nobody goes out to hunt potentially non-existing bugs.
It was only one example of many and should only point it out.
Pingus, MegaMario, Mplayer many SDL demos etc. also here are exactly the same problems with SDL1 under QEMU Pegasos 2 AmigaOs4.1 @smarkusg and also I would support you in debugging.
The SDL expert is you and we depend on your help, if we can test or debug something and they can explain how it is done, we will help to get the problem under control.
You are doing a really great job with SDL and without your support this problem will always be a problem.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
So, XRick is using 8bpp in HWSURFACE mode. For some reason this doesn't work on Pegasos(QEMU) in 16-bit mode (?). And possibly window size can have some impact? (for example zoom option in XRick)
Can somebody test XRick on a real Pegasos in 16-bit mode? If somebody already did, then sorry, I have missed that information.
If you can, check on the old one. I know it can be a problem, but if you can use a Silicon Motion graphics card. I can build a version under 1.2.16 because I have xrick sources on hand.
I've also seen xrick under SDL2 but something is with the sound... but that's another topic.
@all Tested old XRick from os4depot on real pegasos2 on both 32bit modes and 16 bit modes on my AGP Radeon9250 card : no issues. All shown correctly. For sake of tests i check with each test via Ranger that i do have 16bit and 32bit modes on the XRick screen, and yeah, old Xrick works fine on real peg2 with radeon9250 both 32 and 16 bits output.
The last thing I can think of is to check Qemu Pegasos 2 G4 with radeon card via passthrough. I think @MartinW had this configuration. From what I've seen he has become the happy owner of an X5000. Chances are he won't currently have the time or inclination to check it out.
Just as a reminder to those who don't read all posts : Qemu AmigaOneXe cpu G4 SM502 - SDL works fine. Qemu Pegasos 2 cpu G3 SM502 - SDL works fine.
It's a bit less about time or inclination and more about the fact the X5000 parts were built into the case that the Qemu emulated machine was living in so they are currently just individual parts on my workbench pending me buying a new case and PSU to house them which needs to wait for the cash and for building work at home to be finised, so probably October?
After that I really don't mind testing things again.
kas1e wrote:@all Tested old XRick from os4depot on real pegasos2 on both 32bit modes and 16 bit modes on my AGP Radeon9250 card : no issues. All shown correctly. For sake of tests i check with each test via Ranger that i do have 16bit and 32bit modes on the XRick screen, and yeah, old Xrick works fine on real peg2 with radeon9250 both 32 and 16 bits output.
Since was almost to be expected, thank you for their time and test in real conditions.
@all
Let's summarize briefly:
We have 3 emulations under Qemu that we can use AmigaOnXe, Same460 and Pegasos 2.
Pegasos 2 emulation problems with SDL1 G4 CPU 7447/7457 (G3 CPU works with SDL1) AmigOneXe emulation no problems with SDL1 G4 CPU 7447/7457 Sam460-emulation no problems with SDL1 CPU PowerPC460ex
Since we have already run the test on real hardware (Pegasos 2), this does not seem to be due to the Silicon Motion chipset or the 16-bit output, since it works under real hardware with a graphics card and in the AmigaOneXe emulation with SDL1.
We can also exclude the G4 CPU 7447/7457, same result AmigaOneXe SDL1 works, Pegasos 2 SDL1 does not work.
Apparently something within the Pegasos 2 emulation must cause SDL1 to become unusable. It is a big mystery....
Edited by Maijestro on 2023/8/29 16:24:10 Edited by Maijestro on 2023/8/29 16:25:33 Edited by Maijestro on 2023/8/29 16:27:16
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
