ID:2090179
 
Memorial Day weekend is upon us! In the US this is about honoring our fallen veterans, but also it's the unofficial start of summer. (Here in New York state, schools don't actually let out until the end of June, because our school system is stupid. On the other hand, other states send kids back to school in August, which is a hundred times dumber.)

This was a week of transition. I spent Monday doing last-minute bug investigations for 510, in preparation for making 510.1345 the stable release. That went up on Wednesday, and now 510 is officially the new stable version, paving the way to work on 511 with minimal distraction.

Although 510 is now stabilized, I do intend to continue doing maintenance releases on it while working on 511. There are a couple of fixes already in the pipeline, and I won't be ignoring the webclient while all this goes on, either.

So far I'm in a frenzy of adding new features. I mentioned previously that chaining assignment operators, like a=b=c, was implemented, and that's now set to go for 511 except for the documentation. Now I've also implemented pixel_w and SEE_THRU, which need testing, and I showed the Dream Maker map editor some love by adding a long-desired feature to make the nudge operation use pixel offsets instead of step offsets. All of this needs testing and documentation still.

The mutable appearance code has come a long way, although the tying-in part still needs to be done. I'm going to call it /mutappearance, largely because I have no illusions anyone wants to type out /mutable_appearance. (I'm open to other suggestions.)

I'm also forging ahead on the gamepad stuff. I changed my mind about Xinput, and instead I think I'll stick with DirectInput, possibly allowing for Xinput as an alternative down the road. Right now I'm mostly in the tedious part of defining structures and classes for all of this.

Also, early next week I want to work on the var access improvement that SS13 has been wanting for quite a while. This is a potentially important performance upgrade for big games like that, so I'm hoping it'll work out without any nasty surprises.

And while it's not on the list, I did some profiling on Wednesday and discovered that the code that handles the HUD is really horrendous in certain places--in particular, anything that tiles all the way across the map using something like "SOUTHWEST to NORTHEAST". That can potentially add a lot of tiles to the map, which have to be generated (without caching, another problem) and sorted. I want to address that legacy code at some point and give it a serious makeover, but in the meantime developers would be well advised to replace "M to N" screen_locs with a single one and use transform instead, when feasible; you may potentially see big performance gains, especially with high-FPS games.

So it's been a pretty busy week, except for Tuesday.



And now the race to get 511 out to you guys as soon as possible is on.

If you've liked the cascade of new features from 508 onward, please consider showing the fundometer some love with a donation or by becoming a BYOND Member. Since we're going into a holiday weekend, why not now?
/mutappearance

/visdata?

"Visual data".

Also: 200%/400% zoom options for map editor. Plz. 8x8 is painful.
In response to Ter13
Ter13 wrote:
Also: 200%/400% zoom options for map editor. Plz. 8x8 is painful.

Even 16x16 is a pain, squinting my eyes to work in the map editor sucks D:

+++

Yeah, I used to start school very early in August (they later changed it to mid to late August, but still messed up). To put it this way, I used to start like the first to second week of August. :/
In response to Ter13
Ter13 wrote:
Also: 200%/400% zoom options for map editor. Plz. 8x8 is painful.

I'm adding that to my list to make sure I look into it. I can't make any promises, but it is kind of overdue.
In response to Bandock
Bandock wrote:
Yeah, I used to start school very early in August (they later changed it to mid to late August, but still messed up). To put it this way, I used to start like the first to second week of August. :/

Starting the school year before Labor Day is evil, and when I become a supervillain there will be severe penalties for any districts that insist on doing so.
I'm really looking forward to gamepad support. It'll be interesting to see how developers manage their control schemes to include all of the buttons; it'd be weird and quite frankly something I consider a design flaw if some buttons were to do absolutely nothing.

Is there going to be any way to detect what kind of controller a client is using(i.e dualshock)? this would be useful information for presentation purposes like displaying a control layout for a PS4 controller if that's what's being used.
In response to Lummox JR
Lummox JR wrote:
Ter13 wrote:
Also: 200%/400% zoom options for map editor. Plz. 8x8 is painful.

I'm adding that to my list to make sure I look into it. I can't make any promises, but it is kind of overdue.

This alone makes me want to buy a BYOND membership again as soon as I have the money. Don't get me wrong, I love all the new features, and it's not like the zoom is a game breaking urgency but man have I been longing for it for a long time! Seriously thrilled with this mention, even without any promises.
In response to Toddab503
Toddab503 wrote:
Lummox JR wrote:
Ter13 wrote:
Also: 200%/400% zoom options for map editor. Plz. 8x8 is painful.
Has anyone ever suggested collapseable code blocks in Dream Maker? I think that'd be nice for people who have really long procs or a lot of item definitions, etc.
In response to SolarOblivion
SolarOblivion wrote:
Has anyone ever suggested collapseable code blocks in Dream Maker? I think that'd be nice for people who have really long procs or a lot of item definitions, etc.

About nine times, plus someone flew it behind a plane and then it was a special report on the news.
In response to Lummox JR
Lummox JR wrote:
SolarOblivion wrote:
Has anyone ever suggested collapseable code blocks in Dream Maker? I think that'd be nice for people who have really long procs or a lot of item definitions, etc.

About nine times, plus someone flew it behind a plane and then it was a special report on the news.

Can't tell if serious or not.
Lummox JR wrote:
/mutable_appearance

How about "aesthetics"?


And I think code block highlighting would be a nice feature on the code editor.
Like shown here -> http://www.bluej.org/about.htm(l)

And direct short-cuts for creating new Code, Map and Icon files. ctrl+Q, ctrl+W and ctrl+E, respectably.

A change needed would be to take out the current "ctrl+W" short-cut from "Close". Who uses that??
In response to 2DExtremeProductions
2DExtremeProductions wrote:
And direct short-cuts for creating new Code, Map and Icon files. ctrl+Q, ctrl+W and ctrl+E, respectably.

A change needed would be to take out the current "ctrl+W" short-cut from "Close". Who uses that??

Probably the same ones that will use ctrl+Q, ctrl+E, ctrl+W ;)

Well I guess you could call it an appearance builder, that might abbreviate better than mutable appearance and would be similar to other languages that call mutable strings a string builder.
Kozuma3 wrote:
Probably the same ones that will use ctrl+Q, ctrl+E, ctrl+W ;)

"Close" can use another short-cut tho. To increase the usability of the most commonly used actions.

IMO, "Show Tabs" and "Show Line Numbers" shouldn't have short-cuts, people either turn it on or off.

Granted, these are miniscule recommendations,I would rather have code block highlighting infinitely more. =)
Lummox JR wrote:
The mutable appearance code has come a long way, although the tying-in part still needs to be done. I'm going to call it /mutappearance, largely because I have no illusions anyone wants to type out /mutable_appearance. (I'm open to other suggestions.)

I'm in favor of the more verbose naming as opposed to overly-forced abbreviations. Something like "mutappearance" doesn't have much clarity, and therefore could make code harder to understand and increase time to adoption in current and new DM devs. In most modern APIs one is generally confronted with similarly verbose classes, and the train of thought seems to be that verbose class names---though tedious---increase clarity of code.

A few examples: QDesignerCustomWidgetCollectionInterface in Qt, DocumentStructures and ScrollViewer in WPF (as opposed to even, say, "DocStructures" or "ScrollVwr"), and so on. Notably, a decided lack of abbreviations are found in most high-use APIs; the APIs that make excessive use of such abbreviations (ugh C) are often convoluted and hard to understand, learn, and/or use.

Conversely, some abbreviations are more sensible. "Regex" is an industry-wide standard, and anyone in any computer science discipline can easily pick that out; "Mutappearance" only exists in one place: this forum thread. Perhaps another sensible use is in wxWidgets abbreviating AUI. It still contains "UI"---another common shorthand---but without ever having seen it you still have to look it up to understand just what the "AUI" is. However, in this case, the alternative would have been nearly 20 classes like "wxAdvancedUserInterfaceDefaultToolBarArt" == >:'( ...

tl;dr: Favor verbosity and clarity over unnecessary shorthands.
^I agree with Hiead. The reason shortcuts make sense is because DM doesn't have intellisense. The minute that became a standard, languages stopped abbreviating names. We probably shouldn't be adopting dead paradigms.
I had been super hopeful that 511 would be an IDE focused build, however the feature list is far more interesting, so maybe 512 can DM get some love? Please?

PLEASE?

WE'RE LITERALLY DYING OUT HERE.
Page: 1 2 3