Open World RPG canvas problem

[knuxyl]

I need help knowing where to start by creating a composite world made up of A LOT of sections of image, 1280x640, but only draw what is visible on the screen relative to playerx and playery.

I can't find anything about composite images. I want to be able to store the playerx and playery relative to the entire composite, not just the image being drawn, hence why i need the composite.

If I can just get an idea of where to start I can narrow down what I'd need help with when it comes down to it, but idk where to begin.

[zorg]

Usually, i'd call layering (in the same place, on top of each other) compositing, but applying the term to stitching together world regions works too, i guess. (Revenge of the Attack of the Overloaded Terms)

Anyway, this is one solution:

Code: Select all

-- pseudocode follows :3
local player = {x = 0, y = 0} -- This is very basic, i'm assuming you have a player that has a world position.

local currentRegion = {i=0,j=0} -- This holds the index of the "center" region, from your camera's perspective. (i could've written "from your player's perspective, but if you ever wanted to do cinematic camera effects, like showing some other place, this being relative to the camera would be a better idea.

local worldRegions = {} -- This holds a list of loaded regions. I'm assuming they're only images, from what i understood.
local worldRegionOffsets = {} -- This is the more interesting table; each entry is a table containing two numbers denoting how many pixels a region is offset from 0,0 (0,0 because we want to have a logical anchor point)

-- When drawing, you apply the offsets so they're drawn in the correct positions; you can test beforehand whether they're needed to be drawn or not.

Now, i don't know whether you want sprites/objects/whatnot "globally" positioned, or "regionally", but i'd recommend the former, since it simplifies things a lot (except for collision detection, but there's bump for that, for example.)
Basically, you either keep everything sorted by position, and when drawing, you loop through only those that are inside the camera's viewport (basically, what you see on the screen); or you keep two tables, one with the visible stuff and another with the non-visible, that you manage each time the camera moves. (probably each frame, but this too can be optimized in quite a few ways)

Me mentioning cameras is no coincidence, they make your life easier by allowing you to have a gigantic world and simply manage what you see. You will need to convert between world and screen coordinates manually otherwise.

[knuxyl]

Ok, that is where I was at, I created a table with 4 entries labeled as MapXY, then they were a table with FILE, X, Y in it.
I am not sure how I am to refer the camera view to only specified images without having a canvas draw the entire map, which when done, will be well over what should be drawn every frame.
Like if I have

Code: Select all

love.graphics.draw(MAPXY.FILE, MAPXY.X, MAPXY.Y, width, height)

for each entry (probably in a loop to simplify, havent got that far) then it will draw the entire map and that would not be resource wise.

I'm starting this with 4 squares, Map00, Map10, Map01, Map11. Each is 1280x640. I only want them to draw when they are visible on the screen.

In essence, I just want the visible part of the screen to load into ram because the map is probably going to be like 40x120 map files, so 40x1280, and 120x640.

[zorg]

You track your player with the camera, for example:
player is at 720,320 world-coordinates.
that means he'd be at the center of Map00, for example.
If the game window/screen of the user is smaller or exactly the size of that background image, and he doesn't make the camera move, then you'd only need to draw out one image.

But usually, at least the current, and the 9 (or at least 4) adjacent squares should be at least loaded, and if the camera gets near to them, or if the game window is bigger than these, then they should also be drawn out as well.

In my previous post, you could see that i didn't have a table for -all- the regions, only for the ones that are currently necessary to be loaded; this was done through the currentRegion table's two numbers, since i assumed that filenames were something akin to what you use (MapXY), you can dynamically load them in using some relatively simple formula, like worldRegions = {}; for i=I-1,I+1 do for j=J-1,J+1 do worldRegions[#worldRegions+1] = love.graphics.newImage(("Map%d%d.png"):format(i,j) end end, though this does not test whether the already loaded ones were ones we still need to use or not (they usually would be), so it's not the best code, but for demonstrative purposes, it does the job...

[pgimeno]

I may be misunderstanding something, but this sounds like a regular tile map, except with very big tiles which are dynamically loaded.

for i=I-1,I+1 do for j=J-1,J+1 do worldRegions[#worldRegions+1] = love.graphics.newImage(("Map%d%d.png"):format(i,j) end end

Better not to use that naming convention, or e.g. the tile at (1,23) will have the same filename as the tile at (12, 3). Solutions include using some separator between the coordinates (e.g. "Map%d_%d.png"), or fill with zeros at least one of the coordinates to a fixed length (e.g. "Map%04d%04d.png").

[zorg]

for i=I-1,I+1 do for j=J-1,J+1 do worldRegions[#worldRegions+1] = love.graphics.newImage(("Map%d%d.png"):format(i,j) end end

Better not to use that naming convention, or e.g. the tile at (1,23) will have the same filename as the tile at (12, 3). Solutions include using some separator between the coordinates (e.g. "Map%d_%d.png"), or fill with zeros at least one of the coordinates to a fixed length (e.g. "Map%04d%04d.png").

Agreed, i wanted to stick with his terminology, but i should have noticed it myself thanks.