We could easily make this by using @drummyfish’s engine! https://twitter.com/joeyspacerocks/status/1167207302207868930?s=19
1 Like
Someone made a raycasted game for the Arduboy even.
It’s probably only a matter of time until we have one.
It’s kind of a shame that @drummyfish didn’t get round to adapting his engine into a game, but I understand why nobody else has done so.
Is that raycasting? I though it was some vector technique, like this, but am not sure. Anyway I’ve seen many great raycasting demos on Arduboy, it can be done really efficiently.
The idea for a complete game is still on my mind, but there are also many other ideas (currently I’m thinking about a 3D physics engine in the style of raycastlib ad small3dlib… I’m also currently busy with writing some texts). It’s unlikely I’ll get to it anytime soon, but I’m always here to help anyone who would like to create a game with my engine.
The idea for the game is basically this:
I’d like to create a game similar to Doom, which would not only be a game for entertainment, but a bigger project aimed to show how Unix and suckless philosophy can be applied to games. It should be a piece of SW not only used to kill some time, but also to be hacked, forked, reused, used in education, ported to all platforms, used as a benchmark, used in research, etcetc. You know how whenever a new platform appears, one of the first things is to port Doom to it – my game should be something like this standard, but even more portable. It would be completely public domain, written in pure C99 subset of C++, using only 32bit integer math, consisting of completely independent and reusable modules for rendering, gameplay, AI etc. It would run on PC, Android as well as on Pokitto and other open consoles.
You see I have to think this through carefully before I start.
1 Like
You’d have to ask jhhoward.
I assumed it was raycasted because there don’t appear to be any diagonal walls and the game it was based on was a Doom clone.
As noble as your intentions probably are,
I’m fairly confident that most people here would much rather have a new Pokitto game than an experiment in software development philosophy.
There is no pure C99 subset of C++.
There are subsets of C that are also valid subsets of C++,
but C99 is not a subset of C++.
In fact several C99 features don’t have C++ counterparts even in C++17.
(And unless something changes, that’s going to hold true for C++20 too).
That’s right, but to make a game you have to have motivation, and what motivates me is something like what I’ve described. Still, if anyone wants to simply create a game, I’m here to help with any questions about my engine.
I really do think it’s very easy to use, just that people are scared to even try because engines are usually hard. I did my best to make it as easy as possible.
Of course, I mean a subset of both C99 and some older standard of C++, that’s probably the most portable language you can use.
Another idea was a raycasted RPG in the style of The Elder Scrolls, but I know that’s already your plan, so I’ll likely stay with the Doom clone.
Fair enough.
Personally speaking I looked at it and got put off by several things.
Aside from the fact it’s all stuffed into a single file, some of the line splitting makes it really hard to read.
E.g.
int16_t xSquare1 = RCL_divRoundDown(camera->position.x -
RCL_CAMERA_COLL_RADIUS,RCL_UNITS_PER_SQUARE);
Instead of
int16_t xSquare1 = RCL_divRoundDown(camera->position.x - RCL_CAMERA_COLL_RADIUS,RCL_UNITS_PER_SQUARE);
or even
int16_t someMeaningfulName = camera->position.x - RCL_CAMERA_COLL_RADIUS;
int16_t someOtherMeaningfulName = RCL_divRoundDown(someMeaningfulName, RCL_UNITS_PER_SQUARE);
Not to mention stuff like the collHandle macro being somewhat difficult to do mental macro substitution on.
Also it’s nitpicking but C99 actually introduced stdbool.h and yet you’re not using it, but you’re perfectly happy to use types like int8_t and int16_t which wer also introduced in C99.
I.e. you’re happily using one C99 feature whilst simultaneously rejecting another.
Also technically #include <stdint.h> should be:
#if !defined(__cplusplus)
#include <stdint.h>
#else
#include <cstdint>
using std::int8_t;
using std::int16_t;
// et cetera for all used types
#endif
Formatting aside, I don’t think the examples are enough to understand how to use the library, let alone how it works.
It could really do with some proper documentation or at least an in-depth explanation of how it works or how to use it.
There are a number of other things I don’t like about it, but those are mainly style issues.
(E.g. the use of define instead of const variables. Though I’ve heard people claim that enum { value = 5 } is actually a better option in C, so I’m never sure what the C programmer consensus is, if there even is one.)
That’s just my experience though,
maybe someone else would like to chip in with their experience?
Don’t worry about what I’m doing.
Chances are that idea will float on my todo pile ad infinitum.
And if I do get round to it it’s looking less and less likely that it will be raycasted.
Fair points, but I think they’re not real obstacles if you’d like to use it, or even “fix” it to whatever you like, e.g. get rid of line breaks. But let me try to write an additional how-to here, maybe it will encourage someone to give it a try:
- Firstly if you’re only interested in using the library, you shouldn’t need to look further than beyond this line – above it is the API, and the functions are quite well commented if I can say so.
- There is a short how-to in the readme.
- There is a short documentation in the file itlself.
- There is Doxyfile in the repository that will generate you a documentation, just run Doxygen.
- To start you should take a look at examples, e.g. Pokitto hello world, or terminal rendering, again hopefully well commented. I think they’re pretty clear.
- You can also grab one of the three demos and simply start modifying it.
- I am always here to help with anything that may not already be clear.
2 Likes
Even if I substituted all the function macros and went through and fixed every awkard line break,
I’d still only be a few steps closer to understanding it.
Couldn’t you host a copy of that somewhere for the people who don’t have doxygen installed?
(I happen to have doxygen installed, but it’s a recent acquisition and I doubt others will have it.)
That’s arguably the most useful example.
(Though the RCL_initCamera call is mostly redundant.)
I haven’t found anything explaining what ‘direction’ is (degrees, radians, brads).
I think ‘RCL_UNITS’ could do with more of an explanation.
(I’m presuming they are completely arbitrary but that’s never explicitly stated. How they serve the purpose of fixed point arithmetic I can only guess.)
Also ‘equilinear’ apparently isn’t a real word so I have no clue what RCL_EQUILINEAR means.
My search engine seems to think it ought to be ‘rectilinear’ or 'equirectangular?.
I’m assuming from the usage that it means RCL_CORECT_FISHEYE_PROBLEM.
There’s probably some other stuff that could improve people’s understanding,
but if I keep reading this I won’t get any of the things done that I want to get done.
At any rate, it won’t be me using this library,
I have far too many other projects on my todo list.
Maybe @Hanski wants a go? :P
It’s not really pertinent to anything, but ‘fixed point arithmetic’ is uncountable, so ‘a fixed point arithmetic’ and ‘fixed point arithmetics’ are grammatically incorrect.
1 Like
I wanted to do it but I didn’t find a comfortable way to host it and keep it synced with the current version. It is really easy to generate the documentation and also I am kinda against distributing anything compiled, but I know people are lazy (as I am) and can’t be bothered to do it, so I’ll take a look at this again.
I am genuinely sorry you find the formatting “not ideal”, but this question can’t be settled, it’s like tabs vs spaces or where to put brackets. I can’t possibly format the code in a way that would satisfy everyone, I simply have to go with what I like.
Thankfully there are tools that reformat and beautify the code automatically so that you don’t have to do it manually.
It is up in the header:
Angles are in RCL_Units, 0 means pointing right (x+) and positively rotates
clockwise. A full angle has RCL_UNITS_PER_SQUARE RCL_Units.
but I’ll add an extra comment since you found it confusing.
Not sure what more I should add – yes, they are kind of arbitrary spatial units… each game square has a length of RCL_UNITS_PER_SQUARE (1024, chosen to have some precision but also to not cause overflows), and this constant is also an equivalent of 1.0 if floats were used (so e.g. sin returns -RCL_UNITS_PER_SQUARE to RCL_UNITS_PER_SQUARE, instead of -1.0 to 1.0). So the fixed point arithmetic here effectively has 10 decimal bits.
Opps, my bad, should have been rectilinear. It’s fixed, thanks 
There is a comment explaining what it does, but if you don’t know what something does, generally just leave it at default.
Thank you for the feedback, I truly appreciate it, there are things that I simply don’t catch and you’re the only person who has taken a closer look at it and reported some bugs.