No idea sorry although I've just uploaded a new build so you might want to try that as it should be the latest/greatest version available.
Skimming through the comments to your posts, I'd recommend making sure the code isn't trying to set an 'exotic' graphics mode of some kind (eg: 16 bit color) in fact probably safest to try to get it running in windowed mode first.
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
If you want to use Blitz3D runtime in your own projects, I would probably recommend statically linking with the 'bbruntime' static lib. Just building the blitz3d solution in msvc2022 produces a bbruntime.lib in bbruntime/Release which should be all you need. The bbruntime_dll project is a bit useless as-is, it's designed to be linked with blitzcc compiler output - it doesn't actually export any symbols - the blitzcc output code is 'injected' into the dll as a resource, and linking is actually performed at runtime.
You'll also need header files, which you can either include directly from the blitz3d project, or copy the headers from bbruntime (and any other required dirs) into a standalone 'include' dir. Either way you'll need to set up a buinch of include dirs so the compiler can find them.
