#apertus IRC Channel Logs

Bertl: morning!

good day

panintended: any progress?

se6ast1an: is the parameter highlighted when the menu pops up?

yes

Sure, will check that

as currently the loop delay is removed, the performance seems to degrade, probably pic32 trying to push the data to LCD as fast as possible

there are better methods to measure performance, as the MCU has precise timers, current value can be retrieved between certain calls, like start time and end time

also remember this is not a desktop CPU, so does the concept of CPU strain/load exist?

of course the load exists, as it tries to push the data as fast as possible, so the delays there also delay other functionality

but I agree that with event based redrawing the FPS doesnt really mean anything anymore, but how far away are we from this? does it make sense to wait for it?

basic method is to grab the value of system timer, have to find the docs i'Ve used before

Sounds good, but like a bigger taks

back then i've read this thread about core timer -> https://www.microchip.com/forums/m591009.aspx

maybe there are still snippets in the code, as i don't remember the outcome of the tests

did you implement multitasking?

of course, ported freertos all the way

and ported it to C++ of course?

at the moment it looks like the timer at the main page is running slower than before, so hunting down the culprit is necessary, but the loop was simplified already

off for reviving the bike, will update lab task when back

adding those above links and new goals

off for now ... bbl

BAndiT1983: I've replied to your comment https://lab.apertus.org/T1181#16993 - have a look and let me know

will check your version in my VM, then i can see if it works for general setup, like i said before, my manjaro with nvidia drivers isn't having any trouble to run either profile, probably because the drivers were finally improved and no bumblebee is required on intel/nvidia optimus system

not saying, that we can't change the base at some point to software only, it just needs proper UI which has less ties to OGL or similar

3.3 and recent :D -> https://www.khronos.org/opengl/wiki/History_of_OpenGL

haha :'D

good thing about OGL3 that they got rid of old things and slimmed it down, am looking forward what vulkan will deliver in the future

by the way, do the suggested changes work on your setup after all? In the comment you said that no profile worked for you

*continue looking into convincing SDL to use a more recent version

will check your fork

*btw, for me it also starts with 2.1, but the visualizer works just fine

hey, looks great and worked instantly, will check your changes

at the start it tells me that it's 3.3

please create a PR

yep, stdout, as it grabs the version after init

AXIOM Remote Visualizer

Texture ID: 1

SetupGL method is misleading, as it only initializes gl3w

ok, I was referring to the same thing. for me it has been 2.1 ever since I applied the fix :'D

btw is there any cnovention to add a hook to the bug entry in the PR title? (similar to Gitlab's #<issue ID>)

haven't used hooks before, but we had a topic about cimmit messages yesterday, if you add lab task like T1177 to the commit, then it will reference it in the task

commit message can look like -> T1177: Added .....

just the T<number> is sufficient

Ah, great. That was what I was referring to

done: https://github.com/apertus-open-source-cinema/AXIOM-Remote/pull/12

great, thanks. Also regarding the visualizer: I don't seem to be able to select menu items like I could before with button 5. Am I missing something?

button 5 was working for me just moments ago in your fork

let me pull your PR and check here as well

checked it again, works properly

oh boy ;D

strange, my VM is exactly ubuntu 16.04

panintended: just a normal craziness of trying to support most systems

se6ast1an: please paste also your glxinfo in the lab task, for comparison

glxinfo | grep OpenGL

https://pastebin.com/raw/XEF7A9K7

solved

https://lab.apertus.org/T1181#16998

also black in VM

VM looks the same

yes, it also has the same black visualizer screen :)

your hardware looks also like it's ok, but if the host PC has the problems, then it's something else, as the GL commands are passed to the host for quite some time in VB

which linux do you use on your host?

especiall this line tells me that it should work: OpenGL core profile version string: 3.3 (Core Profile) Mesa 19.2.8

GL_RENDERER = Mesa Intel(R) HD Graphics 630 (KBL GT2)

GL_VENDOR = Intel

GL_RENDERER = GeForce GTX 1050/PCIe/SSE2

GL_VENDOR = NVIDIA Corporation

with a rtx 2080, doubt that is insufficient :)

panintended: I tried SDL_GL_CONTEXT_PROFILE_COMPATIBILITY, unfortunately no difference

my dedicated axiom remote development laptop

is it about those functions being called earlier?

in my VM this also works fine

ok, so I guess it's back to the drawing board for me then :)

can you pastebin a screenshot just in case though?

https://lab.apertus.org/T1181#16999

:) sorry *I meant if you can paste a screenshot of the imgui example running (externally no need to spam the bug tracker)

https://lab.apertus.org/T1181#17000

i've meant for VM

we need to check this, like i said, my VM with ubuntu 16.04 is working properly, but i had also problems before, when i'Ve tried to move line panintended has analysed

2.1

was 3.3 before when it worked

now it also fails for me again, crazy times

but only in VM

yes, there are some. Let me try to concisely put them in the bug tracker

also trying at the moment, as it's really suspicious

but both cases are still giving black image, looks like context is not there, as the font atlas (the texture which occurs) is registered at wrong texture id, so it interferes with following operations

they use core profile

ah correct! sorry for that

it's unfortunate that I can't reproduce it on my setup. Can you guys please have a look with these ?

but probably the old ubuntu version is just not up to the task

very funny, i've disabled the creation of SDL renderer and it worked

lines 69-76

IMGUI is used for everything, so SDL renderer won't work there like this and probably they are interfering with each other, as the context is not shared

wanted to check shared context, but just out of curiosity, as we can get along with only IMGUI drawing

indeed it works :P

so both renderers collided without context sharing

panintended: would you be so kind?

yep, let me see if I can redo what you did.

no need

So, I've removed the renderer (and all it's references) as well as removed commented-out lines. And it starts fine (and I've now got OpenGL 3.3)

I beat you to it :)

is that all? anything else?

great, and please create a PR, then i can check the code

great, you guys are the best!

thanks, checking

*not all calls to Shutdown() just one :)

this is my version of SetupGL() -> https://pastebin.com/raw/zUmDvpYC

let me amend

no need, just push the new commit

BAndiT1983: hmm, I guess I should also move the SDL_Window initialization in SetupGL. That was how all of this started right? :) [https://wiki.libsdl.org/SDL_GL_SetAttribute#Remarks]

(even though it still happens to work on my system)

it works on my side -> https://pastebin.com/raw/gT6c2WYZ

ok, almost done. btw you've removed SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1);

not really, as we don't have high-end animations ;) this is probably the reason i've removed it while testing

done. I've also cleaned up some unused variables and changed cout to cerr in the updated functions

have a look and let me know if you have questions. thanks

cool

let's see if this is the end of the saga xD

meaning? :)

sometimes developers use too specific OS features and when OS version is newer it doesn'T work that well

best thing is, that wine allows to start the games sometimes better than windows, e.g. back when processors were starting to change the frequency dynamically, some games haven't taken it into account and ran slower or faster, so i had to start the windows calculator and enter big number then click factorial calculation, CPU usage went up and i could start the game normally, then kill calculator

and i won't even mention old interfaces like directdraw and games which struggle to run on win10 without it

it works!

awesome

:)

hope we can continue tomorrow or so

see you