itch.io

Ping

Is the download right here on this page, the new release?  Or is it elsewhere?   

Hi Mark,

Thanks, I'll look for the new build.  

I haven't gone back to the page I linked, to refresh my memory of what's been said, and it's also been a while since I was actively chasing this, so apologies if I either repeat myself or speak incorrectly.   I have yet to find a solution. 

If I recall correctly, the program does work correctly, even under Windows 10, if run under just the right circumstances -- "windowed, with the Debugger enabled,"  I think it was.  This suggests to me that maybe that particular combination causes the program to run in a sort of "controlled" or "captive" environment where Blitz3D has control and provides a DirectX (7  or 9 or whatever) environment  that got compiled/linked into Blitz3D itself when it was compiled, "back in the 90s" or whenever -- whereas running the program "full screen" and/or without the Debugger -- and especially as a standalone .exe!  --  makes the program dependent on the environment provided by the OS and its current DirectX (11?) environment.  That, then, places the blame squarely on "them" in that they seem to have broken, or at least changed in a fundamental way that breaks this program, something in DirectX itself.   Considering how few lines of Blitz Basic code are actually involved in The Part That Doesn't Work Any More (tm me), it ought to be fairly straightforward for someone (such as yourself, perhaps? -- who knows DirectX well enough to have created Blitz3D in the first place) to look at exactly what's going on and what's changed.  Feel like looking into it for me?  Pretty please?  :-)

If you or anyone else are able to investigate that and nail down the exact details, someone might be able to submit a bug report sufficiently specific to get attention.  I expect that reporting "this one specific feature of  program written in a language processor that was written in the 1990s, doesn't work on Windows 10," isn't going to get much traction.   I'd still report, it, though, if I knew where DirectX even comes from, and to whom to report it; is DirectX a Microsoft thing?  I can't believe I don't know.

Anyway, thanks again for the reply.  I'll pop back in here either if I have difficulty finding/installing/using the new build, or if it doesn't fix the problem.

Chris

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.

(Quickly popping in to see if anything has been added to this thread in the last ~90 days.  Nope.   I guess I could add that I did go to the Gunstar link, but declined to download it because it -- oh, the horror! -- costs money.  Yeah, I'm a cheapskate.)

Hi Mark, and everyone else!

I'd be interested in hearing your thoughts on the strange behaviors outlined here:  https://itch.io/t/1985876/still-not-perfect-on-windows-10

Cheers,
   Xet

Heheh...  Windows developers for 27 years...  do you mean just in BB, or on Windows in general?  Lord knows, every time I've tried to develop any kind of "serious" software on/for Windows I've run into various unsolvable rendering issues between development platform and deployment, that have made me look stupid and may even have cost me one job...   Hence why I've tended to avoid Windows as a platform for any "serious" paying work...  

But I digress.

Thanks in advance for the pointer to Gunstar; I may check it out when I have time.  

Guess I'll just have to continue fiddling with Z-Virus to the extent that time and talent permit...    I still wish I had a better understanding of exactly what's wrong with the thing, though.

Hi  skid,
Thanks for the suggestions.  I'm not sure what version of Blitz3D I've been using up til now, and it's a bit of a nuisance to boot up the computer on which these results were obtained.  But I followed your link and downloaded and installed v1.108 on a Windows 10 machine that has not previously had Blitz3D on  it at all.  I then went out and downloaded a fresh copy of Z_Virus with source and executable.

Alas, results were very mixed, and not at all what I want.

Running the existing executable, of course, the game comes up fullscreen and I still get the black ground, not surprisingly.   Opening the source .BB file in Blitz3D and running it from there, I can't tell, because the game locks up --  the main menu appears, but it doesn't respond to the keyboard, including not responding to Ctrl-F4 -- even when run in Windowed mode rather than fullscreen.   Its an especial nuisance in fullscreen, though, because I had to finagle-finess-and-connive a way to get out of it, when it wouldn't relinquish the screen to Desktop apps!   Alt-TAB had no effect at first but, fortunately, Ctrl-Alt-Del still worked, and brought up a menu that managed to supersede the game screen at least temporarily.  Selecting Task Manager from there returned me to the game screen; the normal Windows Desktop mode did not yet reappear.  But Alt-TAB had become responsive, and I could at least see "thumbnail" views of everything that was running -- large enough, in fact, that I could almost read e.g. the text in a cmd window -- and thereby discover that programs I launched, by blind typing Windows-R and a command, were being launched, and were responding to the keyboard -- they just weren't able to "punch through" the DirectX game screen and become visible, because the gameprocess was jammed up so solidly.   (In Windowed mode, the jammed-up game's window just sits there "in the way" of trying to do anything else; it can't be repositioned, resized, or closed, by mouse clicks or keypresses. )

I managed to  bring up a cmd console behind the game screenand try a taskkill command, but couldn't remember the syntax.  I did, however, happen to do a tasklist command, direct the output to a file, open that file in Notepad, accidentally type stuff into it, and attempt to close it prior to giving up and rebooting -- and that was what saved my butt.  The shutdown phase of the reboot discovered Notepad's SAVE dialog was open (because I had made changes to the file!), and popped up a warning dialog that allowed me to cancel the shutdown/restart -- happily, after it had successfully killed off the stuck Z-Virus game and restored the screen mode!  

SHEESH.

Oh, and somewhere early in all that, the program wouldn't start at all because a new-built .exe couldn't find fmod.dll.   Running the program by its full pathname while cd'd to Blitz3D's bin folder where fmod.dll lives, solved that problem but resulted in the game being unable to find its external data files.  I had to copy fmod.dll from the bin folder to the same folder as the Z_Virus.exe program file.  This is the case only for .exes built fresh from source, here and now, by me -- the .exe supplied in the download does not have this problem.   I have no idea how or whether I can change a setting somewhere and get a new-built .exe that works like the downloaded one.  Do you know?

(Oh, and the very first couple times I tried to run it, it "couldn't get graphics mode," or words to that effect, and finally after a few tries I found lurking behind a couple other windows a dialog prompting me to install DirectX from a supplied link.   But I guess we expect that.)

So.  After the initial debacle outlined above, I figured out the syntax of the taskkill command and created two batch files, one to kill off z_virus.exe and the other to kill off blitzcc.exe, depending on which way I had launched the program.   Unfortunately I then discovered that I had insufficient access / privilege to kill off the process I had launched (which seems stupid) and had to launch that cmd window "as Administratror" in order for taskkill to succeed.  Finally got all the pieces in place to where I could kill off the stuck game process by just Ctrl-Alt-Del to get Alt-TAB working, then using Alt-TAB to select the cmd window and blind-typing the name of the appropriate batch file!

And it's a good thing, too, because most combinations of different values in the fourth parameter of the Graphics3D command, the Debug On? setting, interactive vs compile-and-standalone launch, etc., produced lockup.  Only briefly, running in a window with I don't remember what exact combination of the other factors, did I get an instance of the game that ran with entirely correct graphics, including the ground plane.   Other failure modes, though, included:  (1) Black ground and black background on radar map; (2) NO SOUND (!); and (3) Same old, same old, Windows 10 black ground.  Mostly, though, the thing just locked up.  I have yet to rediscover the combination of things that gave me that one brief moment of perfection, but I do know that I have been absolutely unable to obtain it from a compiled .exe of the program.   Tell me step-by-step exactly what you do, that makes it "work right."

I should probably point out that I'm doing this on a computer that does not have a dedicated graphics card (I don't think any of my three Windows 10 machines do), just the cheap-$#!+ Intel Graphics chip on the motherboard...  But then, that was also true of my XP laptop where this has worked perfectly for years, with "no muss, no fuss," so I have to question whether that could even be a factor.

Anyway -- we're (or at least I'm) not quite out of the woods yet.  Your thoughts?

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....)

I got interested in Blitz3D because one of my favorite games, Stevie G's "Z-Virus" (a port of an Acorn Archimedes game called "Zarch") comes with .BB source code.  I only just discovered in late 2021 that I could download Blitz3D for Windows, and have been having a lot of fun with it, including recompiling from scratch.  (A big piece of my motivation is that there's a "v2" of Z-Virus, but the precompiled binary has always set off my antivirus software, so I couldn't run it until after recompilation from source.  That generated a smaller (!) binary that does not set off antivirus, by the way.)

All of that was on 32-bit Windows XP on a 2008-vintage HP Pavilion laptop.  Worked great.  Gameplay has you flying a little ship over a gently-rolling ground, textured with colors indicating degree of viral infection, over which the author, through clever programming, managed to overlay black shadows of your own and enemy ships.  On 64-bit WIndows 10 on a completely-different, newer, HP Laptop, the game runs, and can be played -- but the "ground," instead of being textured, is rendered in solid black except for a thin border of the expected texture colors, around its perimeter. 

My gut feeling is that whatever tricks the author is playing to get realistic shadows in Blitz3D, they simply don't produce the same visual effects in the new environment as they "always did before."  I have the newest graphics drivers (apparently much newer than can even be had from HP's own website), and Windows did prompt me to install DirectPlay -- and I did it -- when I first ran the game.  

So: (1) something's different, and (2) anybody have any ideas of what/why, and any ideas for fixing it?