Messages

121

Graphics / Re: Rendering a sf::Sprite using a shader results in an inverted Y-axis?

« on: October 06, 2016, 03:30:22 am »

OpenGL's "bottom" is -1 actually, center is 0.

122

DotNet / Re: SFML.NET 2.4 Update

« on: October 05, 2016, 11:09:13 pm »

Correct. It's at least nicer than manually changing all the library names. Plus, SFML.NET compiles relatively quickly.
But I do understand why it may not be desirable.

Yes, I believe it is possible (quick Google search confirms this). It'd boil down to using the OS-specific library loading functions (LoadLibrary/GetProcAddress and dlopen/dlsym). It's not complicated by any means, but I'm not certain if it is worth it or not.

(Side note: OSX and Linux both using dlopen/dlsym simplifies things)

123

SFML projects / Re:creation - a top down action adventure about undeads

« on: October 05, 2016, 07:00:31 pm »

Damn. The watermark is a good idea. Maybe make the watermark a link to your site/devblogs/etc just in case someone does steal it again without looking too hard.

Also, looks like there is a report option, although I haven't used 9gag, so I don't know how effective it is.

124

General / Re: White square issue after accesing resource from std::map

« on: October 05, 2016, 06:54:44 pm »

Look at the lifetime of the sf::Texture you create in LocalTitleManager::createGrassTitle(). It only exists within that function, right? (ie: its destructor is called once execution leaves that function)

125

General / Re: Where do I get MinGW 6.1.0?

« on: October 05, 2016, 06:51:21 pm »

The SFML download page has links to the compilers used right below the library downloads.

126

DotNet / Re: SFML.NET 2.4 Update

« on: October 05, 2016, 06:45:33 pm »

Happy to help!

First, I think it would be cleaner if 2.4 update and style changes were in two different PRs. Even more if those style changes are unrelated to each other.

Agreed. I'll split the changes.

This means that we have to ship the Debug version of CSFML with SFML.Net, right?

Yes, debug versions of CSFML would need to be shipped as well. I expect this isn't necessarily desired, so another thought I had was to have another macro definition, to enable/disable this behavior, so only those who want it (library developers, etc) would need to worry about debug versions of CSFML.
ie:
#if !(DEBUG && SFML_NET_USE_NATIVE_DEBUG)
Best of both worlds, I think.
Now that I'm thinking about it again, do you think this should be a separate PR as well?

And the convention is to name constants in CamelCase, not in UPPER_CASE (so it should be DllName). "Dll" might also be too Windows-specific, since on other OSes we'll load dylib or so files.

Will fix. True, I guess I was in .NET mode. How about NativeLib or NativeLibName?

No need to make the internal code depend on new language features when it changes nothing for the end user, and only restricts the environments where SFML.Net can be compiled.

Will revert.

127

DotNet / SFML.NET 2.4 Update

« on: October 03, 2016, 10:58:56 pm »

Branch: https://github.com/dabbertorres/SFML.NET/tree/2.4

I made a few architecture/style changes that I wanted to make sure were discussed and accepted/not-accepted before submitting a PR.

The major things:

• When updating and debugging to make sure all is well, I realized that only the release CSFML dlls were being used, making debugging a little more annoying. I fixed this by adding a (internal) CSFML class to each module (ie: SFML.Graphics.CSFML, etc) that contains an internal const string with the name of the CSFML dll to be used. It's value is determined by an #if !DEBUG switch. This allows the CSFML debug dlls to be loaded in debug mode, and vice versa in release mode.
• I moved the Context class to the Window module, to match up with SFML and CSFML (it was in Graphics). Side-Effects: had to be made public, which I felt was okay, due to Context being publically available in both SFML and CSFML. More uniform APIs, essentially.
• Null-Conditional operator usage. This feature is tied to the C# 6.0 compiler, not to a .NET version. So it works when compiling SFML.NET for .NET 3.5 (with VS 2015, at least). I wasn't sure if the targeted support version was for Visual Studio (C# compiler) or .NET, hence my question on this.
• Style-wise, SFML.NET used two different namespace styles:

namespace SFML
{
    namespace Graphics
    {
        ....

vs

namespace SFML.Graphics
{
    ....

I normalized it all to the second, as I find it to be a nice feature (I'd like C++17 to get it).

Comments, questions, concerns?

128

DotNet / Re: SFML.NET 2.2 for .NET 4.6.1

« on: October 03, 2016, 10:21:35 pm »

I have a SFML.NET 2.4 branch, (https://github.com/dabbertorres/SFML.Net/tree/2.4) that I'm going to submit a PR for soon. I did make some style/architecture (minor) changes on my branch there as well, so I've been meaning to make a forum post to discuss those before submitting the PR.

129

C / Re: [SOLVED] error: invalid use of undefined type 'struct sfTexture'

« on: October 02, 2016, 09:55:29 pm »

No problem. Just remember that you'll need to free each individual sfTexture* and then the sfTexture** afterwards when/if you're done with it.

130

C / Re: error: invalid use of undefined type 'struct sfTexture'

« on: October 02, 2016, 07:46:08 am »

textures is a pointer to a sfTexture.

When you use array indexing with a pointer, it also dereferences the pointer after indexing, not giving you a pointer to a sfTexture, but a sfTexture value, which is kept hidden in the CSFML API. CSFML is designed to not reveal the internals of the structs it uses.

You need to make textures a pointer to a sfTexture pointer (ie: double pointer).

131

General / Re: Questions about making tiled game

« on: September 27, 2016, 11:45:55 pm »

But that's actually a question I've been asking to myself : doesn't sf::View mechanism already imply that only visible items are drawn ?

What is made visible is done AFTER all drawing has been done. If you're not culling things yourself, the draw calls are still being made, with data still being sent to the GPU. If you cull before drawing, the essentially "useless" draw calls and data transfers are not done.

132

General / Re: [Android] Monitoring app on Android tablet from PC

« on: September 27, 2016, 11:43:23 pm »

Is SFML's Android port using logcat internally? I found normal stdout and stderr didn't even show up there without doing what I mentioned above.

133

General / Re: Questions about making tiled game

« on: September 27, 2016, 06:45:13 pm »

Generally, yes. As you said, it's multiple draw calls (using sprites) vs one draw call (vertex arrays).

And yes, if your vertex array is large enough, then culling becomes useful.

134

General / Re: [Android] Monitoring app on Android tablet from PC

« on: September 27, 2016, 06:41:54 pm »

If your device is rooted, you can do this:

Code: [Select]

adb root
adb shell stop
adb shell setprop log.redirect-stdio true
adb shell start
Otherwise, the next best thing is manual logging:

Include the logging header file:

#include <android/log.h>

Use the built in logging functionality:

__android_log_print(ANDROID_LOG_INFO, "foo", "Error: %s", foobar);

By default, Android redirects stdout and stderr to /dev/null (Although Java's System.out and System.err get re-redirected to Android's logging system).

135

General / Re: Facing in the direction of velocity vector

« on: September 16, 2016, 06:47:30 am »

Ah, I think I see what you're trying to do.

Instead of this:

sf::Vector2f(getPosition().x * CurrentHeading.x, getPosition().y * CurrentHeading.y);

You're looking for this:

getPosition() + CurrentHeading * DesiredLengthOfFacingArrow;

You may want to brush up on some of your vector math.

Side note: you can do "code=cpp" instead of just "code" to get syntax highlighting.