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 - Mörkö

Pages: 1 ... 4 5 [6] 7
76
Window / Generate Event::Closed programatically?
« on: July 10, 2014, 06:07:08 am »
Hi, so I'm looking for a way to create the sf::Event::Closed event without manually doing anything like pressing the close window button or alt+F4.

From what I can tell, all the ways a user could push custom events are private and hidden, unfortunately!!! Well, unless I mod the SFML source of course, but that's undesirable.

For my testing purposes it would be very convenient to be able to generate events in the code somehow in general, but for the moment I'm specifically looking for a way to make the program emit the Event::Closed event. Is it possible?

77
General / Re: Making Consistent Physics with Delta Time
« on: July 02, 2014, 10:12:29 pm »
I don't understand why it would be better to add a fixed amount to jumpTime rather than adding deltaTime.

The point of using deltaTime rather than a fixed amount is to guarantee that the physics are updated the same amount regardless of game FPS, am I wrong?

If you are able to run the update function with exactly the same delta time difference every cycle, then yes there is no need to pass it anything. Maybe that's possible in a trivial systems, but in a dynamic game I don't think you can be sure of that.

Maybe I have misunderstood what you are talking about. Please clarify why it's recommended to use a fixed modifier for updating physics, rather than calculating the modifier based on delta time.

78
General / Re: Making sense of pong example
« on: June 28, 2014, 06:15:43 pm »
Sure, but I don't see where OP or anyone were suggesting that someone should do that.

79
General / Re: Making sense of pong example
« on: June 28, 2014, 06:01:04 pm »
I guess it's a matter of making event organization really easy and clean. For instance, you can have one function that deals with all KeyPressed events, and another function that deals with all KeyReleased events, something like this:

while (m_window->pollEvent(event))
{
    switch (event.type)
    {
        case sf::Event::KeyPressed:
        {
            handleKeyPresses(event);
            break;
        }
        case sf::Event::KeyReleased:
        {
            handleKeyReleases(event);
            break;
        }
    }          
}

The separation of those handlers will make your code more neat.

handleKeyPresses(sf::Event& event)
{
    switch (event.key.code)
    {
        case sf::Keyboard::Space:
        {
            activateBomb;

handleKeyReleases(sf::Event& event)
{
    switch (event.key.code)
    {
        case sf::Keyboard::Space:
        {
            deactivateBomb;

80
General / Re: How to enable GLSL 330
« on: June 28, 2014, 05:43:01 pm »
You can check the GL strings using glGetString(GL_VERSION​) and glGetString(GL_SHADING_LANGUAGE_VERSION​​) after creating the window as well. If it reports what you would expect and GLSL 330 still doesn't work, it is probably a driver bug, nothing SFML can do about those. Also, it seems you are using Gallium3D? It is already quite dated. Did you try updating/installing the radeon driver?
Well I'm using the free drivers at the moment, I did find an article saying that the proprietry fglrx drivers would give access to openGL 3.3, but fglrx have given me a lot of trouble in the past so I'm hesitant to install it. Also an entry on stackexchange suggested that intel users have a more updated version of MESA, but I guess that's unfortunately not relevant to this case.

However, I was wondering if there is any way to enable core profile in SFML, like I did in SDL? From what I can tell that would let me use the features I need without changing drivers.

81
General / How to enable GLSL 330
« on: June 28, 2014, 11:09:52 am »
Is it true that opengl 3.3 is not supported in SFML 2? I seem unable to set sf::ContextSettings.minorVersion to 3, as that is what I believe would enable me to use glsl version 330.

I was following along in a tutorial, and when I tried to create a shader the program gave some error about NEW_IDENTIFIER, which after googling it seems I was using an outdated version of glsl, so I tried using context settings to get the required version.

X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  153 (GLX)
  Minor opcode of failed request:  34 ()
  Serial number of failed request:  69
  Current serial number in output stream:  68


So I thought maybe I simply have an installed version that is outdated.

[morran@5586577d ~]$ glxinfo
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD CAYMAN
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.1.5
OpenGL core profile shading language version string: 3.30


My system clearly supports glsl version 330, so why does it seem like SFML doesn't do so too?

What steps can I take to enable opengl 3.3 in SFML?

edit--

Yeah it turns out I didn't understand the meaning of opengl core profile. So I guess my new question is, can I enable that somehow?

edit2--

For example, in SDL I can do this:

SDL_Init(SDL_INIT_VIDEO);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_CORE);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 3);

SDL_Window* window = SDL_CreateWindow("OpenGL", 100, 100, 800, 600, SDL_WINDOW_OPENGL);
SDL_GLContext context = SDL_GL_CreateContext(window);

char* version = (char*)glGetString(GL_VERSION);
printf("%s\n", version);

And as far as I can tell from my brief testing, it works with no problems.

outputs
3.3 (Core Profile) Mesa 10.1.5

82
General / Re: Static Link Errors
« on: June 24, 2014, 07:01:45 am »
If you link statically you have to link all the dependencies, see here.
I did this and tried to launch the program on another computer, but got an error saying could not launch program because of `missing file msvcp120.dll`

I guess that's a Windows specific issue, and some googling got me an article by Microsoft recommending the developer to build some kind of extracting package or something. I didn't have time to try it yet.

83
General / Re: SFML static compiling for VS13
« on: June 24, 2014, 03:23:17 am »
Yep that fixed it, thanks!

I actually read the part in the tutorial where it said it would be incompatible, but then I tried to compile a small example, which happened to work so I thought maybe it's not a big deal and forgot about it until I made this thread.

::)

84
General / SFML static compiling for VS13
« on: June 23, 2014, 11:53:32 pm »
So I'm completely new to development in Windows, and aside from a new found gratitude to whoever invented package managers, I've run into some trouble trying to compile against the static libs.

Using Visual Studio Express 2013 and the `Visual C++ 11 (2012) - 32 bits` version of SFML.

I can compile it normally just fine, but when I add SFML_STATIC and change the linker options to sfml-xxx-s-d.lib then I get a bunch of these errors:

Quote
Error   1   error LNK2038: mismatch detected for '_MSC_VER': value '1700' doesn't match value '1800' in Source.obj

and
Quote
Error   29   error LNK2001: unresolved external symbol "__declspec(dllimport) class std::basic_ostream<char,struct std::char_traits<char> > & __cdecl std::endl(class std::basic_ostream<char,struct std::char_traits<char> > &)" (__imp_?endl@std@@YAAAV?$basic_ostream@DU?$char_traits@D@std@@@1@AAV21@@Z)

What am I doing wrong?

85
General / Re: How to structure a SFML game?
« on: June 20, 2014, 06:25:41 am »
Or you could give all Entities a Z member and have a single vector of pointers to them which you sort every frame.

Why every frame? You only need to sort them once every time a sprite has just added, and that's assuming the data structure of the layers doesn't have predefined layers that the Z value falls into.

Example 1, each sprite has a Z value deciding it's layer of rendering:
spriteArray = list(sprite for sprite in spritesToBeLoaded)
spriteArray.sort(key=lambda sprite: sprite.z)

# rendering loop
while(gameRunning):
    for sprite in spriteArray:
        render(sprite) # already sorted

# later in the game, some entity is added
spriteArray.append(newSprite)
spriteArray.sort(key=lambda sprite: sprite.z) # we are good until next time something is added
 

Example 2, the sprite data-structure has preexisting layers:
spriteLayers = dict()
for layer in range(maxLayers):
    spriteLayers[layer] = list()

#when adding sprites, they are automatically sorted based on Z attribute
for sprite in spritesToBeLoaded:
    spriteLayers[sprite.Z].append(sprite)

#rendering them in the right order is trivial
for layer in range(maxLayers):
    for sprite in spriteLayers[layer]:
        render(sprite)

#no need to do any sorting, the structure is always sorted
newSprite = Sprite()
spriteLayers[newSprite.Z] = newSprite
 

The second alternative is more similar to the option about having a background-object, level-object and foreground-object, while still retaining all the flexibility offered by Z attribute based layering. 

86
General discussions / Re: SFML Game Development -- A book on SFML
« on: June 19, 2014, 10:59:34 pm »
The article may have a point about someone who just wants to make a very small game. I would agree, if I'm making flappy bird then I will not bother defining a core framework (i.e an engine) before starting on the game logic.

But in anything more complex, I would definitely start by defining some kind of engine first. You may not have to do that, and if you are an expert programmer then perhaps you won't make any fundamental mistakes along the way, mistakes which would force you waste time refactoring deep parts of the game.

But that's all when just talking about someone simply making a game.

However, the book is something else than a diary of an indie developer, it's actually trying to teach something, and my point is that it would have done a better job of doing so by separating the game from the game engine.

87
General discussions / Re: SFML Game Development -- A book on SFML
« on: June 19, 2014, 09:39:30 pm »
I have just finished the book, so here's a small review of it.

I liked the relaxed nature of the text. There were times when a sentence was convoluted, ill formed, or didn't sound like natural English, but it was OK in general. The reason I liked the tone of the book may be because the previous book I read was by Stroustrup, so I guess just about anything feels approachable in comparison.

What I disliked most was the ordering of how different concepts are introduced. I concede to being a programming newbie, and that it's possible the authors had good reasons (which I don't understand) for structuring the book like they did, but mixing the game design with the game engine design was a mistake in my opinion. What the book should have been like, is to build the pure engine in the first chapters without any airplanes or sprites, and in the latter part of the book create a game on top of the finished engine.

This approach would have left all the chapters much cleaner, and probably shorter. Instead of introducing the SFML concepts mixed in with the game code, mixed in with game engine logic, the author would have been free to to describe either one in focus and greater detail. Of course the downside is for the reader to not get to the fun stuff immediately, but I'm arguing that the gain in terms of clarity and succinctness would have been more than well enough worth that trade.

As a bonus, it would let the reader start experimenting with their own game quickly, instead of having to either start over, or to spend the effort of cutting out all the airplanes from their code if they want to make some other kind of game.

That was my main gripe. As a whole I really did like it, and I'm glad to have been introduced to so many useful mechanics, such as the scene graph and command system, although I'm still somewhat confused about lambdas and some other things.

It's a pretty solid introduction for someone wanting to get into C++ game dev, and for now I will recommend it if the topic comes up.

Big thanks to the authors for this book.

88
General / Re: How to structure a SFML game?
« on: June 19, 2014, 07:31:06 pm »
I have been trying to teach myself programming since two years back, and an important part about asking for help is this: Try to be as specific as possible in your questions. You will have better luck getting help if you try to ask specific and technical questions instead of broad and possibly open ended ones. For example, your post contains many questions, most of which aren't precise enough to have any single answer, or not enough context to do so. Therefore answering your post as a whole would be much more difficult than if you had posed a single technical question. In short, try to help the people who want to help you, it's easier for them to answer small questions.

That's just some friendly advice from a someone who asks a lot of questions.

Quote
due to something I did way back means i have to amend something new to fix that problem but some of my old functions are using that function, this happens all the time and I completely understand it is my fault for not fully understanding the structure of my game or the program.

Sounds like you may benefit from making an effort to follow the principles of `Separation of Concerns.` That means encapsulating different areas of functionality such that they aren't entangled in other areas. Making the different concerns into strictly defined and separated modules, with a clearly defined API, will make it so that if you need to rewrite, say, the rendering module down the line, then you don't need to go deep into every area of your project changing function calls and so on, because you defined the interface clearly from the start.

Other ideas include:
Trying to plan your program flow more carefully before actually writing any code.

Writing unit tests for every function, and writing your tests before actually writing your functions.

Trying to make your code `purely functional` whenever possible. That means to minimize your use of functions that have side effects such as changing a global value, or functions that have varying return value depending on something else than their input parameters. This takes some getting used to, but you may very well find that your code is much more robust and reusable.

Quote
I have a State which has a ImageService, the state has a hero and a level, would I assign them each a image? for example hero.sprite = imageService.images["heroImg"];

Without knowing anything about the rest of the structure of your code, I don't think it's too weird or unusual to have some kind of entity system, that includes some kind of Entity.Sprite or Entity.getSprite() attribute. In any case, for small games, I think that's acceptable because it's pretty straightforward and clear what is going on. But I'm not really sure what you are asking, so forgive me if I'm not making sense.

Quote
Second lets say if a level had some blocks, but some blocks are infront of the hero, would I have to write out my render function to say

//Draw level blocks

//Draw hero

//Draw upper level blocks

//Draw menu

//etc...

Well, not explicitly unless there is some other reason to. Maybe you could just assign every sprite a Z value, and render them in order going from least Z to most Z.

Quote
But then a really big important part is, the renderwindow is 800 by 600, in most computer games the user is allowed to change the size of the game, so lets say the user wants to display 1280 by 768, where would be the best place to draw the sprites differently? What about collision detection? if the view was 800 by 600 and now it is 1280 by 768 the width has go up by 1.5 and a bit and the height has changed by 168 pixels, would I save a global variable in my state which has the "ratios" of the screen? so 800 by 600 = 1:1 and 1280 by 768 = 1.6:1.28 would I then use that to modify all sprites displaying and also use that to modify collision detection?

I don't understand the first part of that, you may want to clarify what you mean.

As for collision detection, it would be unusual to scale distances in the game world according to window size. More sane is to apply all game logic such as collision detection using your normal measures, and just scale the final image in rendering.

89
General / Re: help decrypting error message
« on: June 13, 2014, 01:31:46 am »
I found the problem, as I suspected it was a problem with my source, rather than my stl libs.

In world.hpp I had forgot to add an & to the declaration of FontHolder& mFonts.

Now, while there were some small hints in the error message about ResourceHolder and something about sf::Font, it worries me that nowhere did the error point to the line where I had made the mistake.

The reason why this a little annoying to me is that if I didn't have the working source to help me, and this was an error in, say, some code I made myself, then I'm unsure of whether I EVER would have been able to fix it. But I guess that's a problem I will deal with in the future instead of now.

Thank you all for your help.

90
General / Re: help decrypting error message
« on: June 12, 2014, 07:42:16 am »
If anyone is up for it, I can create a repo of my own code, and you can test if it fails on your system as well. Let me know.

Pages: 1 ... 4 5 [6] 7