Bak

I got a Raspberry Pi yesterday, and I'm working on converting the code to use Makefiles, so maybe we will see a Raspberry Pi build at some point...

I wanted to edit the above since apparently pasting into code blocks didn't work. When I hit edit, though, both Chrome and Iexplorer freeze, so I've just tried again here with a quote block.

I figured it out. You can use $(shell ls) in a makefile to spawn a shell and run commands, but that's to slow to do for every module (~35). So instead I made the following makefile, which scans the sources for known #includes so it knows what libraries to include automatically, as well as using gcc's dependency generation so exactly the correct files will be compiled when changes are detected. It also detects shared objects and includes them in the shared object files (.so or .dll) correctly. # A global makefile for creating Discretion. This should be in the src directory.# BaK, 3-28-2013 # standard variablesCC=g++LN=g++CPPFLAGS=-I./Modules/ -O3 -WallLDFLAGS=-shared # directoriesBIN_DIR=../bin/bin/MODULES_DIR=./Modules/ UNAME := $(shell uname) ifeq ($(UNAME), Linux)# Linux specific macrosLDFLAGS += -selse# Windows specific macrosLDFLAGS += -sendif ####################### Rules .PHONY : all clean # extract module namesMODULE_NAMES := $(wildcard $(MODULES_DIR)*)MODULE_NAMES := $(notdir $(MODULE_NAMES)) # remove non-modulesMODULE_NAMES := $(subst Shared ,,$(MODULE_NAMES)) SO_FILES := $(addprefix $(BIN_DIR), $(MODULE_NAMES))SO_FILES := $(addsuffix .so,$(SO_FILES)) all: $(SO_FILES) clean: rm -vf $(BIN_DIR)*.so $(MODULES_DIR)*/*.o $(MODULES_DIR)*/*.d $(MODULES_DIR)*/*.deps # pull in dependency info for *existing* .o files (redirect errors away from terminal in case .d files don't exist)DEP_FILES := $(shell ls $(MODULES_DIR)*/*.d 2> .junk ; rm -f .junk)-include $(DEP_FILES) define make_so# param 1 is name of so file # general rule for making .so files, first make .o.deps and .ld.deps$(BIN_DIR)$(1).so: $(MODULES_DIR)$(1)/$(1).o.deps $(MODULES_DIR)$(1)/$(1).ld.deps $(CC) $(LDFLAGS) -o $$@ `cat $(MODULES_DIR)$(1)/$(1).o.deps` `cat $(MODULES_DIR)$(1)/$(1).ld.deps` ### tracks which libraries should be linked with the .so #### 1. create a blank .ld.deps file# 2. create an entry if SDL.h is detected# 3. create an entry if SDL_net.h is detected# 4. create an entry if SDL_image.h is detected# 5. create and entry if zlib.h is detected$(MODULES_DIR)$(1)/$(1).ld.deps: $(MODULES_DIR)$(1)/*.cppecho -n > $(MODULES_DIR)$(1)/$(1).ld.deps && \\if [ `cat $(MODULES_DIR)$(1)/*.cpp | grep SDL.h -c` -ne 0 ]; \then echo -n "-lSDL " >> $(MODULES_DIR)$(1)/$(1).ld.deps; fi && \\if [ `cat $(MODULES_DIR)$(1)/*.cpp | grep SDL_net.h -c` -ne 0 ]; \then echo -n "-lSDL_net " >> $(MODULES_DIR)$(1)/$(1).ld.deps; fi && \\if [ `cat $(MODULES_DIR)$(1)/*.cpp | grep SDL_image.h -c` -ne 0 ]; \then echo -n "-lSDL_image " >> $(MODULES_DIR)$(1)/$(1).ld.deps; fi && \\if [ `cat $(MODULES_DIR)$(1)/*.cpp | grep zlib.h -c` -ne 0 ]; \then echo -n "-lzdll " >> $(MODULES_DIR)$(1)/$(1).ld.deps; fi #### tracks which .o files need to be built and included in the .so #### 1. create a .o.deps entry for every .cpp file in the module's directory# 2. create .o.deps entry if StringManip.h is used# 3. create .o.deps entry if LittleEndian.h is used# 4. create the .so.deps file from the now complete .o.deps file# 5. recursive call to make so that the .so dependecies get included and the proper .o files get made$(MODULES_DIR)$(1)/$(1).o.deps: $(MODULES_DIR)$(1)/*.cpp+ ls $(MODULES_DIR)$(1)/*.cpp | tr '\n' ' ' | sed -e 's/\.cpp/\.o/g' > $(MODULES_DIR)$(1)/$(1).o.deps && \\if [ `cat $(MODULES_DIR)$(1)/*.cpp | grep StringManip.h -c` -ne 0 ]; \then echo -n " "$(MODULES_DIR)Shared/StringManip.o >> $(MODULES_DIR)$(1)/$(1).o.deps; fi && \\if [ `cat $(MODULES_DIR)$(1)/*.cpp | grep LittleEndian.h -c` -ne 0 ]; \then echo -n " "$(MODULES_DIR)Shared/LittleEndian.o >> $(MODULES_DIR)$(1)/$(1).o.deps; fi && \\echo -n "$(BIN_DIR)$(1).so: " > $(MODULES_DIR)$(1)/$(1).so.deps; cat $(MODULES_DIR)$(1)/$(1).o.deps >> $(MODULES_DIR)$(1)/$(1).so.deps && \\$(MAKE) `cat $(MODULES_DIR)$(1)/$(1).o.deps` --no-print-directory # includes the generated dependencies for the .so (this takes effect in the recursive make call from the .o.deps rule)-include $(MODULES_DIR)$(1)/$(1).so.deps endef $(foreach modname,$(MODULE_NAMES),$(eval $(call make_so,$(modname)))) #for number in 1 2 3 4 ; do \# ./a.out $$number ; \#done %.o : %.cpp$(CC) -MMD -c $(CPPFLAGS) $< -o $@

I'm trying to create a makefile to build the modules part of Discretion, but I'm running into some trouble. The modules structure is fairly organized, so I was hoping to have a single makefile to create all of them, rather than a makefile for each individual module. The dependencies are like this: the makefile is in the modules directory. Inside this directory there is a folder for each module. I want the .so file produced to have the same name as the folder. Inside each folder can be a set of .h and .cpp files. A .o (or is it .obj for c++?) file should be created for each .cpp file which depends on the corresponding .cpp and .h files. The .so file should be created with the sane name as the directory, and depend on each of the .o files. The .so file should be placed in a different location "$(BIN_DIR)". After trying to do this for a few hours I got something like this: CC=g++ GLOBAL_CPPFLAGS= GLOBAL_LDFLAGS= BIN_DIR=../../bin/bin UNAME := $(shell uname) ifeq ($(UNAME), Linux) # Linux specific macros GLOBAL_CPPFLAGS += -DLINKING_LINUX else # Windows specific macros GLOBAL_CPPFLAGS += -DLINKING_WINDOWS endif ###################### # Rules MODULES = $(shell ls -d */) # remove the '/' from all directories MODULES := $(subst /,,$(MODULES)) # remove non modules which have directories MODULES := $(subst Shared,,$(MODULES)) MODULES := $(subst MapLoader,,$(MODULES)) MODULES := $(subst Module,,$(MODULES)) # generate variable for the final SO files: "$(BIN_DIR)/$(module).so" SO_FILES := $(foreach module,$(MODULES),$(BIN_DIR)/$(module).so) .PHONY : all clean modules modules: $(SO_FILES) all: modules # I want: each so file depends on all the .cpp and .h files in its directory %.so : ../../src/Modules/%/Animations.cpp echo deps = $^ When I run this, it works ok for the first module (Animations), since Animations.cpp is hardcoded in the makefile. What I actually want, though, is for the dependencies to be ALL the .cpp files (I'll eventually substitute .cpp for .o). When I replace the dependency line with this, though: %.so : ../../src/Modules/%/*.cpp echo deps = $^ It tells me there's no rule to make ../../bin/bin/Animations.so. If you want to try it out you can get the DiscretionClient source from mercurial (hg clone http://hg.code.sf.net/p/ss-discretion/client ss-discretion-client) and put the pasted makefile into src/Modules/

I tried valgrind afterwards, but all the things it came up with seemed related to SDL rather than my own code. Admittedly, it was after the fact; I should practice with it more to really get a feel for it (maybe I was misreading the warnings). Never tried garbage collection with C (is this a thing?). How does it work?

here you go: http://sourceforge.net/projects/ss-discretion/files/ss-discretion/Server/discretion-server-3.29.2013.tar.gz/download

Debugged another memory error recently. I came up with the following strategy, which seems to work pretty well. The symptom of memory corruption is that something that is obviously correct doesn't work (for example, a data structure appears inconsistent which leads to a crash). I would create a function to do a sanity check on the data structure, and then, if it fails, exit immediately (after printing some debug information about the point at which the sanity check failed). I would have a function like: runSanityCheck(const char* messageIfFailed); then I would call this very often in the code (I did it in the in the module manager before every callback). When I run the program now, it would eventually fail the sanity check, which gives you a range of places where the corruption may have occured (between the time it failed and the previous call to the sanity check code). You can then do a binary search on your code by inserting more sanity checks until you get to a piece of code doing a write to dynamic memory, which is probably the memory that was freed at some point but is being written to anyway (and corruptioning your data structure in the process).

Sure, which architecture are you interested in?

You could prevent the offensive team from dropping bricks if a win is about to happen. Or prevent both teams. Or just near the flag room. Or they could be made visible just to the team dropping them (this would make weapons inconsistent). Combined with an LVZ image showing the enemy team where the bricks are, this would almost have the effect that you want.

I've updated the Discretion server to be based on the newest asss server from mercurial, and updated it to use a linux build process rather than what I had before. You can download the server and run it using mercurial: hg clone http://hg.code.sf.net/p/ss-discretion/server ss-discretion-server Go into the disc-asss-3.24.2013/src folder, run make, then cd to disc-asss-3.24.2013, then run bin/asss Let me know if you try it and succeed or fail. Also, I'm in the process of getting a permanent server up.

just got it working now (see screenshot)! SDL is a little bit tricky with OSX, since it uses cocoa. I'll try to get a release tomorrow (still have a few issues to sort out, like transparency) and then hopefully some of you can test it.

ss-discretion.sf.net has some information. It's not going to be a drop-in replacement for Continuum at this point since Continuum uses secret encryption which is not known yet. Therefore, any servers which use encryption (all of them) won't work. There is an ASSS patch for running discretion servers, but even the ASSS zones won't accept Discretion yet. You can play offline or try to run your own server. Hope that clears things up about what to expect.

There is a server package as well, based on ASSS, I may look for a host in the coming days to get something semi-permanent running.

Yes you have all the correct functionality. The experimental zone is not online right now, so when you hit zone list it does a refresh and gets rid of it since there's no response. When you enter it doesn't get a response to the encryption request (since there's no zone online to get a response from). Also, sound is not yet implemented.

Thank Samp.

I just released version 0.41 on the sourceforge site, which includes both a windows and a linux binary: https://sourceforge.net/projects/ss-discretion/ Not many new features you'll see in this version, but there's lots of bug fixes and I made the build process reasonable both for Windows and Linux. We have also upgraded from svn to Mercurial for version control. If you want to try building a copy of the client, first get mercurial and then do: hg clone http://hg.code.sf.net/p/ss-discretion/client ss-discretion-client After it downloads, read the building instructions which will be at: src/BUILDING.txt Let me know if you have any trouble (or if it works). EDIT: opps, wrong forum. I don't see an easy way to delete, so I'll just leave this here instead.

I just updating the path for the Mercurial server, so use http://hg.code.sf.net/p/ss-discretion/client instead of the one that was there before I edit it above (it should download a thousand times faster, the earlier one was a straight copy from the svn repository).

Newk, I just fixed some bugs based on your feedback (and just ones I ran into along the way) and made the build process more in line with standard development practices for Linux. I tested it on a fresh install of Ubuntu in a virtual machine and everything seems to work. Could you try the new process? Start with downloading the source code from the Mercurial repository: After it downloads, proceed by reading and following the instructions in ss-discretion-client/src/BUILDING.txt let me know if there are any more issues or if it works

Newk I found a bug which might be causing what you see. There was an issue with the main sleep loop where, if the timing works out right, it could enter a black screen. I'll fix it in the next few days and push a new version. Thanks for making me investigate.

Debugging for the last two days (not my intention, but I found a bug which needed to be fixed). Here are the symptoms: crashes (segfault) occur at random after some time. gdb indicates this happens usually in 3 different places, but sometimes happens elsewhere. No much to go on. I tried the standard things, using debug symbols and seeing where it was crashing using gdb to infer the error. However, it would happen in the most innocent places, and behavior would be unbelievable. After further investigation (meaning hours and hours of hitting my head against the desk), I realized it only happened after I fired bombs. Not guns, but bombs. The code is almost exactly the same, save for the different animation and different settings. Why did this matter? I had added this feature recently (meaning a year ago), where particles (bombs had it enabled) could have 'targeters', essentially like a trial showing you where the bomb was going so that you could potentially dodge it. This was all well and nice and seemed to work well. It was implemented as basically whenever a bomb was fired it would create another particle from the same spot with an existing time of (fired time - 1000ms), so that it would appear 1000ms ahead of where the bomb was. This worked well. When the bomb hit something, though I needed a way to make sure the targeter particle also stopped being drawn, since if they were by themselves it would be strange. So I added a pointer to the targeter inside the particle struct. Then if the particle was hit I did: What I didn't take into account was that the targeter might expire before the particle did, so that this had the effect of writing 0 to freed memory, which on occasion was already allocated elsewhere for some purpose. This explains random crashes in many places which make no sense. anyways, I'm EXTREMELY frustrated at this, but glad to have found it. The lesson is when you debug memory corruption, you can't look backwards from the results (start with the crashing location and work your way back, which I spent many hours doing). You need to instead forwards: figure out how to reproduce the problem and start commenting out code until it goes away, then comment out less and less until you find the culprit lines.

Hey sorry for ignoring you for this long. I will update BUILD.txt based on your comments. It sounds like you're making progress. Which zone did you try to enter by the way? Since there's no servers running, you'll probably want to try "practice offline" or something to that effect. The drivel message is normal, you can ignore it. Try pressing ESC if you need to exit (it should bring up a menu).

Well it seems to be a dependency problem. When you build it's strange that the .exe got put into ../bin/Modules/FrontEnd/ Is there a project to build libaedGUI-0.1.8a-bak ? Does it build it? What version of eclipse are you using?

Sure, what's the problem?

Yes, as mentioned in the post, I haven't testing the networking in the Linux version. Once that's tested I'll get a permanent server up. If you want, you can login as single player and use the ?cb command to setup the SSC chat bridge, so you can chat with people on the SSC servers. Any update on my questions on the compilation process?

As promised, here's the linux32x86 binary: http://www.cs.uiuc.edu/homes/sbak2/files/Discrertion-Linux-pre.tar.bz2