*LOAD

[Ric]

Could some one point me in the right direction to convert

Code: Select all

OSCLI "LOAD """+file$+""" "+STR$~addr%%+" +"+STR$~max%

into assembly?

Also, why are ther 3 consecutive " before and after +file$+, other than it says address out of range if there arent?

[Richard Russell]

Could some one point me in the right direction to convert

Code: Select all

OSCLI "LOAD """+file$+""" "+STR$~addr%%+" +"+STR$~max%

into assembly?

That depends on whether you are talking about BB4W or BBCSDL, because the code will be different. In BB4W you will probably be wanting your assembler code to call the Windows ReadFile function and in BBCSDL the SDL_RWread function.

Will it be acceptable to open and close the file in BASIC? It would simplify the task considerably if you are only reading from it in assembler code. From what little I remember (and it's a long time since I've tried to do it) opening a file in assembler code is messy.

Also, why are ther 3 consecutive " before and after +file$+, other than it says address out of range if there arent?

What I always suggest when that kind of question is asked is to replace OSCLI with PRINT so you can see exactly what command is being issued. So in this specific case:

Code: Select all

PRINT "LOAD """+file$+""" "+STR$~addr%%+" +"+STR$~max%

Now you should see exactly why it's the way it is, and can experiment with making changes to see the effect.

[Ric]

Thanks Richard,
Because of what I am doing, speed is the most important factor out weighing anything else by a very high factor, opening a file in assembly is easy enough, so if I can then call the readfile API , then I'll start there.
I have already reduced the number of files that need to be *loaded and increased the file size as I have discovered that all the overhead is in opening the file.
I have tried to read the files with an assembly loop, but it is considerably slower than *load, hence the initial question. I will try with readfile as the next step.

[Richard Russell]

I will try with readfile as the next step.

Bear in mind that, unless the files are very short, it's likely that calling ReadFile from assembler code won't be significantly faster than *LOAD in BASIC, because the time will be dominated by the actual file read operation. So if the motivation for writing it in assembler code is solely speed, it probably won't be worth the effort.

[Ric]

Even if it is the same speed, at least I'll be able to write the other operations around it in the loop in assembly too. Every ms is crucial to the frames per second.

[Richard Russell]

Even if it is the same speed, at least I'll be able to write the other operations around it in the loop in assembly too. Every ms is crucial to the frames per second.

Nevertheless the more you write in assembler code the less portable it will be. If you use BASIC code it will work without modification in all the supported OSes (Windows, MacOS, Linux etc.) and all the supported CPUs (x86, ARM, WASM). So I would say that expending effort on shaving off the last microsecond is a misplaced priority.

In the long term you'll regret it if you make decisions now which mean your program can't work when Microsoft eventually drops support for 32-bit apps, which surely can't be that far away given that every other major OS has either done that already (e.g. MacOS, iOS) or is well on the way to doing so (Linux, Android).

It's not difficult to 'call' BASIC code from your assembler code by temporarily dropping back into BASIC, in fact there's a Wiki article on that specific topic.

[Ric]

I found this when googling the win readfile

BOOL ReadFile(
[in] HANDLE hFile,
[out] LPVOID lpBuffer,
[in] DWORD nNumberOfBytesToRead,
[out, optional] LPDWORD lpNumberOfBytesRead, ::::: These two are optional, can i ignore them
[in, out, optional] LPOVERLAPPED lpOverlapped ::::: or do i need to set them to zero
);

Where does the HANDLE come from, is that the channel from the opened file?

is

push DWORD 0
push DWORD 0
push DWORD 200000
push DWORD ^verticesBuffer{(0)}
push DWORD handle
CALL "readFile"

correct?

Most of the graphics/rendering is already writen in ASM, without it the frames per second would be unacceptably slow, around 37, using asm it is more like 175, which by the time all the game play is added, which i have done the majority in my soley BASIC version (except for a few maths routines and some repetative for/next loops), will drop to about 45 frames per second. By the standard of most modern games this is slow and produces a juddery effect or blurring when the action becomes fast and furious.
Anything i can do at this point to speed up the rendering will produce better results later. (Most of the game play is writen in BASIC, but as discussed, it is reliant on D3D, so at this juncture porting isnt possible anyway. I will try porting something smaller first if you can get answers from the forum you posted on.

[Richard Russell]

Where does the HANDLE come from, is that the channel from the opened file?

No, the channel number is a BBC BASIC concept which the Operating System knows nothing about. The API function needs the native file handle, which in BASIC you would usually obtain from @hfile%(channel). If your assembler code is opening the file using the CreateFile API (which as I mentioned is quite messy) it will return the required native file handle.

Most of the graphics/rendering is already writen in ASM, without it the frames per second would be unacceptably slow, around 37

I wonder if the split between CPU code and GPU (shader) code is non-optimum. What does the profiler have to say about where the time is being spent in the BASIC + shader version? Could you perhaps move some of the time-consuming computation into the vertex shader?

I have on several previous occasions discussed the use of shader code as a kind of 'universal' assembler code, which has none of the disadvantages of traditional assembler code such as being platform-specific. As your program already uses shader code, this might perhaps be reasonably straightfoirward.

Although I won't be around then, I worry about what you'll do if/when your program stops working because it's 32-bits x86 only.

as discussed, it is reliant on D3D, so at this juncture porting isnt possible anyway.

I think you missed the part of my previous post which confirmed that SDL 2.0 is fully compatible with Direct3D, indeed Direct3D is the default back-end when SDL is running in Windows. So your conclusion that being reliant on D3D makes porting impossible is quite wrong.

I've now had a reply at the SDL forum explaining what I did wrong, although not why it crashed which does indeed seem to be an SDL2 bug.

[Richard Russell]

I think you missed the part of my previous post which confirmed that SDL 2.0 is fully compatible with Direct3D...

The proof!

direct3d.png

[Ric]

There are only a couple of matrix calculations done outside the shader, but I don't see why some of what's left can't be done in a shader. I still need a lot of help migrating to SDL, simple( to you) things like getting the ASM to work with not just P% and getting the window handle from the structure you posted etc.....