@hwnd%

[Ric]

Thanks for reading Richard,
I have changed the % to %% and the program now fails/crashes without erorr message. As i said, it is beyond my capability to migrate my program because i dont understand why it is crashing, thus am unable to solve the problem. Going full circle, how do you put a 64bit address(@hwnd%) into a structure for the swapchain description that only accepts 32bit numbers? As I explained in my DM I can not sift through the documentation to solve these issues, I need a direct answer, with example code. Unless someone can "spoon feed" the answers to my questions I can not take it any further.
It is sad because i dont like to conceed, but sometimes you just have to know when to quit.

[JeremyNicoll]

In Ric's program with "DEF FNguid" in it I'm struck by two things:

1. surely - even in a program only intended to demo a fault - it's really odd to load a DLL in a function? You didn't unload it so if that function (or others written in a similar way) were called multiple times - might you not end up with umpteen copies of one DLL loaded? Or is the OS sensible enough only to load it once? But if it IS loaded just once would the OS return the already-loaded copy's address or would a second attempt to load it put 0 into OLE32DLL% ?

2. isn't it your normal practice to check that every important SYS call actually works? There's no point in using OLE32DLL% if the DLL didn't get loaded. Likewise you can't use SYS CLSIDFromString% ... if CLSIDFromString% doesn't have a sensible value ... and so on.

[Richard Russell]

I have changed the % to %% and the program now fails/crashes without erorr message.

Strange. The modified code, after changing the 32-bit pointers to 64-bits, should look like this (I didn't change lenCLSID% to 64-bits, because it's not a pointer, but if you have changed everything to 64-bits for simplicity it won't matter):

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 code runs perfectly for me in 64-bits BBCSDL, so I don't understand why it doesn't for you.

As i said, it is beyond my capability to migrate my program because i dont understand why it is crashing, thus am unable to solve the problem.

One doesn't follow from the other! I wouldn't necessarily expect you to understand why it's crashing - very commonly I don't understand the cause of a crash either - but you should still be able to solve the problem. For example you can very easily identify the statement in which it is crashing, and typically there's only one thing in any given statement which could possibly be the cause.

Going full circle, how do you put a 64bit address(@hwnd%) into a structure for the swapchain description that only accepts 32bit numbers?

You can't. If you are using a structure that contains only 32-bit members, it must be because none of the members needs to be 64-bits. That's entirely possible if none of them is a pointer; for example in a linked list the link member might be a relative offset from one node to the next rather than an absolute pointer to the next node. A 32-bit number is typically fine for a relative offset.

Indeed when I modified BBCSDL from 32-bits to 64-bits there were places where I replaced what are absolute addresses in the 32-bit version with relative addresses in the 64-bit version, so I could continue to use a 32-bit value. The 'pointer' in a string descriptor is an example.

I need a direct answer, with example code.

Online documentation (for example of API functions) often does include "example code", although it will commonly be in C. What it won't give you is code adapted to the precise requirements of your application but that's what "programming" is all about - taking generic code and adapting it to perform a specific function that you require.

These days you may be able to cope without an understanding of C, by asking an AI chatbot to do the conversion for you, and they are getting a lot better. But I would still recommend learning enough of the basics of C (which you probably know already) so you can do that yourself.

Unless someone can "spoon feed" the answers to my questions I can not take it any further.

It won't be me, and I'd be surprised if anybody else offers to write your program for you without being paid, but I will continue to provide answers to specific issues as they arise, such as you having forgotten to change a 32-bit variable to a 64-bit variable.

[Ric]

There won't be any more questions regarding porting D3D to BBCSDL.

[Richard Russell]

1. surely - even in a program only intended to demo a fault - it's really odd to load a DLL in a function?

True. But it's probably not the cause of Ric's crash so is a secondary issue. It will need to be fixed at some point though.

2. isn't it your normal practice to check that every important SYS call actually works? There's no point in using OLE32DLL% if the DLL didn't get loaded.

Again true, a 'well written' program would of course check the value returned from SYS "LoadObject", although as a well-known DLL supplied as part of Windows the likelihood of it being missing is small.

I don't want to discourage Ric even more by drawing attention to shortcomings in his code that aren't directly relevant to his immediate problem, but you're absolutely right on both counts.

[Richard Russell]

There won't be any more questions regarding porting D3D to BBCSDL.

I'm pleased you now feel confident enough to proceed unaided, but please don't hesitate to ask if you get stuck. You are a trailblazer in this endeavour, because I'm pretty sure nobody else will have attempted it.

You need to bear in mind that I've never used Direct3D 11 and I've never used shaders in D3D at all, only in OpenGL. So you are already far ahead of me in understanding the relevant techniques.

[Ric]

I am not confident to proceed, I don't know how to proceed, so I have stopped trying.

[Richard Russell]

I am not confident to proceed, I don't know how to proceed, so I have stopped trying.

I don't understand. Presumably the crash in the code you listed earlier is now fixed, so there's nothing I am aware of stopping you making progress. What was the point of asking for help with that specific problem if, having been given that help, you don't intend to carry on?

As I understand it, you have existing BB4W code which you want to port to BBCSDL. Having ported it to 32-bit BBCSDL, you then want to adapt it to 64-bit operation to make available more memory, yes?

I'd strongly advise against merging the two steps by converting directly from 32-bit BB4W to 64-bit BBCSDL because every problem you encounter on the way could be related to either the BB4W -> BBCSDL conversion or the 32-bit -> 64-bit adaptation, and you won't know which.

[Ric]

The crash is not fixed, I tried BBCSDL 32bit because I thought it would be easier as @hwnd% would be a 32 but integer. But that doesn't stop the program crashing/erroring. Try running your own "tutorial 1" on D3D11 and you'll find the errors. I don't understand them and don't know how to find the answers. As I have stated, I can't do it by sifting the net, so I am at a loss as to how to proceed.