Planet Chili

Hi, I'm new here.

Here is the game thing I'm working on using the SFML library, feel free to give feedback

currently it has a text class, map manager, texture manager, and entity system
I am planning on adding a menu system with buttons and other gui things, and dialogue boxes. Oh and collision

controls: WASD

you can't really do much and it is very limited right now

I'm new to c++, so if you see any mistakes let me know

Just browsing through the code i found this in Engine.hpp : const bool collision = true;
This means you cannot change this value to false . I haven't ran it but from what i've seen in the code it looks a reasonable start.

MrGodin wrote:Just browsing through the code i found this in Engine.hpp : const bool collision = true;
This means you cannot change this value to false . I haven't ran it but from what i've seen in the code it looks a reasonable start.

Ah, I haven't implemented collision yet. I was just laying out all the variables I need.

I just recently implemented all the code to make the camera stop at the edge of the map, which also works when it is zoomed in.

You can see it in action here:


Not really a huge improvement, but it took a while to figure out.

This is what i do to focus a camera on a position m_mapFrame is a rectangle encapsulating the game "world"
The camera position in this case is top/left of the viewport/window . if we pass in an object to focus on, back off the camera half extents (center of viewport) and this will keep the object in the middle of the screen so to speak. Cap the camera position relative to the world dimensions.
I am sure there are other ways of doing this, but it works for me.

MrGodin's stuff doesn't account for zoom level, but the process should be the same. You don't want your viewport to go outside the bounds of your level. Update position of camera, check that the viewport rectangle is not overlapping the level rectangle, add or subtract the amount, if any, overlap to the position of the camera. Remember that your logic code should be separate from your drawing code. If you do this, your logic code should be pretty straight forward.

One way to look at it is when you "zoom in" your viewable area is smaller, like making the viewport rectangle smaller, so maybe do only the calculations needed to resize the rect. Then in the draw portion, you'd have to scale up the graphics assets and such to the zoom factor. Just a thought, but if it's working and you like how it is, then just move on and deal with it later when you have gotten to the point where you want to refactor.

MrGodin wrote:This is what i do to focus a camera on a position

Code: Select all

void Camera::UpdatePosition(Vec2f& in_pos)
{
	m_pos = in_pos - m_center ;
	
	m_pos.x = __max(m_pos.x, m_mapFrame.left);
	m_pos.y = __max(m_pos.y, m_mapFrame.top);
	m_pos.x = __min(m_pos.x, m_mapFrame.right - m_screen_width);
	m_pos.y = __min(m_pos.y, m_mapFrame.bottom - m_screen_height);
	m_pos.y = __max(m_pos.y, 0.0f); 
}

m_mapFrame is a rectangle encapsulating the game "world"
The camera position in this case is top/left of the viewport/window . if we pass in an object to focus on, back off the camera half extents (center of viewport) and this will keep the object in the middle of the screen so to speak. Cap the camera position relative to the world dimensions.
I am sure there are other ways of doing this, but it works for me.

That looks neat, but I'm not used to doing it that way. I'd rather work with separate x and y values to make things easier to look at.

Are you using SFML as well?

albinopapa wrote:MrGodin's stuff doesn't account for zoom level, but the process should be the same. You don't want your viewport to go outside the bounds of your level. Update position of camera, check that the viewport rectangle is not overlapping the level rectangle, add or subtract the amount, if any, overlap to the position of the camera. Remember that your logic code should be separate from your drawing code. If you do this, your logic code should be pretty straight forward.

One way to look at it is when you "zoom in" your viewable area is smaller, like making the viewport rectangle smaller, so maybe do only the calculations needed to resize the rect. Then in the draw portion, you'd have to scale up the graphics assets and such to the zoom factor. Just a thought, but if it's working and you like how it is, then just move on and deal with it later when you have gotten to the point where you want to refactor.

I actually did the zooming accidentally by using the divided screen width and height values on the reset function in sf::View. This is why it was so confusing as to why it wasn't working until I realized I had to remove the call to sf::View::zoom(). Such a time waste, but at least I got it working perfectly fine.

I have just implemented entity sorting and the game still performs surprisingly well, even with over 1000 entities loaded.

Yeah, you will find that stuff at the entity level like that costs a lot less than you might originally thing. This is why I constantly scold people for premature optimization at that level. It often just isn't worth it, and it's better to write clean, scalable, idiomatic code at that that level, and save the optimized hacks for just the few portions where it really matters.