Messages

31

General / Re: 2D First Person Dungeon Crawler

« on: November 26, 2012, 12:51:21 pm »

Note that you don't need 3D though, many dongeon crawler similar to the one you mentioned successfully used 2.5d, and this can often result in very beautiful environments for a fraction of the work needed for a 3d scene. Shin Megami Tensei or Arcana on SNES comes to mind, but examples are too numerous to know them all.

The idea is to have tiles for each position of walls and floor / ceiling.

The "3D" view is split in floor, ceil and wall ; each is then split for each "depth" layer (1st layer, 2nd layer, maybe 3rd layer... I think most games stop at 5 layers or less).
Now, there are a few more tricks if you want to be able to see through openings in the walls.
This also means moves aren't easy to smooth, the basic approach will be to move a whole cell at a time.

In the end, it's a lot of little tricks, so it's far from easy, but it's definitely possible, and can be quite fun too.

I figured that is probably how you do it, have some sort of max view, which represents how far into the dungeon you can see in a straight line ( say if you were to stand in a long corridor ). From the screenshots of other games I think maybe 3-4 cells then if it's not a wall in the 4rth cell, use a black image to represent to corridor continuing.

But the real problem is positioning the graphics of the ceiling, walls and floors. I'm utterly bad of positioning GUI and stuff without an editor, but I'm guessing experimentation with values is the way to start?

32

General / Re: 2D First Person Dungeon Crawler

« on: November 26, 2012, 09:04:16 am »

After reading your post, I feel that maybe fixed 3D is the way to go ( I have been suggested this elsewhere also ), maybe it's time to actually take my time to do some fancy 3D OpenGL + SFML stuff?

Don't want to be a hassle but, maybe you know some good sources online? Sounds like it's just easier to textureize.

I'll look into both options! Thanks for such a quick and informative reply!

33

General / 2D First Person Dungeon Crawler

« on: November 26, 2012, 01:00:49 am »

I'm inspired to make a 2D FPV Dungeon Crawler like Arcana, Eye of the Beholder.
You know when you see a psuedo 3D dungeon in a first person perspective like this:


Now, I'm note sure that SNES supported 3D so I suppose it was all done in 2D, I know that all tiles are drawn to look 3D when pieced together.

It's just that I have no idea on how to code this, at all, not even the simplest clue. I have done 2D top-down and side-scrolling but not a 3D-looking 2D dungeon with "depth". I know this can be achieved through 3D-programming with z-depth and all that fancy stuff, but I'd REALLY just like to do it in 2D, the classical way.

I figured some of you old foxes might know how to code this, and might nudge me in or explain it. I'v tried googling it but I came up with 0 topics around first person view in 2D.

The harders part I can imagine is scaling and positioning the walls, floors and ceilings that's further away so it looks like a complete hallway that you can see a defined amount of "cells" into.

Items, Monsters and other stuff is just plain scaling and not much piecing together with the other tiles so it shouldn't be hard to do.

So how do you do a 2D first person view for a Dungeon Crawler using strictly 2D?

34

General / Re: Raspberry Pi

« on: October 24, 2012, 08:57:48 pm »

You are an angel! Sorry for not reading ahead!
ARM is not supported you say? Have no clue what that is but I'm googling it later!
And you say yet? Have their been any updates about it? Or is the information provided in the linked post everything?

35

General / Raspberry Pi

« on: October 24, 2012, 08:16:08 pm »

I'm really thinking of buying a Raspberry Pi ( Mini Linux Computer ).
I know really nothing about Raspberry Pi ( I'm actually discovering it right now ) but it seems awesome as a toying computer!

I was thinking of running Raspbian ( Debian optimized for Raspberry Pi ). I'm completely new to Linux in general but I was thinking it was a good way to start with it.

I'd like to write graphical applications using C++ and I was wondering if I could use SFML 2.0 on the Rasberry Pi?

Kind regards,
Moonkis

36

Graphics / Re: [SFML 2.0] Render onto a sf::RenderTexture messes with quality?

« on: May 17, 2012, 05:01:30 pm »

Sorry but your code is neither complete nor minimal, I can't help you. Please follow the link that I posted and read carefully what's in it.

I created a minimal reproduction of the problem:

#include <SFML/Graphics.hpp>

int main(void)
{
  sf::RenderWindow window(sf::VideoMode(800, 600), "TITLE AND STUFF");
  sf::Event evnt;

  sf::RenderTexture render_texture;
  render_texture.create(800,600);

  sf::Text text("The old brown fox was filled with joy.");
  text.setCharacterSize(12);

  sf::Sprite sprite;

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

    render_texture.clear(sf::Color::Transparent);
    render_texture.draw(text);
    render_texture.display(); // Apprently this is needed since it's flipped else
    sprite.setTexture(render_texture.getTexture());

    window.clear(sf::Color::Black);
    window.draw(sprite);
    window.display();
  }
}
 

37

Graphics / [SFML 2.0] Render onto a sf::RenderTexture messes with quality?

« on: May 17, 2012, 03:14:41 pm »

Hello all!

I'm been programming the "Saaga Engine Project" which is a text-based adventure engine.
I'v hit up a early version of it yesterday which featured "word by word printing" and some fancy GUI surrounding the screen.

I'm planning to implement word-wrap and allows for rich text ( I'll probably come back later with this topic since I'v been busting my head figuring out how I should parse text with some "tags" that enables different styles of the text. Like This is a Yellow Text will be printed in yellow ).

I am by no means a programming pro I'm more of a n00b with the big 0's. I started making a TextHandler class but seeing as it had a lot of functions that my State's had I decided to make it a TextState that WorldState owns an instance of ( that can be passed onto the sub-screens like Inventory and World Map ).

After a LOT of debugging my code to get it to work ( preparing the code for rich text by having a vector list with all the sf::Text and sf::String objects ).

Enough with the jibberjabber WHAT is the problem son!?
Well when I'm drawing my text with a normal for-loop the text is clear and nice but when pre-rendering it onto a sf::RenderTexture it's thinner and a lot less crisp. Is this a normal behavior and how do i fix it?

EDIT: Minimal example further down the thread, sorry for inconvenience.

38

Graphics / Re: [SFML 2.0 RC] Tiles render slow?

« on: May 16, 2012, 11:29:24 am »

I think I realized what you ment by not using my view's size. It's that the code doesn't dynamically adjust itself to another resolution so if I were to support a larger resolution their is a risk that the tiles I'm drawing wont cover the screen area. Is that what you meant?

I just meant that, to find which tiles are inside the view, you obviously need to know its size
In fact yuo have it (20 * TILE_WIDTH), but using view.getSize() instead would be more explicit and maintainable.

Yeah, realized that but at the time it was getting really late so I figured I'd just hardcode how many tiles to draw for each side of the middle. But now that I know it works ( and it works WELL ) I'll complete it with View.getSize() calculations to adjust how many tiles will be drawn.

I think I managed to actually get the culling using the view right this time:

Yep, looks good. But it's definitely not as easy and efficient as the other solution.

Haha sweet!
Yeah no kidding, getting 750 FPS with Indexed Culling ( Which also is map-size independent )  and about 41 FPS with the Collision-based culling of an 255x255 map ( 65025 Collision checks... ). But with a quad-tree it supposed to be a lot faster.


I also must thank you! You gave quick replies and ( even though it was a bit frustrating ) you didn't give me the direct solution right way just said and hinted what I'd have to use so I could think and code it myself, which hopefully earns me some knowledge that makes me ( slowly ) a bit better in the art of graphical programming. Though I'm getting a feeling that it's not the easiest thing to wrap your head around ( Especially the math in the beginning since you haven't really used it in this way before ).

39

Graphics / Re: [SFML 2.0 RC] Tiles render slow?

« on: May 16, 2012, 07:49:30 am »

But it renders the tiles from the center and down to the right ( It only draws tiles on 1/4 of the actual window ). How do I get it to align correctly and draw the entire screen full of the tiles.

Read the documentation of sf::FloatRect
You just copied and pasted the view's center and size in it, without checking what arguments it expects.

Your second code looks good, but the formula is probably wrong (the view's size doesn't appear in it).

I'll do it when I get home later today! Thanks for the quick replys Laurent.

The Indexed Culling actually worked like a charm!
Here is the code I did last night ( I get around 750 FPS on a 10000 by 10000 map ):

  /* Culling code */
    int startX = (veiw.getCenter().x - ( 20 * TILE_WIDTH))/TILE_WIDTH;
    int endX = (veiw.getCenter().x + ( 20 * TILE_WIDTH))/TILE_WIDTH;
    int startY = (veiw.getCenter().y - ( 20 * TILE_HEIGTH))/TILE_HEIGTH;
    int endY = (veiw.getCenter().y + ( 20 * TILE_HEIGTH))/TILE_HEIGTH;

    if(startX > MAP_WIDTH)
      startX = MAP_WIDTH;
    if(startX < 0)
      startX = 0;

    if(startY > MAP_HEIGTH)
      startY = MAP_HEIGTH;
    if(startY < 0)
      startY = 0;

    if(endY > MAP_HEIGTH)
      endY = MAP_HEIGTH;
    if(endY < 0)
      endY = 0;

    if(endX > MAP_WIDTH)
      endX = MAP_WIDTH;
    if(endX < 0)
      endX = 0;


    for(int y = startY; y < endY; y++)
    {
      for(int x = startX; x < endX; x++)
      {
        sprite.setPosition(x * TILE_WIDTH, y * TILE_HEIGTH);
        window.draw(sprite);
      }
    }
 

EDIT:
I think I realized what you ment by not using my view's size. It's that the code doesn't dynamically adjust itself to another resolution so if I were to support a larger resolution their is a risk that the tiles I'm drawing wont cover the screen area. Is that what you meant?


EDIT 2:
I think I managed to actually get the culling using the view right this time:
It's drawing the entire screen full of tiles and the maximum tiles it's drawing is about 520 per frame which is sounds about right.

Here is the code I'm currently using

    sf::FloatRect screenRect(sf::Vector2f(veiw.getCenter().x - (veiw.getSize().x)/2, veiw.getCenter().y - (veiw.getSize().y)/2) , veiw.getSize());
    std::cout << "View X = " << veiw.getCenter().x - veiw.getSize().x << "  " << "View Y = " << veiw.getCenter().y - veiw.getSize().y << std::endl;

    window.clear(sf::Color::Black);
    int tilesDrawn = 0;
    for(int y = 0; y < MAP_HEIGTH; y++)
    {
      for(int x = 0; x < MAP_WIDTH; x++)
      {
        sprite.setPosition(x * TILE_WIDTH, y * TILE_HEIGTH);
        sf::FloatRect collider(sprite.getGlobalBounds().left, sprite.getGlobalBounds().top, TILE_WIDTH, TILE_HEIGTH);

        if(screenRect.intersects(collider))
        {
          window.draw(sprite);
          tilesDrawn++;
        }
      }
    }
    std::cout << "Tiles Drawn: " << tilesDrawn << std::endl;
 

I'm eagerly waiting for your reply Laurent I really hope I got it right this time.

40

Graphics / Re: [SFML 2.0 RC] Tiles render slow?

« on: May 15, 2012, 11:08:46 pm »

First mistake: you must use getGlobalBounds(). getLocalBounds() doesn't take the transformations (position, rotation, scale, ...) in account and thus will be the same for all your sprites.

Second mistake: the view's viewport is not what you want. Use its center and size instead.

I did update it to this:

    window.setView(veiw);

    sf::FloatRect rect(veiw.getCenter(), veiw.getSize());

    window.clear(sf::Color::Black);

    /* Culling code */
    for(int y = 0; y < MAP_HEIGTH; y++)
    {
      for(int x = 0; x < MAP_WIDTH; x++)
      {
        /* Assign the sprite a position */
        sprite.setPosition( x * TILE_WIDTH, y * TILE_HEIGTH);

        /* Check if the tile is inside the Viewport */
        if(rect.intersects(sprite.getGlobalBounds()))
        {
          /* If it's true then draw the sprite */
          window.draw(sprite);    
        }

      }
    }
 

But it renders the tiles from the center and down to the right ( It only draws tiles on 1/4 of the actual window ). How do I get it to align correctly and draw the entire screen full of the tiles.

But if your world is a matrix of tiles, you can do without any collision check: just compute the index of the first and last tile that fits in the view in both X and Y, and iterate only between these indices.

Something like:

Code: [Select]

int startX = (view.getCenter().x - (NUMBER_OF_TILES_TO_BUFFER * TILE_WIDTH) )/TILE_WIDTH;
int endX = (view.getCenter().x + (NUMBER_OF_TILES_TO_BUFFER * TILE_WIDTH) )/TILE_WIDTH;

int startY = (view.getCenter().y - (NUMBER_OF_TILES_TO_BUFFER * TILE_HEIGTH) )/TILE_HEIGHT;
int endY = (view.getCenter().y + (NUMBER_OF_TILES_TO_BUFFER * TILE_HEIGTH) )/TILE_HEIGHT;

if(startY < 0)
 startY = 0;
if(startY > MAP_HEIGHT)
 startY = MAP_HEIGHT;

/* Same with the X values so that we don't access values outside our array. */


for(int y = startY; y < endY; y++)
{
  for(int x = startX; x < endX; x++)
  {
     sprite.setPosition(x * TILE_WIDTH, y * TILE_HEIGTH);
     window.draw(sprite);
  }
}

I'm sorry if I'm asking these obvious questions but truth is I'm still struggling with these basic stuff when it comes down to graphics. I'm actually stunned on how easy people understand this ( When googling around most people had NO problems understanding what needed to be done in order to achieve the desired result.). Which makes me feel slightly bad since I'm 21 and I still don't get ( having a hard time visualize inside my head how it works ) basics like this...

41

Graphics / Re: [SFML 2.0 RC] Tiles render slow?

« on: May 15, 2012, 10:26:52 pm »

I'v been trying to implement "Frustum Culling" into the program though with limited success.
I'v understand the concept of this basic culling as doing a collision check on every object in the "map" and then if the tile collides with the the "camera" rectangle it's inside the screen and should be drawn.

I'v been trying to get something working with SFML's sf::View but I'm not sure how it's supposed to be done.
This is my code so far:

#include <SFML/Graphics.hpp>
#include <iostream>

/* Dimensions of the Map */
const int MAP_WIDTH = 255;
const int MAP_HEIGTH = 255;

const int TILE_WIDTH = 32;
const int TILE_HEIGTH = 32;

int main()
{

  sf::RenderWindow window(sf::VideoMode( 800, 600, 32), "Tile Engine");

  /* To make sure they are disabled
  EDIT: Doing this seems to gain 3 - 5 FPS
  */
  window.setFramerateLimit(0);
  window.setVerticalSyncEnabled(false);

  sf::Event evnt;

  sf::Texture texture;
  texture.loadFromFile("tile.png");

  sf::Sprite sprite(texture);


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

    sf::View veiw = window.getView();


    if(sf::Keyboard::isKeyPressed(sf::Keyboard::Right))
    {
      veiw.move(1.0f, 0);
    }
    if(sf::Keyboard::isKeyPressed(sf::Keyboard::Left))
    {
      veiw.move(-1.0f, 0);
    }
    if(sf::Keyboard::isKeyPressed(sf::Keyboard::Up))
    {
      veiw.move(0, -1.0f);
    }
    if(sf::Keyboard::isKeyPressed(sf::Keyboard::Down))
    {
      veiw.move(0, 1.0f);
    }

    /* Set the new veiew */
    window.setView(veiw);


    window.clear(sf::Color::Black);

    /* Culling code */
    for(int y = 0; y < MAP_HEIGTH; y++)
    {
      for(int x = 0; x < MAP_WIDTH; x++)
      {
        /* Assign the sprite a position */
        sprite.setPosition( x * TILE_WIDTH, y * TILE_HEIGTH);

        /* Check if the tile is inside the Viewport */
        if(veiw.getViewport().intersects(sprite.getLocalBounds())) // This is not right, don't know really how it's supposed to be
        {
          /* If it's true then draw the sprite */
          window.draw(sprite);        
        }

      }
    }

    window.display();

  }
  return EXIT_SUCCESS;
}
 

42

Graphics / Re: [SFML 2.0 RC] Tiles render slow?

« on: May 15, 2012, 05:08:54 pm »

How many FPS do you get if:
- you never change the position of the sprite
- you run it in Release mode
?

Debug with commented sprite.setPosition: Same ( 15 )
Release with commented sprite.setPosition: 445~
Release: 420~

Oh, WOW that debug mode REALLY drags the "game" down!

43

Graphics / [SFML 2.0 RC] Tiles render slow?

« on: May 15, 2012, 04:52:39 pm »

Hello all!
This time I started prototyping on a tile engine.
I'v noticed that it's very slow ( rendering 55 x 55 tiles ) drags my computer down to around 15 FPS ( In debug I know... ) but it still seems awfully slow even for debug?

I'm not sure If I'm doing something wrong or if it's just my computer acting up, here is the code I'm currently using:

#include <SFML/Graphics.hpp>
#include <iostream>

/* Dimensions of the Map */
const int MAP_WIDTH = 55;
const int MAP_HEIGTH = 55;

const int TILE_WIDTH = 32;
const int TILE_HEIGTH = 32;

int main()
{

  sf::RenderWindow window(sf::VideoMode( 800, 600, 32), "Tile Engine");

  /* To make sure they are disabled
     EDIT: Doing this seems to gain 3 - 5 FPS
  */
  window.setFramerateLimit(0);
  window.setVerticalSyncEnabled(false);

  sf::Event evnt;

  sf::Texture texture;
  texture.loadFromFile("tile.png");

  sf::Sprite sprite(texture);

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

    window.clear(sf::Color::Black);

    /* Render the Tiles */
    for(int y = 0; y < MAP_HEIGTH; y++)
    {
      for(int x = 0;  x < MAP_WIDTH; x++)
      {
        sprite.setPosition(x * TILE_WIDTH, y * TILE_HEIGTH);
        window.draw(sprite);
      }
    }
   
    window.display();
  }


  return EXIT_SUCCESS;
}

44

Graphics / Re: [SFML 2.0 RC] Correct way of using sf::Texture pointer? Does it deallocate?

« on: April 25, 2012, 08:42:48 pm »

Yeah, I know it can be very frustrating

But there's no universal answer. Each project, probably even each module or class will need its own specific solution to correctly load and manage resources.

The best answer is then probably: experiment, try by yourself, and when you realize that managers are not the best answer to all problems then you'll find the better solution that fits your specific design. For now, if you like the simplicity of global managers, just use them.

My point was more to avoid throwing "manager" in every post where there's a scope/lifetime problem. Since it doesn't solve the problem but rather avoids it with something that is not always relevant. Learning how to properly handle objects lifetime is crucial for well-designed and robust programs.

Although I have a hard time seeing it now how I would realize it is not suited for all applications I guess it will come to me in time.

I'm already quite found of "Interfaces" which allows me to pass ( pointer/reference to ) a local instantiated Resource Manager which also limits the access to it ( And THAT I like! Because I'm not found of passing entire objects when the object that is going to use it only needs one function and the rest is quite "no-no" for the object to use. ).

That way if Resource Manager implements IRequestTexture ( Which haves the pure virtual "getTexture(name)" ) then I can with calm in my body pass it to my Game objects that needs to get their textures at creation because they will ( and can only ) access the getTexture() function.

I'm guessing I'm on the right track?

45

Graphics / Re: [SFML 2.0 RC] Correct way of using sf::Texture pointer? Does it deallocate?

« on: April 25, 2012, 08:13:35 pm »

If all my drawables components were carrying their own texture, there will be twice the same texture in memory or more.

If your design requires multiple unrelated classes to potentially share the same resource, then you're exactly in the scope of the resource manager so I have nothing to say against this

My Engish is not the greatest but what exactly are classed as unrelated classes? If I have a lot of different characters in my game say for example "Enemies" and usually a lot of instances shares the same resources are they defined as unrelated or related classes?


I like resource managers ( static/singleton/namespace ) because It gathers ALL of my loading code into one metod which makes it easy to add/delete and re-use the code into another project. Now I'v heard from multiple ways that they are bad( Usually just like this one vauge example of why it's bad. "It just is." ).

Most of the tutorials you come across teaches us using the "managers" since it simplifies a lot. How are we supposed to load/unload and manage our resources in an easy way otherwise?

A lot of the more experienced programmers ( Including most of you that replied in this topic ) tells us that it's bad but you don't provide a good explanation or "tutorial" on how to actually implement or how the "better"/"correct" way actually looks like.

Their are like zero tutorials that show us "beginners" of how to manage game resources, object creation without managers in a good and accepted way.

I'm not trying to be rude, just find it frustrating