Messages

31

General / should i use inline functions?

« on: February 28, 2012, 03:30:57 pm »

As a general rule, leave such decisions to the compiler until you have reason not to.

32

General / SFML Complete Game Tutorial

« on: February 27, 2012, 06:26:38 pm »

I just realized I made a small, but glaring omission wayyyyyyy back in part two!.  Although I talked about pre-compiled headers and the use of stdafx, I forgot to include them in my write up!  This means you wouldn't have them if you weren't using the downloadable project.


This doesn't really sound like a big deal, until you realize that this is where all of the SFML includes are!   This explains some of the questions and problems people had early on and why downloading the full project fixed things.


Ooops.   :oops:


So, I've addressed this mistake so people following along in the future won't have this problem.  If you've run through the tutorial and ran into this problem...  this is why.  Considering #includes are one of the more confusing topics for beginner C++ programmers, this was a majorly stupid mistake on my behalf.  My apologies.

33

General / SFML Complete Game Tutorial

« on: February 25, 2012, 12:54:33 am »

don't know whether it's a good idea to introduce bugs in chapters and fix them later. For some topics this can be meaningful because of the learning effect, but doing this too much gives the impression that your tutorial is incorrect. Maybe you had better fix them in the original code (given this doesn't complicate it as hell).

... yeah... intentional....  [[Wheres the whistle innocently gif???]]  Truth of the matter is, the way I did things, fixing a bug early on creates an absolute friggin nightmare for me, especially because I zip and share a compiled form of each chapters project, so if I change something in chapter 2, I need to propogate the change in chapters 2 thru 10, create and upload 9 8+ MB zips, then change all the source code examples where I expanded upon the code previously.

GetFrameTime() is a relict, it has been removed from SFML. You should use sf::Clock directly. By the way, even though this is out of scope for the tutorial, I have developped a StopWatch class which can be paused.

Tutorial is based on 1.6, where I though GetFrameTime was still the recommended way?  Trying to keep things the "out of the box" way as much as possible.  Got a link to your class, at the very least it would be useful to people reading this thread.

EDIT:  Nevermind, re the link, didnt see your sig while replying.

34

General / SFML Complete Game Tutorial

« on: February 22, 2012, 10:31:43 pm »

Yeah, many of the annoyances should be addressed in the next chapter, whenever that is.

The other thing I've noticed is that any time I try to make changes to the game class I end up with more errors than I'd like.

There should be no real issues in changing the game code, so next time this happens, post the error that occurs and the code you added/changed.



As to disappearing sprites, they aren't actually disappearing, they are moving... very very very far.  The game no longer updates when showing the Menu, but SFML does, and this is where the "bug" is coming from.  Essentially each frame we are getting the elapsed time since the last frame which we then use to normalize movement the next frame.  The code assumes this number is always going to be a tiny fraction of a second, but this isn't true if we do something between drawing frames ( like hitting a break point or showing the menu ).


Any easy crude work around is to discard any deltas over a certain threshold.

So, in GameObjectManager, locate:

Code: [Select]


void GameObjectManager::UpdateAll()
{
std::map<std::string,VisibleGameObject*>::const_iterator itr = _gameObjects.begin();
float timeDelta = Game::GetWindow().GetFrameTime();
...


Add the line:

Code: [Select]


if(timeDelta > 0.1f) timeDelta = 0.0f;


Which basically says if more than 1/10th a second occurred between updates, 0 out the timeDelta, which will effectively cause no movement this update.  If there is a way to "reset" GetFrameTime() or to pause it in general, that would be a cleaner solution.

That will fix the disappearing sprite issues.

35

General / SFML only for games?

« on: February 10, 2012, 04:16:35 pm »

Well, you can use SFML for non-gaming apps.


I think your bigger problem will be the fact its a 2D library, not 3D.

36

General / Collision detection(Pong game)

« on: February 10, 2012, 03:35:54 pm »

Just a suggestion, but if you used sf::Rect's instead of vectors, you could reduce your code down to like 2 lines.


if(ballRect.Intersects(paddle1Rect) return PADDLE1HIT;
if(ballRect.Intersects(paddle2Rect) return PADDLE2HIT;

37

General / SFML 2.0 And Eclipse

« on: February 10, 2012, 03:23:18 pm »

I know I am not really answering your question, but I have to ask...

WHAT ARE YOU THINKING!!!!?






Eclipse + CDT is freaking awful, one of the worst IDE combinations I have ever used.  I am not a huge Eclipse fan to start with and only really use it when forced ( Google tools, such as App Engine and Android all force Eclipse on you ) and for Java it is "OK", but for C++ it is freaking terrible.


I mean, even if you hate Microsoft or arent on Windows, you still have a ton of superior options.

Code Blocks
Qt Creator ( very very good, btw )
NetBeans ( pre 7.1, 7.1 blows )

To name 3 freely available cross platform alternatives.

38

General / SFML Complete Game Tutorial

« on: February 06, 2012, 07:54:42 pm »

Maybe other people can offer a better way

If anyhow possible, I'd probably use a myObj instead of myObj*. This is problematic for polymorphic objects, but one approach is to use smart pointers like std::unique_ptr or specialized containers like boost::ptr_map...

I second this.  Actually unique_ptr is one of the areas I am going to address in the next chapter, I intend to replace the currently naked pointer used in the caching system.  Additionally, depending on your level setup, but if the size is known in advance, a good ole fashion 2D array might be your best bet.  Has minimally less overhead than using a map and is slightly less complicated.  Of course, your sizes are fixed in this situation.

@StormWingDelta, what are the errors you are receiving if you use static.

39

General / SFML Complete Game Tutorial

« on: January 27, 2012, 03:36:05 pm »

Serapth, oh yeah... that was stupid confuse about coordinates...
But I lack at math knowledge at this point so I can't model an elegant collision response model... Maybe you can advice me what to read on this topic?

BTW: If you want to take a look at current state of my project https://github.com/Razzeeyy/Re-tank-dev
The code organization (mostly) "inspired" by your great tutorial )

Ill take a look through your code a bit later, I'm absolutely swamped right now.


But as for learning the required math, it's hard to be The Khan Academy ( http://www.khanacademy.org/ ).  They have video tutorials on EVERYTHING, and the few ive watched were extremely well done.  About 10x better than my OAC level math teachers, who I have a sneaking feeling didn't know shit.

40

General / SFML Complete Game Tutorial

« on: January 26, 2012, 11:56:35 pm »

Serapth, Hi again.
I came back with couple of questions about collision (actually about response to collisions...)

So as far as you know I'm making the tank game...
The collision between tank and bullet was easy to made.
But the collision between tanks more complicated.

My Collision model is something like this:
1)Test Collisions in pairs through all objects
2) if collision happend, then execute Collide method of objects and pass references to the collided objects, one to another
3) objects decide on their own what to do on collision

This model is enough for bullets, but for collision between tanks.. em.. Should I pass the coordinates of obstacle or... something else?

I tried to make a 'simple' tank collision (just forcing the forward movement to act as backward on collision so we make step out of collision..) but I don't think this is an elegant solution.

Hi Razzeeyy,

Your solution seems reasonable.  You could implement this as another base class or interface ( ICollidable ) and do exactly what you discussed as another per frame action ( like Draw and Update now ), or within Update in GameObjectManager.

If you are passing in a reference to the object that collided with another object, why would you need to pass coordinates? You would already have access to them via the reference.

41

General / SFML Complete Game Tutorial

« on: January 25, 2012, 04:47:00 pm »

@StormWingDelta, The bug isn't really all that dire, no worries, its a pretty simple fix, you can easily use this code as the basis for a future product.  It was actually something stupid that slipped in early and I just didn't review that code again.  ( It's the event loop ).

@Jove, I am going to actually do a post about porting to SFML, probably soon.  I won't do it for each chapter, but it should be clear enough to go from there.  What I will probably do is update the Part 2 solution, then part 9/10, so you can go with 2.0 from near the beginning or the end.  Updating all the middle ones though, just too much work.

42

General / SFML installing on Visual Studio 2010 Professional

« on: January 23, 2012, 04:31:04 pm »

Serapth, i mean how to install SFML 1.6 or 2.0 to Visual Studio 2010 Professional. All instructions that i have found were made with Express, where all menus were fully different. But i will test those instructions today...

Ah, Ic.  Those instructions were actually for Express, but as was said, they are pretty similar.  I have both installed right now, so if you get hung up on a specific thing missing, let me know.

43

General / SFML installing on Visual Studio 2010 Professional

« on: January 22, 2012, 11:18:18 pm »

I'm a bit confused exactly what you are looking for, but if you are looking for detailed installation instructions for Visual Studio 2010, start right here.  It should get you going.


If I misunderstood your request, please clarify.

44

General / SDL->SFML conversion; very strange performance issues

« on: January 19, 2012, 01:13:53 am »

I tried to replicate the problem and had some success.


I got it to go from >1000 + FPS, plugged in my 360 wireless receiver, nothing happened, turned on the gamepad and a few seconds later, FPS dropped to 20ish, but then it jumped right back up to 1000+ and I haven't been able to get the framerate to drop like that again.

If I can make it 100% replicable, I will try to bug hunt it, but this intermittent stuff... that's irritating.  Is there a way to make this 100% reproducable?


Right now I used:

Code: [Select]

int _tmain(int argc, _TCHAR* argv[])
{
sf::Window app = sf::Window(sf::VideoMode(800,600,32),"test");

sf::Event event;
for(;;)
{
        while (app.PollEvent(event))
        {
            if (event.Type == sf::Event::Closed)
                app.Close();

            if (event.Type == sf::Event::KeyPressed)
            {
                if (event.Key.Code == sf::Keyboard::Key::Escape)
                    app.Close();
            }        
}

sf::Uint32 elapsedTime = app.GetFrameTime();

if(elapsedTime == 0.0f) app.SetTitle("Lots");
else
{
std::ostringstream ost;
ost << 1000.f / elapsedTime;
app.SetTitle(ost.str());
}
app.Display();
}
}



That should be sufficient to cause the problem, right?

45

General / Multiple inheritance

« on: January 18, 2012, 06:33:56 pm »

If you insist on going the inheritence route, why not use sf::Shape instead?

Additionally, are you sure it isn't a HasA relationship in that CollisionShape HasA Shape, not IsA shape, meaning you can implement the relationship as a member, preferably a templated one, if the signatures are consistent enough.