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 - Sub

Pages: 1 ... 5 6 [7] 8 9 ... 11
91
SFML projects / Re: Game on Kickstarter 28 May!
« on: May 25, 2015, 06:41:14 pm »
How much are you guys going to be asking for? 

I'm sure I'm going to come off as a jerk, but I think the reality is that indie platformers are a dime a dozen nowadays, and you'd have to have something that looks pretty amazing for it to be successful on Kickstarter.  It's unfortunate and it defeats the purpose a bit, but you really need something that looks more or less complete, and you need an active following in order to have a successful kickstarter. 

I'd look at Moonman as an example.  Extremely professional art / animation, relatively popular dev blog (3k+ comments, 800k+ views), exposure from multiple news sites + staff pick on Kickstarter, and even that struggled to reach its modest goal.

Don't get me wrong, I think it's really cool what you've managed to build so far.  I suppose it all depends on the goal you set, but with no gameplay other than a character running around, and with the state the art / animation is currently in, it's going to be a rough road.   :-\

92
This might not look that great, but you could calculate a radius around the player, and make any vertices which fall in that radius semi-transparent while keeping those outside non-transparent.  You should get a smooth gradient between verts of different colors, check out the triangle on this page.

http://www.sfml-dev.org/tutorials/2.1/graphics-vertex-array.php

I'm not sure where there's a good / comprehensive shader tutorial

93
General discussions / Re: SFML 2.3 released!
« on: May 17, 2015, 11:37:41 pm »
Whew!  Congrats guys, this is pretty awesome.

94
Graphics / Re: Resizing a RenderTexture?
« on: May 17, 2015, 08:51:00 pm »
That makes a great deal of sense.  Thanks for the quick reply, I appreciate it  :D

95
Graphics / Resizing a RenderTexture?
« on: May 17, 2015, 08:41:01 pm »
I can't figure out how to resize a RenderTexture. 

This is some test code I've tried.  The desired result is a screen which is entirely green, but instead I'm left with a screen that's 1/4th green.

The code creates a render texture at half of the windows width and height, and then clears it red and draws the RenderTexture to the screen.  It then calls create again with the full window width/height, and repeats the process but this time with the color green.  Green does indeed get drawn, but the size remains half window width/height.

What am I doing wrong?

#include <SFML/Graphics.hpp>

int main()
{
        sf::RenderWindow Window(sf::VideoMode(200, 200), "SFML works!");
        sf::RenderTexture RT;

        //create half screen size
        RT.create(100, 100);
        RT.clear(sf::Color::Red);
        RT.display();

        sf::Sprite Sprite;
        Sprite.setTexture(RT.getTexture());

        Window.clear();
        Window.draw(Sprite);
        Window.display();
       
        //Right now the screen is a red rectangle starting from the top left to the middle
        //lets try to resize the render texture so that the entire screen is filled by it
        RT.create(200, 200);
        RT.clear(sf::Color::Green);
        RT.display();

        Sprite.setTexture(RT.getTexture());

        //doesn't seem to have an effect though.  The RenderTexture will clear green, but the
        //rectangle will still only go from the topleft to the middle

        while (Window.isOpen())
        {
                sf::Event event;
                while (Window.pollEvent(event))
                {
                        if (event.type == sf::Event::Closed)
                                Window.close();
                }

                Window.clear();
                Window.draw(Sprite);
                Window.display();
        }

        return 0;
}

I've also tried to make it a bit more explicit by making the RenderTexture a pointer, and allocating it with new
#include <SFML/Graphics.hpp>

int main()
{
        sf::RenderWindow Window(sf::VideoMode(200, 200), "SFML works!");
        sf::RenderTexture *RT = new sf::RenderTexture();

        //create half screen size
        RT->create(100, 100);
        RT->clear(sf::Color::Red);
        RT->display();

        sf::Sprite Sprite;
        Sprite.setTexture(RT->getTexture());

        Window.clear();
        Window.draw(Sprite);
        Window.display();
       
        //Right now the screen is a red rectangle starting from the top left to the middle
        //lets try to resize the render texture so that the entire screen is filled by it
        delete RT;
        RT = new sf::RenderTexture();
        RT->create(200, 200);
        RT->clear(sf::Color::Green);
        RT->display();

        Sprite.setTexture(RT->getTexture());

        //doesn't seem to have an effect though.  The RenderTexture will clear green, but the
        //rectangle will still only go from the topleft to the middle

        while (Window.isOpen())
        {
                sf::Event event;
                while (Window.pollEvent(event))
                {
                        if (event.type == sf::Event::Closed)
                                Window.close();
                }

                Window.clear();
                Window.draw(Sprite);
                Window.display();
        }

        return 0;
}

96
General discussions / Re: Mutual following on Twitter!
« on: May 02, 2015, 03:31:30 am »
I gave everyone a follow.

I'll add myself to the list, https://twitter.com/DanJP_

There's nothing posted for now, but I intend to actually start posting on Twitter one day soon ;)

97
Graphics / Re: Efficiency question
« on: April 26, 2015, 01:00:09 am »
Are you limiting the frame rate?  If not, try calling either .setFramerateLimit(60) or .setVerticalSyncEnabled(true) on your renderwindow.

It's probably not a problem, but you could experience some lag if you have too many draw calls.  Taken from the SFML tutorial

Quote
SFML provides simple classes for the most common 2D entities. And while more complex entities can easily be created from these building blocks, it isn't always the most efficient solution. For example, you'll reach the limits of your graphics card very quickly if you draw a large number of sprites. The reason is that performance depends in large part on the number of calls to the draw function. Indeed, each call involves setting a set of OpenGL states, resetting matrices, changing textures, etc. All of this is required even when simply drawing two triangles (a sprite). This is far from optimal for your graphics card: Today's GPUs are designed to process large batches of triangles, typically several thousand to millions.

To fill this gap, SFML provides a lower-level mechanism to draw things: Vertex arrays. As a matter of fact, vertex arrays are used internally by all other SFML classes. They allow for a more flexible definition of 2D entities, containing as many triangles as you need. They even allow drawing points or lines.

I didn't really look at the code too much, but every frame you're declaring a vector and pushing the sprites into the vector to be drawn after the loop.  Why don't you just skip the indirectness and draw the sprites directly in the loop? 

98
SFML projects / Re: It Always Ends In Nuclear War
« on: March 21, 2015, 07:10:33 pm »
Thanks for the suggestions guys :)

I consider myself a slow worker, but I am still making some progress on this thing.  I spent all of last Saturday and Sunday debugging various errors with the game that had popped up, which is harder to talk about than shiny new features.  I mostly worked on fixing issues / crashes due to incorrect syncing of data between the province view screen (pictured below) and the actual game data. 



I don't expect this screen to look anything like this when the game is done, but it has to look like something for now and I'm not sure where it'll end up.  In any case, I've worked out all the issues and the game is once again solid as a rock in terms of bugs / crashes.  I have no one but myself to blame for the issues, though.  I'm making my own GUI system for this game and it's a learn as you go process. 

I also spent a little bit of time last weekend stress testing units / pathfinding and I'm pretty happy with the results. 



That's a few hundred units auto exploring the map.  This is subject to change, but I currently envision the game ticking along at a solid rate similar to the Europa Universalis series, so it's pretty important that the time between turns is almost non-existent. 

Last night I built another GUI widget for the game -- We now have progress bars!  Try to contain your excitement. 



It might be a bit hard to see with the embedded screenshot.  At the moment I'm using it to countdown time until the next game tick occurs (aka the next 'turn'), as well as to show the progress of things being produced by a province. 

The remainder of this weekend I'm going to attempt to actually hook up the province growth algorithm that I have planned.  I want the number of births per 1000 people to roughly approximate the rate that populations have grown through history.  I'm going to have a rudimentary model of disease and a food/starvation system to keep populations from growing indefinitely.  In Civilization, population grows on a stairs sort of system, where it's flat for a long period of time and then it bumps up instantly when you fill up your food bars.  I want the population in this to grow in a more linear fashion, until you start developing technologies to eliminate starvation / disease. 

99
SFML projects / Re: Screenshot Thread
« on: March 12, 2015, 11:41:37 pm »
Woah, that looks really nice Elias.  Post some more!

100
SFML projects / Re: SFGUI (0.2.3 released)
« on: February 18, 2015, 02:53:07 am »
A lot can happen in two weeks  ;)

101
SFML projects / Re: It Always Ends In Nuclear War
« on: January 11, 2015, 10:43:43 pm »
Is that what your setup is like? 

I'm sure it's a great workflow once you get everything set up and you're used to it.  Too much of a hassle for me to take that on right now though.

102
SFML projects / Re: It Always Ends In Nuclear War
« on: January 11, 2015, 10:16:16 pm »
Yeah, I was just surprised at how easy it was.  I suppose I was afraid that I might have some code which wouldn't work.

I was looking for a Linux IDE which was similar to Visual Studio, and the top reply for this SO thread recommends not using an IDE, but that seems crazy to me.  I just decided to use MonoDevelop since I've used it before and it works fine.

103
SFML projects / Re: It Always Ends In Nuclear War
« on: January 11, 2015, 09:24:32 pm »
I worked a bit today on the code for getting armies (units) working, and then got bored of that and decided to get the game up and running on Linux.  SFML is awesome -- It basically worked out of the box. 



The low FPS is from the screenshot program freezing everything.

104
SFML projects / Re: It Always Ends In Nuclear War
« on: January 01, 2015, 05:44:04 pm »
Happy new year!  Let's get to it.

The Civilization series used to have a flaw in that the minimap would reveal exactly where you were on the map.  It wasn't a huge deal, but it could be abused in some situations.  For example, if you spawned near the top of the map, you'd be able to see that and plan accordingly.  Scouts would be sent south, settlers would be sent south, and no time would be wasted exploring the north of the map.  I'm not sure what version of Civilization fixed this, but it was fixed by having the minimap zoom in to fit the area explored.   

I'd like to have that same need for exploration in IAEINW.  You should have to explore or look at the terrain type to figure out where you are on the map.  Up until today, however, you were able to abuse the sides of the map to figure out where you were in the world.  Check out this old screenshot to see what I mean.



A few months back I sort of fixed it by only drawing a side of the map if a player discovered a tile on that edge of the map, but this wasn't perfect.  The entire side was still drawn, so you could gauge exactly how large the map was and where you were in it once you discovered one edge.  I've been wanting to fix this for a while now, and today I finally got around to it.  I'm now only drawing the edges of the map between the furthest explored reaches of the edge.  Check it out to see what I mean







There are more important things I could be working on, but it's the little things that make me happy.  And as an aside, I think I've now got all the pathfinding stuff worked out.

105
SFML projects / Re: It Always Ends In Nuclear War
« on: December 30, 2014, 01:32:00 am »
Thanks, I really do appreciate it :).

There are a lot of ways to go about the map generation.  I'd like to eventually have multiple map generation algorithms, but for now I'm doing something reasonably simple.  I'm doing this from memory, but from what I remember, this is the main algorithm:

-  Start with a small board (70 x 75 tiles)
-  Make every tile water
-  Pick a tile at random and make it land.
-  Add that tile to a list we'll call tiles to check.

while the number of land tiles is less than some arbitrary number (I think I made mine 35% of the map). . .

  • For every tile in the list we made we look at each of their neighboring (i think only water) tiles to determine whether to change them to land or keep it as water.
    • The closer this tile is to the first tile that we chose, the greater chance it has of becoming land.
    • If we decide to make the tile into land, we add it onto the list of tiles to check.
    • Tiles that stay as water don't get added to this list.


Once all neighbors for a particular tile are checked, that center tile gets removed from the list. When the list is empty, you can repeat the process with a new starting tile. Repeat this entire process until we hit a desired number of land tiles.

I then translate this small board onto the larger board, which I described in one of the above posts.

It seems to produce reasonable results, and you have a bit of control over things like the size of a landmass (adjust the weight on distance), the % of the map that is water (adjust the # of desired land tiles), you can dictate certain areas of the map that are more likely to contain water/land (for example, if you want a map with a gigantic ocean in the middle, you can favor starting tiles that are far away from this area), you can control how many continents appear on the map, as well as the size variance between continents (that is, how large the largest continent is in relation to the smallest) by changing the distance weight for each continent you place.

That being said, I'm sure there are better ways to go about it.  A lot of people use perlin noise to generate random maps.  I found another project on the web a few weeks ago which generated similar maps in Javascript.  You can check out the results, code, and a writeup of that here if you're interested.  I actually highly recommend it, it was really interesting.

For the height, I did something that was roughly this -- All tile corners are at height 0, and there's a list of corners that are locked and will no longer be heightened, and a list of unlocked corners.  All corners start out unlocked.  First lock all water corners. Iterate over all remaining unlocked corners and randomly either heighten a corner if allowed (i.e. this will not make it too high over any of its neighbors) / do nothing if not allowed, or lock the corner.  Keep iterating over the unlocked list until it's empty.

Pages: 1 ... 5 6 [7] 8 9 ... 11
anything