@hwnd%

[Ric]

I recently have had to take stock of the fact i am having to move over to BBCSDL from BB4W(hopefully not just yet Richard), this wil have the advantage of significantly larger memory available to me. However, the first program i have run that has not specifically been written for BBCSDL has thrown up this fault:
"Number too big" at this line

Code: Select all

 1360 PROCinitiateD3D(1,screen_width%,screen_height%,DXGI_FORMAT_R8G8B8A8_UNORM,60,1,DXGI_USAGE_RENDER_TARGET_OUTPUT,@hwnd%,1,0,D3DTRUE)

When tested @hwnd% = 1.xxxxxxxE12

I can only summise two things, neither of which i can find answers on.
1. BBCSDL cant run D3D - I am running it on a Windows based x86 laptop
2. @hwnd% is not the coerrect system variable in BBCSDL

Could someone please help me out?

[Richard Russell]

the first program i have run that has not specifically been written for BBCSDL has thrown up this fault: "Number too big"

This issue is explicitly called out in the Differences between BB4W and BBCSDL document, which says this: "64-bit editions of BBCSDL... require that your BASIC program be compatible with 64-bit addresses. This means using 64-bit integer variables (%% suffix) or variant variables (no suffix) whenever they may contain an address or pointer".

2. @hwnd% is not the coerrect system variable in BBCSDL

That is almost certainly true, but fortunately there's an easy fix: call SDL_GetWindowWMInfo() to obtain the native Windows window handle.

1. BBCSDL cant run D3D

I simply don't know the answer to that for sure, I've never tried it; you're breaking new ground here! One thing that will definitely be necessary is using *REFRESH OFF before attempting to access D3D, so there's no conflict.

Reasons to be hopeful that it may work are as follows:

• SDL itself can definitely use Direct3D. indeed it's the default back-end renderer when SDL2 is running in Windows.
• I have successfully switched between two different versions of OpenGL, so switching to D3D may not be fundamentally any different.

Reasons to fear that it might not work:

• BBCSDL uses OpenGL, it may be that running both OpenGL and Direct3D from the same process might break something.
• The way you are running Direct3D may accidentally rely on some feature specific to BBC BASIC for Windows.

Even if it doesn't work, all is not lost. There are still possible ways forward:

• Convert your BASIC program to run in OpenGL. If it largely uses custom shader code this might not be too difficult because shader language is very similar between different 3D back-ends.
• Build (from the source at GitHub) a custom version of BBCSDL which uses the Direct3D backend rather than OpenGL. That ought to be easier than it might sound at first, because SDL2 fully supports Direct3D.

Converting your program to OpenGL would of course potentially have the major benefit of making it compatible with MacOS, Linux (including Raspberry Pi), Android, iOS and running in a browser - hugely increasing its potential market and user base.

[Richard Russell]

Build (from the source at GitHub) a custom version of BBCSDL which uses the Direct3D backend rather than OpenGL.

In fact it should be even easier than that: simply defining a Windows Environment Variable ought to be sufficient to switch BBCSDL to running with Direct3D rather than OpenGL. But in practice it seems not to work (it crashes), and I've posted a query at the SDL forum to see if anybody there can shed light on why. I wonder if I've found a bug in SDL 2.0!

[Ric]

Thanks Richard, unfortunately I have no idea how to extract the window handle from SDL_getwindow, let alone change the code at GitHub. I will have to stay with bb4w for now as the code I am writing heavily relies on d3d.

[Richard Russell]

Thanks Richard, unfortunately I have no idea how to extract the window handle from SDL_getwindow

I provided a link to the documentation page, here it is again. It's a perfectly straightforward API call of the kind you must be making dozens of times in your program already, so go ahead and use it to recover the native handle. If you do have any difficulties just ask here.

let alone change the code at GitHub.

Looks like you didn't see my later post, where I corrected my previous comment having realised that it's simply a matter of setting an environment variable (albeit that it doesn't work here, but I have an open query about that at the SDL forum).

I very much look forward to seeing your progress in porting your program to BBCSDL, because with any luck it's going to be considerably easier than it might initially have appeared. It will be a valuable contribution to the BBCSDL 'knowledge base'.

[Ric]

I will keep my fingers crossed about porting across.
With regards to the @hwnd%, I have looked at the link, but there appears to be a multitude of structures etc to wade through. I don't even know how to start extracting the correct information from the numerous variables involved. At this point I don't need helpful hints, I need the answer.

[Richard Russell]

With regards to the @hwnd%, I have looked at the link, but there appears to be a multitude of structures etc to wade through.

It only looks complicated because it's a union of lots of different options depending on the OS. Since you are only interested in Windows you can ignore everything else, and the structure then becomes very simple:

Code: Select all

struct SDL_SysWMinfo
{
    SDL_version version;
    SDL_SYSWM_TYPE subsystem;
    HWND window;         /* The window handle */
    HDC hdc;             /* The window device context */
    HINSTANCE hinstance; /* The instance handle */
}

which trivially translates to BBC BASIC as:

Code: Select all

      DIM SDL_SysWMinfo{     \
      \    version%,     \
      \    subsystem%,   \ 
      \    window%,      \ The window handle
      \    hdc%,         \ The window device context
      \    hinstance%    \ The instance handle
      \ }

(this is for 32-bit code, for 64-bits you would presumably need to use window%%, hdc%% and hinstance%%).

[Ric]

Thank you, but what next, I understand that this creates a structure, but how do I extract the information?

[Richard Russell]

Thank you, but what next, I understand that this creates a structure, but how do I extract the information?

The native window handle (which I think is all you need) is SDL_SysWMinfo.window% (or SDL_SysWMinfo.window%% in the case of 64-bits), this is just a regular integer structure member.

If you need a refresher on structures, the relevant section of the Help documentation is here.

[Ric]

Please could you explain how to use SDL_getWindowInfo.
Do I CALL SDL_getWindowInfo
Do I SYS SDLgwtWindowInfo
Does it have parameters
If so what are they
Sorry for the abrupt questions, but I have no idea how to impliment what you have suggested above.
Would it not be easier if the @hwnd% variable was changed to @hwnd%%

I have researched SDL_getWindowInfo and the information meant nothing to me