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
Spread for your judgment, my experimental mini project:
https://github.com/Blitz3DFASM/Blitz3DFASMSDK
The fact that I used Blitz3D in the title violates the copy rights? Another name would not make sense, since this project is associated with Blitz3D SDK. Do you give me permission to use this name?
This written for B3D.dll, I would like to add this DLL directly to the repository. It would be very convenient to use. But it probably violates copyright.
I don't like that the B3D.dll doesn't have network and file functions, it doesn't even have a random number generator... I would like everything to be included into the library, such as in Monodevelop for example.
Do I understand correctly that if you rename runtime.dll from Blitz3D to b3d.dll, then everything will work? I think there are fundamental differences in the work.
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.
I can't handle it, I'm not that great of a programmer... \
And msvc2022 won't even fit on my PC. I usually use something compact like Dev C++ :)
Could I put the B3D.dll library on github? Or Blitz3D SDK is it still paid?
Of course, it would be cool to use the original editor and slip FASM instead of blitzcc when compiling. But it requires huge competencies.
For example if user open *.bb file run blitzcc, if user open *.asm file run FASM.
You didn't answer anything about the naming and copyrights.
In fact, this is strange ... I look other DLL's like openB3D, miniB3D, blast3D, of course they have something innovative, but there is no input processing, there is sound not everywhere, there is no work with the file system. On this side the original SDK is still the most convenient as a standalone dll without the use of BlitzMax and etc... Although Blitz3d runtime.dll has even more features, but it is not a standalone dll as you say. I mean, the SDK project wasn't that bad, although it could have been even better.
