Messages

1

Games / Re: RetroArch Port

« on: November 18, 2024, 11:53:05 am »

Hi.

I did understand, that you disabled this stuff. My point was that you should not concern yourself too much with getting this to work. Cores will be enough work by themselves ;-)

2

Games / Re: RetroArch Port

« on: November 18, 2024, 09:17:29 am »

Well I understand, that on an RaspberryPi, you would want that functionality, but I would just #ifdef Discord out.
Downloading of cores would also mean, you or someone would have to host the OS/2 specific core files. I don't know that it would be worth the hassle.
Rather I would have some RPMs or WPIs, which install some cores.

3

Games / Re: RetroArch Port

« on: November 15, 2024, 09:02:56 am »

Hi Martin,
the next few weeks will be truly a handful both at work (where I have an ArcaOS VM) and in theatre, but I'll see what I can do. RetroArch would be really cute to have. It was tricky to port it due to its SSL libraries which rely a lot on IPv6 but I managed somehow - and I feel OS/2 would profit a lot of a new TCP/IP stack (which, I'm afraid, we will not see).

Mentore

Which feature needs networking? Is it for downloading core etc.?

4

Programming / Re: ClassiCube porting thread

« on: November 10, 2024, 01:04:55 pm »

Hi Jochen

I tried starting ClassicCube and was rewarded with this message

"Some required resources weren't found
OK to download?"


What are the "required resources"?


Regards

Pete

Classicube will download all the files it needs to the executable's directory.

5

Programming / Re: ClassiCube porting thread

« on: November 08, 2024, 03:22:49 pm »

I have just compiling the newest ClassiCube version.
It now has sound and music. I use libkai (a static version for now, so no installation needed.).
What I observed on my T480 with uniaud, is that music and sound will hang after some time, and I can resume sound by playing something else like a system sound.
Anyone has an idea, what to do about it? Can somebody without Uniaud please test the sound?

6

Programming / Re: DOSBox-x - infinite loop in configure/make

« on: November 08, 2024, 09:25:17 am »

In DOSBOX, drive is a char array, but on DOSBOX-X it seems to be a struct or object. So, there is some work to do.

Yes, I should have looked at drives.h

Sure. I already thought, it wouldn't be a straight compile, because of all the native GUI element DOSBOX-X has.

7

Programming / Re: DOSBox-x - infinite loop in configure/make

« on: November 07, 2024, 09:01:42 am »

In DOSBOX, drive is a char array, but on DOSBOX-X it seems to be a struct or object. So, there is some work to do.

8

Multimedia / Re: Can aswitch.exe be used for always connected/attached usb speakers?

« on: October 23, 2024, 03:25:19 pm »

@Lars: It was a typo. I corrected my post.
The source code should be on BWW's Github. IIRC, the old SDL2 audio was an almost straight copy from SDL.

9

Multimedia / Re: Can aswitch.exe be used for always connected/attached usb speakers?

« on: October 22, 2024, 10:45:32 am »

Hi Lars

The SDL package in use is SDL-1.2.15-5.oc00.pentium4.rpm (from netlabs-rel) which provides the sdl120.dll required by dosbox074_2020-11-04.wpi which seems to be the latest release.

No response to my email to Jochen


Regards

Pete

@Pete: Sorry, I was sick. You got a response ;-)

To clarify: DOSBOX proper only uses SDL. The maintainers have explicitely stated, that they don't want to use newer SDL libs and stay with SDL.
I haven't looked into DOSBOX-X or other forks, yet.

10

Programming / Re: Development Help with INF2Html

« on: May 13, 2024, 08:24:35 am »

The generated HTML for the lists is completely wrong. You don't put <ul> inside <ul>.
You have to do something like the following:

Code: [Select]

<ul>
  <li>WC_BUTTON<br/>
Consists of buttons and boxes that the operator can select by clicking the pointing device or using the keyboard. These messages are described in <a href="...">Button Control Window Processing.</a>
  </li>
...
</ul>
you can also try to wrap the explanation in <p> making it its own paragraph, then you don't need the <br/>. But I  don't know ATM how that would look.

11

Programming / Re: ClassiCube porting thread

« on: May 10, 2024, 02:39:02 pm »

I will create a ticket next week, as I'm away doing other retro stuff.

12

Programming / Re: ClassiCube porting thread

« on: May 08, 2024, 02:01:34 pm »

[..]
On all occasions, the trap does not happen in the main thread. I suspect some problem with the File Dialog obscuring part of the window drawn to by DIVE and the DIVE thread trapping rather than "WinFileDlg". In all cases, it is running out of stack.

Do you mean, Dive itself spins up thread. I myself wait for CC to call me for an update without doing the blit in a thread.

One more data point, I could get, was, that when call WinFileDlg directly after WinCreateMsgQueue, the dialog stays up (without showing any files), but after that CC can't create any (p)threads, and so stops.
Something is really screwing up the memory.

FOC DNU list is less than ideal, but could be a solution.

13

Programming / Re: ClassiCube porting thread

« on: May 08, 2024, 08:47:43 am »

I have attached a new executablewith my most recent version.
Can somebody with the eCoSoft runtime installed, please test it.
Please start a single player game, then press ESC. In the menu, please click on "Load Map", and then on "Load File".
If everything works, and you exit, the application will put up a crash message. I don't have investigated that.

14

Programming / Re: ClassiCube porting thread

« on: May 08, 2024, 07:14:57 am »

This is not correct.

Actually, Lars is correct. 'args' is the setup struct from ClassiCube, and filters is an array of pointers (more acurate a pointer to pointer )

@Rich: Thanks all the same, anyone thinking about the problem could be bringing us nearer to the problem. And yes, you are correct, copying a simple string to fileDialog.szFullFile is a better solution, but I verified this already

15

Programming / Re: ClassiCube porting thread

« on: May 08, 2024, 07:06:23 am »

1) Since the trap occurs in "WinRequestMutexSem" (which you are apparently not directly calling from anywhere), I suspect it has something to do with calling "WinSetVisibleRegionNotify" before calling "WinFileDlg" and after calling "WinFileDlg". My gut feeling is that it is a problem surrounding the call to "WinFileDlg" with these calls. As a test, I'd remove that

I added these calls just recently. With or without them the app crashes.

2) "args->filters" is effectively a PAPSZ pointer, that is, a pointer to an array of pointers where the last pointer in the variable array is a NULL pointer, see the example code for the Windows implementation:
[..]

You are correct, but that's why I did '*(args->filter)' which let's me copy the first string to fileDialog.szFullFile. Also, I have used 'char szFullFile[CCHMAXATH] = "*.*"', and copied it to fileDialog.szFullFile. The app still crashes.

I suspect, that thread 0a from the popuplog is spinned up by the dialog, since it's always the last one, as per process dump.