Mark Sibly

Forum Replies Created

Viewing 15 posts - 1,366 through 1,380 (of 1,431 total)
  • Author
    Posts
  • in reply to: Extending classes and Override question #1088

    Mark Sibly
    Keymaster

    Ok, looks like c++ enforces it, but other languages only warn about it:

    http://stackoverflow.com/questions/3404301/whats-wrong-with-overridable-method-calls-in-constructors

    https://msdn.microsoft.com/en-us/library/ms182331.aspx

    I think it’s generally a good rule – if a ctor calls a method that is overridden by a subclass, that method can no longer depend on it’s class fields being properly initialized because it’s ctor hasn’t been executed yet. Or just as bad, the override could be called, but then anything it did gets undone by the ctor being called later, eg:

    http://stackoverflow.com/questions/12100449/java-calling-superclass-constructor-which-calls-overridden-method-which-sets-a

    But I’ll likely end up sticking with what’s most practical/flexible on the translator side of things.

    in reply to: Extending classes and Override question #1085

    Mark Sibly
    Keymaster

    > In most languages the extended version of startup should be called…

    Well, most languages except c++  (and I think Java gives an error).

    A bit more on this here:

    http://www.monkey-x.com/Community/posts.php?topic=10557

    I actually haven’t decided 100% which way I’m going here either.

    in reply to: JSON module getting started #1081

    Mark Sibly
    Keymaster

    Attempt 2…

    in reply to: JSON module getting started #1070

    Mark Sibly
    Keymaster

    Ha! Just got ‘banned’ from my own site for trying to post some code! They’re fixing it now…

    in reply to: JSON module getting started #1068

    Mark Sibly
    Keymaster

    Test…

    in reply to: Cant overload Get in StringMap #1067

    Mark Sibly
    Keymaster

    > In MX1 we could override Map.Get, any reason why you have decided to make it final in MX2?

    Basically because I think it’s a better design. You can read some of the arguments for and against virtual methods vs final methods and why I prefer final unless there’s a good reason to make some virtual here:

    http://www.monkey-x.com/Community/posts.php?topic=10392&page=1

    in reply to: Strange slowness using canvas texture #1064

    Mark Sibly
    Keymaster

    >  But if I actually include gles20.glFinish() the render duration becomes the vSync interval, about 16ms.

    Weird, I don’t get that here – yours must be waiting for the last ‘flip’ to finish whereas mine isn’t. Quite likely a driver thing, but it does mean you can’t reliably measure render time.

    Perhaps try with SwapInterval=0?

    in reply to: Class extensions #1063

    Mark Sibly
    Keymaster

    Full support for extension methods will not be in V1.0, but there is actually limited extern-only extension method support in already. The only drawback is the method needs to be written in native-code, but this is sort of the point – it’s for methods that don’t translate easily from native code to mx2.

    You can use it like this:

    There used to be an example of this in tests/monkey/externs but it appears to have gone…

    in reply to: Strange slowness using canvas texture #1061

    Mark Sibly
    Keymaster

    So, wait, is there a way to not call Flush() when drawing to a texture?

    No, but all rendering needs to be flushed eventually anyway, whether it’s to a canvas or to the render window. Window does a canvas.flush internally, so render to window will be ‘slower’ than you think because you’re not measuring this flush.

    Try this just before calcing _renderDuration:

    This should flush all drawing on the mx2 side, followed by all GL drawing.

    Render to image will probably be a little slower, because there’s the extra ‘blit’ to update the window canvas, but it should be pretty much the same.

    Also, you can probably optimize the blit a bit – get rid of _windowCanvas.Clear and use BlendMode.Opaque.

    in reply to: Cant overload Get in StringMap #1060

    Mark Sibly
    Keymaster

    Map.Get is final and cannot be overriden.

    IMO, best approach is for ScreenBank to have an internal _map field and present it’s own interface, but you could also add a GetScreen method if you really want to extend Map.

    in reply to: Strange slowness using canvas texture #1045

    Mark Sibly
    Keymaster

    Ok, 2 main problems:

    • Use the TextureFlags.Dynamic flag for frequently modified textures. By default, texture contents are ‘backed up’ to system memory (so they can survive a graphics device reset) after texture target changes, but this is not necessary if you’re constantly updating the texture.
    • The ‘render to texture’ code path executes a ‘canvas.flush’ where-as the ‘render to window’ path doesn’t, so it’s not a fair comparison! Flush() will cause all the ‘draw commands’ you’ve submitted to execute as GL code which will still partly execute in parallel but will still have some overhead.

    No idea about the image problem – how did you add the image? Can you see an ‘Add Media’ button? Testing here…

    monkey2-logo-63

    in reply to: Passing a Struct type that's within a class #1038

    Mark Sibly
    Keymaster

    Not 100% sure what you mean here, but the general idea of the iterator ‘Erase’ method is that the iterator already points to the thing you want to erase, so the second RemoveRect doesn’t make sense to me: if ‘i’ doesn’t point to the ‘r’ you want to erase, you’ll need to find it first so ‘i’ is redundant. If ‘i’ does point to the ‘r’ you want to erase, then the ‘r’ is redundant!

     

     


    Mark Sibly
    Keymaster

    > there isn’t a formatting guide for this forum.

    I just use the ‘<>’ button in the visual editor toolbar and paste my code there.


    Mark Sibly
    Keymaster

    Short answer is the compiler shouldn’t be allowing the struct->interface conversions, such as the cast or the F() call with ‘a’. This should cause an error – will fix.

    Although structs can implement interfaces, they don’t really! An interface is a ‘reference type’ and a struct is a ‘value type’ and without some form of boxing (which mx2 does not and probably will not support) there is no way to convert a value type to a reference type. So these conversions should fail.

    I’ve allowed structs to be able to implement interfaces though for the sake of allowing you to specify generic constraints, eg: you can do this for F():

    When a struct implements an interace, it’s a purely static thing. The struct is checked to make sure it implements all interface methods but that’s all that really happens – the struct doesn’t gain a ‘virtual function table’ or anything, and no extra c++ code is generated.

    The built-in primitives already implement some interfaces, eg: Int implements IIntegral which extends INumeric. This allows you to write methods like:

    This is currently a bit ‘loose’ in that INumeric doesn’t actually have any methods so it’s not clearly defined what it even means to be numeric. This means you can declare something that implements INumeric and ‘Add’ could fail to work with it because it expects it to have Operator+ or something. But it works OK for the built-in types.

    I’m waiting until I get some more time to improve this side of things, but what’s really needed I think are generic methods in interfaces and this is a bit tricky! I had a shot and have an idea of the issues involved but decided it was a ‘later’ feature in the end.

    in reply to: Casting and error: Type 'Void' cannot be invoked #1031

    Mark Sibly
    Keymaster

    http://monkey2.monkey-x.com/forums/topic/casting-classes-and-subclasses/

    I really should come up with a better error message though…

     

Viewing 15 posts - 1,366 through 1,380 (of 1,431 total)