Oh no worries, it’s not goin anywhere 
plus I keep myself busy messing around with other things in the meantime.
And that definitely helps clarify, thanks! I knew what the modulo operator was/did, just wasn’t sure if it was really being used how it seemed (as in the remainder being somewhat literal as far as the tile goes). Thanks again!
I’ve updated the code to make the names a bit more descriptive.
I’m going to redo the diagram using the new variable names becuase I’ve just realised the way I was doing it before probably doesn’t make as much sense in context.
One of the reasons you might be struggling to understand it is because I’m cheating a bit.
Normally you’d use the actual tile indices to index a map and draw the tile in the map,
but because the background is going to be all one tile and it’s going to be drawn infinitely,
but instead I’m drawing tiles from 0 (or -1) to the number of tiles on each axis.
Sorry for the delay in this but these last few days have been quite busy for me.
Oh no worries on the wait, sorry it’s been taking me as long to grasp it, but I’ve been intermittently working on other stuff to keep busy in the meantime… I can just see the camera system being more beneficial too, so I’m also holding off on working on anything too major til I get it (so I can use it for other applications as well). I’ll get back to it tonight though and try to get it worked out. Thanks again!
Actually, now that you mention it, ive started another game and im now at a point where using the tile indices should make more sense to me (and i would need to adapt the camera for it, too) but im still have a hard time, for a few reasons…
Mainly, im trying to figure out how to change what i have so i wouldnt have to rewrite it entirely (because so much of it is dependent on how its written now)… also since i would be using it in different ways between the games ive started I dont mean to bounce around, thats just sort of why ive been having a problem…
As for this game, since i want to repeat the actual map coordinates im confused as to how id do that now too… even if i just hold off on changing the flight part for now (due to the parallax) and only try to modify the exploration part (which is simpler and also repeats the same sized tiles).
And then additionally, i have another game i just started. Just noticed the lack of RTSes on here… i know these are due to limitations but i thought why not make a simplified/one-bit RTS and started on that (which is what the rectangle question was for)… nothing too crazy considering the limitations, just something little/portable. At the moment its the just the cursor/rectangle bit, a randomly populated 2 dimensional array (filled with 16x16 rectangles for trees, rocks, or empty space, but i can maybe work this into better patterns), and a camera object (which is currently set up to scroll like this one, but i am hoping to change to an actual camera using what you have here). Since this uses the tile indices i may have better luck giving it another look over with that in mind too, though.
Here’s another drawing that may help:
This time the variable names match up:
You’d have to loop the coordinates of objects in the world when they move past the ‘edges’ of the world.
@Botisaurus was working on a turn-based strategy, but he ran out of memory,
so he’s been reworking it when he gets time spare.
(I’ve been assisting him from time to time.)
I think one of the reasons Arduboy doesn’t have many RTS games is because usually RTS games are heavily reliant on hotkeys.
I think at the very least you’d have to be able to pause combat to go through the menus,
otherwise you’d struggle to keep up with the action.
What exactly would the difference be?
One of my other drawings might help with that one:
If in doubt, have a look at the tile rendering code from the platformer I was helping with a while back:
You should notice some similarity to my earlier code,
albeit some of the variables have different names and are initialised later.
Awesome, thank you! I’ll look back over that tonight. May try to start back from the ground up this way also, just because it would probably be easier for me (not that the entire thing would be scrapped, I could just start over restructuring it and pick the old one apart)
Yeah, I would think that and the size… small screen, but also data wise would be difficult to program all the necessary mechanics and enemy ai… but I was thinking even something as minimal as populous (the ps1 version, not the original)… was a simplified RTS but still made for some solid gameplay.
I’m still kicking around ideas for that because it doesn’t always need to be as traditional as PvP either, if size is too much a limitation I could always try to make it something like building up a small settlement and survival, resource management, occasional animal attacks, etc.
But since I’m not tiling that I suppose the camera system I have should work just as well. I just got most of the stuff fixed in that one, just have one more thing then I’ll shift back over to this and rewrite a bit. Thanks again!
Looking at this, the ability to modify the map is still going to be a bit of an issue.
Modifying the map requires RAM.
One option would be to make every modification an object stored in a big list,
but even then you’re going to be limited.
A bit like Gnomoria…
It would be possible, but you’d still have memory issues to overcome though.
At the moment I have trees and rocks in their own arrays like I have my people set up, except the resource arrays are populated randomly (as far as location). I was thinking to add them to another array to track state (0 for harvested, 1 for populated) and have them change states back to populated after a specified time. But they need to be overhauled to reflect a similar structure as my people, that saved me a 3% of ram (sorry, wasnt paying attention to bytes) just changing my people to how you showed above so im sure itll save some there as well.
Im sure memory limitations will be a big factor in how things work out, thats why i didnt set on any one idea initially, but im sure i can work it into something playable, hopefully.
So Im starting from scratch here and figure i should break it into parts for the flight and on foot (like i did initially)… started with the on foot part (due to lack of parallax) and ran into the first issue…
It seems that my playerSprite coordinates line up with the camera in a way Im not sure how to use them.
If I do:
void drawArdunautSprite() {
Sprites::drawSelfMasked(ardunaut.position.x - camera.position.x, ardunaut.position.y - camera.position.y, playerSprite, playerFrame);
}then my player sprite is placed relative to global coordinates. If I do
void drawArdunautSprite() {
Sprites::drawSelfMasked(ardunaut.position.x + camera.position.x, ardunaut.position.y + camera.position.y, playerSprite, playerFrame);
}then my player sprite seems inverse to world coordinates (moving the camera moves the sprite, but inverse).
I would think that i shouldnt be adding or subtracting it to the camera coordinates at all because the sprite is meant to be stationary in the center of the screen, but the object coordinates dont actually correspond to the camera coordinates (the camera 0, 0 is offset to the right of the sprite coordinates 32, 64). I would imagine this is due to the camera offset being used in the camera code, but im not sure how to account for this when placing my player sprite.
I have updated the files here:
Sorry, i got it, time to go get the duck again…
just changed to this:
struct Ardunaut{
Point position {camera.position.x + 64, camera.position.y + 32};
Point shadowPos;
};
Ardunaut ardunaut;
void drawArdunautSprite() {
Sprites::drawSelfMasked(ardunaut.position.x, ardunaut.position.y, playerSprite, playerFrame);
}Technically if it’s only ever going to be in the centre of the screen then you could cheat and only draw it in the centre,
but you’ll probably still need to be able to check for collisions against it.
Games sometimes have the camera separate because then the player’s entity (be it a ship or a character) can move independently of the camera.
I’m not sure what you mean by this.
Going by this I’m assuming you meant that (64, 32) was off-camera,
which would be the case because 64, 32 would be ‘global/world coordinates’.
If your ‘Ardunaut’ is only ever going to be in the centre of the screen then you could do:
void drawArdunautSprite() {
Sprites::drawSelfMasked(camera.position.x + 64, camera.position.y + 32, playerSprite, playerFrame);
}
Two bits of advice though:
Firstly instead of 64 and 32 you should do something like:
constexpr uint8_t screenWidth = WIDTH;
constexpr uint8_t halfScreenWidth = (screenWidth / 2);
constexpr uint8_t screenHeight = HEIGHT;
constexpr uint8_t halfScreenHeight = (screenHeight / 2);
Not just because of the possibility of WIDTH and HEIGHT not always being 128 and 64,
but also because it shows that the 64 and 32 aren’t arbitrary numbers - they have a specific meaning.
Secondly, is position supposed to be the centre or the top left corner?
If it’s supposed to be the top left corner then to have the sprite drawn truly in the centre of the screen you’ll need to subtract half the width and height of the sprite:
constexpr uint8_t ardunautSpriteWidth = 16;
constexpr uint8_t ardunautSpriteHeight = 16;
constexpr uint8_t ardunautCameraOffsetX = (halfScreenWidth + (ardunautSpriteWidth / 2));
constexpr uint8_t ardunautCameraOffsetY = (halfScreenHeight + (ardunautSpriteHeight / 2));
Oh, alright, thanks! I wanted the position to be center, but wanted it to share the same coordinate system as the camera (so even though the camera is at 0, 0, if the sprite is in the center of the screen its at 32, 64 like it should be globally), but giving it a more direct relationship like that definitely makes more sense so Ill change that for sure. Thanks!
In that case, make sure you account for that fact when doing any collision detection.
If everything else is expecting the collision to be the top left corner then you need to calculate the top left when doing collisions.
Yeah, I was thinking to make a second set of coordinates for global player position (for collision detection, enemy movement, etc). Thanks!
Rather than maintaining the second set between frames, you might be better off calculating them as you need them depending on how often they’re actually needed.
Aside from minimising repetition, that makes it less likely that you’ll end up getting the coordinates ‘out of sync’.