@hwnd%

[Richard Russell]

I can surmise from this that there are a whole set of calls to the d3d api that are 64bit and thus changing over could be very difficult.

I don't think that's at all likely, it's not the way Windows libraries usually work: generally the 64-bit library and the 32-bit library have identical function names and templates. There may be a very small number of exceptions but they're rare, certainly not a "whole set".

List an example of an API function which appears to exist in the 32-bits DLL but not in the 64-bits DLL.

Questions like does d3d still operate with float4 variables etc.

I'm sure it does, yes. The way these things usually work is that the 32-bit and 64-bit libraries share the same source code (typically in C or C++), the only thing determining whether a 32-bit or 64-bit DLL is generated is the compiler. Therefore if a data type is declared as float in the source code it must necessarily be 32-bits in both DLLs, similarly with double (64-bits float), int (32-bits integer) etc.

My experience with porting code from a 32-bit platform to a 64-bit platform is that it's generally straightforward. Obviously addresses / pointers (and in many cases that also includes handles) must be stored in variables able to hold a 64-bit integer, and sometimes alignment changes (which can alter the layout of a structure).

You may find it helpful to look in one or more of the 3D libraries used by BBCSDL (ogllib.bbc for OpenGL, gleslib.bbc for OpenGLES and webgllib.bbc for WebGL) which are all compatible with both 32-bit and 64-bit platforms. You will find a few bits of code which test whether it's 32 or 64-bits and does something slightly different, but not much.

I describe the main things that you need to be aware of when adapting code to be 64-bit compatible in the differences document.

[Ric]

Thank you, I will take a look because I am interested in trying to get d3d on SDL, the memory allocation is far greater and would allow for many more vertices to be stored.
It will be in a few days time, I am working away this week, but it takes that long for me to digest the information.

[Richard Russell]

Thank you, I will take a look because I am interested in trying to get d3d on SDL, the memory allocation is far greater and would allow for many more vertices to be stored.

As I've said before, another approach would be to port your code from Direct3D to OpenGL (or WebGL) which would offer the same increase in memory availability but greatly increase the number of platforms on which it could run. Windows seems to be falling in popularity quite quickly.

Since I believe much of your application is shader code it would probably not need to be changed in any major way. I think Direct3D uses a left-handed coordinate system whereas OpenGL is right-handed, so that would mean a small alteration.

[JeremyNicoll]

Experience of SDL is not what i need, i have written several programs in SDL ...

But ALL of them, apparently not issuing any SDL_xxx calls?

It seems to me that you also don't know how to 'read' an SDL function template - and maybe also Win32 API call templates - aimed at C (or C# or C++) programmers, & convert those to BB4W equivalents.

In your position I'd look at a known-working BBC SDL program, find its uses of "SDL_xxxx" functions & then compare the SDL documentation for those functions with how they're actually used in the BBC SDL code, until you understand how descriptions map onto use.

So... look in a BBC SDL download, in: examples\tools\SDLIDE.bbc. Search through it for every mention of "SDL_". Yes... there's a few constants, but very soon you find some examples of /SYS/ "SDL_xxx" calls. So it should have been obvious that SYS is the method, not CALL. If you search for ' SYS "SDL_ ' you'll find all such SDL_ function calls. Learn from them.

[JeremyNicoll]

In your position I'd look at a known-working BBC SDL program ...

Another place to look: lib\gfxlib.bbc ... & possibly some of the other \lib files, though quite a lot of them have no SDL-specific code in them.

[Richard Russell]

I don't think that's at all likely, it's not the way Windows libraries usually work: generally the 64-bit library and the 32-bit library have identical function names and templates.

I asked DeepSeek AI and it said the following

"When coding Direct3D applications for both 32-bit and 64-bit platforms, you need to consider several key areas:

1. Pointer and Handle Sizes
   - `HWND`, `HANDLE`, and pointer sizes differ (4 vs 8 bytes)
   - Be careful with pointer arithmetic and casts:

   Code: Select all

     // Avoid assuming pointer fits in 32-bit integer
     DWORD_PTR ptr = reinterpret_cast<DWORD_PTR>(pObject); // Use DWORD_PTR
     

   - Use `UINT_PTR`, `INT_PTR`, `DWORD_PTR` for pointer-sized integers
   
   
2. Structure Alignment and Packing
   - Structures passed to Direct3D may have different padding:

   Code: Select all

     #pragma pack(push, 1)  // Ensure consistent packing
     struct ConstantBufferStruct {
         XMFLOAT4 data;
         // ...
     };
     #pragma pack(pop)
     

3. COM Object Reference Counting
   - COM method signatures remain the same, but underlying implementations differ
   - Ensure proper `AddRef()`/`Release()` usage - 64-bit doesn't change COM rules
   
   
4. Window Procedure Signatures
   - Ensure `WNDPROC` uses correct types:

   Code: Select all

     LRESULT CALLBACK WndProc(HWND hWnd, UINT message, 
                             WPARAM wParam, LPARAM lParam);
     // WPARAM and LPARAM are pointer-sized
     

5. Shader Compilation
   - HLSL shaders are platform-independent, but compiled shader binaries differ
   - Store separate shader binaries or recompile per architecture:

   Code: Select all

     #if defined(_WIN64)
     const char* shaderFile = "shader_dx11_x64.cso";
     #else
     const char* shaderFile = "shader_dx11_x86.cso";
     #endif
     

6. Buffer and Resource Sizes
   - When calculating buffer sizes, use `size_t`:

   Code: Select all

     size_t bufferSize = numElements * sizeof(Vertex);
     // Not: DWORD bufferSize = ...
     

7. Function Pointer Types
   - Callbacks and function pointers need proper casting:

   Code: Select all

     typedef void (CALLBACK* PTR_CALLBACK)(void* pData);
     // Use void* for data pointers
     

8. Direct3D 11 Specifics
   - Most Direct3D 11 interfaces are architecture-agnostic
   - Pay attention to:
   - `D3D11_BUFFER_DESC::ByteWidth` (UINT, but ensure calculations don't overflow)
   - `ID3D11DeviceContext::Map` - pointer parameter is `void**`
   - Constant buffer sizes (must be multiple of 16 bytes on both architectures)
   
   
9. Third-Party Library Dependencies
   - Ensure all linked libraries match architecture
   - Common issues with:
   - Effects library (FX11)
   - D3DX libraries (deprecated but still used)
   - Texture loading libraries
   
   
10. Debug Layer Compatibility
    - Direct3D debug layer has separate 32-bit and 64-bit versions
    - Ensure correct debug library linkage:

      x86: d3d11sdklayers.lib
      x64: d3d11sdklayers.lib (different binary)
      

Some of those probably don't affect BBC BASIC programs, but they confirm that changing function names is not an issue, so I'd still like to know what function you were trying to call which seemed to be missing in the 64-bit environment. Ideally create an MRE (Minimal Reproducible Example) which I can run - I don't have to understand it if I can simply run it and observe an error message.

[Ric]

Thanks guys, I will try to limit the code, but it might be difficult to get it small enough. As you know, for d3d you need an awful lot of set up just to get things going.

[Richard Russell]

Thanks guys, I will try to limit the code, but it might be difficult to get it small enough. As you know, for d3d you need an awful lot of set up just to get things going.

But didn't you imply that it fails quite early on? In which case all you need to include in the MRE is the code up to that point, I don't want to see anything after the point of failure. Anyway, if the issue is that an API function doesn't exist you don't need to bother with setting up the environment, because it is irrelevant; testing the function call alone is sufficient.

Here's an example of what ideally I'd expect such an MRE to consist of:

Code: Select all

      SYS "SDL_LoadObject", "example.dll" TO dll%%
      SYS "SDL_LoadFunction", dll%%, "FunctionName" TO Function%%
      IF Function%% = 0 THEN ERROR 100, "No such function FunctionName in example.dll"
      SYS Function%%, first, second, etc TO result%%

Substitute the name of the DLL and the name of the 'missing' function and you have a complete MRE in just four lines!

[Ric]

My appologies for the delayed response,
I have looked through as many programs as i can and am not really any wiser, I have tried changing my BBCSDL IDE to the 32 bit version to see if that helps, but not to my understanding.
Unfortunately I am going to have to conceed that the migrfation is not going to happen from me, my knowledge of what to do is not good enough. It is a shame because the memory available is a big draw. Ho hum.
For example:

Code: Select all

 
   120 GUID_ID3D11Texture2D = FNguid("{6F15AAF2-D208-4E89-9AB4-489535D34F9C}")
   REM rest of program
   130 END
 
 1890 DEF FNguid(strCLSID$)
 1900
 1910 lenCLSID% = 2 * LEN(strCLSID$) + 1
 1920
 1930 DIM pCLSID%% 30
 1940 DIM psCLSID%% lenCLSID%
 1950
 1960 pCLSID%% = (pCLSID%%+15) AND -16               : REM Align on WORD boundary
 1970
 1980 SYS "SDL_LoadObject","OLE32.DLL" TO OLE32DLL%
 1990 SYS "GetProcAddress", OLE32DLL%, "CLSIDFromString" TO CLSIDFromString%
 2000
 2010 SYS "MultiByteToWideChar", 0, 0, strCLSID$, -1, psCLSID%%, lenCLSID%
 2020 SYS CLSIDFromString%, psCLSID%, pCLSID%
 2030
 2040 = pCLSID%

This is the first bit of code it fails on.
I have changed what i can from reading the documentation but............

Thanks for the advice guys and if anyone else wants to try getting D3D11 to work on BBCSDL I have a whole set of tutorials from setting up to creating shadows etc that you can have to experiment with.

[Richard Russell]

This is the first bit of code it fails on.

When I run the code you listed, it fails with a 'No such variable' error in line 2020 for the trivial reason that you use pCLSID%% (64-bits) in one part of the code and pCLSID% (32-bits) in another part of the code. In other words, it's just a typo!

If I change it so the 64-bit variable pCLSID%% is used throughout it works (at least, it does in 32-bit BBCSDL, there are some other changes of pointer variables from 32-bits to 64-bits which will of course be necessary)!

To reiterate what I've said before, you can access Windows API functions from BBCSDL code, if it's only going to be run in Windows. Obviously if you're porting it primarily to get more memory you need to be aware of changes necessary when moving from 32-bits to 64-bits, such as using 64-bit pointers (p%%) rather than 32-bit pointers (p%).

Also, API functions which work with strings may need to have the A (for ASCII) suffix explicitly added to their names in BBCSDL, which isn't necessary in BB4W (so for example SYS "GetModuleFileName" becomes SYS "GetModuleFilenameA"). The need for this will be apparent from the 'No such system call' error you will receive if you don't add the A.

Another reason why you might get a 'No such system call' error is that BBCSDL doesn't automatically load the same set of DLLs as BB4W does, so if you're calling a function in a library that BB4W loads by default, but BBCSDL doesn't, you will need to load it explicitly at run time.

If you don't want to pursue the conversion of your app to BBCSDL that's fair enough, but you haven't explained why.