Messages

1

Graphics / Re: Differences in speed between DEBUG and RELEASE builds on Win32

« on: August 28, 2017, 01:58:17 pm »

OK, but for your average Joe all of that is irrelevant.

[My Code] => [CSFML] => [Runtime Libraries]

My Code can be in Debug or Release, and still target the Release build of SFML (and by extension, the Other Libraries) - it does not require a Debug build of CSFML to run, and running in Debug won't break the integration with the Release build of CSFML.

And 99% (or more) of the time, that will be the use case.

I find not-providing-binaries to be typical of Linux-targeted libraries where the target machine could be running any version of Linux on any platform. Some of those also target Windows, but maintain the paradigm. Generally Windows-focused libraries come with or as binaries - Windows for RISC and Windows for PowerPC never really took off. (Largely because everything comes pre-compiled for x86!)

2

Graphics / Re: Differences in speed between DEBUG and RELEASE builds on Win32

« on: August 26, 2017, 01:02:08 pm »

There are debug builds that have to be used in debug mode

What do you mean by "have to be used"? How does it make a difference to the calling code? And how do you propose that this might work where people generally just download the libraries and call out to them? (CSMFL-2.4-windows-*.zip only contains one set of dll files)

3

Graphics / Re: Differences in speed between DEBUG and RELEASE builds on Win32

« on: August 25, 2017, 12:30:20 am »

Wow, OK, so this could be a difficult one to untangle.

The first thing is that SFML is not building when you build your code. You're using a library that's already built - so SFML is *always* in Release mode.

That means it's probably your code. And it would DEFINITELY be a good idea to test it out on different machines in both Release and Debug modes.

If you haven't already, it's worth getting SFML to use VSYNC, or force it to 60FPS (or whatever FPS you will find acceptable.) Before you publish, you'll want to consider whether to support machines that are too slow to run at 60fps - which could give you major headaches if your game logic is dependent on specific numbers of frames passing. 60fps is roughly 1 frame per 16.6667ms (or 1/60 of a second) so you want to either do all your processing in 16ms or force your framerate down to the number of milliseconds you need to do your inter-frame processing.

I'm interested to know - if you don't consider yourself a *fantastic* programmer, why do you use C++? C# is far more forgiving. You don't need to worry about allocating memory, freeing it, and all that. I'm a bloody amazing coder (although a really bad mathematician), and I prefer C#. And yes, it is definitely fast enough.

Now, I don't know what your code looks like, but if you're creating a new Time object frequently, that might be causing you problems. For keeping track of time, you're better getting the start time of your application then using Modulo (% operator) to get the current value of a hypothetical looping timer. Let's say a is always increasing, a % 100 will always be between 0 and 99, and will "roll over" to 0 when it reaches 100.

For moving stuff around I also prefer to 'outsource' the responsibility to a physics engine. I'm using Box2D/LiquidFun. Main issue I have at the moment is that it's single-threaded, and making it multithreaded would not be a straightforward project. So I just call Box2D in a separate thread. I have a semaphore joined to my vsync, so Box2D runs in parallel to my game logic. I've got a C# wrapper around a C++/CLI wrapper around Box2D with more semaphores so that stepping the world and modifying the world do not overlap. That's not to say that this is necessarily a "normal" way of doing things - you don't have to follow my example. I am not a professional game developer (yet).

The other thing you might consider is offloading your starfield to GLSL. Using a Stopwatch (or just counting milliseconds since your exe started) you can pass the number of elapsed milliseconds to a Fragment Shader, and let that deal with drawing a starfield. If it's a horizontal startfield you could "take inspiration from" these:
http://glslsandbox.com/e#41903.0
http://glslsandbox.com/e#41888.3

4

Audio / Re: When I disable and re enable audio output device there is no audio output.

« on: August 22, 2017, 07:49:04 pm »

After a quick look at OpenAL, I don't see that this would be particularly hard. SFML "knows" which sounds are playing, because it's got to be dealing with populating the AL buffers... right? (?) You might lose a bit of buffer, but I doubt anyone's writing military-grade communications systems with SFML. All that's required is to check for error states, and if there's an unrecoverable error, just clean up the old context and create a new one. Swapping out a pointer to the context would mean not much more needs to be done - any music that's playing will pick back up when the buffer next gets written, and sounds would recover too. The only fly in the ointment might be the listener, but if you abstract the refresh of the context to another method, that should be manageable.

All I need to do to switch to OpenAL (via OpenTK probably) is to put together a class that manages the data and streaming it into the OpenAL buffers, either from file (like SFML Music) or from memory buffers. The worst part would be integrating a Vorbis decoder.

5

Audio / Re: When I disable and re enable audio output device there is no audio output.

« on: August 22, 2017, 04:48:54 pm »

I don't have to restart anything when I unplug my USB amplifier. binary1248 are you using Windows 10 or some earlier version?

I typically change audio devices so that I can listen on speakers when nobody else is in the room, then switch to earphones without interruption. Or I might switch to the digital output so audio goes through my surround system - or back to earphones again if I need to.

I don't see what's so strange about it, and Windows 10 seems to support it better than any previous version of Windows I've used. That suggests Microsoft also consider it a valid and common enough use case for them to support.

The only app that might occasionally "break" is Audacity, but that's because it allows you to select your output device - making it an expected behaviour.

Even Winamp 5.666 works.

6

Audio / Re: (Windows) Kernel crash after audio device unplugged

« on: August 22, 2017, 04:33:26 pm »

Thanks eXpl0it3r I'll check out the discussion.

Unplugging devices is something I do and I imagine others will do the same, so I might look for an alternative.

7

Graphics / Re: Erasing from a RenderTexture with BlendMode Factors

« on: August 22, 2017, 04:31:54 pm »

Thankyou Laurent - and thankyou for creating this awesome library

DstAlpha - DstAlpha also works, but I guess that could be slower so I'll try BlendMode.None

8

Graphics / Re: Can move up but not down.

« on: August 22, 2017, 11:25:57 am »

Your character might be moving at a supersonic rate if you're polling the keys every frame. 60fps would be +60 pixels every second. You could use an external counter or (as I mentioned before) a velocity:

Code: [Select]

xVelocity = 0;
if (right key pressed) {
  xVelocity = 10;
}
if (left key pressed) {
  xVelocity = -10;
}

Your sprite.move is given the xVelocity.


Then you can get into acceleration and deceleration:

Code: [Select]

if (right key pressed && xVelocity < 10) {
  xVelocity += 3;
}
if (left key pressed && xVelocity > -10) {
  xVelocity -=3;
}
if (neither left nor right key is pressed){
  xVelocity *= 0.5;
}


9

Graphics / Re: Can move up but not down.

« on: August 22, 2017, 11:24:17 am »

Sorry, I see now that it's a button check to see which keys are down, so you won't have that problem.

If it was an event handler, you would get one event when the key is first pressed, then a delay, and then more events.

I use event handlers for move, fire, mode switch. But I also use IsKeyPressed for mouse modifiers (so Ctrl+click has some different behaviour to just click) - that's in conjunction with mouse events.

10

Graphics / Re: Can move up but not down.

« on: August 22, 2017, 09:58:54 am »

I don't really understand what you're trying to achieve with the 2nd charSprite line. It just doesn't make any sense. The parameters will be evaluated first:
Get the sprite's X
Get the sprite's Y

Then those will be passed back in to Set Position.

You're just telling the sprite to be where it already is.

Remove that line and see if matters improve.

Additionally, moving the sprite by 0.25 probably won't get it very far. SFML uses Vector2f because of OpenGL peculiarities, but positions need to be represented by whole numbers. And 0.25 * 1 will round down to 0. Try taking out those multiplications.

If you're making a game with this, moving your sprite in this manner will look pretty weird: you'll have to wait for the key repeat delay before the sprite starts moving. But take it one step at a time. Once you've cracked this problem, you might consider setting a flag when the key is pressed and resetting the flag when it's released. In your main loop, if the flag is set, you move the sprite by n. If the flag is not set, you stop moving the sprite. Then it can get a bit more interesting and you can use a velocity.

Down to why your setPosition line might be working with the call to yReset, it might be some side effect of the way the compiler is building your code crossed with the inner workings of SFML. If the compiler can see two calls to getPosition next to each other and no expectation of change of value (if the getPosition method is marked const in the SFML source) then it will optimise out one of the calls and only call it once. When it's calling yReset, there's no telling what you've done with that method and it'll be calling getPosition twice. Now,  SFML will internally have made some change based on your call to move, and that will have changed the position.

I still don't really get how it's been working at all with moving by 0.25 though.

(If Vector2f is a struct, as it in the .Net bindings, you won't need to initialise it.
sf::Vector2f key;
will be sufficient.)

11

Audio / Re: (Windows) Kernel crash after audio device unplugged

« on: August 22, 2017, 01:58:15 am »

Anything at all?

Should I switch to something else for audio?

12

Graphics / Erasing from a RenderTexture with BlendMode Factors

« on: August 22, 2017, 01:43:34 am »

Hi, I'm having a little difficulty understanding the factors and parameters of BlendMode.

The effect I want to achieve is simply to have the destination pixels replaced with rgba(0,0,0,0) - actually it doesn't matter what the R, G, B components are, but let's just say 0 for now.

Am I meant to be putting the SrcColor factor into the SourceFactor, DstColor into the DestinationFactor? Or should I be putting DstColor into both and using Equation.Subtract?

Evidently I'm confused...

(Use case is painting - not drawing sprites or shapes - directly onto parallax layers that slide over one another. So drawing in the background colour that's behind the RenderTexture just isn't an option.)

Many thanks!

13

Audio / (Windows) Kernel crash after audio device unplugged

« on: August 12, 2017, 02:05:00 pm »

So I have a USB audio decoder attached to my PC. I use it when nobody else is in the room watching TV or similar. Typically I will unplug it when my noises would be disturbing others, and switch to my earphones. In pretty-much everything, this works. Except when I'm using SFML.

When I unplug the device, I immediately get this message:
"AL lib: (EE) MMDevApiProc: Failed to get padding: 0x88890004"

Some time later (seems to be a few seconds after I try to play a previously unplayed sound) my code crashes and I get this during a call to window.DispatchEvents:

Exception thrown at 0x00007FFC06F679A3 (KernelBase.dll) in GameCore.exe: 0xC0000005: Access violation reading location 0x0000000000000004.

So... how can I:
- Detect the removal of a device (or, preferably, detect the change of default device - I'd like it to work when I plug the USB amplifier in, too)
- Pause all sounds
- Change devices (reset audio, whatever is required)
- Resume all sounds

Any suggestions gratefully received!

Many thanks