Messages

1

Graphics / Best way to "SCROLL" an overworld map?

« on: December 04, 2008, 09:58:19 am »

Take a look at the following XML file:

world.xml

Code: [Select]

<map tileset="world.png">
    <row>
        <tile>0</tile>
        <tile>0</tile>
    </row>
    <row>
        <tile>0</tile>
        <tile>1</tile>
    </row>
</map>

The TinyXML library helps me easily take this XML file and turn it into a fully usable instance inside my application.

Hah, I never thought of using XML like that. That's quite nice.

2

General / Error when trying to display background and image

« on: November 26, 2008, 04:20:29 am »

Code: [Select]

     //check for left key
      if(App.GetInput().IsKeyDown(sf::Key::Left));
      {
         float newX = plSprite.GetPosition().x - (deltaTime * PLAYER_SPEED);
         //Keep the image on the screen
         if(newX -(.5*plImage.GetWidth()) < 0)
         {
            newX = .5 *plImage.GetWidth();
         }
         plSprite.SetPosition(newX, plSprite.GetPosition().y());
      }
      if(App.GetInput().IsKeyDown(sf::Key::Right));
      {
         float newX = plSprite.GetPosition().x + (deltaTime * PLAYER_SPEED);
         if(newX < App.GetWidth())
         {
            newX = App.GetWidth();
         }
         plSprite.SetPosition(newX, plSprite.GetPosition().y());
      }

I believe your problem is within here. You're referencing a method of sf::Vector2 called y(), but nothing of the sort exists. It shouldn't have compiled.

Change "plSprite.GetPosition().y()" to simply "plSprite.GetPosition().y" like you have with the .x ones.

3

General / Separation of logics and graphics

« on: November 22, 2008, 09:26:10 am »

I've had a few adventures in program design because of this very topic while working on my game. I decided that I would make the engine as if I was only making the engine and then passing it off to another programmer (who also happened to be me) to use it to make a game. Naturally, I built it with a separation between logic and graphics since the second programmer should never have to interface with SFML, and the design of the whole thing relies on the extendability of certain objects.

I decided that an easy way to render things was to create a sprite for each entity each frame, and I found that the approach could create performance problems if you're using a very lot of them. It's about the easiest thing you could set up while keeping a separation between graphics and logic, but it's not the best way of doing it.

I've got an Athlon X2 5200+, and I could have around 2,400 of them being created and destroyed at 60 frames a second while using only a little over half of my CPU power. If you don't have a lot of entities, then, although it's not the most efficient method, it won't create any problems.

The part I didn't like about it, though, was how it made me put a lot of data into my entities, which also made the constructors take around 11 arguments, which can be a bit of a pain to work with.



That didn't fit my desires entirely, though, as it limited me to one sprite per entity, and, as mentioned before, it's not really efficient. What I'm doing now is creating a structure that allows me to control and render a group of sprites as a single entity and allow it to be referenced by a unique name. Load it once before it's used, then just put it in a tree of sorts and search out your desired sprite sets each time an entity is created, returning a pointer to be kept inside the entity it's being associated with.

Searching a tree for an object containing sprites once when an item is created rather than creating a sprite every time an item is rendered is definitely more efficient, and the use of pointers to reference the stored sprites lets you cut down on memory use. It also allows you to reduce the amount of graphical information your entities need to contain, which also makes their constructors simpler.

This is the best solution I have come up with for this problem.

4

Graphics / just draw a image, not a sprite

« on: November 18, 2008, 04:37:30 am »

You could just create a function that takes an image and an x and y location and then, inside the function, create a sprite and render it in the correct location. If you keep everything else at the default, it won't change the image any.

Although it does save memory, this is more redundant and runs slower than doing it how it's supposed to be done.

The idea is to make it easiest for the programmer in this case. Take 2 minutes and make a function that makes sprites for you so you can pretend you're drawing images directly to the screen. Unless you're making hundreds of thousands of these things, performance won't be a problem.

5

Graphics / just draw a image, not a sprite

« on: November 17, 2008, 11:21:36 pm »

To my knowledge, you cannot draw images directly to the screen. You must have a sprite that is tied to an image in order to render it.

Not to worry, though, sprites are very lightweight. They don't use up a lot of memory, and you can create, modify and destroy thousands of them each second without a large impact on performance.

It might just seem like another hurdle you have to jump through in your case, but the system makes a lot of sense when you have to deal with thousands of them each being transformed in different ways.


You could just create a function that takes an image and an x and y location and then, inside the function, create a sprite and render it in the correct location. If you keep everything else at the default, it won't change the image any.

6

General / Best Way to Handle Instances

« on: November 14, 2008, 07:33:48 pm »

I'm making a shmup, and for this, I'm using a list of pointers to a base class with a virtual handle function.

A list isn't the fastest thing to iterate through, but I'll be adding and deleting random items from the list constantly. Lists handle random object deletion better than vectors do, and that is why I chose to use a list.

7

General / drawable class

« on: October 05, 2008, 09:42:35 am »

Also, try looking up the term "encapsulation". It's a very important principle of object-oriented design.

Basically:

Make it so that your objects can only be used in exactly the way you want them to be used.
Make the implementation of the object irrelevant to its usage.



This is mainly in response to the fact that you made everything public. It's actually very bad form to do so and can cause difficulties working with the class.

8

Graphics / so many things i dont understand ...

« on: October 03, 2008, 12:10:09 am »

My preferred book for learning C++ is Walter Savitch's "Problem Solving in C++: The object of programming"

I got it as a textbook for a class and have since made my way through the whole book in my spare time. It starts with the very basics and makes its way into advanced object-oriented concepts. Pretty much everything I know about C++ I've learned from this book.

Whether you need help with using strings, creating linked lists or working with virtual functions, this book covers it. It is quite simply an excellent book. I keep it around and reference it often whenever I need to.

9

Graphics / does it makes sense to have a lot sprites of the same image?

« on: September 30, 2008, 09:59:49 pm »

Sprites are pretty small, and doing things with them is a light operation. You don't much have to worry about it.

The test run for my current project has about 1800 sprites all with the same image, just in different positions, rotations, colors, alpha, etc. moving about the screen, and I can maintain 60FPS easily. It uses, at most, 25% of my CPU (18 of those 25% are spent drawing, the creation of the sprites and all the other handling I'm doing takes up the remaining 7%).


Oh, and I'm also creating and destroying those 1800 sprites each frame. It may seem inefficient, but I wanted to keep any direct references to any of the SFML objects away from my simulation and kept squarely in the graphics bit.

10

General / some day u´ll hate me =)

« on: September 26, 2008, 08:56:44 pm »

Declare them once at the beginning and then just re-assign them once each frame.

11

General / some day u´ll hate me =)

« on: September 26, 2008, 08:02:52 pm »

Your bats don't move because you're only checking input once at the beginning of the program.

All of this:

Code: [Select]

   const Input& Input = App.GetInput();
    bool left_up = Input.IsKeyDown(Key::W);
    bool left_down = Input.IsKeyDown(Key::S);
    bool right_up = Input.IsKeyDown(Key::Up);
    bool right_down = Input.IsKeyDown(Key::Down);

Needs to be put in your main loop somewhere. Also, you have right_down twice in your bat movement part of the loop.

12

General / Help *lol*

« on: September 26, 2008, 06:40:41 am »

bat *x = new bat;
do i have do add something like

~bat(){ x = NULL);  ?

It'd simply be

Code: [Select]

delete x;

and yes, any anonymous variables you have floating around need to be specifically deleted in the destructor. If you don't, then they'll be doomed to sit in memory until the application ends since you'll no longer have any way to reference them.


Also be very sure that you don't try to use that pointer after it's been deleted. This can happen when you pass that location around a bit. You'll get a fun, fun null pointer exception and wonder where and why it is happening.

13

Graphics / sf::String Memory Leak?

« on: September 23, 2008, 04:43:30 pm »

Oh yes, it's definitely in the SetText method. Commenting out that one line in my program got rid of the memory leak.

14

Graphics / sf::String Memory Leak?

« on: September 22, 2008, 10:33:32 pm »

I haven't implemented shape drawing yet, but it does not happen when sprites are drawn.


Edit: I realize I should've said sf::Sprite up there instead of sf::Image. I'm getting all my layering messed up :s

15

Graphics / sf::String Memory Leak?

« on: September 22, 2008, 08:38:16 pm »

This being my first post here, I'd first like to say that I love SFML. I originally started my programming project (a fairly sophisticated shmup engine) in SDL and switched to SFML later. It took me weeks to get to a certain point with things in SDL, and it took me only a day to do it again in SFML. It makes things so much easier. I love it.


Anyways, my program has a memory leak, and I've traced it back to sf::String. It's tiny, very tiny. I'm creating amd destroying 60 of these a second in my test run (I really hope that process is as light as I think it is), and I accrue around 3 kilobytes per second.

I'm using the sf::String object in my own object that inherits from a base class, it contains no pointers whatsoever. It's mirrored by another object inheriting from that same class but uses sf::Sprite in place of sf::String, and that object creates no memory leaks despite being handled with the same code.


The only things I do to sf::String are:
SetSize
SetText
SetFont
SetColor
SetPosition
SetRotation

All done during the constructor of the containing object, then it gets rendered and promptly destroyed.


Can anyone else confirm the occurrence of a memory leak in this object? I can post my code if necessary.