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

Pages: [1]
1
DotNet / Re: Access violation on drawing a sprite.
« 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.

2
DotNet / Re: Access violation on drawing a sprite.
« 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.

3
DotNet / 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.

Pages: [1]
anything