[overflow]

I'd noticed a few people looked at this previously but nothing was ever really released or they seem to have stopped but i put together a simple version that would work for a development environment if anyone wants to debug a script etc.

• It has been written with multiple OS's in mind, however as iv only have acces to and worked with windows that is the only implementation included. If any one wants to write an osx / mac version and share it id be grateful.
• Uses swing so would not be allowed on the bot store (iirc Arbiter wants javafx impl)
• Need to add the JNA and JNA platform libs to project.
• It will actually work on any window but iv included a test script showing a Runemate / Runescape implementation.
• I forgot we couldn't call game rm methods from the awt event thread so the current version of submitting the drawing to an executor is a hack. If any ones interested ill go back and rework it using BufferStrategys or something.

SourceCode -> Overflow-RS/RM-Overlay

Example

 

[savior]

Thank you Kanye, very cool!

edit: actually cool though, maybe it's useful for local debugging. Last time i've used an overlay the performance of rendering 3d model's bounds was horrible, presumably because of the huge RMI overhead. Have you tried that out and kept an eye on performance?

 

[overflow]

Thank you Kanye, very cool!

edit: actually cool though, maybe it's useful for local debugging. Last time i've used an overlay the performance of rendering 3d model's bounds was horrible, presumably because of the huge RMI overhead. Have you tried that out and kept an eye on performance?

Yep and it was pretty much exactly as you experienced 1+ second render times, ill admit there would be some room for improvement as i just called NPC#render() and didn't try optimise it at all.

However thats the main reason why id only suggest this as a development tool unless the API can be speed things up by caching things more often or significant client work to reduce the RMI overhead ie grouping RMI calls or perhaps a native agent utilising a custom socket implementation?

 

[savior]

Yep and it was pretty much exactly as you experienced 1+ second render times, ill admit there would be some room for improvement as i just called NPC#render() and didn't try optimise it at all.

However thats the main reason why id only suggest this as a development tool unless the API can be speed things up by caching things more often or significant client work to reduce the RMI overhead ie grouping RMI calls or perhaps a native agent utilising a custom socket implementation?

I doubt that would increase performance dramatically, after all everything still has to be serialized and deserialized again

 

[overflow]

I doubt that would increase performance dramatically, after all everything still has to be serialized and deserialized again

Which one grouping or a native agent with a custom socket? In my experience both would provide at least some benefit possibly a lot depending on the implementation

For grouping i've noticed there can actually be a decent overhead on each individual RMI call, if you grouped them together you could minimise that over head.

For a custom socket impl you wouldn't use the standard java serialisation that's just ridiculously slow. I remember a navigation mesh i had for RS was originally serialised and it took 5+ seconds to load, i changed it to encode / decode itself directly from a stream and it brought this down to sub 500ms.