Messages

1

Graphics / Re: Dealing with the tilemap issue without sacrificing zoom capacity

« on: May 05, 2016, 10:58:50 pm »

REVALATION:
When I call setSmooth(true) on the computers that didn't have the error, it creates the error.

I think the computer having the issues is overriding the smooth option in the driver settings and forcing it true, causing this error.

Is there anyway I can deal with this besides just telling the user they need to turn that off?

2

Graphics / Re: Dealing with the tilemap issue without sacrificing zoom capacity

« on: May 05, 2016, 10:22:55 pm »

Okay I had a friend with an nvidia gpu test it and they didn't see lines either. it seems to be a problem with my system specifically. I'll look into it when I get home but, does anyone have any clues as to what might be going on?

3

Graphics / Re: Dealing with the tilemap issue without sacrificing zoom capacity

« on: May 05, 2016, 09:13:08 pm »

A possible solution mentioned on the IRC channel (by Jonny I think) is to render an area of the map, unzoomed, using the working view, to a render texture. Then you can zoom in/out on the rendered area and draw it to the window using a sprite or a single quad via vertex array.

That sounds like a good idea. After I send the program to some friends to see whether they get the error I'll investigate this. I'm still trying to figure out why it happens on some computers but not others...

EDIT: I had another friend with AMD run it and they similarly did not experience issues. Now I just need someone with nvidia that isn't me to run it.

4

Graphics / Texture smoothing override (and how to deal with it)

« on: May 05, 2016, 08:51:52 am »

So I implemented the ole vertex tilemap example into my game project today, and ran into the dreaded "lines appearing between tiles" problem.

(click to show/hide)

I read about a billion threads on the topic and spent a good while wrangling with it, tossing std::floor all over the place, until I narrowed it down to one problem: the view size. When the view is the same size as the window, everything works perfectly. But when I change the size of the view (or the window) it goes to hell.
(btw I am using a letterboxing algorithm when the window is resized https://github.com/SFML/SFML/wiki/Source:-Letterbox-effect-using-a-view)

EDIT:
It turns out this was happening because texture smoothing was being forced, so texture.setSmooth(false) had no effect. I didn't notice because my tiles were solid color, but when drew shapes in them I realized the textures were blurry... so it looks like this is my real issue and I'll have to figure out the fix. I can fix it on my own computer but I can't go onto any user's computer to make them turn off smoothing override...

5

General discussions / Should I put drawing and processing in separate threads (and other questions)?

« on: May 04, 2016, 06:14:06 pm »

I currently have a standard game loop that calls process() and then draw() on the contents of a vector<Entity> of dynamically allocated Entities. (I have 2 vectors of pointers, one for processing and one for drawing, and the drawing vector is sorted by y-value of each entity before drawing because this is a top-down game that layers sprites based on that. They currently use raw-pointers because I didn't know shared_ptr existed when I started this project, but I'm going to refactor them into shared_ptr so the drawing vector won't lose stuff in the middle of a draw run)

I considered putting drawing in a separate thread so that the game logic won't be blocked if the draw calls take too long for some reason (although I don't really anticipate this happening).

Really I'm wondering how I should handle this situation, as well as whether the way I'm managing the sprite layering correctly and how I should determine the tick rate of the game logic.

(Here's a screenshot of my game right now if you're curious
it's my first game and it's really primitive right now so go easy on me pls)

(click to show/hide)