SRL Archive - Senior Discussions and Debates

Why do we use safe mode?

I don't think any normal player uses safe mode when he/she is autoing? With Jagex breathing in our necks, they'd only have to check users running safe mode, which narrows down their options drastically.

I believe we do so due to colours? Worth investigating although in the past I have suggested that we use a more advanced mode.. the extra colours can be as much a disadvantage as an advantage imo

-RM

Safe mode

Software

OpenGL

Main-screen looks pretty much the same in all of them, it's just the minimap is fucked up in other modes.

May this safe mode to non safe mode be whats fucking ups SPS? Sure looks like it. Other than that, no big difference indeed.

Also, SMART automatically loads safe mode right? Perhaps who ever did the SPS map last time wasn't actually running in safe mode…

And honestly I'd be up for OpenGL being our default running strategy, as that'll already have us prepared for the future..

-RM

the minimap in both software and openGl both look like they would be easier than safe mode. higher contrast?

Just after OpenGL was introduced (It was named HD back then), gametabs and login was f*cked up so SRL only worked on Safe mode (And nothing else). I think we just stuck with it since that's what we got used to

It looks like only big change is minimap.
It's also nice to use whatever mode is least CPU intensuve.
I say we use whatever mode has the most minimap contrast to help with walking!
Bit then we would need to tweak a lot of our functions, all scripts act buggy in modes besides safe mode.

I think I ran yohojo's PMS script to work in OpenGL last year and it worked great. Only really had issues with the login. OpenGL shouldn't be that big of a change for us and we really need to stop standing out.

Is there any way to detect how it's loaded and we can load different tolerances to adjust for the different minimaps. Then scripts could possibly use all 3 so we don't jam up 1 stream so it makes it a little bit harder for them.

Or am I completely off?

Wow wow wow, that's fantastic! The minimap in Software and OpenGL is darker, which is exactly the problem we were running into when creating the map for SPS. Maybe those minimaps match the world map better.

Glad you brought this up. Also, yeah I think it's time to move away from safe mode; although I'm not sure what would break. Everything does look quite similar.

From: Sir R. M8gic1an
Also, SMART automatically loads safe mode right?

It's not intrinsic to the SMART binary, but it is currently setup that way on the SRL side. That being said, I do not know if OpenGL mode will work through SMART currently. (unless it uses the AWT graphics subsystem…) There is a possibility I could cook something up to make it work if it doesn't. I would be appreciative if someone could test and shoot me those results on IRC sometime.

From: Coh3n
Wow wow wow, that's fantastic! The minimap in Software and OpenGL is darker, which is exactly the problem we were running into when creating the map for SPS. Maybe those minimaps match the world map better.

Glad you brought this up. Also, yeah I think it's time to move away from safe mode; although I'm not sure what would break. Everything does look quite similar.

It shouldn't be any more complicated than adjusting some colors and perhaps some counts. I always thought the shadows were more likely to mess things up in OpenGL and other versions, but that screen shot doesn't look too bad.

Where's that wolf fellar with the OpenGL hax?

From: lordsaturn
Where's that wolf fellar with the OpenGL hax?

He magically disappeared :/

Everything breaks, since all colors are different. Tried it? I did. Nothing works anymore. Nothing. Do not take this lightharted, it will become a mess. Best way to tackle this imho is through #hashing, no? Assign a constant to every color that needs to be tweaked for the different engines.

From: WT-Fakawi
Everything breaks, since all colors are different. Tried it? I did. Nothing works anymore. Nothing. Do not take this lightharted, it will become a mess. Best way to tackle this imho is through #hashing, no? Assign a constant to every color that needs to be tweaked for the different engines.

Yes, but it's necessary; and indeed everything in SRL must be made much more modular.

Well, it seems to be a great time to make it more modular, post SRL 5.

We started doing this before.. just need to do it more now

From: WT-Fakawi
Well, it seems to be a great time to make it more modular, post SRL 5.

Still trying to finish up documentation.

Wait so you're suggesting to have a different constant for colors depending on the graphics mode? I could get very messy. I'm not particularly fond of that idea, but it like Ray said, it may be necessary.

E: If we were to do this, it should be for SRL-6.

From: Coh3n
Wait so you're suggesting to have a different constant for colors depending on the graphics mode? I could get very messy. I'm not particularly fond of that idea, but it like Ray said, it may be necessary.

E: If we were to do this, it should be for SRL-6.

Agree'd. Let's just get SRL 5 done and out so we can begin the real changes.

From: Coh3n
Wait so you're suggesting to have a different constant for colors depending on the graphics mode? I could get very messy. I'm not particularly fond of that idea, but it like Ray said, it may be necessary.

E: If we were to do this, it should be for SRL-6.

Messy? If every colour is a constant one can just create a whole colour set for a different colour mode, it's the opposite of messy.. It's pure clean code :p

From: mastaraymond
Messy? If every colour is a constant one can just create a whole colour set for a different colour mode, it's the opposite of messy.. It's pure clean code :p

I agree making a type for colors could make it very clean indeed.

Just a lot of work maintaining them. Stick to one I'd say (software).

From: Markus
Just a lot of work maintaining them. Stick to one I'd say (software).

OpenGL is tons faster than software..

From: mastaraymond
OpenGL is tons faster than software..

But requires more from the computer

From: Zyt3x
But requires more from the computer

With faster I mean it requires less CPU; simply because it uses the GPU..

It depends on the driver. Let's just get SRL 5 done. There's only a few more files to document. And it's even just copy pasting. Why doesn't everyone just do at least one file? After that we can focus on the future.

From: mastaraymond
Messy? If every colour is a constant one can just create a whole colour set for a different colour mode, it's the opposite of messy.. It's pure clean code :p

That makes more sense, I was thinking a different constant for each mode, like:

COLOR_SAFE_BANK = 2234785;
COLOR_SOFTWARE_BANK = 234087;
COLOR_OPENGL_BANK = 1293872;
COLOR_DIRECTX_BANK = 1023780;

From: Coh3n
That makes more sense, I was thinking a different constant for each mode, like:

COLOR_SAFE_BANK = 2234785;
COLOR_SOFTWARE_BANK = 234087;
COLOR_OPENGL_BANK = 1293872;
COLOR_DIRECTX_BANK = 1023780;

You would..

But they'd all be:

COLOR_BANK=2324226;

Then just use defines to include certain files. :)

What about for colors that are not constant…

Its gunna be a bitch to write a script and have to collect colors from software, openGL, ect..

also autocoloring will be a bitch

Why can we not just pick one and stick with it?, I dont really care which one, just pick it and lets move forward

From: Nava2
You would..

But they'd all be:

COLOR_BANK=2324226;

Then just use defines to include certain files. :)

Yeah I was thinking we'd have to have a big case in every function they're used. Wasn't thinking there. :p

From: _ChArMz
What about for colors that are not constant…

Its gunna be a bitch to write a script and have to collect colors from software, openGL, ect..

also autocoloring will be a bitch

Why can we not just pick one and stick with it?, I dont really care which one, just pick it and lets move forward

I'd have to agree. In theory it's a good idea, but it's actually a lot of work that's not really necessary.

So, let's pick one.. OpenGL vs Software.

Could someone who has time check out the differences between the two? (Like how do colours change between loading screens, world switches etc..)? Furthermore, I would vote OpenGL simply because it might allow us to easily enroll in a OpenGL bot in the future.

I feel like on current computers, OpenGL is best. But that would be for those who are not working on like 10 clients at once..

Software otherwise.. but OGL does use the GFX card so that is a good thing.

Bump back into discussion.

OpenGL or Software mode. The time for us to commit to one or the other is coming. We have all the OpenGL things being looked into so that might be the direction we want to go to be compatible with both.

Fixed OpenGL has my vote.

I would vote for OpenGL as well. That would allow us to stay with color and explore other options.

OpenGL, as it offers the double incentives of moving us away from safe mode and using interception à la Brandon's work.

SRL would have nothing to do with interception, so I wouldn't really call that an advantage. It would help interception if it required SRL to work properly, however.

No but users can use both of them at the same time is what he means.

Ah yes, very true.

Yep I would vote OpenGL mode as well, but keep in mind we don't have a way to read colour, at all, in OGL mode if we're running Simba in Windows.

From: Flight
Yep I would vote OpenGL mode as well, but keep in mind we don't have a way to read colour, at all, in OGL mode if we're running Simba in Windows.

So that would mean there would be no SRL? Unless we scrapped the whole colour concept, which I am not in favour for.

Why can't we read colours in OpenGL?

From: Flight
Yep I would vote OpenGL mode as well, but keep in mind we don't have a way to read colour, at all, in OGL mode if we're running Simba in Windows.

We do if we use SMART. Or Wizzup? implements some hacky solution to allow us to capture OGL windows. :p

From: Coh3n
So that would mean there would be no SRL? Unless we scrapped the whole colour concept, which I am not in favour for.

Why can't we read colours in OpenGL?

I don't know the reasoning for it, I just know Simba doesn't read colour in OGL mode using Windows OS. Load Runescape in OGL and try it out for yourself. Search the full parameter of the client for any color, any tolerance; it won't be found. Even load up Simba's DTM editor tool, you'll see a completely black screen in place of the RS client.

As I've read from Wizzup?, it's possible to read colour in OGL through system's running on Linux using WINE.

From: Daniel
We do if we use SMART. Or Wizzup? implements some hacky solution to allow us to capture OGL windows. :p

Ben was talking about that, and I believe Brandon has successfully loaded his OGL plugin with SMART. But even though SMART has the ability to run in multiple modes, only Safe Mode works in Windows.

What are the differences between software and OpenGL mode? Speaking colorwise.

So has anyone tested it out recently to see about that color issue with OpenGL. Possibly Software mode. I've modded a Yohojo's PMS last year to work in software or OpenGL can't remember which. So one of them works. Can someone test it out right quick?

Looks like it works to me. Anyone else try it yet?

This is my first time loading RS in forever. All I used was this little script as well.

program new;
  {$DEFINE SRL5}
  {$DEFINE SMART}

  {$i SRL/srl.simba}
begin
  SetupSRL;
end.         

It should work?

From: Daniel
We do if we use SMART. Or Wizzup? implements some hacky solution to allow us to capture OGL windows. :p

SMART cannot read colors for OGL at all (yet, anyway. OGL does have functionality that might make that possible but no one has gotten it to work). Simba can't read OGL on Windows because Simba uses bitblt on the DC for color information (afaik, at least that's how it used to be so I'll go with that), and the DC has nothing to do with hardware rendering, e.g. OpenGL. Basically, the color information is on the video card, not in regular memory, so you can't just trivially copy it. The hardware basically overlays the rendering right before it is displayed.

@Brak I see a vX.2 version number there, which leads me to believe you're using v7.2. In which case, there is literally no way you got it to load OpenGL since that functionality didn't exist in v7.2

Huh thought I updated to 8.0 I'll update and try again. Haven't loaded RS in a while a yeah I did click the OpenGL to toggle over guess it didn't take.

From: BenLand100
SMART cannot read colors for OGL at all (yet, anyway. OGL does have functionality that might make that possible but no one has gotten it to work). Simba can't read OGL on Windows because Simba uses bitblt on the DC for color information (afaik, at least that's how it used to be so I'll go with that), and the DC has nothing to do with hardware rendering, e.g. OpenGL. Basically, the color information is on the video card, not in regular memory, so you can't just trivially copy it. The hardware basically overlays the rendering right before it is displayed.

@Brak I see a vX.2 version number there, which leads me to believe you're using v7.2. In which case, there is literally no way you got it to load OpenGL since that functionality didn't exist in v7.2

I hate you.

From: Daniel
I hate you.

Huh?

Need help :S

http://pastebin.com/pTSGn80Q

That's the code and below is the image. I cannot figure out why it's being distorted. If I use an image from my desktop and have the DLL load that and pass it to smart, it works perfectly fine. The second I use the GLBuffer, it goes ape shit. Thing is, if I save the image in the GLBuffer, it saves perfectly fine -__- Drawing it to smart is my problem.

Anyone know Java well enough to help? I'm waiting on Benland100 to look at it but he's busy and whenever he's on, I'm not on. I won't be on for a while either.

Smart is definitely communicating with the plugin.. I need this to work in-order for Simba to read Colours in this mode (currently it cannot). Any help?

Solved it.. Safemode is no longer the only mode SRL/Simba can run in. Yeah I know it's flipped but it can easily be flipped in one or two lines of code.

=] Time to go bother Ben. Also you can remove the Navbar at the top easily by just supplying the ID's of it. But meh might as well leave it there and leave SRL as is if Ben likes this implementation.

Great work! :D rep+

Would rep you if I could, Brandon. Great work. Your unrelenting progress towards the unknown is admirable.

Oh man… I'd get a headache from trying to play upside down. Looking good there Brandon. Now where's 'ol Ben?

Now, if this is implemented into SMART, great, but we still have the issue with running Simba in a browser on OGL, correct?

From: Coh3n
Now, if this is implemented into SMART, great, but we still have the issue with running Simba in a browser on OGL, correct?

If it can be done to smart, it can be done to the browser as well. It's just a matter of Simba reading the pointer instead of Smart.

Also I believe Simba can already read OpenGL colours in the browser as it just uses a Device Context (Screen Scrapes) whereas Smart actually has to give it a buffer even for safemode.

I was under the impression the findColors methods didn't work in OGL without SMART. That's why we decided to stick with Safe Mode for SRL6.

From: Coh3n
I was under the impression the findColors methods didn't work in OGL without SMART. That's why we decided to stick with Safe Mode for SRL6.

It seems you're right. I wonder how come though :S If anything and if required I'll just have the plugin write the data to the SharedMemory and have Simba read them (There's already a class that does). I'll play around with it later.

How does Runescape perform when having multiple OpenGL instances?

Being able to run multiple Runescape instances + OpenGL would be an ideal situation. (After all Runescape is a game, the whole reason we have graphic cards, so please lets make use of it).