Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - sjaustirni

Pages: 1 2 [3] 4 5 ... 7
31
General / Re: Smart Moving Problem
« on: May 05, 2017, 09:15:33 pm »
Firstly, notice there are 3 parts of the tutorial, make sure you read all of them.
Secondly, as you may have noticed, this assumes you're familiar with vector math. Now, I don't know if you have learnt about vectors in school, but if you haven't, I suggest you to look up the vector math on the Internet and only once you have a fair understanding of it to come back to programming. There really are no shortcuts here, trust me, I've been there.

32
General / Re: Smart Moving Problem
« on: May 05, 2017, 04:44:55 pm »
Store velocity and acceleration of spaceship and iterate on that. Here's a great tutorial on this subject: http://blog.wolfire.com/2009/07/linear-algebra-for-game-developers-part-1/

33
Feature requests / Re: small sf::rect suggestion
« on: May 04, 2017, 10:24:13 am »
Yes, you must have misunderstood it.

The rect would be defined through the the two points (left, top) and (right, bottom).

Both can be calculated from each other and thus it's just a question of preference:
1) (right, bottom) = (left, top) + (width, height)
2) (width, height) = (right, bottom) - (left, top)
Yes, I see I have misunderstood it now. Indeed, they're equivalent approaches of a representation of a rectangle. I made an implicit assumption that the sf::Rect constructor was somehow involved. I am sorry for the annoyance I caused.  :-[

No, they are not. All members of sf::Rect<T> (left, top, width and height) are single values of type T, with T being a scalar type (int and float are used internally in SFML).

Yeah, what I meant was that left and top made together de facto a left a top coordinate, but that's moot now. Stupid me  :-[

34
Feature requests / Re: small sf::rect suggestion
« on: May 03, 2017, 08:30:07 pm »
I thought we were talking about sf::Rect. left and top are defined as coordinates there (corners, not edges).
But I suppose I have misunderstood something here?

35
Feature requests / Re: small sf::rect suggestion
« on: May 03, 2017, 02:37:04 pm »
bottom and right can already be easily calculated using top+height and left+width.

Yeah but if you store bottom and right you can also easily calculate height and width. It's a matter of what you prefer. I personally also find bottom and right more useful, I use them more often than height and width, thus doing more calculations.
No, it is not a matter of preference. The way SFML does it is objectively superior.
If you're given x, y, width and height, it is guaranteed you're always given an axis-aligned rectangle. Had you had been given four (random) points instead, the rectangle is not guaranteed  to be axis-aligned. Hell, it is not guaranteed to be a rectangle at all* (it could be any quadrilateral, even a concave one).

* not without cumbersome dedicated checking and error reporting


Touching doesn't make much sense if it returns false even when they do intersect.
However, it is useful to know if 2 objects are right next to eachother, in some cases like checking if a point is on the edges of the rectangle and other similar operations.
SFML is not a collision detection library and you should not treat it so. Besides, thanks to how float-point arithmetic works, you're never going to get a perfect "touch". That's why even in dedicated collision detection/resolution libraries intersections are treated as "touches" (especially if the relative velocity of the colliding objects is small).

36
General / Re: undefined references to... On Windows
« on: April 29, 2017, 01:02:59 pm »
You're right, I have just seen the combo "windows linking failing" and "sfml-main not linked" and assumed the wrong conclusion.

Thanks for the comment about setting the window subsystem. I will implement it once I boot Windows again. I am glad I haven't taken it out as an irrelevant piece of code as you would have not made the comment then :D

37
General / Re: undefined references to... On Windows
« on: April 29, 2017, 10:32:54 am »
EDIT: This is not the cause of the error. See the post by eXpl0it3r.

You're not linking main.

Personally, I use this setup for cross-platform linking
if(MSVC) # Hide console window on Windows
    set_target_properties(${EXECUTABLE_NAME} PROPERTIES  LINK_FLAGS "/SUBSYSTEM:WINDOWS")
    find_package(SFML 2 REQUIRED main system window graphics network audio)
else() # Linux doesn't need the special care
    find_package(SFML 2 REQUIRED system window graphics network audio)
endif(MSVC)

if(SFML_FOUND)
  include_directories(${SFML_INCLUDE_DIR})
  target_link_libraries(${EXECUTABLE_NAME} ${SFML_LIBRARIES})
endif()

38
Feature requests / Re: query the system's current FPS setting
« on: April 28, 2017, 09:08:14 pm »
I believe that what Hapax meant by error accumulation is the error (inaccuracy) caused by std::chrono, which does accumulate when using multiple measurements.

39
Firstly, put the code inside the code tag please.

As to the problem of yours, the most common reason for seeing a white space instead of the respective texture is that the texture is out of scope. I suggest you to write/use a ResourceManager class, which will take care of it and you won't be bothered by this issue again.

40
General / Re: Creating standalone of specific RenderWindow
« on: April 25, 2017, 09:58:07 pm »
I'm creating a game engine like Unity.

Sounds.. bold :D

Anyway, back to your original question - it depends on how your engine is used. For instance, if in your engine one writes C++, you simply start gcc/clang on the user's project including your API headers, statically link your library to it and then you embed the assets into the exe. If one uses a scripting language, you could write your own compiler with bytecode generaton (LLVM is there to save you), or the exe could be just an interpreter with the scripts embedded in the exe and ran everytime the interpreter is clicked on, or you could compile the scripting language to C/C++ and then go the gcc/clang path.

And I just scratched surface on this one. I need to stress, however, that none of these are an easy thing to do, even though the first one is the easiest one by a large margin.

41
General / Re: Enemy intersection trouble
« on: April 23, 2017, 09:58:41 am »
I am quite confused as well :D .It seems that you have been just adding stuff to your game loop without any proper refactoring and thinking about the code design (which is not really uncommon for the novice programmers, I was the same when I was starting out :D). The result is something which we call Big ball of mud. It is hard to write, hard to test and most importantly, hard to read.

I would suggest you to
  • break down the main.cpp file into multiple ones, so that every class has its own header and source file, which is a widespread practice
  • (if you want to go OOP) implement one common public interface for Entity (update(), render(), control())  and for the descendants of Entity (remember, each one in its own file) you would just call free functions and private/protected member functions inside those three methods, so your main loop would only know about those three public functions form Entity
  • make your functions as short as possible by decomposing them into multiple functions

As an example, here's a small SFML game using OOP I have just found on Github. From a basic skimming through it it seems it's written pretty well to illustrate my points. https://github.com/hlilje/sfml-game

I am sorry I was lazy enough not to fix your issue with collision, but I believe collision is currently not your main problem, the code structure is.

GL and have fun, because programming should be :D ;)

42
Graphics / Re: RenderStates Error
« on: April 21, 2017, 03:26:43 pm »
This means the compilation has finished successfully but the linker was not able to do its job.

Well, for the start you're using is an essential information.

In case it's VS on Windows:
(click to show/hide)

43
Graphics / Re: how to set background.
« on: April 19, 2017, 02:26:59 pm »
"image doesn't show up" is lacking information needed to diagnose the mistake you've made. Read this page thoroughly, I believe it contains the solution to your problem (hint: it has something to do with working directories). If following the solution in the tutorial doesn't help, come back to the forum and explain what have you tried and what error messages you've got.

Good luck! ;)

44
SFML projects / Re: "Our Dear Paper Fighters" - Top down shooter
« on: April 18, 2017, 08:19:26 am »
I love the dog part  and the self-destruct button :D I hope that you will keep things like these in the release. (I'd probably work a bit on the dialogues though, they could really make the game more fun. I understand however, that the dialogues featured in the video are just a temporary placeholder until the real ones come)

At 3:08 though, are those guys worshipping the box? It made me smile :D

45
System / Re: Help in threads
« on: April 16, 2017, 06:10:02 pm »
If you have a decent compiler (i.e. one that supports C++11 features), I suggest you to forget about sf::Thread and start using std::thread. sf::Thread is most likely going away in SFML 3 anyway and your knowledge of std::thread you can reuse in myriad of other projects you may be a part of later on.

In fact, I have just realised this is mentioned in the official docs, but I'm keeping it here anyway. :)

Pages: 1 2 [3] 4 5 ... 7