Trying out C instead of C++, could use help.


Half Pepperoni, All Cheese
Sep 15, 2015
North Carolina, USA

According to a graph in that repo, my project is 97% C and 2% C++. Can someone help me find the rogue C++ code and eliminate it? I guess keeping my knowledge of C and C++ separate is tough.
[doublepost=1529407489,1529394463][/doublepost]Some guy in a C channel on freenode said it was probably just a false positive. Said he didn't see any C++.

I'd still be interested in your opinions.
Can you build it in a C compiler? If so, it's not C++.

I've not seen any C++ code in the files I looked at. I see no objects, just function calls, and as far as I understand the difference that makes it C not ++.
Maybe the parser does not fully support C99, your for loops and comments are not C90 compatible.
What is your target C level? "//" in-line comments came in C99.
I originally learned // in-line comments as a C++ only thing

change them to /* comments */ and see if that is it
Hey, um, anyone tried compiling this yet? I'd like some input on possible directions for gameplay.
My Pandora is out of action, and I haven't set up a code::blocks environment anywhere else.

Actually, I just created a makefile, and have been trying to match up header files. Turned out I needed to install the sdl2_image package under arch, and link in -LSDL2 and -LSDL2_image and I was good to go.

In terms of gameplay, I assume you can't do anything at present other than move about. Moving works, but being limited to a grid like that makes the controls feel laggy and makes it easy to overshoot anything you're aiming at. I can understand why you've coded it that way, but you don't find many games these days that are coded like that. It does make collision detection quicker, but it's still a hack.

Also, I've noticed you don't allow chorded arrow keys. Maybe it's just me, but on games that require pixel-perfect alignment I usually chord the game keys as I approach the interchange, which in games like Chuckie Egg at least, smoothly transitions me in that direction.

Furthermore, I'll just mention that the first name I picked for my executable based on your .c filename, ctest, is not a great name, as there's a tool packaged with cmake which is called that (so if you ever forget to ./ your filename, you end up running that instead, but with little clue as to what you did wrong).

Here's my git diffs if you're interested:
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..f5167d0
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1 @@
diff --git a/src/makefile b/src/makefile
new file mode 100644
index 0000000..45dc65c
--- /dev/null
+++ b/src/makefile
@@ -0,0 +1,29 @@
+IDIR =../include
+LDIR =../lib
+LIBS=-lSDL2 -lSDL2_image
+_DEPS = ctevent.h ctmap.h ctplayer.h ctsdl2.h cttext.h
+DEPS = $(patsubst %,$(IDIR)/%,$(_DEPS))
+_OBJ = ctevent.o ctmap.o ctplayer.o ctsdl2.o cttext.o
+OBJ = $(patsubst %,$(ODIR)/%,$(_OBJ))
+../c-test: $(OBJ) $(ODIR)/ctest.o
+	$(CC) -o $@ $^ $(CFLAGS) $(LIBS)
+$(ODIR)/%.o: %.c $(DEPS)
+	$(CC) -c -o $@ $< $(CFLAGS)
+	$(CC) -c -o $@ ../ctest.c $(CFLAGS)
+.PHONY: clean
+	rm -f $(ODIR)/*.o *~ core ../c-test

You'll need to make the src/obj directory before you run this the first time.