Messages

1

DotNet / Re: c# Sfml 2.0 GUI

« on: March 20, 2013, 06:17:45 pm »

I've updated Gwen.Net's SFML renderer to work with latest SFML.Net version from github (minor SFML API changes).

2

DotNet / Re: [Solved] Any recent (possibly) breaking changes?

« on: June 29, 2012, 10:31:08 am »

Well, I didn't have the variable initialized at all (no "new m_RenderState") and was just assigning textures to it. Weird that the compiler didn't complain, I guess it's a struct but still. Structs are bitwise zeroed at the start if not explicitly constructed, so that's probably why. You may add a default constructor that sets the blend mode to avoid such bugs I guess.

3

DotNet / [Solved] Any recent (possibly) breaking changes?

« on: June 24, 2012, 01:02:12 pm »

I was quite busy lately and didn't have time to touch GWEN.Net code but it seems some recent SFML change broke my rendering completely. SFML 2 rc version from May 9th was working fine, now all my textures appear black. I didn't have time to investigate in depth yet, but textures are loaded fine and appear to be of correct sizes. Maybe some change in the .NET wrapper?

I'm using single texture for the controls skin. When drawing a rectangle I add it to the cache and then flush it with
m_Target.Draw(m_VertexCache, 0, m_CacheSize, PrimitiveType.Quads, m_RenderState);

I'll debug it more thoroughly tomorrow but maybe someone has hints what might be the cause.

Edit: I see there was a change to Transform (class->struct). I'm not using it directly anywhere though.

Edit: Problem solved: I didn't have properly initialized RenderState's blend mode. It somehow worked before but stopped now

[attachment deleted by admin]

4

DotNet / Re: RenderTarget.Draw(Vertex[]) missing size parameter

« on: May 09, 2012, 09:08:05 pm »

Awesome - it seems to work fine and I see visible FPS gain in my GWEN.Net renderer

5

DotNet / Re: RenderTarget.Draw(Vertex[]) missing size parameter

« on: May 09, 2012, 10:48:08 am »

Whoops, I search a bit but stopped at 2 months in the past. Thanks.

6

DotNet / Re: Image.createMaskFromColor

« on: May 09, 2012, 10:46:09 am »

Yeah, you need to lock bitmap bits and work on that to perform with any reasonable speed.

7

DotNet / RenderTarget.Draw(Vertex[]) missing size parameter

« on: May 09, 2012, 10:41:42 am »

Why the above method omits the size parameter? In most cases you have one big array for vertex cache, its size don't usually change, but number of actual vertices does. Right now you need to reallocate the array every time the call is made and that puts a lot of strain on the GC.

8

DotNet / A few design questions

« on: March 02, 2012, 09:41:52 pm »

As for event naming see http://msdn.microsoft.com/en-us/library/ms229012.aspx

Names of Events

Do name events with a verb or a verb phrase.

Do give event names a concept of before and after, using the present and past tense. For example, a close event that is raised before a window is closed would be called Closing and one that is raised after the window is closed would be called Closed.

Do not use Before or After prefixes or suffixes to indicate pre and post events.

Do name event handlers (delegates used as types of events) with the EventHandler suffix.

Do use two parameters named sender and e in event handler signatures.

The sender parameter should be of type Object, and the e parameter should be an instance of or inherit from EventArgs.

Do name event argument classes with the EventArgs suffix.

This convention is used in the BCL.

9

DotNet / Scripting with C#/Mono...in C#/Mono

« on: March 02, 2012, 09:50:31 am »

C# isn't interpreted language. You can easily compile code in runtime without any external compilers, just use System.CodeDom.Compiler:
http://msdn.microsoft.com/en-us/library/system.codedom.compiler.aspx
http://stackoverflow.com/questions/826398/is-it-possible-to-dynamically-compile-and-execute-c-sharp-code-fragments

10

DotNet / Scripting with C#/Mono...in C#/Mono

« on: March 01, 2012, 11:04:19 pm »

One way is to use runtime compilation to compile your script into an assembly and then load it.

11

DotNet / SFML.Net GUI?

« on: March 01, 2012, 09:37:47 am »

there is gwen.net

Yeah, I intend to update it for the latest SFML API ASAP.

12

DotNet / .net clock

« on: January 06, 2012, 01:24:06 pm »

Stopwatch is the most precise timer, it's the equivalent of QueryPerformanceCounter Windows API. Check Stopwatch.Frequency property to see how often it updates.

http://msdn.microsoft.com/en-us/library/system.diagnostics.stopwatch.aspx

13

DotNet / Performance questions

« on: November 14, 2011, 10:09:11 am »

Creating many objects every frame is a bad idea. Not because of SFML internals, but because .NET's garbage collector will need to collect them very often. Hence your performance drops.

14

General / How do I bring an SFML game out on the Internet?

« on: October 23, 2011, 12:34:56 am »

All the cloud buzzwords are so irritating. Desktops will never be completely replaced, no sane person would store sensitive personal data on some server outside their power. Same goes for corporations with trade secrets, financial data etc. But that's getting offtopic.

15

DotNet / Suggestion: Show warning when resource is not disposed

« on: October 12, 2011, 10:24:27 am »

But not disposing a resource is not an error, so why should it deserve a warning?

So why have Dispose in the first place? Like you said, it's not an error, but a warning.
It's like saying "You don't need to bother with deleting objects in C++, OS will release all memory when the program terminates anyway!" GC is not meant to manage resources, but memory.
If your SFML objects contain unmanaged resources like OS handles etc, not disposing them will cause handle leaks. Of course you can rely on finalizers, but every finalization will cause object to be promoted to the next generation of managed heap, which means GC will have more work to do than if you disposed the object.