VOGONS


Reply 40 of 53, by Dege

User metadata
Rank l33t
Rank
l33t
kjliew wrote:

Ideally, I would like dgvoodoo to be "Resolution = unforced". Just render at Glide resolution from _grSstWinOpen. Scaling is optionally controlled by host environment using the HWND based on the size of the client area. It doesn't have to scale perfectly, just try the best to keep the aspect ratio and performance. It is OK to leave black borders. QEMU does the same to its 2D SDL display for scaling. OpenGlide would render from lower-left corner and leave black borders on top and right. Resizing window is done prior to activating Glide and the size cannot change once Glide is running. I would like to experiment with this design concept for Glide games that only support 640x480. LFB accesses must be maintained at Glide resolution to make things work.

Then let's just set resolution to unforced in the config file. dgVoodoo currently has no support for applying its scaling modes (centered, stretched, kept, etc.) for windowed mode, as it doesn't really make sense for most of the cases: the content is always stretched along the entire window and it's up to the user how he/she sizes the window itself. The only help is 'Keep window aspect ratio' config option that forces manual sizing operation to keep the aspect ratio of the output resolution (forced, unforced). But this is done through a hooked windowproc too.
So, if I completely remove window hooking for QEmu then Alt-Enter is lost, and window size doesn't change at all, independently on wrapper resolution (forced, unforced), it's up to QEmu to give it an initial size + window sizing ends up in stretched image without keeping aspect ratio.
LFB accesses works because they are independent on window size.

kjliew wrote:

Gulikoza's patch actually resizes the window for dgVoodoo1 based on Glide resolution. It is detecting dgvoodoo1 by the exported symbol "DispatchDosNT". Obviously, this had failed for dgVoodoo2. If you add back the symbol as dummy, then DOSBox will resize the window for you, too.

It's new information for me, thanks!! 😁 😁

Reply 41 of 53, by Dege

User metadata
Rank l33t
Rank
l33t
DosFreak wrote:

I emailed gulikoza a couple of weeks ago and he was planning on working on his patch some more. Dunno if he knows about any of this though. May be worth it to hit him up.

If any new development is going to happen, I'm interested!

Reply 42 of 53, by Dege

User metadata
Rank l33t
Rank
l33t

I have a new build:
http://dege.fw.hu/temp/dgVodooo_2_55_3_Glide.zip

It contains the x64 version of Glide3x. Also, I added the 'environment' option into GeneralExt section. Set it to 'qemu' and dgVoodoo won't horn into window handling and message overriding.

Reply 43 of 53, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

Thank you very, very much! Everythings now work out so great on QEMU with this version of dgVoodoo2. I also checked out Glide resolution scaling for games that only support 640x480 and it works great together with the option for anti-aliasing.

I really hope that one day you will find interests to work on Vulkan/modern OpenGL shaders rendering backend for dgVoodoo2 to make it cross-platform, especially for supporting Linux. OpenGlide is quite long in the tooth with no maintainer to fix existing games issues. Since both DOSBox and QEMU are cross-platform ready, it would really bridge the gap between Window and Linux flavors in getting 3Dfx games to run at their best and continue to work in the foreseeable future.

Reply 44 of 53, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

Hi Dege, did you get a chance to look at Turok 1? I found that dgVoodoo2 does not render the HUD display correctly. Both OpenGlide and psVoodoo handle this game pretty well. I am surprised to see dgVoodoo2 missed it. A demo version (1.01) is available for download that support Direct3D and Glide. I checked out the Glide rendering from QEMU.

BTW, I also checked out Turok 2 Glide3x rendering. The HUD rendered fine with dgVoodoo2, but I think it is too slow to be playable from QEMU. Glide3x seems to demand more CPU power as the games had grown in details over time.

Reply 45 of 53, by Dege

User metadata
Rank l33t
Rank
l33t

I tried Turok natively and it had no problems with dgVoodoo.
Weird, but when I try to run it from QEmu (both full game and the demo) it won't start, complaining 'cannot open Video_3dfx.dll'. The 3Dfx SDK samples work fine though. 😕

Meanwhile I did some modifications:
- grSstWinOpen has the 'hwnd' parameter with FxU32 type. HWND is 64 bit in Win64 so I modified grSstWinOpen to accept a 64 bit hwnd instead of FxU32.
- guTexGetMipMapInfo was also incorrect, it returned a 32 bit ptr instead of 64 bit.

Reply 46 of 53, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
Dege wrote:

I tried Turok natively and it had no problems with dgVoodoo.
Weird, but when I try to run it from QEmu (both full game and the demo) it won't start, complaining 'cannot open Video_3dfx.dll'. The 3Dfx SDK samples work fine though. 😕

I got this from the QEMU WIN32, so the HUD corruption is not related to 64-bit pointers. The HUD for weapons circular list (left) and player stats (lower-left) were messed up with strange textures. In non-benchmark mode, the in-game PAUSE menu and both player stats on the upper left and right corners were also messed up with strange textures.

turok1.png
Filename
turok1.png
File size
381.52 KiB
Views
1497 views
File comment
Messed up Turok1 HUD
File license
Fair use/fair dealing exception

Did you get a chance to build your own QEMU? If not, then I should update your copy with my latest code. I think I may have fixed something along the way. The guest wrapper DLLs need to be updated, too.

Dege wrote:

- grSstWinOpen has the 'hwnd' parameter with FxU32 type. HWND is 64 bit in Win64 so I modified grSstWinOpen to accept a 64 bit hwnd instead of FxU32.
- guTexGetMipMapInfo was also incorrect, it returned a 32 bit ptr instead of 64 bit

I had initial doubt on this, too, but I think you can safely ignore grSstWinOpen. Both OpenGlide and psVoodoo use FxU32 as HWND and the 64-bit version are working fine. It seems that the upper 32-bit of HWND is always 0. WIN64 API would still get back the same HWND when the handle is expanded. OpenGlide Linux does not use the HWND at all. On Linux, it will always be NULL.
I think guTexGetMipMapInfo is disturbing. It is not currently handled by Glide pass-through implementation in DOSBox and QEMU if the guest actually used it. It is only used internally in DOSBox and QEMU such that the return pointer always stays native. But yes, you should return a pointer and for 64-bit OS it is a 64-bit value. Both OpenGlide and psVoodoo already did the right thing of returning a pointer. Since guest address map is always virtualized, host pointers cannot be passed directly into guest even for 32-bit OS. To get this wrap properly, the guest wrapper DLLs need to preallocate the memory and pass the pointer into the host. The host will then copy the data from its native pointer into the guest memory pointer. Do you have any idea that any Glide games actually use guTexGetMipMapInfo?

IIRC, this is the only Glide 2.4 API that is returning a pointer. My goodness, this makes it easy for wrapping Glide API. Glide3x changed that and that requires more work from the guest wrapper DLL to deal with that.

Reply 47 of 53, by Dege

User metadata
Rank l33t
Rank
l33t
kjliew wrote:

Did you get a chance to build your own QEMU? If not, then I should update your copy with my latest code. I think I may have fixed something along the way. The guest wrapper DLLs need to be updated, too.

Could you attach the updated version plz? 🙄

kjliew wrote:

I had initial doubt on this, too, but I think you can safely ignore grSstWinOpen. Both OpenGlide and psVoodoo use FxU32 as HWND and the 64-bit version are working fine. It seems that the upper 32-bit of HWND is always 0. WIN64 API would still get back the same HWND when the handle is expanded. OpenGlide Linux does not use the HWND at all. On Linux, it will always be NULL.

Yes, it's true, in practice the upper 32 bit seems to always be 0 (hwnd's are operating system wide valid, so they are for 32 bit processes too).
My only concern was what if in rare cases or future windows versions it can be 0xFFFFFFFF (signed extended or sg like that) like some GDI handles. But anyway, I'll mask out the lower 32 bit for now.

kjliew wrote:

I think guTexGetMipMapInfo is disturbing. It is not currently handled by Glide pass-through implementation in DOSBox and QEMU if the guest actually used it. It is only used internally in DOSBox and QEMU such that the return pointer always stays native. But yes, you should return a pointer and for 64-bit OS it is a 64-bit value. Both OpenGlide and psVoodoo already did the right thing of returning a pointer. Since guest address map is always virtualized, host pointers cannot be passed directly into guest even for 32-bit OS. To get this wrap properly, the guest wrapper DLLs need to preallocate the memory and pass the pointer into the host. The host will then copy the data from its native pointer into the guest memory pointer. Do you have any idea that any Glide games actually use guTexGetMipMapInfo?

32 bit ptr was because of a dgVoodoo internal thing, other wrappers should handle it properly.
I can't remember if any game uses this function though.

Reply 48 of 53, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

Updated prebuilt QEMU WIN64 in 1st post.
You *MUST* update the wrapper guest DLLs. Glide3x is still very experimental.
You should be able to check out Turok 1 HUD issue. I found that dgVoodoo1 has the same issue on Turok 1, so this must be specific to dgVoodoo texture management.

Reply 49 of 53, by Dege

User metadata
Rank l33t
Rank
l33t

Thanks! Now I can reproduce the error. Even the initial screen is corrupted (missing part from the textured letter 'o' of Turok).
I debugged it and there is something I don't understand.
Letter 'O' seems to be drawn as 4 parts of 64x64 textures, each of them are allocated through guTexAllocateMemory and uploaded by guTexDownloadMipMap.
When guTexDownloadMipMap is called for those textures, the incoming 'src' pointer points to an area where most of the texture data is missing (zero or some garbage for later textures).

See the attached screenshot.

QEMu_Turok_Debug.png
(Ignore '[dgVoodoo] ERROR: GlideCore::UTexAllocateMemory: Texture object (3) is allocated.'. It not an error but an INFO, it's just a mistyping...)

Before each guTexDownloadMipMap, guTexGetMipMapInfo and grTexTextureMemRequired are called, I guess they are for calculating the size of the texture data to copy to a temporary area for guTexDownloadMipMap. A texture 64x64 with GR_TEXFMT_ARGB_1555 requires 0x2000 byte data, but debugging the memcpy call copying to the src area for guTexDownloadMipMap shows that only 0x930 bytes are copied instead. 0x930 bytes means roughly 18 scanlines instead of 64, and that's what I can see on the screen when the texture quad is drawn.

Where does that 0x930 come from? I guess dgVoodoo returns some erroneous value somewhere but I can't see the point of that. GrMipMapInfo from guTexGetMipMapInfo seems to be fine and grTexTextureMemRequired returns 0x2000 as expected.

Reply 50 of 53, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
Dege wrote:

Thanks! Now I can reproduce the error. Even the initial screen is corrupted (missing part from the textured letter 'o' of Turok).

My initial screen looks fine though, with dgvoodoo2.

turok1_01.png
Filename
turok1_01.png
File size
122.58 KiB
Views
1449 views
File license
Fair use/fair dealing exception

Were you checking out the v1.01 demo? There are 2 versions of demo. The older one only has 3Dfx, the new one (which is the one I am testing) support both Direct3D and 3Dfx. The titlebar has "v1.01 (3Dfx v1.0). I only see issues with the HUD and in-game pause menu. The opening intro scenes are fine. They looks the same as OpenGlide and psVoodoo.

Anyway, I will check out the pass-through code around the guTex* APIs that you just described.

Reply 51 of 53, by Dege

User metadata
Rank l33t
Rank
l33t

Yes, you're right, the demo behaves differently. HUD is indeed erroneous (even natively) and I found the bug in guTex* that was exactly the same in dgVoodoo 1/2. 😀

Now the demo works fine, but I still get texture corruptions with the full game.
Turok_Qemu.png

But now I guess it must be because of a potential corruption in my game install inside QEmu (it's OK natively).

I reuploaded http://dege.fw.hu/temp/dgVodooo_2_55_3_Glide.zip with the recent fixes, plz try this again.

Reply 53 of 53, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie
Dege wrote:
kjliew wrote:

Gulikoza's patch actually resizes the window for dgVoodoo1 based on Glide resolution. It is detecting dgvoodoo1 by the exported symbol "DispatchDosNT". Obviously, this had failed for dgVoodoo2. If you add back the symbol as dummy, then DOSBox will resize the window for you, too.

It's new information for me, thanks!! 😁 😁

It's somewhat funny to read that each component has some hack about detecting the other one 🤣

http://www.si-gamer.net/gulikoza