Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Access violation on drawing a sprite.  (Read 6065 times)

0 Members and 1 Guest are viewing this topic.

Jewel

  • Newbie
  • *
  • Posts: 3
    • View Profile
Access violation on drawing a sprite.
« on: June 28, 2014, 02:34:22 pm »
Edit: Ahahaha. It seems a thread was posted just before on the same issue; that I missed. Why is the old extlibs being redistributed though? This seems like it should have been fixed almost instantly.

I assume this is a different issue than the other access violation thread currently running. Even though it's the same error I think it's a different scenario.

I've never built SFML.Net from source before so I don't know if it's my changes or the way I compiled/referenced the libraries in my project that caused the issue.

I was working with a (very small, very barebones; only one sprite drawn) test project that used SFML.Net 2.1. I wanted to add a ton of useful methods to the various Vector classes because they're absolutely garbage (I know you don't want to add anything that's not in SFML but c'mon, they're nearly unusable for anything in their current state) so I grabbed the source from the github. I noticed things were switched around a bit since 2.1 (such as Vector being in the new SFML.System namespace), but I didn't notice any major differences.

I add my new bunch of methods to the Vector2f class (only this one at first, I wanted to check if it was working) and only touched that class, and then I went to build. I had to get Tao, and I referenced only Tao.FreeGlut,Tao.OpenGl.dll, and Tao.OpenGl.Glu.dll which were the only three references in the project that visual studio shown existed (well, it showed they existed previously and couldn't be found).

Everything compiled fine, so I renamed my old SFML library folder and put the new one in it's place (this could be the cause in some way but I haven't worked out anything wrong here; mentioned it just in case though), then i went to my C# project I was working on and removed the SFML.Net references and added in the new DLL's (definitely sure I added the new ones), and deleted the extlibs and re-added all the new ones from the github (once again, sure I added the new ones).

Finally; time for the actual error! I cut down my entire code to this:

static void Main()
{
    // Create the main window
    RenderWindow window = CreateWindow("Test", 1280, 720);

    Color clearColor = new Color(130, 140, 150);

    Texture testTexture = new Texture("Resources/image.png");
    Sprite testSprite = new Sprite(testTexture);

    // Start the game loop
    while (window.IsOpen)
    {
        // Process events
        window.DispatchEvents();

        //Draw game
        window.Clear(clearColor);

        window.Draw(testSprite);

        // Update the window
        window.Display();
    }
}

The line that causes the exception is "window.Draw(testSprite);"

The exception info is:

Quote
System.AccessViolationException was unhandled
  HResult=-2147467261
  Message=Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
  Source=sfmlnet-graphics-2
  StackTrace:
       at SFML.Graphics.Sprite.sfRenderWindow_drawSprite(IntPtr CPointer, IntPtr Sprite, MarshalData& states)
       at SFML.Graphics.Sprite.Draw(RenderTarget target, RenderStates states) in d:\Libraries\SFML.Net-2.1\src\Graphics\Sprite.cs:line 171
       at SFML.Graphics.RenderWindow.Draw(Drawable drawable, RenderStates states) in d:\Libraries\SFML.Net-2.1\src\Graphics\RenderWindow.cs:line 472
       at SFML.Graphics.RenderWindow.Draw(Drawable drawable) in d:\Libraries\SFML.Net-2.1\src\Graphics\RenderWindow.cs:line 460
       at LidgrenNetworkTest.Application.Main() in D:\Projects\LidgrenNetworkTest\LidgrenNetworkTest\Source\Application.cs:line 46
       at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()
  InnerException:

And a maybe-clearer image of the exception:



What's going wrong here? I assume something to do with the C++ texture not being initialised and I have no idea why. If I comment out the sprite draw line the window displays fine with a cleared color. Have I just done something really dumb without noticing? Thanks in advance.
« Last Edit: June 28, 2014, 02:36:11 pm by Jewel »

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: Access violation on drawing a sprite.
« Reply #1 on: June 28, 2014, 02:43:47 pm »
Quote
This seems like it should have been fixed almost instantly.
All bugs deserve to be fixed instantly. Unfortunately, we live in a world where developers also have a life ;)

So I'm sorry for the trouble, but you need to recompile the whole chain yourself if you want to use the latest SFML.Net.
Laurent Gomila - SFML developer

Jewel

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Access violation on drawing a sprite.
« Reply #2 on: June 28, 2014, 03:31:47 pm »
This isn't a bug. This isn't something you have to scour through code to find the answer for. This is forgetting to upload the latest file in a repo and completely breaking it. Either don't have the extlibs there at all or just take the two seconds to check in your working files. No matter what you do; you have a technically broken repo right now, and nothing you do could make that worse, so even if your current files were wrong too, nothing changes. It would take not even ten seconds to check them in.

This is along the lines of creating two new classes that rely on eachother and only checking in one. You never have an "Oh! I'm busy!" reaction to something that's completely just misuse of source control and nothing to do with bugs in the code.

I'm just frustrated because I've spent a few hours out of my life because someone forgot to; and continues to refuse to check in updated files, leaving their master branch completely broken, which is.. kind of shameful, I'unno. Master should always be working. Not to say it can't have bugs, but when it's completely unusable that's where it gets to "C'mon" territory.

I'm on windows, where Visual Studio is buggy enough that "Installing Visual Studio 2012" is enough to break 2010's compiling without disabling incremental building, so even trying to compile SFML with cmake is enough of an arduous task that it's taken over an hour to try and get it to work and it's still not working. Now I've pretty much wasted all the time I've had and I can't continue working on anything until someone checks in the files.

Jewel

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Access violation on drawing a sprite.
« Reply #3 on: June 28, 2014, 03:39:56 pm »
Sorry for gettin' mad at you. Just taking out frustration I guess. Building other peoples' libraries and consistently failing with cryptic errors is just not what I wanted to spend my day on.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: Access violation on drawing a sprite.
« Reply #4 on: June 28, 2014, 04:30:04 pm »
If I had the files of course I would push them. But I don't. Because SFML, thanks to its new team, has received many improvements lately, and CSFML / SFML.Net are not up to date because some people prefer complaining on the forums than trying to help.

It's true that SFML.Net/extlibs should be in sync with the source code. If they don't, then it's probably because of an external pull request that was merged without me noticing it would break it. So what I suggest is that you use your precious time to find the revision which breaks rendering, create an issue on the tracker, and then the developers may start working on fixing it -- even if it's just a workaround until all bindings are properly updated.

And don't be mad because the HEAD revision is not working. It's something that happens all the time. Use stable releases if you want stability.
Laurent Gomila - SFML developer

zsbzsb

  • Hero Member
  • *****
  • Posts: 1409
  • Active Maintainer of CSFML/SFML.NET
    • View Profile
    • My little corner...
    • Email
Re: Access violation on drawing a sprite.
« Reply #5 on: June 29, 2014, 07:35:25 pm »
Well since I was the one who made the changes so SFML.NET works with the latest master, I will be making a PR that updates the /extlibs folder here shortly. I did not realize that there was an extlibs folder that needed updating.  :)

Thank you for bringing it to my attention.
« Last Edit: June 29, 2014, 07:37:48 pm by zsbzsb »
Motion / MotionNET - Complete video / audio playback for SFML / SFML.NET

NetEXT - An SFML.NET Extension Library based on Thor