SRL Archive - FAQ

Okay so what with all the other projects, i also started BegoLib.

Its a DLL written in C++, For extremly fast object recognition, i was planning on porting to Pascal..

I have a few questions… Ive not had time to benchmark simba AT ALL.

How long does it take to scan the screen?

Im planning on extending some of my object recognition functions, So that BegoLib will be able to tell diffrent objects by default…

IE: Will know from the RS screen that a wall is diffrent from the floor. Know that on the floor there is a object… etc.

Of course something like this requires looping through a buffer thousands… if not millions of times

Im just curious as to what speed simba offers.. (obvious its very fast)

Why not try it yourself? It depends on the computer after all, right?

I'll test anything you need if you supply directions/code :P (running a phenom quadcore 2.3ghz)

From: weequ
Why not try it yourself? It depends on the computer after all, right?

Computer… Resolution…

Guess ill have to, Wouldnt of thought it would vary too much from pc to pc… Since the operation is going to be so quick.

Guess ill have to start benchmarking.. :-/

Where's BegoLib?

I believe this is what simba uses to scan the screen:

function TWindow.ReturnData(xs, ys, width, height: Integer): TRetData;
  var
    temp: PRGB32;
    w,h : integer;
  begin
    GetTargetDimensions(w,h);
    ValidateBuffer(w,h);
    if (xs < 0) or (xs + width > w) or (ys < 0) or (ys + height > h) then
      raise Exception.CreateFMT('TMWindow.ReturnData: The parameters passed are wrong; xs,ys %d,%d width,height %d,%d',[xs,ys,width,height]);
    Windows.BitBlt(self.buffer.Canvas.Handle,0,0, width, height, self.dc, xs,ys, SRCCOPY);
    Result.Ptr:= self.buffer_raw;

    Result.IncPtrWith:= w - width;
    Result.RowLen:= w;
  end;

It's a slow process, cause every time you want to find colors it has to create that buffer again unless frozen is called. I'm looking forward to see how a c++ plugin could speed this up. Will it be open source?

From: ggzz
Where's BegoLib?

BegoLib is actually a rename of my pretty old RS library…which i used to use in my bots.

Im currently cleaning all the code, alot is broken, and for the main rs gameplay we have wonderull SRL/Simba.

BegoLib will just be avanced object finding/recognition… Also maybe even some decent map walking.

From: masterBB
I believe this is what simba uses to scan the screen:

function TWindow.ReturnData(xs, ys, width, height: Integer): TRetData;
  var
    temp: PRGB32;
    w,h : integer;
  begin
    GetTargetDimensions(w,h);
    ValidateBuffer(w,h);
    if (xs < 0) or (xs + width > w) or (ys < 0) or (ys + height > h) then
      raise Exception.CreateFMT('TMWindow.ReturnData: The parameters passed are wrong; xs,ys %d,%d width,height %d,%d',[xs,ys,width,height]);
    Windows.BitBlt(self.buffer.Canvas.Handle,0,0, width, height, self.dc, xs,ys, SRCCOPY);
    Result.Ptr:= self.buffer_raw;

    Result.IncPtrWith:= w - width;
    Result.RowLen:= w;
  end;

It's a slow process, cause every time you want to find colors it has to create that buffer again unless frozen is called. I'm looking forward to see how a c++ plugin could speed this up. Will it be open source?

Great thanks.

Yeah exacally.. Im not trying to replace Simba's color finding functions at all, Lets be honest there great.

As mentioned above, Just want to create some advanced object finding… (i already have some write up, just need cleaning etc…) With some of the functions i had i was able to solve all the randoms in rs, 1-2 years ago, after speaking withing coh3n, seems a bit is changed.

But yes, of course we store a BMP in a buffer, then we can do as many operations on it as we like… We can call the appropiate function again to update the memory buffer with the current screen.

From: cause
I'll test anything you need if you supply directions/code :P (running a phenom quadcore 2.3ghz)

Thanks!

Sounds like another neat project, i3egoHan. :) Do you have it open-source already? I'm willing to bet before the library is made official for Simba you'll be asked to have it open-source.

I look forward to hearing more about it. ;)

From: masterBB
I believe this is what simba uses to scan the screen:

function TWindow.ReturnData(xs, ys, width, height: Integer): TRetData;
  var
    temp: PRGB32;
    w,h : integer;
  begin
    GetTargetDimensions(w,h);
    ValidateBuffer(w,h);
    if (xs < 0) or (xs + width > w) or (ys < 0) or (ys + height > h) then
      raise Exception.CreateFMT('TMWindow.ReturnData: The parameters passed are wrong; xs,ys %d,%d width,height %d,%d',[xs,ys,width,height]);
    Windows.BitBlt(self.buffer.Canvas.Handle,0,0, width, height, self.dc, xs,ys, SRCCOPY);
    Result.Ptr:= self.buffer_raw;

    Result.IncPtrWith:= w - width;
    Result.RowLen:= w;
  end;

It's a slow process, cause every time you want to find colors it has to create that buffer again unless frozen is called. I'm looking forward to see how a c++ plugin could speed this up. Will it be open source?

Just to clarify, we don't create a new buffer at all. We just copy (a part of) the screen to our buffer again, which is the best way to do if we also want to implement the ``freezing''. It would also allow us to implement aggressive caching, by for example only updating every 30ms, and every call before the 30ms will just use the cached version of the screen.

On Linux, we do not have a buffer because Xlib is silly. It has XGetImage, which creates a new image + buffer, and it has XGetSubImage which draws to an existing buffer, but uses XGetImage under the hood and thus is a lot slower than calling XGetImage directly. There is also the MIT-SHM extension which I've tried playing with, but it requires increasing the max shm size in the kernel through /proc as well as some additional fixes because I simply didn't get it to work yet. But that would essentially bring us on par with BitBlt wrt using a buffer. However, Simba Linux' speed is pretty close if not better to Windows, so it's not a big deal. It really depends on the driver and resolution.

One final note, SMART allows Simba to directly access its own bitmap, so we don't do any copying at all with SMART, except when calling Freeze. (Obviously, SMART already does the copying)

If I were to rewrite the core of Simba (also called the MML) now, I'd probably go for C. Let me also remind you that part of the Simba project there is libMML, which is pretty much what I just describe, but instead of writing it in C, it simply exposes a C-like API to the underlying object pascal code. It's not finished, but I've recently been polishing up my C knowledge again, so I might make it more usable soon.

@Wizzup, there's a mml.simba file in the includes, what's in it?

From: Wizzup?
Just to clarify, we don't create a new buffer at all. We just copy (a part of) the screen to our buffer again, which is the best way to do if we also want to implement the ``freezing''. It would also allow us to implement aggressive caching, by for example only updating every 30ms, and every call before the 30ms will just use the cached version of the screen.

On Linux, we do not have a buffer because Xlib is silly. It has XGetImage, which creates a new image + buffer, and it has XGetSubImage which draws to an existing buffer, but uses XGetImage under the hood and thus is a lot slower than calling XGetImage directly. There is also the MIT-SHM extension which I've tried playing with, but it requires increasing the max shm size in the kernel through /proc as well as some additional fixes because I simply didn't get it to work yet. But that would essentially bring us on par with BitBlt wrt using a buffer. However, Simba Linux' speed is pretty close if not better to Windows, so it's not a big deal. It really depends on the driver and resolution.

One final note, SMART allows Simba to directly access its own bitmap, so we don't do any copying at all with SMART, except when calling Freeze. (Obviously, SMART already does the copying)

If I were to rewrite the core of Simba (also called the MML) now, I'd probably go for C. Let me also remind you that part of the Simba project there is libMML, which is pretty much what I just describe, but instead of writing it in C, it simply exposes a C-like API to the underlying object pascal code. It's not finished, but I've recently been polishing up my C knowledge again, so I might make it more usable soon.

I really never thought of that… So does Simba point to a SMART bmp buffer?

Yes, exacaly, depending on the operation you could update the buffer every x amount of MS.

As i said, the amount of work thats gone into libMML, Simba, SRL… Im not trying to recreate anything, But object recognition in RS shouldnt be too hard at all… If were consistently reading pixels from a buffer, we can compare the distance, color diffrence, shape, size… Thus being able to debug objects on screen by size and color.

Yes it could probarly be done with Simba, and TPA's. Much of the hard work is already there, But speed is the key, and what with all the pascal around, i really feel like writing some C/C++.

Do you mean like using a canny edge detector to split up the TPAs, So you have the objects? Or how else did you had it in mind? What kind of shape recognition do you have in mind.

Also, I'm no expert on the simba source. Most of the things I say are false ;)

masterBB: Quite some time ago now i write several object recognition functions, they worked well.. and the fixed moving object ones (for random event solving) were flawless.

Ive seem something close in SRL, but not quite the same thing.. (moving object, analyses a fixed postion for x amount of time, ignoring background colors, and calculating coverage.)

Its pretty hard to explain, but i just have a few ideas in mind, basically a algorithms which determines if a area is a seperate object… Its like detecting if a dropped item is really part of the RS ground/surface… if this item as colors in the 32x32 square that the surrounding 200x200 doesnt have then its pretty obvious its a seperate object.

Wizzup?: Whats your views on 24 vs 32 bit BITMAPS.

Is alpa at all usefull?

Sounds very cool, looking forward to seeing it….

you should post it here so others can help you work on it?

To answer the question on reading from Smart's buffer.. I was asking Ben about return types for exported functions from LibSmart to Cpp

SmartGetDebugArray returns an LPVoid to a BMP buffer.. so you can basically read and write directly to it with the GDI Functions..

Which I'm told would be better than using the DC of the debug.. So I've been using that instead for drawing on smart with both Simba and Cpp functions.

Guessing that might be useful for you instead of grabbing a DC and making your own BitmapInfo and Info/File headers

What is the use of 32 bit bitmaps? I don't see how you would obtain the alpha from the runescape screen. Unless you mean in the sense of overlapping bitmaps. I can imagine using it for that.

From: ggzz
To answer the question on reading from Smart's buffer.. I was asking Ben about return types for exported functions from LibSmart to Cpp

SmartGetDebugArray returns an LPVoid to a BMP buffer.. so you can basically read and write directly to it with the GDI Functions..

Which I'm told would be better than using the DC of the debug.. So I've been using that instead for drawing on smart with both Simba and Cpp functions.

Guessing that might be useful for you instead of grabbing a DC and making your own BitmapInfo and Info/File headers

Thanks for the info, Well… As far as C/C++ go's there isnt much around in terms of libarys for pixel searching etc.. And for the novice users there first insight would be GetPixel() which is extremely slow since everytime you read each pixel, its basically taking another snapshot.

So that being said, ill probarly keep it independant of SMART.

There really isn't any better ways other than GetDIBits or even better.. DirectX.. And you wouldn't need to snapshot it every time.. smart provides direct access to it's buffer AND get pixel just requires the DC and location.. the slowest part would be looping through all the pixels and matching..

I was thinking that any other method would require creating your own buffer?

From: ggzz
There really isn't any better ways other than GetDIBits or even better.. DirectX.. And you wouldn't need to snapshot it every time.. smart provides direct access to it's buffer AND get pixel just requires the DC and location.. the slowest part would be looping through all the pixels and matching..

I was thinking that any other method would require creating your own buffer?

There isnt any better ways? Slightly confused.

GetPixel will still be awfully slow… The best way is obviously just to read the RAW buffer.

Heres a little info….(BegoLib)

ClientSetup(NULL); // Defines the client (area to snapshot) NULL is the window handle

ClientSetup, loads properties into a 'global' struct, which contains the client/windows height/width, bmp buffer. (global code is bad! but in these timely situations its well worth it)

BMP's… the scan lines are stored upside-down. So i write a function to invert (not reverse) the buffer.

BGR becomes RGB, and bottom to top scanlines, Now the bmp is stored correctly in the buffer, we simply loop through the buffer….

From: Sin
@Wizzup, there's a mml.simba file in the includes, what's in it?

It wraps some MML functionality to normal functions for the extensions.

From: masterBB
Do you mean like using a canny edge detector to split up the TPAs, So you have the objects? Or how else did you had it in mind? What kind of shape recognition do you have in mind.

Also, I'm no expert on the simba source. Most of the things I say are false ;)

Well, you got a lot of things right. No problem. :)

From: i3egoHan
I really never thought of that… So does Simba point to a SMART bmp buffer?

Yes, exacaly, depending on the operation you could update the buffer every x amount of MS.

As i said, the amount of work thats gone into libMML, Simba, SRL… Im not trying to recreate anything, But object recognition in RS shouldnt be too hard at all… If were consistently reading pixels from a buffer, we can compare the distance, color diffrence, shape, size… Thus being able to debug objects on screen by size and color.

Yes it could probarly be done with Simba, and TPA's. Much of the hard work is already there, But speed is the key, and what with all the pascal around, i really feel like writing some C/C++.

Yes, Simba has SetTargetArray() which just uses a memory segment as a ``target''.

I don't think TPA's would be very fast either, you'd probably just want it in a plugin and depend on a few Simba functions to get the client data etc. That would make it easier to integrate (if you can share Simba's target it would also work on SMART etc.)

From: i3egoHan
masterBB: Quite some time ago now i write several object recognition functions, they worked well.. and the fixed moving object ones (for random event solving) were flawless.

Ive seem something close in SRL, but not quite the same thing.. (moving object, analyses a fixed postion for x amount of time, ignoring background colors, and calculating coverage.)

Its pretty hard to explain, but i just have a few ideas in mind, basically a algorithms which determines if a area is a seperate object… Its like detecting if a dropped item is really part of the RS ground/surface… if this item as colors in the 32x32 square that the surrounding 200x200 doesnt have then its pretty obvious its a seperate object.

Wizzup?: Whats your views on 24 vs 32 bit BITMAPS.

Is alpa at all usefull?

32 bit is a lot easier to work with, and since with 24 bit bitmaps you'll most likely align to 32 bit anyway, there's no reason not to go with 32 bit.

32bit is actually faster as x86 CPUs operate internally @ 32bit, so it saves you a lot of bit shifting.

From: Wizzup?
32 bit is a lot easier to work with, and since with 24 bit bitmaps you'll most likely align to 32 bit anyway, there's no reason not to go with 32 bit.

Dat double post.
Reported.

From: Wizzup?
It wraps some MML functionality to normal functions for the extensions.



Well, you got a lot of things right. No problem. :)



Yes, Simba has SetTargetArray() which just uses a memory segment as a ``target''.

I don't think TPA's would be very fast either, you'd probably just want it in a plugin and depend on a few Simba functions to get the client data etc. That would make it easier to integrate (if you can share Simba's target it would also work on SMART etc.)

Thanks for explaining.

Yeah at the moment i was just getting rid of the Alpha bits.

When comparing colors we should only compare RGB right? For Simba compatability.

This is something ill be working on whilst working on sound detection, BegoSwitch, and keeping SMARTManager updated, Wizzup? ill probarly need to talk to you nearer release, as for interacing with simba.

Thanks

Okay i rewrote some of the core screen capture since i was using GetDibIts() which was slow.

as Wizzup? mentioned, that wont even be needed since we can share SMART's buffer, which does the updating… and process that data accordingly.

Just the matter of looking into getting a pointer to smarts buffer…a somewhat tacky edge detections implemented… still alot of work to do, to seperate objects into an array, along with there size, colors and whatnot.

I'm eagerly looking forward to seeing the end results of this! Good luck!