0
\$\begingroup\$

I'm working on a top-down 2D RTS with C++ and SDL2, and have implemented the biome/terrain generation, tile rendering and a rudimentary camera system. I already have the skeleton code in place that can create 64x64 Chunks but what I've been struggling to realize is how to render them on an infinite grid plane, where they will dynamically generate/load and deactivate/unload based on the cameras scrolling position. What design patterns and SDL functions should I use to achieve "infinite terrain rendering?"

\$\endgroup\$
2
  • \$\begingroup\$ How many chunks do you need to have on the screen or processed offscreen at the same time? \$\endgroup\$
    – Philipp
    Commented Jun 27, 2023 at 9:14
  • \$\begingroup\$ Judging by my experimentation, we need to have up to 16 chunks drawn at a time (1-4 Onscreen, 8-12 Offscreen) \$\endgroup\$
    – ireece1
    Commented Jul 1, 2023 at 18:04

1 Answer 1

1
\$\begingroup\$

I'm not going to go into much detail, but conceptually, in broad strokes... what we're talking about here is display, not game logic, and not the vagaries of SDL. So I won't go into chunk generation, but rather, chunk & chunk-slot management (assumes you have chunk data already).

Forget 2D. Think 1D, a straight line running left to right. Imagine you have the data of 4 elements (chunks) A, B, C, D. Imagine that the infinite world this 1D line represents consists of a never-ending sequence of ...ABCDABCDABCD... in both directions along the line. And imagine that you can always see for 2 chunks in either direction (to each side of you, left & right). 2+2 = 4 slots.

So let's say you're sitting between AB & CD. Great, you have two chunk slots to either side of you. Right now they're filled with AB & CD. But what if you move right? Well then you need to take A and put it next to D, don't you? If you move more right, then you need to shift B over next to A as well... and then C... and then D... and then A again... ad infinitum.

The opposite applies if you're moving left... ad infinitum.

I like to think of it as the "area of interest slots" problem. You have 2 slots to one side, and 2 slots to another. What is in each of those slots (A, B, C, or D) varies as the player moves. But they should always be able to see for 2 slots in each direction in my example; your viewing distance may vary.

Then step it up into 2 dimensions. I would use the first 16 letters of the alphabet to create a 4x4 space where you always remain in the middle, but the chunk slots shift around you.

Then to dispay your 2D world, rather than just flipping a finite number of chunks data (ABCD) between slots as above, you'll instead use generated data to put into the slots, and move those slots in x and y, rather than in just one dimension.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .