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

Pages: [1] 2 3 ... 7
1
General discussions / Re: SFML Game Development by Example - 4th SFML book
« on: December 01, 2019, 06:46:52 am »
Hey OrderNexus,

Finally finishing up the Networking Portion of the book and I've run into a snag with the Chapter 14 code.  When I compile the code for the Client, I get the following errors everywhere an instance of the Shared Context is referenced.

Output (VS2017)
1>c:\src\sfml-2.4.2\include\sfml\network\sockethandle.hpp(46): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>c:\src\sfml-2.4.2\include\sfml\network\sockethandle.hpp(46): error C2146: syntax error: missing ';' before identifier 'SocketHandle'
1>c:\src\sfml-2.4.2\include\sfml\network\socket.hpp(140): error C3646: 'getHandle': unknown override specifier
1>c:\src\sfml-2.4.2\include\sfml\network\socket.hpp(140): error C2059: syntax error: '('
1>c:\src\sfml-2.4.2\include\sfml\network\socket.hpp(140): error C2238: unexpected token(s) preceding ';'
1>c:\src\sfml-2.4.2\include\sfml\network\socket.hpp(159): error C2061: syntax error: identifier 'SocketHandle'
1>c:\src\sfml-2.4.2\include\sfml\network\socket.hpp(159): error C2535: 'void sf::Socket::create(void)': member function already defined or declared
1>c:\src\sfml-2.4.2\include\sfml\network\socket.hpp(148): note: see declaration of 'sf::Socket::create'
1>c:\src\sfml-2.4.2\include\sfml\network\socket.hpp(177): error C3646: 'm_socket': unknown override specifier
1>c:\src\sfml-2.4.2\include\sfml\network\socket.hpp(177): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int

The culprit seems to be in the SocketHandle.hpp (SFML/Networking) with the following line of code:

#if defined(SFML_SYSTEM_WINDOWS)

    typedef UINT_PTR SocketHandle;

#else
 

I've determined that the problem is coming from the Client somewhere, and yet when I run the same code in Chapter 13, it works as intended.  Odd.

I was hoping to finish this chapter before moving onto your next book (Mastering SFML).

Q1: Any ideas how I can fix this?  Are there any changes you are aware of in SFML since 2.4 in Networking?
Q2: Is the Networking module for SFML needed in Mastering SFML?

I'd like to get the code working as intended

Thank you!

Q2: networking isn't covered at all in the "Mastering" title.


This is still a problem...it doesn't have anything to do with the Shared Context.  Something is wrong with the S_Network...the strange thing is that the Chapter 13 project works fine.

Furthermore, I'm seeing some other problems...there seems to be another error with Rect.inl in the API and this project.  Fortunately, it isn't necessary for the next book but it would be nice to get it implemented successfully.

If I had to guess at the moment (I don't have the source code available), I'd say this is probably some kind of include order issue. I vaguely recall running into something like this in conjunction with some windows-specific includes, specifically in "Utilities.h". I might be completely wrong, but I can't verify this at the moment. Does anyone else have memory of / experience with this type of issue?

2
It sounds like that's a fairly common issue. Between different SFML version releases, the enums being used end up changing in value. The default keys.cfg file that comes with the projects uses "old" values. You'll have to look up the values you need in the enumeration and use those in your file instead.

Another common issue people have with loading files in general is the extensions. If you have your extensions hidden, even if you save a file as something like "keys.cfg" from your notepad, it will save as keys.cfg.txt, and since you have file extensions hidden, you won't see the difference. I'd suggest enabling the file extension visibility or using a more robust piece of software that doesn't assume a .txt file type.

Hello, I'm really enjoying the book. It's been such a long time since I've used C++ so this has worked nicely as a reminder as well!
Anyways, I got up to chapter 7 until I encountered a problem I just haven't been able to solve. Any help would be appreciated!

The problem is that when the map file is being read and the entityManager's Add is being called with EntityType::Player, it throws an exception at the first find in the function.
Exception is "Exception thrown: read access violation. **this** was 0x50"
I did a lot of googling and even tried directly copying some of the code from the provided files with no success.

Thanks! I look forward to being able to proceed with this project.

Is this happening with the unaltered code that was included? Can you include a snippet of the code that throws this error?

3
Hello,
first of all congratulations for the book, that is really well written.
Reading through chapter 5 I have encountered a problem, while the code works I cannot go past the intro state because the program doesn't recognize the input, and this problem is encountered both in my code and in the sample code and I don't understand why since the code in chapter 4 worked.
I'm using SFML 2.4.2.

Best regards

Michele
I've sent you a PM back. I'll keep this thread updated on the issue and solution once more specifics come into play.

4
General discussions / Re: SFML Game Development by Example - 4th SFML book
« on: November 03, 2017, 07:03:28 am »
First of all, sorry about the late response. I should've tackled this sooner.

You're right, this is something that got overlooked by me during the writing process. Funny thing is, I had that corner case pinned in my notes and I completely "goofed" it when making final alterations before submitting it. My bad on that one.

Setting the type of m_frameCurrent to a regular integer would indeed fix the issue, or you could simply add >= and <= checks in the right half of the lowest if-statement. I haven't tested this yet, but upon first glance after a long time of not looking at this code, it seems like that might be a good way of dealing with the issue as well. Having negative frames was never really intended behavior, so it's important to avoid that as much as possible, since it could produce unexpected bugs later on. The code would then look like this:

void Anim_Directional::FrameStep(){
    ...
    if ((m_frameStart < m_frameEnd && m_frameCurrent >= m_frameEnd) ||
        (m_frameStart > m_frameEnd && m_frameCurrent <= m_frameEnd)){
        if (m_loop){ m_frameCurrent = m_frameStart; return; }
        m_frameCurrent = m_frameEnd;
        Pause();
    }
}
The m_frameCurrent = m_frameEnd; line is still kept, simply to ensure we didn't blow through the intended range somehow. This should allow you to switch back to the 'Frame' typedef for continuity.

5
That would probably have to fall under the issues of optimization, given the type of project you're working with. I would go with switching back to rendering individual tiles into a buffer texture that's the size of the screen to eliminate the need of having a large texture that may not be available on certain platforms. Without any more details I can't provide a better answer.

6
its my second sfml book and have to say thanks for the many stimula though i started to rebuild the examples with smart pointers i'm able to get nearly everything  to run.
I'm happy to hear that! Let me know if you have any problems.

7
Hi _Imperial_,

Sorry I wasn't able to reply sooner, I was actually away for quite a while and was unable to really be of any assistance. Let me know if you have figured out your problem, or if it still persists and I will do my best to aid you in resolving it.

8
Hi _Imperial_,

Sorry about the late response. I've been incredibly busy for the past couple of days. The first problem does seem strange. Are you experiencing any other types of lag? Can you debug your code and spit out some basic information about the update loop while the problem persists, such as the delta time during the update? I'd have to know more details to really draw any useful conclusions.

Second problem might be happening in cases where you don't have your OpenGL context created yet, but you're trying to call a gl function. Make sure the context is actually created beforehand, again, probably by just stepping through code while debugging and making sure. You will want to take a look at the Window::Create method and see if the context has been established. Also make sure that the sf::ContextSettings variable in there actually reflects the GL context your machine supports. By default, I believe, it's v4.5. Try to downgrade it to 3.0 and see if it works. Chances are your graphics card may not support the latest GL versions.

Let me know if it works, and give me some more details on both issues if at all possible. Preferably, the type of exception you're getting, driver versions, glew version, GL version, etc.

9
I vaguely remember testing that just before finalizing, and it not crashing at all. Weird. While it's possible some other small but crucial bit of code got left out as you were building the editor, I'm not sure. Either way, since solidity toggling only applies to selection mode, I'd stick to modifying that branch down the line inside the SolidToggle method:
void GUI_SelectionOptions::SolidToggle(EventDetails* l_details) {
  auto mode = m_mapControls->GetMode();
  ...
  if (mode == ControlMode::Brush) {
    ...
  } else if (mode == ControlMode::Select) {
    ... // Modify/verify the selection range here.
  }
  ...
}
Doing it up top like that completely ignores the fact that brush mode doesn't even deal with selection range. At least modify your check up top to something like this:
if (m_mapControls->GetMode() != ControlMode::Brush && (mode != ControlMode::Select || m_selectRangeX.x == -1)) { return; }
Goes to show how missing something simple like that can result in a crash.

10
OrderNexus, I have some questions.
...
eXpl0it3r is actually right on the money about that. Building in certain values can be useful, but most of your game data will be subject to change, whether through tweaking, updates, or simply adding new content. Serialization separates that part of development from actual code so that:
a) Changing the values at any time is easily maintainable and relatively fast.
b) Tools can be built to speed up that process even more by manipulating an established format. (Editors)

Regarding the ideas I haven't had time to implement, I have a whole list, actually. Let me know in PM if you want me to share that, and I'll send you some stuff. By the way, the diagram is actually really useful! Did you do it by hand, or use some sort of software to generate that? Let me know!

11
The smart thing would probably be re-using the existing system, but it was specifically designed to work with sprite-sheets. Depending on how you actually store the animated tiles, it may not work exactly as you want. Some re-designs might be in order. You could generalize the existing animation class enough to apply to your situation.

12
As Packt was kind enough to give me a 70% Discount code for their developer survey, I picked this up. First look is promising, and if the pain Points of the first book have been reworked I look Forward to the rest.
Glad to hear you picked it up! The pain points have been re-worked, I assure you. Perhaps there might be some new pain points though, so feel free to let me know if you find something like that.

13
Nice job! From looking at it quickly, it seems like it should work as intended.

14
It's a great idea, actually. I had the same thought as well, except I couldn't quite get it to work just the way I wanted. The results you saw already had that technique applied. Chances are if it wasn't crunch time and I had a bit more room to work the magic, I would've perfected it. Thanks though, I appreciate the feedback!

15
Hope you enjoy it. Let me know if you have any questions or concerns!

Pages: [1] 2 3 ... 7