Hi Skid,

No apologies necessary -- I am 70 days late in even seeing your reply.  (Should I have received a notification, via email perhaps?  I wonder where it went?  Did I simply miss it?  Dang.  Too many webpages, too many browsers, too many computers.  "Where did I see that? How do I get back there?"   Thank goodness I left this page open in a browser on a hibernated (not shut down) laptop, or I'd probably never have found my way back here at all!)  I'll continue to leave it open, and try to remember to check it once in a while.

As of two seconds ago, I was able to download Z-Virus for 32-bit Windows -- a precompiled .exe and all the source, model data, etc., files necessary to build-and-run it "from scratch" in Blitz3D -- from https://archive.org/download/ZVirus/Z_Virus.zip .  If you nibble off the filename portion of that, you'll get to a top-level page where you should be able to navigate and possibly also find V2.   (Since first posting here, I've heard that compiling Blitz3D source with the BlitzMax (I think that's the name; the "next version" after Blitz3D) compiler produces .exe files that give false positives in certain antivirus software, so after 20 (?) years I'm officially standing down from Red Alert on the subject of my antivirus engines always flagging the precompiled V2 .exe file....)

I'll be interested in hearing what you're able to figure out.  I haven't had time to do any further investigation, myself.   (Too busy getting dozens of other things to work under Win 10, that I got used to over fifteen years' use of XP....)

Hi Noah,

Good to see you, and thanks!  I'll reply to your specific points in a moment.  However, I, too, happened to get the "itch" (pun intended!) just tonight, to look at this again, and while I can't say I "got any further," I can now characterize the failure mode a little better.  I'll talk about that first.

It turns out that there are  three factors involved.  (1) Whether I run the program windowed or fullscreen; (2) Whether the Debugger is on or off; and (3) Whether the program is running "within the IDE" or "compiled, standalone."  Specifically, the only combination that works entirely correctly is "Windowed, in the IDE, with the Debugger on."   Changing any of those things leads to various failure modes.

Turning the Debugger off, or changing the Graphics3D() mode argument to force "fullscreen always," results in the initial game menu appearing on the screen, but the entire program locking up, to the point where it won't accept keystrokes for menu navigation, Alt-F4, or Alt-TAB.  It took me a while to find a way out of this situation: first, Ctrl-Alt-Del to get to the screen where you can shut down, launch the Task Manager, etc.  Then either initiate a Shutdown which you can then cancel after it has forcibly terminated the locked-up game, or use Alt-TAB, which now does respond, to navigate to a Command window, running "as Administrator" and poised to execute a script that issues a TASKKILL command that targets the game process.  The downside is that you have to have remembered to prepare that window before running the game... ;-)

Building a standalone executable exhibits one of two pathologies: with the Debugger disabled/off at compile time, the resulting standalone executable locks up exactly as described; the only difference is that you have to give the TASKKILL command a different process name in order to kill it.  With the Debugger enabled/on at compile time, the resulting standalone executable actually runs "normally," except for two problems: first, the "black ground" bug that brought me here in the first place, and second, there is no sound.

The downloaded standalone executable -- built, one assumes, years ago by Stevie G. -- responds to input, has sound, and would be perfectly playable except that it exhibits the "black ground" problem.

As a software engineer with unfortunately little information on the innards of Blitz3D, Direct<anything> in general, Windows GPUs and shaders, etc., the best I can hypothesize is that "it's almost as though the Blitz3D IDE itself carries with it its own little cocoon of 90s-era DirectX, or whatever, with some functionality being provided by the IDE itself and some being provided specifically by the Debugger.  (Clearly there is some difference between running a program in a window and fullscreen, and clearly there is an interaction with the debugger, judging just from the way Graphics3D's mode argument works.)   Obviously Blitz3D when it was compiled, and the downloaded standalone Z-Virus game executable, were built in an environment where, most likely, the "internal/cocoon" DirectX environment within the IDE, and the "external, host system" Direct___ environment, were the same.  So what "worked in the IDE" also "worked exactly the same in the outside world."  Thirty years later, things have changed a bit ;-), this is no longer true, and whatever Blitz3D is doing in "creating an executable," is no longer compatible with the latest "outside world" installed version of DirectX.   So is there a way to install an old(er) version of DirectX -- such as that which "just works, on my 32-bit XP laptop" -- in Windows 10, just for the exclusive use of Blitz3D?

The fact that the downloaded Z-Virus executable doesn't suffer total lockup, or lack sound, tells us that it represents some entirely other combination of pieces, put together by tools apparently not available to the ordinary Blitz3D user.   It seems to incorporate within itself the 90s-era functionality it needs for reading the keyboard and playing sound -- while lacking that which allows shadows to be rendered properly on the "ground."

Now, Noah my friend, on to your specific remarks.

I believe I got past the 16-color (are you sure about that?  It's not 256-color?) issue very early on, in order to even get far enough to open this conversation to begin with.  But thanks for clarifying.  How did you determine that that is what's happening?

You are "preaching to the choir" with your disgruntlement at 24-bit "TrueColor" graphics hardware not being able to emulate "16-bit" etc. (actually, "indexed"  or "pseudocolor") graphics modes -- I've been b*tching about that since the 1990s!  I started out trying to display 24-bit RGB images on 8-bit (256-color), indexed/pseudocolor screens under the X windowing system -- and then had to scrap it all and rewrite from scratch for 24-bit TrueColor displays when those came in and turned out not to emulate the 256-color indexed mode!  (This was especially infuriating because X anticipated that, and made it possible to ask the environment to give you the type of display behavior you needed, and implicitly encouraged you to believe that a variety of modes would generally be available for the choosing, and supported a lot of rigamarole that went into writing code that could make the best possible use of whatever hardware it found itself talking to -- but I observed very quickly that manufacturers generally didn't bother to implement any but the one mode they were in love with, making a lie of the whole portability thing those guys at MIT had sweated so much blood to implement...)   To this day, I have programs that I wish I could make run in 256-color, indexed, mode, because that would save me from having to try to approximate it in the application's code.  You know what I mean.   But enough about that.

What do you mean by "SuperF4"?  Is that simply what I would call "Alt-F4," or has something new been introduced since XP days?

I just tried your recommendation of changing the 16 -- oh, duh, that's how you knew the program was trying to operate in 16 colors! :-o -- to a 0, and it did improve things a tiny bit -- but alas, not enough.   I can now get proper shadows in Fullscreen mode (!), even in a standalone, compiled executable -- as long as I leave the Debugger enabled.   The only problem is that these instances don't have sound.   Changing the code to run windowed rather than fullscreen fixes that -- but why the heck?!?    I'd really prefer to run (or at least have the option of running) this thing fullscreen.

I haven't had to copy any DirectX DLLs to the local directory to get Blitz3D or Z-Virus to run -- but the way you phrased it, sounds like I might get an improvement if I put the "old version of DirectX" DLLs in the local directory!    Hmm...

If only this were VAX/VMS ;-) , I would be able to write my own tools to pick apart and put together .exes "any way I wanted."  I have no idea  how things work on Windows, though.

It looks to me like the drawing of shadows is done by simply having a camera, looking straight down and doing an orthographic rather than perspective, projection of pitch-black (0, 0, 0) renderings of all objects, onto a full-white (255, 255, 255) background, into a dedicated texture buffer, and then blending that texture with the "ground" using "multiply" mode (the default).    One way to get a completely solid black ground would be if that rendering is failing; another would be if the texture is getting zeroed out (the equivalent of a big black shadow filling the whole thing!) somewhere along the line.  I've tried to investigate these as best I can, but perhaps you can do better.  Commenting out the ShowEntity and HideEntity statements in the "shadows" section of function TERRAINUpdate(), I am able to get a display that shows the black-shadows-on-white-background where the game's HUD ought to be; they are getting generated and are not being wiped out to all black, at least not at that point.  I tried copying, to that same section of TERRAINUpdate(), the statements used in GAMEInit() to set up the solid-white background in that texture in the first place, but that doesn't seem to have any effect.  Something just isn't working in the final, graphics-rendering step of blending that shadow texture into the ground object.

Midnight?  Hah.  It's 2:35 AM, here. :-)

Again, thanks.  I look forward to whatever else you can discover.   I'll post here myself if I get a chance to try dropping "old version" DirectX DLLs into the local folder.   That'd be a painful way to have to do all this, but I'll do what I must.

Last-minute edit, late-breaking weirdness.   I was going to try One More Thing -- set the Blitz3D-built new executables to "run in 256-color mode," "XP compatibility mode," etc. and see if that made any difference.  First, though, I wanted to check to remind myself (it's getting late, right?) what the fullscreen behavior of my latest executable was.  I launched it -- and it came up, fullscreen, fully operational, including menu navigation, keyboard input, and proper shadows.  I just about had a heart attack.  "I didn't change anything!"  So I exited out of it, and noticed that in starting up it had put up a small  "unable to set graphics mode" dialog (at least, I think it was this program that did it; for all I really know, though, it could have been lurking back there half the night) and -- something I forgot to mention -- a whole separate, empty, window, that comes up before the game proper (even in windowed mode).  I wanted to "see that again," so launched the same program again -- and this time it didn't work -- was right back to the "no sound" failure mode I described earlier.

I'd sure like to know WHAT THE HECK WAS DIFFERENT ABOUT THAT ONE RUN, that for one  brief, shining moment everything worked--?!?   Now we have to start looking at environmental dependencies and interference from other code.  Good grief.

Ping