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 - GraphicsWhale

Pages: 1 ... 4 5 [6] 7 8 9
76
General / Re: Small questions about game programming
« on: September 01, 2015, 08:03:39 pm »
I know someone already answers, but to give you my opinion:

1. How should I build my game loop? Or more specificly where? Should I create it to main directly, or should I have class that has function for game loop, and then I just create object and call the function in main? Is there any performance differences between these 2 options?

It shouldn't matter. Any performance difference will be so low you wouldn't be able to measure it. In terms of performance in general, as long as you don't do anything overly stupid, 2D games (what I assume you're doing) aren't really effected by performance all that much.

2. What is best way to create different cursor? Is it just fine to make cursor invisible and draw own cursor to position of mouse? Or is this too heavy thing to handle?

Use whatever method you like best. Again, any performance "issues" with such little things would be impossible to notice.

3. How should I implement drawing inventory? Or anything that contains buttons, should I make class that checks for clicks inside specific coordinates or is there better way to do it?

There's lot of information on GUI programming out there. If you're starting out, I suggest looking for a simple GUI library (I've heard about SFGUI, not sure if that's what you're looking for, though) and learning out it works before trying to roll your own. There isn't a single way to program GUIs in C++, so there's no "wrong" or "right" way to do it (that isn't to say you can't make a bad GUI library, but that they're many ways to make one).

4. How do I know is my code good/efficient? What can I do to improve it?

I suggest reading up on good programming practices (Scott Meyer's Effective C++ is a good book, also check out http://gameprogrammingpatterns.com/contents.html). But performance, again, shouldn't really be an issue. This isn't like the Atari days. You don't need to micro-manage every little piece of your code (maybe if you're writing an OS kernel, but that's entirely different).

5. How I should make character dialogues? If there is lot to talk about, it is pain to write that.. Maybe I should use Lua to write the dialogues and then just implement them to characters with c++?

Do not use Lua. Lua should be reserved for when you need to program behavior in files, not data, like dialog. You can just save dialog inside text files.

6. Imagine I have created game. I have all textures in folders. Anyone can go and change them? He could take for example wall texture and make it transparent, and with this he sees through walls? Is there a way to precent this? Same with .exe file that runs the game, is it possible to crack the code and edit it?

Any files left out in the open, the user can edit. If you really want to keep users from accessing the files, you could try custom binary formats.

To save a float in binary:

void save(const char *filename, float value)
{
    std::ofstream stream(filename, std::ios::binary | std::ios::trunc);

    stream.write(reinterpret_cast<const char*>(&value), sizeof(float);
}
 

To load it back:
float load(const char *filename)
{
    std::ifstream stream(filename, std::ios::binary);

    float value;
    stream.read(reinterpret_cast<char*>(&value), sizeof(float));

    return value;
}
 

Just store whatever data you need in that and you'll be good. It does come with the downside that you need to convert any asset that uses the format into it before you use it, though. So it might be useful to create a small library for any custom formats, and then create a small program that will allow you to convert files to and from the format and just access the (now converted) files through the library in your game.

If you need it really secure, you'd have to do some tricks in order to try to make it so the format cannot be easily decoded. But as long as the game's single-player, you shouldn't worry. If the player wants to see through a wall, let them do it.

You also cannot keep them out entirely. No matter what format you use, your game has to decode it one way or another. You can put as many barriers in their way as you'd like, but your game will still have the code to decode the files, so any "hacker" determined enough can and will get to the files. If you were selling the game, you'd typically make it hard enough that you'd hope the hacker would simply pay the money for the game instead. :)

77
General / Re: Does anyone know what's the problem here?
« on: September 01, 2015, 07:14:38 pm »
if you didn't build it as statically linked then you will have put all the SFML dlls into your debug folder

True, but a missing DLL, in Windows, should off an explicit error message saying it can't find the DLL. So I'm led to believe this is not the issue.

or copy them into system32 or somewhere the program can find them

I would not recommend that. As soon as he changes his SFML version, or he changes his compiler, all hell will break loose.

78
General / Re: Does anyone know what's the problem here?
« on: September 01, 2015, 01:39:12 am »
If I set the application to a GUI application in the projects properties like the tutorial says I get this in the build log:

Does it run as a console application?

I am using SFML 2.3.1 with Code::Blocks 13.12 (GCC 4.7.1) on a 64bit Windows 10

Did you build SFML yourself? If not, are you sure your compiler is exactly the same as the one the pre-compiled binaries were compiled with?

79
General discussions / Re: Looking for work?
« on: September 01, 2015, 12:56:59 am »
I agree with Nexus.

To add more, here are a couple more specific reasons why I am against it:

- You probably don't want to work with most of the people on this forum. Not because they're necessarily bad programmers, but because it's overwhelmingly likely that trying to synchronize your schedule, workflow, programming style, etc with any given member to complete a project would result in less work getting done than if it were to be done with a single programmer.

- A project requiring multiple members is likely a large project that uses various libraries, and possibly even various languages. You're much more likely to find someone who suits all your needs on a website like gamedev.net than here.

- I can already see the posts made by people who only have enough experience to draw a couple rectangles on the screen asking for help with MMOs.

- Very few projects are actually likely going to be even finished, so most people posting would be just wasting others' time.

80
SFML website / Re: Fake or fine?
« on: August 29, 2015, 12:17:44 am »
Not part of the dev team but I don't think that's legit...

Look at this: http://icwww.epfl.ch/~sam/. Especially the "School of computer and comunication sciences" part.

Since the website is owned by some college in Switzerland, I'm going to assume it's a copy of the official documentation (hence why it says "official") posted on their website for their students to use (though, I don't have a clue what's up with their bad looking SFML banner). Might be wrong, but I'm almost certain.

Unless whoever put it there got explicit permission from an SFML developer, the only way to know for sure why it's there is to email them.

81
Feature requests / Re: A couple suggestions
« on: August 28, 2015, 07:25:45 pm »
However, if a single stream / sound file is shared among multiple musics, it will have to seek a lot, which can be very slow (or even impossible) depending on the underlying stream.

Maybe have a max amount of "clients" for the stream, depending on the platform's limitations (or some fixed number)? Probably not the best solution, but an idea.

Speed shouldn't be a concern. There's nothing stopping anyone from creating a million sf::Musics and streaming them all to the same file with the current system. Just like how you should warn against creating loading a really large file into an sf::SoundBuffer, you could simply warn against having too many sound instances trying to stream from the filesystem.

82
Feature requests / Re: A couple suggestions
« on: August 25, 2015, 05:23:01 pm »
I beg to differ:
sf::SampledSound, sf::Sample, sf::Soundtrack, sf::SoundEffect, sf::AmbientSound, sf::Ambience, sf::Ambulance

To be perfectly honest, if you came up with a name for every single possible usage, I wouldn't even be upset. I'd be a bit like: "do I want a sound track? sf::SoundTrack.. what about sad music? sf::SadMusic, maybe even throw a bit of sf::JustinBieber in the hell level";D

83
Feature requests / Re: A couple suggestions
« on: August 25, 2015, 04:24:51 pm »
In hope that this is still a discussion and not an argument...

I don't consider this an argument. Maybe a debate. But that isn't exactly a bad thing.

for their usage, this should at least be sf::OpenGlTexture, right?

As I said, I'm not for unreasonably "correct" names.

I have no problem with sprite. I think you again misunderstood what I was saying.

You were trying to make a point by giving a slightly extreme example, yes?

Thanks  :'(

The source does not compile (dependencies on missing headers). Could only "play" via looking at the code and imaging what could've been. 2/10 :'(

84
Feature requests / Re: A couple suggestions
« on: August 24, 2015, 09:43:32 pm »
What about the people who think they're too good for documentation? Even if they don't want to learn, it's not always a bad idea to give some sort of hint of the differences in the name.
I agree that names should try to indicate what classes/functions represent. Sure.
I'm not so sure that changing these names buys us much when it comes to clarity.
But what I really want to comment on is your statement above about people who can't be bothered to read docs. Well, in my opinion, such people are just beyond reach/hope and not worth spending time on or worry about.
If you can't be bothered to read the documentation you'll have problems with any library - regardless of naming. And in any case, you probably should not be programming professionally.
Using this as an argument really doesn't convince me in any way. It's just saying that SFML should cater to idiots and I don't agree with that.

Hey, if it's good enough for an idiot, it's probably excellent for anyone who actually knows what they're doing.

Also, I wouldn't consider most of the usage of SFML to fall under the category of "programming professionally". These "easy" wrappers for window management (and other utilities) might be capable of being used professionally, but most of the time they're used for making bad pong clones. SFML especially (since these types of people also seem to flock to C++).

Not trying to insult SFML, or say that this is true to anyone on the forum, but there's a lot of beginners who like to use this library.

EDIT: Just for clarification, I am not saying I want SFML to cater to idiots. I honestly couldn't care less about making life easier for those who refuse to read the docs. However, I also don't want the names to be misleading (which is what I believe the class Music does).

85
Feature requests / Re: A couple suggestions
« on: August 24, 2015, 07:29:13 pm »

..................

can't take a joke or understand sarcasm

I... I legitimately have absolutely no clue what you are talking about.

86
Feature requests / Re: A couple suggestions
« on: August 24, 2015, 07:27:36 pm »
As somebody new to SFML, the difference between Sound and Music was perfectly clear for me even without documentation.

Average rate that people immediately know the difference: 100%
Sample size: 1

By the way: QSound, QSoundEffect

Can you explain your point, instead of giving me links to qt documentation? I can't tell what kind of message you're trying to convey here.

87
Feature requests / Re: A couple suggestions
« on: August 24, 2015, 06:13:55 pm »
sf::Texture is NOT
"the feel, appearance, or consistency of a surface or a substance."
sf::Texture is named for its specific use case (and its location) when it's really just an image.
An SFML texture corresponds with an OpenGL texture, so it's not out of place. As for why they're called textures in the first place, I don't know.

sf::Sprite is named for its specific use case when it's really just a rectangle, or a vertex array.
A "sprite" is something that exists in lots of libraries/engines. It's a standard name.

sf::Lock is NOT
"a mechanism for keeping a door, window, lid, or container fastened, typically operated by a key."
Request it to be changed to sf::MutexLock, then.

88
Feature requests / Re: A couple suggestions
« on: August 24, 2015, 04:01:02 pm »
I don't think this conversation will ever lead anywhere productive at this point. Can't tell if we're either not understanding each other or we just have different opinions, but I'm lost. But I will say this:

I really don't care that much about the naming of the class Sound. It's mostly Music. According to Google (because we all know Google is the one and only true God, the kingdom of the internet, that we'd all be lost without), the definition of music (there's two definitions, but this is the one referring to the audio music) is:

vocal or instrumental sounds (or both) combined in such a way as to produce beauty of form, harmony, and expression of emotion.

I consider this definition an accurate representation of what most people think of when they hear the word "music". With that said, the reason why I point that out is because music has a pretty concrete meaning of a certain type of sound.

Music in SFML, on the other hand, is simply anything that streams directly from the file.

There's a lot more to streaming audio directly from a file than music. Therefore, I think it's in the best interest to have it changed to a more "useful" name.

89
Feature requests / Re: A couple suggestions
« on: August 24, 2015, 09:04:12 am »
Other libraries doing something doesn't mean that it's the right way to do something.
You did, here, seem to make a distinct between sounds being in RAM and music being the streamed audio. I think those distinction may be why those names were chosen for SFML.

My point was the the notion of "Music" being something that streams it's audio is unique (AFAIK) to SFML. Maybe, just maybe, there's a reason why this naming scheme was not used in other libraries

It doesn't have to necessarily specify exactly what it's doing. "BufferedAudio" doesn't say where it's being buffered. Your reply was odd  :P
My point was that it's accurate and differentiates from the 'other' type by describing why it's different.

When you have a class that has a function to load a file, and a function to use it, the word "buffered" is pretty meaningful. Sure, it might not say to which point is it being buffered (the whole file, a small section, maybe even per-sample?), but most of the time it's referring to the whole file. "External" is not a good way to refer to something in the filesystem, so it's a lot less meaningful.

No, because BufferedUnbufferedAudio isn't unbuffered.

Does BufferedBufferedAudio|BufferedAudio tickle your fancy?

If the "permanent storage" (SSD or HDD) has cache, it would also be buffered there, too. Dang. Ok, what about BufferedBufferedBufferedAudio|BufferedBufferedAudio?

I know. They'll come to the forum and ask why it isn't working and then they'll be (hopefully politely) directed to the documentation.

Not sure why'd you want that.

90
Feature requests / Re: A couple suggestions
« on: August 24, 2015, 08:34:16 am »
why is that code wrong  ?

Because your game should be continuously updating regardless as long as it's running. Maybe pause it when minimize, but that's a change to your game's "state", not branch in the rendering code.

sf::Keyboard::isKeyPressed(...)
"This function directly reads the keyboard state, ignoring the focus state of your window. This means that isKeyPressed may return true even if your window is inactive."

so from that documentation that's exactly what I've been doing in my code (checking if window has focus)

I never said to ignore keyboard input, I just said that there doesn't need to be a branch in your rendering code, therefore only passing a graphics object instead of the whole window is a non-issue.

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