Seriously though, we could just have a couple of tiers of question asking badges:
“Asked a question”, “Asked a notable question”, “Asked a famous question”
It started as a joke, now I’m not even sure if I’m joking anymore.
I think I’ll just leave that idea haning and come back to it if we need badge suggestions in the future.
Semi-related: earlier today I discovered a discourse plugin that allows threads in designated categories to be marked as ‘questions’ and then the owner of the thread can opt to select a specific post as an ‘answer’ (kind of like Stackoverflow).
Now I’m a happy user of this pattern, but I’m encountering some problems using this with Embitz. The code works perfectly with Code::Blocks but compiling in EmBitz rise some strange erros.
Ok, this is going to be my official last post for the day :P
I think it’s possible that the error is actually nothing to do with the template.
I took the code and tried to compile it and I think I’ve found the problem.
I think it’s possible that that the compiler doesn’t like that you’ve got an unused variable.
For some reason there are certain ‘warning’ situations that EmBitz flags as errors.
I suspect it’s something in the project settings that can be changed though.
I never actually got it fully compiling because FixMath kept giving me various errors.
It would be kindly if it tell me in a better way.
Anyway that was the point, just removed the “unused/debugging” variable and everything compile correctly.
It sort of does tell you.
The warning saying ‘unused variable’ is underneath the red error message.
I admit that it probably should be highlighted in red as well though.
There should be a way to make it not flag up unused variables as errors.
I’m not sure if it’s a bug in the system, an ill-conceived ‘feature’ or if something somewhere is using a pragma to force that particular warning into an error.
Let’s suppose now I need to incapsulate a couple or more of 2d const array in a object.
The plan is to have a Layer.h class that have a “reference” to immutable 2d array that describe the tiles with another 2d array that keep track of rendering modification or functionality of the tiles.
Should the Layer.h class keep a pointer to the 2d array? If so how should I build the contstructor ?
Sure, that was quite smoky also for me.
You can reference the code posted before for the basic structure of this small project I’m working on.
Basically it’s a 2d platform game where the map is stored as 2d array of tiles index.
const uint8_t map_0_data[14][64] ={...}
Toghether with this there is also another 2d array of the same dimension that store various bit that contains rendering info
const std::bitset<4> map_0_renders[14][64] ={...}
This is used to flip the tiles or rotate them.
There’s also another 2d array that store tiles properties (solid, animated, destructible etc etc)
Note all this arrays are const to avoid use precious ram. There should be some other data that will not be const to keep track of map modifications.
Now I’d like to pack all this data together, maybe storing as reference in a Layer class, keeping a reference (pointer?) to original data. In this way I can build some common methods to manipulate and render the map all together.
Now I’ve a ugly but workink method that looks like
Or perhaps even doing the bit shifting yourself in this case.
std::bitset is a good match for when you just need arbitrary bits or you don’t feel confident enough to write your own bit handling, but if you’re giving bits special meanings and you think you’re up to it then doing your own bit manipulation might be worthwhile.
Assuming that you can’t split your arrays up into separate values then you’re going to end up with large templates, there’s little choice in the matter.
Yes, but you’d have to write something to manually handle the bit packing.
I could probably write something suitable, but I’d need to know as much detail about the use case as possible and I’d rather leave it till tomorrow because I’ve been juggling a lot of things and it would require more focus.
new is for dynamic allocation only, and you probably don’t want to be dynamically allocating.
Well the idea behind is simply that when I need to render a tiles at cell X,Y I can simply extract the index from
map_data[x][y] and get rendering information at render_data[x][y], same 2d address.
If you don’t need the 3 arrays to be separate then you could make matters easier by fusing the 3 into 1.
(Although you might miss out on an opportunity to save memory with the render flags.)
That’s good to me!
When you said only one array I didn’t understand what kind of array were you thought about. I get the idea of fuse all data in a huge array [width3][height3]. That sound soo ugly.
So when I found a tile that is destructible I look in the table for a specific row and column. If found I decrease the life.
This should limit RAM usage.
For animations there’s something similar but I’ll change it, because it’s a waste of memory have different animation for every combination of row-cell. I’ll simply look for the specific tile id.
Ok, I’ve finished writing something.
It looks like a lot of boilerplate, but it’s not.
I haven’t tested it so let me know if it doesn’t compile.
I’ve assumed since you were asking about EmBitz that you have access to C++11, if you don’t it’ll need a big rewrite.
const Tile tile = tileMap[0][0];
// Test if the tile is both visible and solid
bool isSolidAndVisible = tile.getPropertyOptions().hasAllFlags(TilePropertyFlags::Solid | TilePropertyFlags::Visible);
// Test if the tile is using FlipV or FlipH
bool usesFlipping = tile.getRenderOptions().hasAnyFlags(TileRenderFlags::FlipV | TileRenderFlags::FlipH);
I debated whether to allow stuff like tile.getPropertyOptions().isVisible() (which could still be enabled),
but I decided against it because even though it’s often easier to read, it could lead to larger and slower code.
For example, the following two things are logically equivalent:
But ‘Option 2’ is done using bitshifting and ‘Option 1’ probably requires more jumps (depending on how good the compiler is), so it makes sense to use the second version, even if the syntax isn’t as nice.
I find it kind of odd that Visible isn’t part of RenderFlags instead of PropertyFlags.