BerryBots pre-release testing help
The highlighted comment was created in this revision.
Hey dudes - I'm gearing up to release BerryBots v1.1.0 with a full GUI for Mac/Linux/Windows. If any of you would be willing to grab this release candidate and test it on your systems, I would be super duper grateful! I mainly just want to know it launches and runs battles ok, but obviously any/all feedback is also welcome.
I just downloaded the windows version. It is launching and running battles alright, so far.
I'll also add that it has a very nice, simplistic interface.
I get the following error with the Linux 64 bit version:
[andrew@host-110-86 berrybots]$ ./bbgui ./bbgui: error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directory [andrew@host-110-86 berrybots]$ sh berrybots.sh ./bbgui: error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directory
Great, thanks for testing this! What Linux distro/version is this?
I think the cleanest solution is probably just to ask people to install libpng (and/or check that it's installed from an install or run script first). Maybe testing a few other distros to figure out what needs installing would be a good idea before release. I know it doesn't require anything on the last two Ubuntu's.
Sweet, was able to duplicate this on Mageia 2. Will try to either get to the bottom of it or maybe just building it on non-Ubuntu will solve the problem. Right now looking to test on Ubuntu / Mageia / Fedora - still curious to hear what you're using.
Oops, I forgot I didn't say. I'm using fedora 18. I installed libpng, but then hit more libraries that I was missing. I'll try it on Windows today.
After some research, I think the problem is that you have a newer version of libpng (like libpng14 or libpng15), not that you don't have libpng at all. My Mageia 2 install has libpng15. I know what libpng is but this whole problem is pretty new to me, so I have to figure out what's the right way to address it.
Thanks man!
Versions after libpng12 broke compatability with libpng12 in notable ways. For this reason, libpng12 still has maintnance release, and many distributions (i.e. Arch Linux, Ubuntu, Debian, and after checking, Fedora 18 too) have pakages for both libpng12 and the newst version of libpng, which can be installed simuntaneously without conflict.
AW: You should be able to install a "libpng12" package from your package manager I believe.
I have no attachment to any libpng versions, so I guess the best move is to compile against whichever version works most commonly across default installs of Ubuntu / Mageia / Fedora, probably libpng14. Is that what you'd recommend?
No clue about Mageia, but Fedora and Arch provide both libpng15 and libpng12 (libpng12 isn't installed by default, but should be easy to install). Ubuntu and Debian however only provide libpng12. To me libpng12 looks like the safest for binary releases of software for now. Well, safer still is statically linking libpng, but yeah.
Thanks Rednaxela, this has been really helpful. If installing libpng12 is simple on most distros that don't ship with it, that sounds like the way to go.
I could still have a problem, though. wxWidgets will dynamically link to GTK, which dynamically links to system libpng. So I could then be linking to libpng12 and libpng15, which seems bad, but maybe it's not. I'll do some tests. Maybe I just have to build a separate binary release for Ubuntu/Debian and Fedora/Arch/Mageia, which isn't really a big deal.
Yeah, I installed libpng 1.2 and now I need libGLEW 1.8 (fedora's package mannager only has 1.7) It runs fine on Windows though!
Cool, thanks AW! Funny, Windows was the platform I was most worried about. :-) Btw are you on Windows 7?
I guess offering binaries compiled on several common Linux distros is probably a fairly safe way to go. Packaging as an RPM may help in defining/managing these dependencies, too, though.
It works here as well. But does seem to have an unused console window. Windows tends to be fairly straight forward once you know what it needs to have. Namely dlls.
On a side note, I have noticed random bot hitting itself with its own laser shots.
Compiled on Fedora 18 64-bit, if you want it: [1] (It does give a harmless warning about receiving unicode text input that I am not sure I can fix.)
But hopefully I can figure out a way not to have to offer per-distro Linux binaries...
Bah, I'm not finding much to indicate I can make this any easier than separate binaries for a few major Linux distros and providing source / good build instructions (which I have) for anyone else to compile it themselves.
Still very open to advice from any resident Linux gurus tho. :-)
Mainly what I have seen lately is many programs have moved to being managed by a package manager. I have opinions on that. But other programs such as audacity offer a few different packages for a few major distro's and the source code.
If you statically link libpng and libglew, I'd expect that to work better across distros probably Voidious.
Aren't the odds high that those each link to the system specific version of something else which has the same problem? I'm also concerned about ending up linking in two versions of libpng and libglew, since something like GTK would dynamically link them in.
Those two would link to other things yes, but those (libc, zlib and and OpenGL itself) have a very stable ABI so far as I know, and likely would not have the same problem. If really worried though, one could probably staticly link everything except OpenGL and wxWidgets. GTK dynamically linking a different one in shouldn't be a problem I think, it should coexist just fine.
I noticed this game has a lot of fast-moving bright colors--many more than Robocode.
It would be wise to put in some kind of legal disclaimer, such as:
"Do not use this product if you have been diagnosed with epilepsy or any other photosensitive medical condition."
Hi mate,
Right now i have not much time to check it out, but on my macbook the app crash instantly.
I can send you the full crash report if you want but maybe the first lines help you to see whats wrong
Date/Time: 2013-03-06 06:50:35.838 +0100 OS Version: Mac OS X 10.6.8 (10K549) Report Version: 6 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 ??? 000000000000000000 0 + 0 1 libwx_baseu-2.9.4.0.0.dylib 0x00000001926c7e8b wxEntry(int&, char**) + 11 2 voidious.BerryBots 0x00000001919610b6 0x19195d000 + 16566 3 voidious.BerryBots 0x000000019195ece4 0x19195d000 + 7396 Thread 1: Dispatch queue: com.apple.libdispatch-manager 0 libSystem.B.dylib 0x00007fff83bcec0a kevent + 10 1 libSystem.B.dylib 0x00007fff83bd0add _dispatch_mgr_invoke + 154 2 libSystem.B.dylib 0x00007fff83bd07b4 _dispatch_queue_invoke + 185 3 libSystem.B.dylib 0x00007fff83bd02de _dispatch_worker_thread2 + 252 4 libSystem.B.dylib 0x00007fff83bcfc08 _pthread_wqthread + 353 5 libSystem.B.dylib 0x00007fff83bcfaa5 start_wqthread + 13 Thread 2: 0 libSystem.B.dylib 0x00007fff83bcfa2a __workq_kernreturn + 10 1 libSystem.B.dylib 0x00007fff83bcfe3c _pthread_wqthread + 917 2 libSystem.B.dylib 0x00007fff83bcfaa5 start_wqthread + 13 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0000000000109f80 rbx: 0x0000000000000000 rcx: 0x0000000000000001 rdx: 0x00000000000fc080 rdi: 0x000000000013b7e0 rsi: 0x0000000000100000 rbp: 0x00007fff5fbffa90 rsp: 0x00007fff5fbff978 r8: 0x0000000000000000 r9: 0x000000000013b300 r10: 0x00007fff8ab4b630 r11: 0x0000000000000000 r12: 0x00007fff5fbffa08 r13: 0x0000000000109f60 r14: 0x0000000000000000 r15: 0x00007fff5fbff9f0 rip: 0x0000000000000000 rfl: 0x0000000000010206 cr2: 0x0000000000000000
I plan to give it a deeper look on weekend.
take care wompi
It just won't work on anything before 10.7. I tried to get it compatible with 10.5 or 10.6 but couldn't get the main gfx library (SFML 2.0) to compile with that. Still like 30% of folks on 10.6, so that kind of sucks... But I'm a late updater and even I'm on 10.8 now so hopefully most people will be on at least 10.7 pretty soon.
Thx for giving it a shot tho!
Actually, I am going to take another pass at 10.6 compatibility. I'll let you know if I have any success and maybe I can get you to try it again...
Argh.. i didn't read the requirements, sorry that was my bad. If it comes to updates, I usually switch to the next version if there is a program I want and which needs those requirements. And because I desperately want to have a look at BerryBots, it is a perfect time to get "Lion", I guess.
Please don't bother with 10.6 compatibility, it's not worth the time.
Take Care
Wow, I'm honored. :-)
I'm all in favor of being as backwards compatible as possible, so I gave 10.6 compatibility another shot, but I couldn't get it working. I got wxWidgets and SFML to compile with the 10.6 SDK and 10.6 target version, but my XCode project itself still fails with some linker errors I can't figure out when I set the target to 10.6. Seems like I'm close, but I'm at a loss...
So far it's working on my Windows XP box. But the first match I tried seems potentially buggy. I put Drifter and MyFirstShip into lasergallery. Is lasergallery just meant for 1 ship? The two ships seems to start on top of each other. Is robot positioning random? Or controlled by the level perhaps? Sometimes Drifter drifts away and it runs okay, but most of the time Drifter holds still while MyFirstShip totally spazzes out, always appearing to touch Drifter but bouncing from side to side like mad. [1]
A couple other things. I realize this is still an early release, but is there a way to set descriptions for stages? One of the first things I noticed was that I had no idea what the stages were meant for, outside of guessing based on the file name. It would be nice if their was a way for stage designers to set descriptions for their stages that could be read by users when picking a stage to run.
Also, when the New Match window is open, the BerryBots window where the battle plays out doesn't repaint. A minor thing, and it's interesting the patterns I can make by running other windows over top of it, but I doubt that's an intended feature. :-)
Another bug or perhaps just me not understanding the level, on the drift stage I put WallHugger and Drifter in it. WallHugger wanders around the walls while Drifter tries to go up the middle. Drifter always wins, but WallHugger always makes it to and around the zone at the top before Drifter gets there. If the goal is to get to the zone first, WallHugger should be winning. Or maybe I misunderstand the goal?
Would you rather me be spamming all this feedback in your BerryBots forum? Or do you want to keep it here among Robocoders for the moment. I have been assuming the latter.
![[1]](http://www.distantvisions.net/robocode/MyFirstShipSpaz.png){kind=link}