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

[JDTAY]

https://gitgud.io/JDTAY87/c-test

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.

 

[levi]

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 ++.

 

[Letalis Sonus]

Maybe the parser does not fully support C99, your for loops and comments are not C90 compatible.

 

[JDTAY]

Hey, um, anyone tried compiling this yet? I'd like some input on possible directions for gameplay.

 

[dgame]

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

 

[levi]

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:

Spoiler

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..f5167d0
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1 @@
+src/obj
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
+CC=gcc
+CFLAGS=-I$(IDIR)
+
+ODIR=obj
+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)
+
+$(ODIR)/ctest.o:
+	$(CC) -c -o $@ ../ctest.c $(CFLAGS)
+
+.PHONY: clean
+
+clean:
+	rm -f $(ODIR)/*.o *~ core ../c-test

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

 

[JDTAY]

Thanks for the advice, @levi I've moved on to bigger and dumber things though: https://pyra-handheld.com/boards/threads/loeve-on-pyra.83035/#post-1439464