[SOLVED] AHK help

[nosh]

I was working on systems yesterday and landed on Dreamcast and as far as i know the best emu is nullDC but the downside is there are issues with fade and bezels. After looking at the module and all of DJ's frustrated comments and commented code i saw why. I decided to start digging into HL's code, specifically bezelDraw() in bezel.ahk, to get a better understanding of how bezels work. Everything seems to go down hill after the winget command which relies on a variable called emulatorID to get the active emulator window.

Where does emulatorID come from? Is the core problem with fade and bezel that ahk cant find the window based on that id?

I am no AHK expert so i am just looking to understand a little more about AHK and the inner workings of HL so that i may at some point be able to give modules like nullDC some love.

 

[djvj]

I believe that id is the Process ID of the emulator. But since you said it's using WinGet then it might be a window hwnd ID.

I'm also not aware of there being any core problems.

Sent from my SCH-I535 using Tapatalk

 

[bleasby]

That line gets the game active window ID in order to move and resize it to apply the bezel and locate correctly the game window.

I did not had the chance to look at nullDC special case both for not having the system setup and for the lack of time.

But I am sure that the bezel code is more than robust as it works for a a few dozens different scenarios, and I am sure that wherever problem you are having is not a fault of this part of the code. Whenever I have the time to check this system I am very sure that only with module changes we could achieve the support for it, as until today there was no module that we worked that we couldn't add bezel and hyperpause support.

Meanwhile, for sure everybody will be most glad if you can make it work. Just try to focus more on learning the behavior of the emulator window on windowed mode and on adding code to deal with it on the module that I am sure that te answer lies there.

 

[nosh]

That line gets the game active window ID in order to move and resize it to apply the bezel and locate correctly the game window.

I did not had the chance to look at nullDC special case both for not having the system setup and for the lack of time.

But I am sure that the bezel code is more than robust as it works for a a few dozens different scenarios, and I am sure that wherever problem you are having is not a fault of this part of the code. Whenever I have the time to check this system I am very sure that only with module changes we could achieve the support for it, as until today there was no module that we worked that we couldn't add bezel and hyperpause support.

Meanwhile, for sure everybody will be most glad if you can make it work. Just try to focus more on learning the behavior of the emulator window on windowed mode and on adding code to deal with it on the module that I am sure that te answer lies there.

First, I don't have any reason at this point to think that the problem would be caused by bezel.ahk. I just wanted to understand what all the calls are doing within a module.

Emu's like nullDC and Demul have always been problematic with regards to controlling the window. I guess the first problem to tackle is that when the emu is run from the module it becomes active and on top of fade for a second and then is hidden. I know there is a console window that becomes active first so maybe that is what is throwing everything off. I don't really know i was just mainly looking for some guidance, tips, ways i could troubleshoot so i don't spin my wheels. Ill look at some of the other modules too to see if there is another approach.

 

[bleasby]

It is very difficult to the game window not be the one active when you are ready to play the game as it would not take your keyboard or gamepad commands. But if this is the case, for sure a winactivate command would play a important role before the bezeldraw function call.

I did tried to help step by step rfancella on adding the bezel support for some systems on this thread: http://www.hyperspin-fe.com/forum/s...ding-bezel-support-A-step-by-step-Walkthrough
Take a look at our posts from page 4 and foward. I give some tips over there.

As I cannot test the system right now, maybe you could do the same and I would be glad to help to figure out what can be done.

The only problem on that is that I will need you to test some things before trying to give any suggestion on any problem that could come.

Let me know if you want to work together on that.

 

[nosh]

First, I don't have any reason at this point to think that the problem would be caused by bezel.ahk. I just wanted to understand what all the calls are doing within a module.

Emu's like nullDC and Demul have always been problematic with regards to controlling the window. I guess the first problem to tackle is that when the emu is run from the module it becomes active and on top of fade for a second and then is hidden. I know there is a console window that becomes active first so maybe that is what is throwing everything off. I don't really know i was just mainly looking for some guidance, tips, ways i could troubleshoot so i don't spin my wheels. Ill look at some of the other modules too to see if there is another approach.

Second, bleas your code is awesome and same with yours DJ, i wasn't trying to say it was your code but i get that it could come off like that. Forgive meh

 

[nosh]

I just fixed the problem with fade, i found HideEmuStart() in another module right after the run command, emu no longer pops in front of fade.

 

[nosh]

It is very difficult to the game window not be the one active when you are ready to play the game as it would not take your keyboard or gamepad commands. But if this is the case, for sure a winactivate command would play a important role before the bezeldraw function call.

I did tried to help step by step rfancella on adding the bezel support for some systems on this thread: http://www.hyperspin-fe.com/forum/s...ding-bezel-support-A-step-by-step-Walkthrough
Take a look at our posts from page 4 and foward. I give some tips over there.

As I cannot test the system right now, maybe you could do the same and I would be glad to help to figure out what can be done.

The only problem on that is that I will need you to test some things before trying to give any suggestion on any problem that could come.

Let me know if you want to work together on that.

DJ hooked me up with a new version of the module that contains hideemuobj. That seems to have taken care of the bezel problem for the most part. The window shows up on top of the bezel but is resized and positioned correctly. Also the emu still pops up above fade for a second. At least now there are minor problems to deal with.