Messages

1

Graphics / Re: Help with Tile collisions

« on: February 07, 2014, 02:32:46 am »

Why not just assign a particular state to tiles set by 2 and 3? I.e. If your character goes to move onto a pixel that part of the tile marked by the number 2 (let's say 2 denotes a wall tile), then movement in that particular direction will fail.

Or is this what you're stuck at? I apologize if I'm just rephrasing your question.

2

Graphics / Re: Does anyone use the built in sf move function?

« on: February 03, 2014, 03:16:07 pm »

My thoughts essentially boil down to "Why do what's already been done for me?" SFML's move() and setPosition() have done all I needed them to do, so I don't feel the need to implement my own movement behavior.

3

General discussions / Re: AW: How much memory take a simple sfml app

« on: February 02, 2014, 05:12:55 am »

And I bet everyone is look at thd task manager, without knowing that not everything you see there is fully allocated. The system usually assigns more memory to an application that what it actually needs, just in case it would request more and thus would get it alot quicker.
But if another application needs the memory, the system would free the unused memory.

int n;
int m = (n * n);
float *k = malloc(sizeof(float) * (m*m));

...It's a good way to crash programs. Malloc doesn't like uninitialized variables.

4

General discussions / Re: Sfml Question

« on: February 02, 2014, 05:05:05 am »

Well for starters using some punctuation instead of one huge run on sentence will greatly improve the results you get around the internet while searching for C++ related stuff and for anyone bashing C++ they better realize that almost everything has a basis in C/C++ somewhere and that without C/C++ there would be no operating systems and you may also want to join us on SFML IRC (irc.boxbox.org #sfml) for some help with learning SFML but remember you will be expected to know the basics from the official SFML tutorials....

Now, I also hope you understand the meaning of run on sentences from the above post 

The fact that you used just a run-on sentence to violate the rules of grammar is driving me mad.

5

Graphics / Re: [Beginner] Help with Bouncing Circles

« on: February 01, 2014, 03:18:17 am »

You don't need bounding boxes for only circles. Circle to circle collisions detection is easy: if the distance between their centers is longer than the sum of their radiuses, they collide.

Here's a good tutorial: http://gamedevelopment.tutsplus.com/tutorials/when-worlds-collide-simulating-circle-circle-collisions--gamedev-769

^ And it's things like this that I need to remember if I plan to get a job programming... Ignore my first post; sorry!

6

Graphics / Re: [Beginner] Help with Bouncing Circles

« on: January 31, 2014, 10:58:09 pm »

You'd want to make it so the circles have boundaries; one of the simplest ways I've worked with collision is box collision - that is, you make a box around the entity you wish to implement collision for, and when two entities collide (for example, when the left boundary of thisCircle is at the same coordinates of the right boundary of thatCircle), you can then add code as to how they behave.

7

General discussions / Re: Current situation of SFML

« on: January 30, 2014, 03:38:44 am »

Hope things go smoothly for you; good luck!

8

General discussions / Re: #pragma once vs #ifndef - Which is better?

« on: January 24, 2014, 01:14:16 am »

Not sure if it counts for anything, but what I was taught was to use #ifndef - might have been because we used GCC at the time, though. I use #Pragma once if I know I'm the only one who will be looking/working on the project.

9

General discussions / Re: I am developing a game using 2 engines - comparison

« on: January 22, 2014, 07:35:37 pm »

Hm, I've used SDL 1.2 a bit (and SFML), and didn't mind the way keys were mapped in either engine. Of course, what I developed wasn't exactly consumer-ready nor all that far along, and the applications were separate rather than trying to have the two imitate each other.

Regardless, I'm interested to see your thoughts/comparisons of the two.

10

General discussions / Re: One Game A Month

« on: January 14, 2014, 03:30:02 am »

I definitely don't have time for something like this, but it looks pretty neat. I look forward to seeing your megathread.

11

General discussions / Re: Mutual following on Twitter!

« on: January 13, 2014, 05:46:26 am »

I'm sure no one will mind, welcome!:)

Thanks!

12

General discussions / Re: Mutual following on Twitter!

« on: January 13, 2014, 02:41:39 am »

Although I really want (and plan) to get into SFML a lot more, I'm a bit new here. I hope you guys don't mind if I follow you (I'm @Vitontonio).

13

Graphics / Re: Pass RenderWindow to function

« on: January 12, 2014, 11:58:19 pm »

If I understand what you're saying, why wouldn't you just use window.draw(player)? It calls the draw() method from your Player class.

You can find more here under "Creating a SFML-like Entity".

14

Graphics / Re: Peculiar issue with transforming a sprite.

« on: January 12, 2014, 09:09:45 pm »

If computer is entity then its draw is NOT called, sprite's draw is called, if you want to have sprite both transformed by own transform and computers transform, draw it after vertices in draw and draw computer itself or pass a second argument to draw which will be render states with your transform from computer.

This was the issue; thank you again, everyone.

15

Graphics / Re: Peculiar issue with transforming a sprite.

« on: January 12, 2014, 08:51:20 pm »

You need to multiply your transform with the one in sf::RenderStates in draw() from drawable. Show your Entity draw function.

void Entity::draw(sf::RenderTarget &target, sf::RenderStates states) const {
        states.transform *= getTransform();
        states.texture = &texture;
        target.draw(vertices, states);
}

My draw function was the same for both tests, and it was called in a render function where computer is an Entity (if I don't use getSprite(), nothing is rendered to the window):

void Manager::onRender() {
        mainWindow.clear(sf::Color::Black);

        mainWindow.draw(computer.getSprite());

        mainWindow.display();
}

Expl0it3r, I'm assuming you're also referring to what appeared to be my lack of a draw function?