Noughts n' Crosses - A simple tic-tac-toe game [1.1]

And thus I have created this thread:

Now everyone can discuss it properly instead of cluttering this thread.

Ive released version 1.1, it shaves off 500 bytes of progmem and i cleaned up the code alot. Plus I added a hex!

1 Like

Have you considered using Github’s release feature to keep track of your releases?

(It makes it easier to provide a stable release that’s separate from the master so you don’t have to worry about breaking the master branch. And you can provide hex files as an extra upload.)

Alright, I added a release.

1 Like

One last thing while I think of it.

You accidentally re-added arduboy.audio.on() back in so the game ignores people’s sound settings and turns sound on regardless.
(I’m guessing you were using that for testing or something.)

Other than that, job done.

Yeah, it was so the emulator sound worked. ABE gets really buggy.

Oh yeah, I saw that thread.
Hopefully that issue will be fixed later down the line.

It’s a shame you can’t do #if defined(PROJECT_ABE) to conditionally put stuff in for the emulator and leave it out for actual Arduboys.

Let me talk to FManga about that.

He rejected the idea since it would be discarded if arduino compiled it and it would still carry over on the arduboy.

I thought that would be the answer (one of the reasons I didn’t bother to post the suggestion myself).


In future you could put #define DEBUG at the start of your code and then use #if defined(DEBUG) to do all the debugging stuff like manually forcing sound on.

You still have to remember to remove the #define DEBUG, but it would let you do other debugging stuff.
(Just remember to test the release version as well.)

Visual Studio does that automatically for C# programs.
It can be quite handy (again, as long as you remember when you have it on and off).

Advocating #define?! Who are you and what have you done to the real @Pharap?! :stuck_out_tongue:

1 Like

Every language construct is a tool and every tool has its uses.
I don’t implicitly hate all use of #define, only the uses where there are better alternatives,
like using #define to define constants (e.g. #define GAME_STATE 1) or function macros (e.g. #define min(a, b) ((a) < (b) ? (a) : (b))) because those suffer from various issues.

In the former’s case it’s untyped, doesn’t always give nice error messages (since errors are sometimes generated after substitution) and of course has no concept of scope.

In the latter’s case it can’t be overrided like functions, can result in larger code (hence why absT can be found in Dark&Under - the template approach made smaller code) and suffers from the same ‘error message’ and ‘macro bleed’ complaints.

Using preprocessor symbols for conditional compilation on the other hand is usually justified.
Be it for including/excluding certain features, for detecting details about the compiled platform or for doing things other language features can’t do.
(For example, PROGMEM is actually a define for __ATTR_PROGMEM__ (which I think is a define for __attribute__((progmem))), and no other language mechanism that I’m aware of would handle that in a suitable way.)
Of course, those can still ‘bleed’, but in some cases that can be prevented, e.g.

#if defined(DEBUG)
constexpr const bool IsDebug = true;
#undef DEBUG
#else
constexpr const bool IsDebug = false;
#endif

You didn’t have to justify, I was just kidding, hence the “:stuck_out_tongue:” .

For DEBUG, a macro makes sense. For PROJECT_ABE I think it’s problematic (compile-time decision for a run-time condition).

Maybe not, but I don’t think I’ve gone much into detail about it before.
(And it’ll be good to refer people back to, or I can re-use it for other explanations at a later date.)

It depends how aware people are of how preprocessor symbols work.
Really I think the issue is more ‘how useful would it be’ than people not realising that preprocessing doesn’t work on hex files.

I think it would be useful while there are still issues floating around so people could keep working until the issue is fixed rather than having to stop using the emulator.
(I’m thinking hypothetical issues rather than issues that have happened.)
Maybe I’m overestimating the usefulness though, I wouldn’t really know what sort of issues there have been or are likely to be.

I think it would be best if people made their own defines (like DEBUG), instead of trying to detect the emulator because of a bug in a particular version. When the bug is fixed in the emulator, we don’t want to have to update the hex to see the expected behaviour.

In this particular case, the best solution would be an option to enable sound in the main menu (B to toggle sound). This is necessary for people playing on real hardware anyway, as they might have audio disabled from a previous game.

I think im going to forgo with eeprom since it seems a little gimmicky and might clutter what i think is some pretty elegant c++ code. Luckily for my next game I will have another (and simpler) chance to use eeprom.

1 Like

Fair enough.

The only thing I could think you’d want to save in noughts and crosses is a tally of who has won, but I’m not sure that’s worth it anyway.
If people want to keep a tally then it’s easy enough to do on pencil and paper.

1 Like