Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Proply

Pages: [1]
1
Thanks, yes I eventually realized that the window would open after waiting a while (~40s), which eventually lead me to identify the keyboard as the culprit. See https://stackoverflow.com/questions/53017551/sfml-renderwindow-taking-a-long-time-to-open-a-window.

2
Hi,

I have a very odd problem that has just recently started occurring. When I try to create a RenderWindow variable, my program will simply hang - e.g. the last line of the code below will never execute.

std::cout << "go to here" << std::endl;
sf::RenderWindow window(sf::VideoMode(2560, 1600), "SFML window");
std::cout << "got past here" << std::endl;

Weirdly, if I restart my computer and execute this code, the RenderWindow will be successfully constructed and program execution will continue for the first few times. However, after a couple of minutes, it will start hanging on RenderWindow construction again. Any ideas as to what might be causing this?

Thanks in advance for any replies!

3
Ok I have implemented vertex arrays for displaying terrain tiles, but am now running into a problem re-implementing the zoom functionality. Previously all terrain tiles were sprites, so i simply used setScale() to scale the tiles to any square from 8x8 px to 64x64 px, resulting in a nice smooth zoom effect. The problem with zooming using vertex arrays is that sf::Texture is not scalable. What is the best alternative to including a tileset for every desired zoom level? (which would be fast but uses quite a lot of video memory).

-Thanks, Proply.

4
Of course, thankyou! I knew I must have been missing something obvious.

5
Is it only possible to apply one texture to a vertex array? My terrain tile map consists of many different types of terrain and therefore many types of textures need displaying on the screen.

6
Thanks for the reply, will update once I have implemented your suggestions (or tried to at least!).

7
Graphics / Wanting suggestions for improving "lighting" performance
« on: April 26, 2013, 06:38:01 am »
Hi All, I am building a game for fun/learning using SFML that basically simulates a planet. The surface of the planet is represented through a layer of square terrain sprites, with sprites of other objects such as trees or clouds drawn on layers above this base. When fully zoomed out there can be anywhere up to 36K 8x8 px terrain sprites drawn on my 1920x1200 screen at a time, with sprites on subsequent layers further increasing this count. Obviously this results in low FPS, and I am looking at ways to improve this (specifically I need to investigate the suitability of vertexArrays and/or tileMaps which I currently know nothing about, or as a last resort just limit zoom!), but I have a specific question regarding my implementation of lighting for a day/night cycle. Each tile on my world map has an insolation value (amount of light from sun hitting this location), and to illustrate this value the final graphical layer is an array of black tiles the same size as the terrain tiles underneath, with an opacity value applied to each tile that is the inverse of the insolation value - so in light areas most or all of the tiles underneath the black tile layer are visible, but in dark regions very little makes it through the opacity filter. Obviously as this is the equivalent of drawing the entire terrain layer again it reduces performance significantly.

My question is if this is the lowest-cost way of achieving this effect, or if there is some way of shading each terrain tile/tree/cloud/etc sprite as they are drawn to achieve the same effect that would be faster, or perhaps there is some other method that I am not aware of that would be helpful. Feel free to offer advice on improving performance of displaying my terrain tile array/trees/clouds etc if you wish also, but I have yet to research this thoroughly myself.

-Thank you for your attention.

[Edit]: spelling

Pages: [1]