Difference between revisions of "Thread:User talk:Voidious/BerryBots updates/reply (26)"
m |
m (argh) |
||
| Line 1: | Line 1: | ||
I'm not sure I'll make the time, but I don't see any reason we couldn't add this same style of replay support to Robocode. All you really need is fast/native buffers to cache all the pertinent data during the match in a lazy/efficient way. Java has ByteBuffers. I re-tested and with BerryBots, it really is only a 5% performance penalty with trivial bots. And of course some memory, but not even that much. And once you have sophisticated bots, the engine itself is only a small % of overall CPU usage anyway. | I'm not sure I'll make the time, but I don't see any reason we couldn't add this same style of replay support to Robocode. All you really need is fast/native buffers to cache all the pertinent data during the match in a lazy/efficient way. Java has ByteBuffers. I re-tested and with BerryBots, it really is only a 5% performance penalty with trivial bots. And of course some memory, but not even that much. And once you have sophisticated bots, the engine itself is only a small % of overall CPU usage anyway. | ||
| − | There's still a fair amount of work in coalescing/parsing the data, saving it | + | There's still a fair amount of work in coalescing/parsing the data, saving it, tying it into the GUI and control API, writing the replay renderer and all that, but no major technical limitations I can see. The biggest obstacle for me would just be getting my build environment setup to build Robocode, which I've never done before. The Javascript rendering could probably be forked from BerryBots, too, instead of starting from scratch. |
Latest revision as of 19:02, 4 October 2013
I'm not sure I'll make the time, but I don't see any reason we couldn't add this same style of replay support to Robocode. All you really need is fast/native buffers to cache all the pertinent data during the match in a lazy/efficient way. Java has ByteBuffers. I re-tested and with BerryBots, it really is only a 5% performance penalty with trivial bots. And of course some memory, but not even that much. And once you have sophisticated bots, the engine itself is only a small % of overall CPU usage anyway.
There's still a fair amount of work in coalescing/parsing the data, saving it, tying it into the GUI and control API, writing the replay renderer and all that, but no major technical limitations I can see. The biggest obstacle for me would just be getting my build environment setup to build Robocode, which I've never done before. The Javascript rendering could probably be forked from BerryBots, too, instead of starting from scratch.
