Messages

31

General / Screen coordinate and world coordinate troubles

« on: April 23, 2013, 06:08:39 am »

Hey all, I'm having problems converting between screen and world coordinates when zooming my views. Everything has been going smoothly up until I added zooming. As long as I don't zoom in or out, I can rotate and move the camera and still have proper world/screen coordinate conversions. Also, it seems when I zoom, it scales things about the top left of the screen rather than the center even though I set the center of the view to the center of the screen.

My questions are these: How do I zoom relative to the center of the screen instead of the top left corner? And how do I properly convert screen coordinates to world coordinates and vice versa when scaling is involved?

Edit: Actually, it seems like the zooming is about the lower right hand corner o.0 and it doesn't change no matter what I set the center of the view to.

View code:

mView.setCenter(mRenderWindow->getSize().x/2, mRenderWindow->getSize().y/2);
mView.setRotation(-mCameraRotation);
mView.zoom(mCameraZoom);
mRenderWindow->setView(mView);
 

Coordinate conversion code:

sf::Vector2f RenderingManager::screenToWorld(sf::Vector2f screenPos)
{
    screenPos -= getCameraScreenOffset();
    screenPos *= mCameraZoom;
    screenPos += getCameraScreenOffset();

    sf::Vector2f worldPos = screenPos-getCameraScreenOffset();
    worldPos.x = worldPos.x/mPTU;
    worldPos.y = -worldPos.y/mPTU;
    worldPos.rotateBy(getCameraRotation(), getCameraPosition());

    return worldPos;
}

sf::Vector2f RenderingManager::worldToScreen(sf::Vector2f worldPos)
{
    sf::Vector2f screenPos = worldPos;

    screenPos -= getGame()->getRenderingManager()->getCameraPosition();
    screenPos /= mCameraZoom;
    screenPos += getGame()->getRenderingManager()->getCameraPosition();

    screenPos.rotateBy(-getCameraRotation(), getCameraPosition());
    screenPos.x *= mPTU;
    screenPos.y *= -mPTU;
    screenPos += getCameraScreenOffset();

    return screenPos;
}
 

Thanks for your time.

32

SFML projects / Re: Fission - A simple, object-component based game engine

« on: April 22, 2013, 11:20:39 pm »

Hahaha - spiritual coding. Yeah, code refactoring is not my favorite chore :/

33

SFML projects / Re: Lua SFGUI Loader

« on: April 21, 2013, 10:36:41 pm »

Looks cool! I'm definitely going to give this a try. Looks soooooooo much less tedious than hardcoding my GUI together.

34

SFML projects / Re: Fission - A simple, object-component based game engine

« on: April 21, 2013, 10:34:16 pm »

Alright, I will give this some more thought. The immediate idea that pops into my mind is a template class called InstanceRef where the template parameter is the instance's class type. It'll be essentially the same as the GameRef class only an abstracted template for any kind of instance. Then I can typedef different Manager references in their headers. Then, I can derive classes that need access to a manager from the corresponding manager reference class.

I started out trying to have modules have no dependency on each other, but as I stopped focusing on the engine and more on the games I started getting sloppy and just adding quickfixes to make games work quickly haha.

35

SFML projects / Re: Fission - A simple, object-component based game engine

« on: April 20, 2013, 11:50:50 pm »

The question here is: Why? What does Game do that everything needs to know of? And should it do that? Is that the kind of thing that belongs in Game? Or is it something that is not the responsibility of Game?

Game holds all of the managers - RenderingManager, PhysicsManager, etc. If there are no singletons, every single class that needs to reference any manager needs a reference to its corresponding Game. I just finished implementing it - now off to finish Nexus' other suggestions. Right now, all classes that need to reference Game (primarily to take advantage of the Game as the middleman to get to the managers) inherit from GameRef, which takes a Game* as a parameter to the constructor, has a private Game* member, and has a corresponding accessor.

36

SFML projects / Re: Fission - A simple, object-component based game engine

« on: April 20, 2013, 10:27:46 pm »

Well, if neither the managers nor the Game class are singletons, pretty much every single class will need a reference to the Game. I suppose at that point I'd just create a base class called GameRef or something. Does that sound good? I apologize for the C++ lessons in the project announcements. Haha. Then I'd access the managers this way:

mGame->getSomeManager()->doMyStuff()

37

General / Re: Should Sprite Alpha affect collision detection?

« on: April 19, 2013, 08:35:22 pm »

What are you setting as your AlphaLimit parameter? By glancing at that Collision code from the link you provided , it looks like only alpha values above that alpha limit will trigger a collision. So, if you want anything even remotely visible to collide, your AlphaLimit should be 1

38

SFML projects / Re: Fission - A simple, object-component based game engine

« on: April 19, 2013, 08:29:26 pm »

Nexus, thanks for the detailed feedback! You sound like a pretty picky coder I will definitely do that stuff this weekend. Here I was feeling like the hot-shot freshman who codes circles around all the seniors, but I guess I have a long way to go

By not making all the managers to singletons, you allow other uses. I don't see why they need to be a singleton, the alleged convenience has many disadvantages, which are not necessary with a clean design.

I've definitely been going back an forth with the singleton design for the Managers - the problem became more evident when I started coding a scene editor. Could the Game class be a singleton to access all of the managers?

I am in favor of this idea. If you want other people to use your code (and it's awesome that you do!) then you have to work hard at making it clear how it works.

I think there is a lot of cool stuff in Fission, and I'm still going through it to see how it works. Thanks again for sharing with us.

Yeah, I've been thinking about that. I need to go through and add comments for Doxygen, which I've never used before :0 And thanks! Means a lot

39

SFML projects / Re: Fission - A simple, object-component based game engine

« on: April 19, 2013, 09:12:57 am »

I glanced at it and will probably implement the smart pointers soon, but it's not an urgent issue as it's not a professional game engine If it turns out that a ridiculous amount of people want to use it maybe I will take my memory management more seriously haha.

Thanks for the suggestions though, I will definitely get around to implementing it, as I do plan on releasing my current project on Desura, and hopefully it'll be good enough where I can sell it for at least a buck

40

Graphics / Re: One does not simply scale an object

« on: April 19, 2013, 08:15:30 am »

Yes, sf::View will affect the entire screen, but you can apply a view, render all of your game sprites, then reset to the default view and render your health bars, interface, and whatnot.

41

General / Re: Should Sprite Alpha affect collision detection?

« on: April 19, 2013, 08:10:13 am »

Which collision detection are you using? Circle? Bounding box? Pixel perfect?

42

SFML projects / Re: Fission - A simple, object-component based game engine

« on: April 19, 2013, 07:50:21 am »

States are deleted when they are popped from the state stack. So, you could have a main menu state, then push a game state. Then when the game state is popped, it will be deleted and you will return to the main menu. You were right though, there was a scenario in which the state wouldn't be deleted, but I just uploaded the fix

43

SFML projects / Re: Fission - A simple, object-component based game engine

« on: April 18, 2013, 07:09:14 pm »

Nice, that project actually looks like you are working on it for quite a long time. I'm not a fan of the graphics style, but that's just eyecandy.

Well, this is actually a rewrite, so up to this point I've known exactly where to go next. Last semester, I worked on this game for like 2 months and ended up giving after I couldn't resolve the lag issues. But now all is well! Also, having Fission always helps - last semester the game had it's own game engine. I did have Fission last semester, but I felt like the game deserved its own game engine. It doesn't. Haha.

You can take the art up with my roommate

Oh btw, are you accepting shirts?

Ehh. It's hot here in Hawaii.

Bah... this means I still have a reason to work on SFGUI -_-

jk Nice job, it's always a good feeling to see the library put to good use

Haha, thanks! I am putting it to very good use. I hate GUI programming so, so much. But SFGUI is like my ibuprofen

44

General discussions / Re: Z ordering

« on: April 18, 2013, 11:52:25 am »

Although, I suppose I could just call the render function for whatever external library wherever I want, so maybe it isn't such an issue.

If particles stay in one specific layer, then it's not a problem. But just imagine smoke particles that go up in a top-down game. They might start below other objects, but after some time occlude them due to moving up.

Or the problem I currently face: You look along the z axis and simulate sprite depth by scaling them. Sprites need to be ordered so they occlude what's behind them, and the same applies to particles: If an object explodes at z=10, the explosion effect particles have to occlude stuff with z<10 and be occluded by objects with z>10.

It's impossible to do except you implement your own particle system that does z ordering. Considering that Thor already provides a nice particle system, I find it an unacceptable solution (rather a workaround for something that should probably be supported out of the box, because the underlying graphics backend supports it).

Touché.

45

General discussions / Re: What physics engine to use?

« on: April 18, 2013, 11:50:30 am »

Box2D seems to be the most popular choice.

Box2D is the way to go

Box2D! It's great. Jump on the bandwagon.