Messages

1

Graphics / Re: Image too large?

« on: September 10, 2013, 09:42:52 pm »

Yeah, trivial getters and setters tend to eat up a lot of space.  In theory you should only need to add those methods when getting or setting has some additional step (eg, checking the value is valid), and you can't simply make the members public or let the constructor handle it.  But in the real world it's best to add them early on so that all the code using this class won't need to be rewritten when you inevitably change how the class works internally.

With that said, it may be better to combine x and y into a single sf::Vector2i or std::pair<int,int>.

This was just kind of a retrofit for the rest of the program.  Just to see how it would work.  I can start to see some possibilities tho.

Stupid Q #2:
Is it common for class methods to use other class methods or even plain old functions throughout the program.  Or are they generally self contained?

2

Graphics / Re: Image too large?

« on: September 10, 2013, 07:02:30 pm »

After all this talk about oop and classes.  I created one.  As well as shooting, my player can throw bombs.
I used to have:

struct bomb1{
    int x;
    int y;
    bool available;
} bomb[99];
 

And now I have:

class BombClass{
    public:
        void setX(int X){
            x = X;
        }
        void setY(int Y){
            y = Y;
        }
        int getX(){
            return x;
        }
        int getY(){
            return y;
        }
        void setAvailable(bool a){
            available = a;
        }
        bool getAvailable(){
            return available;
        }

    private:
        int x;
        int y;
        bool available;
};
BombClass bomb[99];
 

And it all works.   
It seems like a lot of lines of code for what it does, but I had to start small and start somewhere.
Thanks for all the motivation and inspiration.

3

Graphics / Re: Image too large?

« on: September 10, 2013, 03:28:22 pm »

Thanks.  I briefly touched on vector containers before for that very reason.  I will look into it more though.

The project I'm working on was actually supposed to be a learning tool, but it's turned into something I kind of like.  I'm a pixel artist as well and spend about half my time pixeling for this when I should be learning classes, etc.  I'm kind of a scatter brain, but I've accepted that.   

4

Graphics / Re: Image too large?

« on: September 10, 2013, 02:22:22 am »

Yes it's normal to have hundreds of sprites.  The sprite class itself is very lightweight, since it essentially just stores some information like position and rotation to be used when drawing the underlying texture.  The texture is the expensive part.

For a fixed animation like a 14 frame explosion, I believe the right way to do it is put all 14 frames in one texture, and change the sprite's textureRect every frame (using setTextureRect()).  I don't think there's much point in multiple sprites, not for performance reasons, but because it's more intuitive and logical to have one sprite changing each frame than 14 sprites you cycle through.

Of course it may be even better to put all your zombie related images in a single big texture and have for example one row with frames for the walking animation, one row for the idle animation, one row for each of your explosion animations, and so on.  In the long run you'd probably abstract all this into a Zombie class with methods like startExploding(), so that only the Zombie class itself has to worry about exactly what textureRect to use every frame.

Thank you for this explanation.   This clears some things up for me.

I should really start experimenting with classes.  I understand how they are assembled, but it's the real world application part I don't quite get yet.   Right now I use this:

struct undead{
    bool alive;
    int state;
    int x;
    int y;
    int direction;
    int animation;
    int zombienumber;
    int instruction_set;
    int counter;
    int old_count;
    int explosion;
} zombie[400];
 

Which could be part of a class public part.
And when did they start calling functions, methods?   I thought that was a java thing.   

5

Graphics / Re: Image too large?

« on: September 09, 2013, 10:57:29 pm »

I'm aware of the complexities of c++.  This is why I held off learning it for so long.
What I liked right of the bat was how it kind of forces me to write cleaner code.  I wasn't expecting that.  If that makes any sense.
But, I do find myself chasing my tail when adding features to my programs, which I believe is some of what you were getting at.

Stupid Q #1:
Back to the sprite thing.  Is it normal to have 100's of sprites in a graphically intensive game? (All with their x, y, h, w sources set of course)
I'm writing a platformer zombie shooter/adventure thing.  I have 3 different zombie explosions of 14 frames each.  Would that be 42 sprites?  Plus all the other 100+ frames of other stuff.

6

Graphics / Re: Image too large?

« on: September 09, 2013, 09:56:41 pm »

To be clear: Performance is not the crucial factor for one or the other way. It will really take a lot until you reach the limits, and once you do so, the bottleneck will be somewhere else.

Much more important is clean code, as it will shrink the development, maintenance and debugging time dramatically. If you're used to old habits, you should probably read a current C++ book, maybe even one that deals with C++11. It's of great advantage to know the programming language well, as it will save you a lot of time and pain.

So please don't favor ancient techniques because you think they are faster (such assumptions are usually wrong), instead focus on writing code that will be easy to maintain and extend. Typically, optimizations are then also simpler to achieve.

To be honest, I've just started learning c++ about 6 months ago.  I've always wanted to, but thought the learning curve was too steep for me.  My programming experience goes back 20+ years though, with languages such as vb, pascal, etc.  And then to my surprise, c++ wasn't that hard after all.  And paired with a graphics library, I was able to do pretty much anything I wanted.  Plus the internet is a world of information I never had years ago.
I know my code isn't  modern by todays standards, but I still have fun making my little games.
And because oop is a new concept to me and I'm not one to ask a lot of questions, I tough it out in other ways.   Old dog new tricks syndrome.   
I do need to understand more concepts of oop, but I'd be asking 50 stupid questions on here before I finally get it...lol

7

Graphics / Re: Image too large?

« on: September 09, 2013, 07:36:32 pm »

But why don't you store different sprites in the first place, instead of recycling sprites and adjusting their texture rects again and again? I hope it's not for performance reasons...

That would be a lot of sprites.  I didn't think it would be done that way. 
How big of a performance hit am I taking adjusting the texture rect every time?

using the object-oriented approach 

Yeah, I'm a bit old school with bad habits.  I'm using no Classes, only structs...lol

You have magic numbers across your whole application.

Yes I do.  LOL

I'll try and wrap my head around that tutorial

8

Graphics / Re: Image too large?

« on: September 09, 2013, 07:00:48 pm »

I'm always using the same texture with the same sprite.  Just the x, y source is changing to get the right frame.

And yes.  I ported my game from SDL to SFML.  Except for the audio, which crashes on exit.  (Already have a post on here about that)

This Blit function works surprisingly well, which is mostly used on animations...which is why my .png files are large...I try to keep all the frames on the same X position, so the png width gets long.

Is there some sort of performance problem with the way I'm doing this?  My goal was to put something on the screen with one line of code.

9

Graphics / Re: Image too large?

« on: September 09, 2013, 04:51:49 pm »

I guess I'm confused about "switching between different textures".   I don't know if I'm doing that...lol

Every .png file I have is loaded into a texture and then assigned to a sf::Sprite.  Then I just blit parts of the sprite I need.
I just want things running effeciently as possible.
This is what I'm doing:

    sf::Texture interfacetexture;
    sf::Sprite interface;

void init()
{
    interfacetexture.loadFromFile("interface.png");
    interface.setTexture(interfacetexture);
}

void Blit(int x, int y, int srcX, int srcY, int srcW, int srcH, sf::Sprite sprt)
{
    sprt.setPosition(x, y);
    sprt.setTextureRect(sf::IntRect(srcX, srcY, srcW, srcH));
    window.draw(sprt);
}

 

10

Graphics / Image too large?

« on: September 09, 2013, 04:12:36 pm »

Hi all,

I was getting a "white sprite" problem.  It shows up fine on one computer and as a white box on another. 
And I thought it was the sf::Sprite, sf::Texture scope, after reading around.    I narrowed it down that the image was too big for the vid card.  The width was 2089 and I cut it back to 2048 and everything was fine.

Anyway, I have a lot of graphics in this game and there will be more.  I've read in the tutorials that it's best to have as few textures as possible, but I did not understand why from the reasoning.  Could someone explain in more simple terms.   Thanks.

11

General / Re: FPS Help

« on: August 31, 2013, 03:10:07 am »

No will don't keep same aspect ratio.

That's what I was afraid of.  I don't need a full screen, although it would be nice.  Just a bigger screen. 
I did my pixels in Graphics Gale and then resampled them to 200%.  The screen size on the game I'm working on is 800x450 which is 16:9 ratio, so doubled to 1600x900, they look perfect.  Almost any 16:9 ratio setting should look ok depending on the interpolation...some monitors can do it better than others I've found.  The monitor I have has a native resolution of 1920x1080, 16:9 which also looks good, but not as crisp as 1600x900.

@zsbzsb - That's a great article.  Thanks. 
I was thinking about something like those ideas as opposed to my hard coded Walk_Right() animation function below.  I've been programming for 20+ years and developed some bad habits.  "Old dog, new tricks syndrome" 

12

Audio / Re: Audio crashes of exit

« on: August 31, 2013, 02:23:07 am »

For the time being I'm using SDL_mixer.  It seems to work fine with SFML.

Would there be some kind of shut down code I could use to clear the memory or something with SMFL Audio to avoid the crash on shutdown?

13

Audio / Re: Audio crashes of exit

« on: August 30, 2013, 04:04:27 pm »

It took a while to figure out, but I got it compiled, but still the crash exists.

On the compile I noticed that theres no new:
libsndfile-1.dll
or
openal32.dll

Does that make a difference?

EDIT:

I found the libsndfile-1.dll and openal32.dll and copied the to my project.  Still Crashes.   

FMOD?  lol

Just for reference my audio code is this:

sf::SoundBuffer buf1;
sf::Sound sound;
buf1.loadFromFile("explode1.wav");
 

Then call it like this:

if ((bullet[j].x >= zombie[i].x-WorldPosX) && (bullet[j].x <= zombie[i].x+40-WorldPosX) && (bullet[j].y >= zombie[i].y + 5) && (bullet[j].y <= zombie[i].y + 60))
                            {
                                bullet[j].flag = false; //turn off for mega bullet
                                zombie[i].state = 1;
                                zombie[i].alive = false;
                                player.score = player.score + 10;
                                //Mix_PlayChannel( 1, sound1, 0 );
                                sound.setBuffer(buf1);
                                sound.play();
                            }
 

14

Audio / Audio crashes of exit

« on: August 30, 2013, 07:06:04 am »

I've been reading about some issues with Windows XP and sf::Sound, etc.  I don't really understand what's going on...if it's an issue that I have?  Or if the issue was fixed?

My program crashes on exit with a:

The instruction at "0x100453cc" referenced memory ar "0x030cb490". The memory could not be "read".

All I have to put in is this one line to make it crash on exit...

sf::SoundBuffer buf1;

Other than that, the audio works fine.

15

General / Re: FPS Help

« on: August 30, 2013, 12:39:37 am »

First, thanks for the replys.

@ slotdev - Yes, I have tried window.setFramerateLimit.  It seems to work fairly well, but I've noticed some inconsistencies at higher frame rates.  For an example, if I set the fps @ 150 at a screen resolution of 800x450 and then change the resolution to say 1600x900 and then back to 800x450, the fps changes to ~130 fps.  The code I have here doesn't do that.  So I didn't know how accurate window.setFramerateLimit was.

@ AlexxanderX - Does sf::VideoMode::getFullscreenModes() keep the aspect ratio if initially set to a non-full screen mode?  Another words...a black border around what it can't fill.   
One of the reasons I'm messing around with SFML is the way the textures and sprites stretch with the screen.  I think SDL 2.0 does this, but I wanted to see what SFML can do.  I'm a pixel artist, so I don't want my pixels stretching the wrong way.   

My code here is just for testing/learning purposes.