FYI - software I've tried.

Gateways by Trauma (assembly98 winner demo) - works perfectly in all modes (8bit, 15bit, 16bit, 24bit, 32bit)

Terra Nova: Strike Force Centauri - movies work, menus work, you can get to "your room", but from there on mouse is mandatory, so I haven't tried ingame yet. Ingame probably requires tweaked modes (modex, modey), but I can't try that before the mouse works.

Transport Tycoon Deluxe: If mouse support is enabled (like in the above alpha), it crashes on startup. If it's disabled, the game seems to work fine, but since it (also) requires mouse..

Death Rally: intro movie and menus work, ingame doesn't show anything. Ingame is most likely tweaked mode, so this is not too surprising. Intro movie has some palette issues, most likely since I'm not tracking vertical retraces at this point.

Hi, Sol_HSA - Interesting work you are doing here. I have not tested your proggy but i hope you will improve it soon. Keep up the good work 😎

Quick status report - I finally figured out the mouse problem. Partially my mistake, partially bad specs.. but it's solved now.

Good news is that the TN ingame, while in 320x200, worked straight away. 320x400 is a tweaked mode and doesn't work currently.

Bad news is that before I write keyboard support, I still can't actually play the game. And since keyboard use in most games is much more low-level than mouse support tends to be, that might take a while (hopefully less time than solving the mouse problem).

Also, the mouse isn't flawless yet.. Anyhow, I might post a new alpha once I get couple of small bugs squashed.

take a look at some parts of dosbox as it provides keyboard and mouse emulation.

Nice work 😀

I hope it will be possible to merge your work with VDMSound, in order to avoid comflicts.

The PC emulation forum may be better suited for the next post (Dege posts his DOS glide wrapper news there).

qbix, I will. Although dosbox and vdm extension are somewhat different beasts, at least it can give me some kind of insight on what applications expect from the keyboard.

zorbid, I don't think there are any conflicts, as long as vdmsound leaves VESA alone =).
I started a new thread on the PC emulation board, posting a new alpha there.

For keyboard you may be better off just forwarding keyboard events from the DirectX window to the original VDMS window and letting it habdle the stuff for now. Mouse is different because of the window size, of course.

V.

Good point on the keyboard. That does, however, create another problem (don't they always) - how to figure out which vdm window is what we should be talking to.

Mouse is more than just window size problem, btw - client app can change the valid mouse region etc. However, mouse is now pretty much done.

Ok, I didn't bother looking into the irq stuff too deeply because of your suggestion, and wrote a routine that finds the correct console with acceptable accuracy. And it works! I can play TN now 😁 😁 😁

A new alpha will pop up later on again..

The way M$ recommends to identify the console window is by setting its title (via the console methods) and then scan all windows for that title and get its hwnd. Don't know if that's what you implemented. 😀
V.

That's what I'd do if the program I'm running in the console was an nt console app. Unfortunately it's an 16-bit DOS application, and thus doesn't have much of an access to the win API =)

SolVBE thus accepts the console if it's either
1. the only console around
2. has 'solvbe' in the title (eg. rungame.bat solvbe command line or some such)

Ah, is this what you meant, Vlad?
http://library.mobrien.com/manuals/mprm_group … sole-shell.html

Whoa, one moment, you mean you don't use a VDD? I think you do, and the VDD has full access to the console API, I can guarantee you that.

V.

Oh, hadn't even considered trying that. =) Somehow I feelt that the VDD is somehow separate from the console it's running in..

I've removed all the alphas now that the beta is out:
SolVBE 1.3b release (VESA driver for WinXP/Win2k)