Who's Online |
28 user(s) are online ( 24 user(s) are browsing Forums)
Members: 0
Guests: 28
more...
|
|
|
|
Re: The OpenGL ES 2.0 thread
|
|
Just can't stay away 
|
@Capehill glCompileShader returns a GL_COMPILE_STATUS of 0, when the call is made in the new thread. glGetShaderInfoLog in this case returns nothing. glSnoop does an enormous amount of logging. It also interestingly removes the compile error. I get this in the log: Quote: [262.857543] Shell Process 'threadedqopenglwidget': W3DN_DrawArrays: <- Result 22 (W3DNEC_NOSHADERPIPELINE) [262.866984] Shell Process 'threadedqopenglwidget': Warning: unsuccessful operation detected [262.875127] Shell Process 'threadedqopenglwidget': GL error 1286 (GL_INVALID_FRAMEBUFFER_OPERATION) detected after DrawArrays EDIT: It could be an issue with context sharing. Maybe I have some wiggle room. EDIT: Probably not, though.
Edited by elfpipe on 2025/2/2 12:27:57 Edited by elfpipe on 2025/2/2 14:05:08 Edited by elfpipe on 2025/2/3 8:53:37
|
|
|
|
Re: The OpenGL ES 2.0 thread
|
|
Just can't stay away 
|
@Capehill
My app is working now. The bitmap thing is still a mystery, but I don't need to know, actually.
I have another problem, though. In an "app", that wants threaded rendering, I have problems compiling the shaders in the new thread. I don't know, if this is a must-have, but apparently it works on other ogles2 platforms. I have threaded rendering in another app from the same "bundle" working just fine. EDIT: The shaders in the problem-app all compile just fine, when this is done in the main thread.
|
|
|
|
Re: The OpenGL ES 2.0 thread
|
|
Just can't stay away 
|
@Capehill
I know this is silly, but I often get very discouraged, when I cannot get code from another source to build at first run. It seems, that I don't have updated examples. I am using the examples supplied with the Enhancer Software version, that comes with ogles2.library v3.3. It seems these examples are older, since they don't use aglCreateContext2(), but rather the older aglCreateContext(). Or am I wrong?
I can get the bitmap function to work, if I render directly to the bitmap of a screen. But of course that is quite useless.
At this point, I am really interested in knowing, what the OLGES2_CCT_CONTEXT_FOR_MODEID tag is used for. Is this what I think it is? What I think it is, is the ability to create a modeid neutral context, that doesn't do any rendering. This would be very useful to me at this point, especially if it turns out, that I can change the parameters of a context on the fly. I'm not going to tell you why. Unfortunately, this tag seems to be impossible to make work, at least on its own, which makes me think: What is it meant for?
|
|
|
|
Re: The OpenGL ES 2.0 thread
|
|
Just can't stay away 
|
@Capehill
I don't use a rastport for the bitmap. In my example, I am opening a window on the workbench, using its bitmap as FriendBitmap for AllocBitMapTags, tagging Displayable, TRUE, and after rendering I use BltBitMapRastPort to the window. Or I use a screen for testing, it doesn't make a difference.
I also have a problem with an app, that renders fine as long as I use _MODEID, 0, for the context, but as soon as I want to use a window, it fails to render (I am using LAYERS_NOBACKFILL for the window, so the content is just garbled). This also used to work with an earlier ogles2.library/Warp3DNova.
EDIT: I tried switching the version of the RadeonHD.chip, which made no difference. I no longer have the earlier versions of libraries. I have not changed my gfx card.
|
|
|
|
Re: SpotLess debugger
|
|
Just can't stay away 
|
@sailor
I have not been too involved with the latest developments, so maybe I am not the right person to ask for those extensions to the codebase. I barely did any of the thinking with regards to those two debuggers myself, mostly just picked up on knowledge about the exec debugging interface, tutorials on creating simple debuggers etc. The issues you are seeing with optimized code is a good example of where my development skills hit the brick wall - I simply don't have a concept of how to improve on the basic algorithm.
Thanks for the test case, at least we know, that the tool is has some appeal for simple use cases.
|
|
|
|
Re: The OpenGL ES 2.0 thread
|
|
Just can't stay away 
|
Hi all,
I have a question about programming ogles2.library v3.3.
I am trying to get OGLES2_CCT_BITMAP to work. I remember using this in previous versions of the library to render to a bitmap and then blitting wherever I saw fit. In this version it doesn't seem to work.
I can run exactly the same code with OGLES2_CCT_WINDOW/MODEID, and it works just fine. With _BITMAP it renders the background color, but the content is not there. I have tried to resize the viewport, but so far nothing has turned up. As I mentioned, it worked in earlier versions.
Thanks! :)
|
|
|
|
Re: SpotLess debugger
|
|
Just can't stay away 
|
@sailor
Thsnks for trying out Spotless. As you mention, it relies on modules, that might or might not get released at some point. Also, it has not been updated for a long while, and it lacks quite a lot of functionality, for instance debugging of libraries.
I think your best bet is to go with gdb atm. It is actively being worked on, and it has a more solid and all-encompasing foundation compared to Spotless. Spotless is more like a proof-of-concept, although it could potentially be worked on to create a fullblown debugger. Also it has some nice gui features like the MemorySurfer and split window mode.
|
|
|
|
Re: CMake 3.29 Native (OS4)
|
Posted on: 12/25 10:46
#8
|
Just can't stay away 
|
@MartinW Quote: I get an instant crash. I am assuming that "FetchContent" is not implemented. Would that be correct? I am assuming this is usually built on a cross platform. Well, to be honest, I have no ambitions to make this kind of constellation fly, but then again : wouldn't it be wonderful? What you can do is to check up on the state of git on AmigaOS. I remember reading about this, but I have no idea what the real state of affairs looks like. Maybe you can be my Hermes in this regard? Best wishes for Christmas :)
|
|
|
|
Re: CMake 3.29 Native (OS4)
|
Posted on: 12/20 18:54
#9
|
Just can't stay away 
|
@Raziel
I think we are all in a situation, where devotion is a matter of schedule more than passion. For me, Amiga is therapy as much as other things, so I like to have it at the back of my hand, when I need it the most.
On a side note: There will be an update shortly, which should fix the lingering pipes problem. I haven't been working on other things with it, but I hereby take requests. I have noted the FetchContents problem mentioned above.
|
|
|
|
Re: CMake 3.29 Native (OS4)
|
Posted on: 12/13 20:07
#10
|
Just can't stay away 
|
@Raziel Quote: Jee. And I thought we were more than friends now...  I am glad, we made some progress. If I was able, I would work on this all day. Life keeps you busy, though, and I am happy and alive at the moment.
|
|
|
|
Re: CMake 3.29 Native (OS4)
|
Posted on: 12/13 18:41
#11
|
Just can't stay away 
|
@Raziel
I'm not leaving anyone, I just have a lot on my plate at the moment. I still have an ambition to fix the remaining issues with cmake and look at the qt toolchain.
|
|
|
|
Re: CMake 3.29 Native (OS4)
|
Posted on: 12/13 17:28
#12
|
Just can't stay away 
|
@MartinW
I am guessing, that the command you call FetchContent is using ProcessUNIX.cxx instead of libuv to run exterior commands. This diversion has not been tested and will probably just crash. It could be fixed.
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2024/10/27 15:51
#13
|
Just can't stay away 
|
@Maijestro
Thanks, I am glad, you enjoyed them :).
@smarkusg
I can recommend, that you do a shared build instead of static. We did some work to fix some symbol resolutions in elf.library, that didn't work before, so now ui signals will actually reach the callback function. This depends on *beep*.
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2024/10/25 22:21
#14
|
Just can't stay away 
|
@smarkusg
No-no, I mean if you do a better version than mine, that's perfectly all right with me. I am sure that you are on the right track and that the work you are doing is worthwhile. I am keeping the repository open because of legal reasons, but also just because I like to share. And I don't like to take credit for the work, my contribution compared to the whole is very small. So if you feel like going big, go for it. :)
EDIT: I know the project has been stagnant for a while. I am just glad, that there is some progress.
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2024/10/25 21:27
#15
|
Just can't stay away 
|
@smarkusg
Short answer : It is the plan, as soon as the native build environment is confirmed and gl rendering is at an acceptable state, that work should be done to update all relevant modules from the changes done in qt4. I am pretty sure, that most could be used in some form, and it would be quite clear where possible upgrades could be done to those changes.
It is nice, that you are doing experiments with various improvements. If it is ok with you, I would love to include those changes in the final version whenever it seems reasonable.
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2024/10/18 7:23
#16
|
Just can't stay away 
|
@smarkusg Quote: My compilation is cross-compilation not native. Ok. I have tested a basic clib4 app, and I can see that it produces normal functions but it doesn't produce CON: output. Probably there is some path issue, that prevents the qt app from opening the environment, although I have trouble seeing what that could be. If we could redirect the stdout and stderr output, we could probably see what goes wrong.
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2024/10/17 20:15
#17
|
Just can't stay away 
|
@smarkusg Quote: I only have one question. Do you know what needs to be done to run a program compiled under QT to be run from icony (workbench) not shell ? Strange, I did not foresee a problem here. There doesn't seem to be any failing calls in snoopy, so perhaps this is a feature of clib4. I haven't studied this, but maybe there is a special main function, that needs to be implemented? EDIT: I have a question - did you test the native build tool chain?
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2024/10/16 17:42
#18
|
Just can't stay away 
|
@smarkusg
What a pleasure to watch :). That program sure has a lot of functions! I am glad that work on qt is no 100% stagnant, and if I can contribute anything to development, please ask.
@Maijestro
There is probably some setting to turn regular windows into gl windows, it just needs to be located. Otherwise it uses software rendering as default.
|
|
|
|
Re: CMake 3.29 Native (OS4)
|
Posted on: 2024/10/12 21:39
#19
|
Just can't stay away 
|
@joerg Quote: For example OWB, which used CMake as well, can't be built on case-insensitive AmigaOS file systems and I had to use a case sensitive formatted SFS\2 partition for building it. Thanks for the explanation. I had some problems with OWB, that went away, when I moved it to a FFS partition. As I said, I still need to test this difference, I am sure from what I hear from people testing cmake that there is a possible connection on functioning and some relation to the file system(s) used. @hypex The crash you are seeing looks strange, and I don't have a ready answer (from looking at the source in this place, there is not much to see, other than a possible connection to pipe()/read() which sometimes has a little bit strange behavior). EDIT: Is it a regular crash, or does it only happen from time to time (ie. are the conditions stable or spurious)? About using source tree builds, this should not be a problem, but perhaps the specific build situation triggers some otherwise hidden problem.
Edited by elfpipe on 2024/10/13 10:59:36
|
|
|
|
Re: CMake 3.29 Native (OS4)
|
Posted on: 2024/10/11 11:40
#20
|
Just can't stay away 
|
@Hypex
This might be a problem with filesystems and case sensitivity issues. I haven't gotten around to checking cmake on another partition, so I can't tell for sure, but if you want to try it out, you can try installing in an sfs partition and see, if that helps. It might also be important, what partition your SDK is located at.
|
|
|
|