ArkNESS

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: ArkNESS

Post by calima »

Platform agnostic mobile platform... that uses dx12??
thekamal
Posts: 9
Joined: Fri Mar 04, 2022 4:25 pm

Re: ArkNESS

Post by thekamal »

I would port the code to use Vulkan instead of dx12 (or Metal for iOS), when going to other platforms. The code is already partitioned to easily do this...k3 contains most of the platform specific code, and ArkNESS itself is (mostly) platform agnostic.

Anyway, I added a new release which uses the win32 dialog box for opening files.

https://github.com/thekamalp/ArkNESS/re ... el0.1d.zip
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: ArkNESS

Post by Dwedit »

Getting an access violation exception. A NULL pointer getting deferenced.

Happens soon after a call to SHCreateItemFromParsingName, but that might not necessarily be the location of the error.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
thekamal
Posts: 9
Joined: Fri Mar 04, 2022 4:25 pm

Re: ArkNESS

Post by thekamal »

Not sure why that didn't work...but this code was there to add the default directory, which is not required...the win32 example did not do so.

I removed that code in this release...

https://github.com/thekamalp/ArkNESS/re ... el0.1e.zip
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: ArkNESS

Post by Dwedit »

Looks like the program isn't processing windows messages while the Open File window is open, combined with using DirectX, this is seriously bogging down a system. It takes Windows a whole second to process a single keystroke!

I can see the main window become a Ghost Window while the Open File dialog is visible. ("Ghost Windows" are a feature of Windows since Vista where an unresponsive program fades to gray, and pressing the Close button requests terminating that process)

Is the emulator's main Windows Message Loop on the same thread as the file dialog box?

Drawing to a Window, even when using DirectX is done using some decidedly oldschool Win32 code.
* When you want draw a new frame, use InvalidateRect to post a WM_PAINT message into the message queue
* Make sure that code returns to your message loop, don't put in delay loops or wait loops for a time to happen, unless you are processing messages inside those loops (beware of recursion)
* You make WM_ERASEBKGND return 1, just so Windows doesn't try to paint your screen white.
* In WM_PAINT, you use BeginPaint/EndPaint just like an ancient Win32 program, but in between that, you call your DirectX code, including Present.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
thekamal
Posts: 9
Joined: Fri Mar 04, 2022 4:25 pm

Re: ArkNESS

Post by thekamal »

I couldn't reproduce the slow keyboard issue, but I suspect I know the issue. I re-used some code from an old project I had to process the keyboard, and it used a low level keyboard hook. It looks like this hook is used to trap keys that otherwise couldn't. This seems unnecessary for this project, so I disabled that.

The ghost window is definitely a problem, and yes, it's because I had a single thread, which blocks once the dialog opens. I fixed this by creating a second thread that just repeatedly sleeps for a quarter second, polls if we are open menu state, and sleeps again. If we are in the open menu state, it opens the dialog, allowing the main thread to continue to process windows message and repaint the main window.

The one weird behavior is if the dialog is open, and I close the main window, the main window does close, but the dialog remains open. Once I close the dialog, the application does terminate correctly, but ideally it would be better for the dialog to automatically close once the main window is closed. I've made several attempts to do that, but no luck...

https://github.com/thekamalp/ArkNESS/re ... el0.1f.zip
Post Reply