@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!