quirks, requests, questions and answers

[Simon ArmstrongParticipant]

i asked in the interwebs and got this:

http://stackoverflow.com/questions/18544881/sdl-2-0-retina-mac

so maybe try changing modules/mojo/app/window.monkey2[335]

Local sdlFlags:SDL_WindowFlags=SDL_WINDOW_OPENGL |
SDL_WINDOW_ALLOW_HIGHDPI

[taumelSpectator]

Nope, didn’t work. I’ll take a break until full retina support shows up. Thanks for your help.

[taumelSpectator]

Some of the things i faced when using monkey2-1.1.01 (OS X 10.11.6) more recently:

a) ted2 (the real one) crashes from time to time, dunno why. Fix: restart.
b) ted2 sometimes also crashes when it thinks there are file issues. Fix: restart.
c) After returning from fullscreen, ted2’s content window is messed up (with gfx mem dumps). Fix: drag the window out of screen and then back.
d) There is no Redo. Undo only works till a certain depth. Fix: Either don’t use it or copy&paste to Sublime, do your stuff there and copy&paste back into ted2.
e) ted2/monkey2 don’t handle low and retina resolutions properly. ted2 doesn’t select the right icons. monkey2 can’t release non-/retina content. Not saving images with the appropriate dpi settings. …
f) Using multiple of sdl2’s channel options like pan and rate can crash monkey2 content.
g) Going fullscreen the usual way, only works from 1280×800 on. Lower resolutions like 1024×640 or 720×450 are wrongly placed and/or show screwed up content.
h) ted2 shows you with red lines where there are bugs. But when you’re fixing them, the red lines remain. It’s hard to read code on these lines. Sometimes the explanations for what’s wrong could be more helpful.
i) 2 finger pinch only scrolls the vertical text scroll bar, not the horizontal one.
j) It would be nice to see syntax highlighting in the prefs/documented, so that you can easily define what you would like to be highlighted and define the colours.
k) It would speed things up if you could mark code at a given position and then split the code window into two windows (horizontal/vertical) so that you’re able to scroll and edit in both but at different positions. Closing a window by icon and shortcut.
l) Marking text in the source sometimes helps, sometimes it doesn’t. Sparse info below (which you can’t copy & paste into the code), some info on the right. In the end you scroll through a huge commands’ list on a tiny part of the window on the right but often without meaningful relationships -> which can be inefficient.
m) In the docs, chipmunk could be structured in a more reasonable way (without this you only get chipmunk’s alphabetised commands’ list) and offer a little bit more info, like, #cpDampedSpring’ a.o. wants ‘stiffness’ to be defined and it’s a ‘float’ but how about its range? Just like with pan for channels.

Generally:
1) Ideally a command is part of the documentation. Firing up by search or fn+F1 (the shortcut should be definable in the prefs).
2) You can switch through similar ones, show the classes they’re embedded in, like it’s already implemented. When there is some meat, it works quite good.
3) Once you choose a command, you get a description for it, how the parameters can be defined, etc.
4) Ideally there would be one example (or more than one if the command can be used in very different ways) showing a simple usage of the command.
5) There would be a history allowing you to jump forth and back.
6) There also would be links which show you where you are and where you could go within the house which is the docu. Like looking up a spring could bring you to other constraints/a level up/general physics/showing the other modules on the same level and so on. Making the docs a surf&enjoy-able experience and so getting a better understanding of what exists and how it works together.

n) Ogs aren’t replayed properly. The rate is too low. If you increase the rate, then the data gets cut (problems occur with stereo, mono seems to be fine). No flac support.
o) … out of time.

[Author]

Posts