OpenBeken Simulator Discussion and improvements

As we talked in the shift register thread, I'm starting this one to discuss OBK Simulator.
@p.kaczmarek2

I see that the SDL Window and SDL Renderer uses the variables "WinWidth" and "WinHeight" in sim_sdl.cpp
the pre-set resolution is 1680x940, but when I start the program on my laptop (1920x1080) the program render is offset and some of the items in the render is out of my screen.
Window Mode:


Fullscreen mode:


The solution I found was to change the base resolution manually for now.
Here's an example using the resolution 1366x768 and using SDL_WINDOW_RESIZABLE in window flags on simulator.cpp:
Windowed mode:


Maximized Window:


FullScreen:


Now content Renders with top left corner in the right place. When I maximize the window or change to fullscreen the render doesn't adjust to the new resolution.

I am going to try to change that so the renderer adjusts every time there's a window change event, and later I find it useful to add the functionality to move and zoom the renderer.

Thank you for your interest in the OBK simulator,
first of all, I would like to note: if you have some changes/suggestions, try to open Pull Request quickly, try to keep one change (or at least few changes) per pull request and not more. This is because it's faster and easier for me to review and merge little change then large ones.
Futhermore, Github diff is hard to read and laggy when many files are changed.

Regarding window resize, this is because those variables are used every frame to setup OpenGL viewport:

You need to catch SDL window resize event in the event loop and update the dimensions accordingly.
https://wiki.libsdl.org/SDL2/SDL_WindowEvent

You can also consider changing win_main.cpp (btw, it's a bad name, because it should also work on linux, it's SDL app) to support setting custom resolution in command arguments:

That way you can create, for example "sim_800x600.bat" script that just runs simulator in given vid mode.


Also please note that there are some example projects:
https://github.com/openshwprojects/obkSimulator/tree/main/examples

I am having some difficulties finding where the renderer is set.
You are using SDL Renderer or OpenGL renderer?

OpenGL is a renderer, it's used to render shapes like lines, points, polygons, also possibly textures. It also does matrix transforms, etc.
SDL is doing window management, window resize, keyboard events, mouse events, etc.
There is also a little WinAPI incursion (which is sadly not portable) needed to create menu bar.

So, basically, SDL is used alongside with OpenGL. OpenGL could be also used with 100% WINAPI windows/event management, but it would not be portable.

Current version of simulator can be very easily run on linux and the only problematic code is in WinMenuBar.cpp because I didn't see an option to create menu bar in SDL.

Do you have a specific reason to not use SDL_Renderer?

I know about some options to create a menubar using SDL.

From what I know about the dependencies in the project:

1 - OpenGL is the main renderer.
2 - SDL is a lib that uses OpenGL and has some managers to make it easier - we can use its renderer instead of OpenGL's since it makes some management simpler (and we avoid mixing different libs for the same thing).
3 - FreeGLut is pretty much the same as SDL, but made by another person with some different uses and it's a little older (it's not needed).
4 - LibDevil is specific for managing images, and it's really powerful... But at least in the actual state of the simulator, I don't see where it is really useful.
5 - LibFreeType is for rendering texts... But SDL already has a lib for that too (SDL_ttf), that works alongside with its other functions.

Summarizing:
I might be wrong; you can be using those specific libs for some reason.
But, in my point of view: If the simulator uses all the functions SDL can offer, the only lib that I see as really a good addition is nativefiledialog... the others are not really being used in a relevant way or they are doing something that SDL already can do.
Again, I might be wrong in this, but from what I know about these libs that's my opinion.

smkassist wrote:

Do You have a specific reason to not use SDL_Renderer ?

I don't know how much changed in the last years, but I used SDL renderer in the past (and Allegro as well) and I remember that those 2D drawing libraries were very crude, only allowing to blit sprites and draw lines, while I'd prefer to have more freedom of operations. I also have experience in OpenGL, so it was an obvious choice for me. Still, it is possible that Simulator could also work in SDL Rendererer.

But rendering is already done and everything is drawn through an abstraction layer (each object has shapes) so we shouldn't worry about the matter of which system is doing the display.

There are many projects using SDL with OpenGL. Having OpenGL system also allows us to create more advanced effects in the future, it also allows usage of shaders. I just want to keep the window of possibility open.

smkassist wrote:

3 - FreeGLut is pretty much the same as SDL, but made from other person with some diferent uses and it's a litle older (its not needed).

GLut is only for glutBitmapCharacter system, so I can draw text with OpenGL system easily.

smkassist wrote:

4 - LibDevil is speciffic for managing images, and it's really powerfull... But at least in the actual state of simulator, I dont see where it is really usefull

This is currently not used, but I am planning to have image icons and I also considered using images to display objects in a more nice way. That dependency could be removed for now.

smkassist wrote:

5 - LibFreeType is for rendering texts... But SDL already has a Lib for that too (SDL_ttf), that works allongside with its other functions

As far as I know, this is currently not used, as we are using glutBitmapCharacter . That dependency could be removed for now.

Btw, I have seen your pull request, but it looks like you have accidentally included your private changes in the PR as well. I can see some msvc project changes, some DLLs added to main repo, etc..... can you reopen PR but only with the relevant code changes? Thanks!

I think it's ok now:
https://github.com/openshwprojects/OpenBK7231T_App/pull/780

Changed .gitIgnore to ignore build items and dependencies dlls and lib
Changed window default size to 800x600
Window can be resized
Windows resize event to fix renderer size
Shape Drawing information SubShapes index fixed

Thank you, merged. You can also add ability to specify resolution via command line while starting the simulator.

I think setting resolution via command line is irrelevant now that the window can be resized...
Maybe render quality to make it faster in slow PCs... But I ran it in the old PC in my shop today and it ran fine[/tr]

No problem, I may add that options when I get some time. Or make simulator remember it's last window size from previous session.

Have you managed to get rendering to slow down? Those are just few lines, there is not much to render, it should be quick.

Have you checked out the uploaded examples?

Making it remember last window state is a good idea.

I made it render just a little slow in the shop's old pc...
It's an i5 second gen and 8GB ram. I was running multiple tabs on chrome (more than 10), and put it on fullscreen mode.

I didn’t check examples yet. Busy days

there SDL libraries for image and text management. I think it would be useful to implement them .
Just got home. I will see those examples

I think that top priority should be adding more features. The simulator will be available for download in compiled form, and it doesn't change much for users if we use SDL for text.

I'd first look into supporting more features like shift register device.

About the examples:
I tested some of them, and they work as intended.
But, autoexec.bat doesn’t load automatically when we load an example. I had to go to file manager and use save and run option.

Thank you for reporting,
I have updated the scene change logic to fix the autoexec issue.
You can check it now, for example on this scene:

I had made a little change and sent a PR. Did you see that? PR 784. After the screen resolution fix, the collision checks had a vertical offset for some reason, so I did a little adjust until I find the correct solution

hmm but I added this offset to fix collision issue caused by WINAPI Menubar addon, see sim_sdl.cpp:

so it looks like our changes cancel each other out.

Does it mean that handling WINAPI resize message somehow indeed fixed correctly the menubar? Well... it makes sense, if you think about....

It seems that your windows resize event made my offset hack unnecessary. Nice.

I need to double check that and remove both offsets.

Something Broke in the last commit:



I think it would be useful if you kept libs_for_simulator folder in the OpenBK7231T_App Git page (remove it from gitignore) so if something is changed in the deps we don't have to sync the app branch AND change manually the deps

Added after 1 [minutes]:

>>20537961

Different approaches to the same thing. But yours seem to be a better approach... Ignore mine and fix it the right way then.

smkassist wrote:

Something Broke in the last commit:

I was adding a TM1637+GN6932 custom driver and forgot to update msvc project.

smkassist wrote:

I think it would be usefull if you kept libs_for_simulator folder in the OpenBK7231T_App Git page (remove it from gitignore) so if something is changed in the deps we dont have to sync the app branch AND change manually the deps

Do you mean in the OpenBK7231T_App repository?

smkassist wrote:

Different aproaches to the same thing. But yours seem to be a better aproach... Ignore mine and fix it the right way then.

No, I was saying that I think you had to add your fix because my fix was redundant after the Resize Window event code was added.
In other words, my offset was causing problems now.
https://github.com/openshwprojects/OpenBK7231...mmit/330fbd472eeae184cc357b8d69c07b95acf07fd3

p.kaczmarek2 wrote:

smkassist wrote:

Different approaches to the same thing. But yours seem to be a better approach... Ignore mine and fix it the right way then.

No, I was saying that I think you had to add your fix because my fix was redundant after the Resize Window event code was added.
In other words, my offset was causing problems now.
https://github.com/openshwprojects/OpenBK7231...mmit/330fbd472eeae184cc357b8d69c07b95acf07fd3

Sorry. Miscommunication for thinking faster than my fingers... Understood the issue but typed something totally different from what I had in mind

p.kaczmarek2 wrote:

smkassist wrote:

I think it would be useful if you kept libs_for_simulator folder in the OpenBK7231T_App Git page (remove it from gitignore) so if something is changed in the deps we don't have to sync the app branch AND change manually the deps

Do you mean in the OpenBK7231T_App repository?

Yeah. That's right... Keep the dependencies in the main repository.

Added after 6 [hours] 24 [minutes]:

Some examples with buttons are buggy in my old pc. When I get home I will test the same in my laptop
The buttons freezing in an "almost active" state:

Before click:


after click - button keeps frozen like this:

Hello, this is the first time I hear about such issue. Are you able to use debugger to check what exactly happens in the code?

So... I have been busy.
I had tested some examples on my laptop and they ran perfectly.
My best guess is that this bug is happening due to poor performance in the shop's old PC.
Unfortunately, I will only have the chance to try to debug that in 3 days from now.
If I find something new about it I will post it here.

Hardwares:
Laptop:
Core i7 6th gen
12Gb RAM
nvidia gtx 960m

Old desktop:
Core i5 2nd gen
8Gb RAM
No VGA

Sorry for bothering...
But does anyone have any pre-built binaries (win or linux) for the simulator available anywhere?

Or at least some more "detailed" instructions on how to actually compile the simulator (with dependencies etc)?

THANKS!

Hmm I don't think I have published any more instructions yet, but I can help you if you have any specific questions.

Still, I have myself build my simulator only on Windows so far.

Well... I'm struggling with HA auto discovery and related stuff (functioning in general) so I wanted to set up some sort of "test environment" instead of "destroying" the little functionality of real devices installed...
Not to mention my wife not approving "much playing" with her lights etc... ;)

So... the "real" issue for me is the auto discovery and things not showing/working and other "under the hood" stuff working which is not visible without digging through code and connecting the dots...

Well, you can either try to build simulator or maybe open another topic where we can discuss HASS discovery issue, I will help in both cases

Hello,
@p.kaczmarek2: Is the link for the simulator always https://github.com/openshwprojects/obkSimulator/tree/main?

It seems to contain only DLL and no project files. Maybe I'm wrong or not looking in the right place?

Main simulator code is here:
https://github.com/openshwprojects/OpenBK7231T_App
The entry is in win_main.c, but it's SDL and it could be compiled on Linux as well.
The simulator itself is in sim directory:
https://github.com/openshwprojects/OpenBK7231T_App/tree/main/src/sim
and it's written in C++

Many thanks ! will have a look at it .

Hello,
I've tried to compile under VS Community to get the simulator working but I can't succeed. I've added all the libs/includes needed and at the end, I have those errors:



Is there a kind of guide/tutorial to get it running or maybe I forgot something?

Regards.