Development news: behind the scenes

Page: 1 2
ID:1986168
 
Nov 20 2015, 3:22 pm
Astute users will note there has not been a new 509 release this week. That's because I've spent most of my time working on stuff that I think will be integral to 510. 509 is very near a stable release, and my goal--pending the resolution of one webclient bug that appears to be a pretty nasty one--is to get the stable 509 out by early next week, before Thanksgiving.

One of the things I've been working on is the command parser for the webclient. When the project was first written--this was for when it was the Flash client--the goal was for the server to do everything. Over time in the webclient it became clear that this was not viable, but the server still does parsing. I'd ideally like for the parser to be moved client-side to be more in line with Dream Seeker, but mainly I'm doing this because there's a verb availability issue (namely, that verbs that aren't truly available appear in the verb panel) whose solution overlaps with a lot of that same code. With all the webclient is doing client-side now, it made sense to just translate that code en masse. But this will not be done in time to make the next 509, so it will go into 510.

Another of my pet projects has been the regex lib modification, taking a really old and outdated lib and adding features that I think are required for a minimal regex engine. This lib supported some things, but not case-insensitive matching, multiline matches, character class aliases like \d, {n,m} repeat specifiers, nongreedy matching, and word breaks. The foundation the lib provided was enough to get me started, so I've been busily tacking all this stuff on. I really, really want regular expressions in 510.

Other irons I've mentioned previously are still in the fire. Things are progressing, but right now they're all mostly under the hood.

Thanksgiving is coming up! Make the most the holiday and throw some time into developing your games, or checking out other people's awesome projects. Get inspired, and get coding.

Now I present you with a recipe I'll be making this Thanksgiving, for my wife who's eating low-carb.

Cauliflower faux-tatoes
  • Microwave-safe cooking dish (mostly covered)
  • Food processor
  • 1 lb. frozen cauliflower florets
  • 1 cup heavy cream, divided
  • 1 stick butter
  • 1/4 tsp. guar gum (optional thickener)
  • Salt and/or pepper (to taste)
Microwave cauliflower in dish, covered but with a few holes (I use the Pampered Chef Micro-Cooker), for several minutes until partially thawed, then add 1/2 cup cream. Continue to microwave until cauliflower starts to become tender, then dump out old cream and replace with remaining cream. Microwave until extremely tender. Add cauliflower, with cream, to food processor. Add the thickening agent and the butter. Process until mostly smooth. Add salt and/or pepper to taste and finish processing smooth. Makes about 3 cups.

Thanksgiving morning I'll be live-blogging the Macy's parade over on my blog. Why do I do it? Mostly to amuse myself, but hey, maybe it'll amuse you too. I'll be complaining about the obligatory country music acts, cheering on Snoopy, and hopefully eating a pumpkin muffin.

The next edition of development news will come Wednesday.
Nov 20 2015, 3:29 pm
Doity meat eater

):
Nov 20 2015, 8:57 pm
Yassss :3
Nov 21 2015, 1:27 am
Yess
Nov 22 2015, 1:49 pm
I take offense to you cooking fake potatoes.
Anyway, why are you using such an out of date and possibly dangerous regex library instead of using a modern one?
Nov 22 2015, 2:07 pm
The modern choices are all near-impossible to integrate easily.
Nov 22 2015, 3:53 pm
In response to Lummox JR
Lummox JR wrote:
The modern choices are all near-impossible to integrate easily.

Any news on that update?

Nov 22 2015, 4:42 pm
In response to Kozuma3
Kozuma3 wrote:

Nov 23 2015, 1:42 am
In response to Lummox JR
Lummox JR wrote:
The modern choices are all near-impossible to integrate easily.

All except the STD lib/MAAAYBE boost.
C++ libraries are for some reason pushing asynchronicity extremely hard and its pretty obnoxious to have to nodify c++, so I can see where you're coming with since byond is using an old VC++
Nov 23 2015, 3:36 am (Edited on Nov 23 2015, 3:49 am)
In response to Somepotato
Somepotato wrote:
Lummox JR wrote:
The modern choices are all near-impossible to integrate easily.

All except the STD lib/MAAAYBE boost.
C++ libraries are for some reason pushing asynchronicity extremely hard and its pretty obnoxious to have to nodify c++, so I can see where you're coming with since byond is using an old VC++

Wasn't BYOND Updated to VS2012/VS2013 with BYOND 504/506 last year?

EDIT: Just checked, it was updated to VS2013 with many builds made in it with 506 and it becoming the official stable release with 507.
Nov 23 2015, 1:00 pm
I thought it was updated to like 2010, never bothered checking. In that case there is really no excuse not to use stdlib
Nov 23 2015, 1:29 pm
We did switch to VS2013 for builds last year. Two caveats: I still do occasionally build and test (not for release) on VC6, and because BYOND was written before STL we've never used it.

When the host ban code for Dream Daemon was first implemented, I actually started out using STL, but Tom made the good point that because none of the other code used it, we were basically adding another unnecessary layer of complication into the code and yet another library. Eventually it'd probably make sense to reintroduce STL in a more concerted way, but basically BYOND doesn't use it for historical reasons.

I'm not saying STL wouldn't be a good idea at some point, but "no excuse" is far from the truth. In a legacy project, there are often good reasons for not overhauling to include a more modern library.
Nov 23 2015, 2:28 pm
Using the STL is not adding another library, its using the standard library that your code links to regardless of whether or not you use it unless you specifically don't link the default libraries.
Modernizing an old project has to start somewhere and its silly to limit yourself because there's no explicit reason not to use it especially since you're using VS13
Nov 23 2015, 3:34 pm
In response to Somepotato
Somepotato wrote:
Using the STL is not adding another library, its using the standard library that your code links to regardless of whether or not you use it unless you specifically don't link the default libraries.

It's adding another library as far as the type of code used internally is concerned. Already in the project I've cleaned up a number of cases where we did the same thing multiple places by multiple different methods. That was the sort of thing that concerned Tom about starting to use STL, as it would make project maintenance all the more complicated. For instance we already have code for collections, strings, etc. None of it is likely as good as STL, but having one part of the code use STL and all the rest not was deemed, at the time, a bad idea. I agreed with his decision then.

I think it would make sense eventually to start transitioning a lot of stuff to STL, if only because STL has a number of advantages like fast internal sort routines, etc. But it's the kind of thing I'd want to do in big chunks, not just in one place at a time.

Modernizing an old project has to start somewhere and its silly to limit yourself because there's no explicit reason not to use it especially since you're using VS13

But as I mentioned, I'm also using VC6 some of the time--just not for release builds. So even if I start transitioning to STL, its regex remains out of the question.
Nov 24 2015, 12:30 pm
Of note, STL implementations are often -garbage-. Things like random number generation you should never use STL with especially in the case of games because the implementations are just terrible and inconsistent. Stuff like lists/vectors and strings it makes more sense to use the STL with. BYOND is rather abstract in code and I really like that about it-- it shouldn't be that hard to use STL for some higher level things.
--
I just don't think its wise to use an old regex library is the primary concern. Lack of features, potential security issues, and low speed are all concerns with it.
Nov 24 2015, 1:07 pm (Edited on Nov 24 2015, 1:39 pm)
In response to Somepotato
Had to retype this because I accidentally clicked BYOND's cancel button. -.-

Somepotato wrote:
Of note, STL implementations are often -garbage-.

Excuse me? The STL is a standard that compilers adopt and implement, and popular compilers like GCC and Visual Studio have been extensively tested for efficiency. Sometimes they're optimized in a way by the compiler that can't be done regularly. One example being exception pointers, although not part of the STL.

Things like random number generation you should never use STL with especially in the case of games because the implementations are just terrible and inconsistent.

You don't know what you're talking about, so stop trying to pretend like you do. Each RNG is situational and has its strengths/weaknesses. If it's terrible, you're using it wrong.

Stuff like lists/vectors and strings it makes more sense to use the STL with.

...

BYOND is rather abstract in code and I really like that about it-- it shouldn't be that hard to use STL for some higher level things.

I dislike that about BYOND. I think it should abandon its outdated backend for the convenience and standards modern day offers. We'll see a performance increase, if done correctly, and we'll see a reduction in file size since the standard library is often dynamically linked.

I just don't think its wise to use an old regex library is the primary concern. Lack of features, potential security issues, and low speed are all concerns with it.

Ideally, the stable release should never be outdated. In the case of backwards compatibility, I'd prefer separate builds.
Nov 24 2015, 1:29 pm
In fairness I'm the one who said the regex library I'm looking at was outdated. Which it is; it's very old and apparently descends from code used by some of the earliest regex implementations.

I have serious doubts there are security concerns involved, though. Low speed might be a question mark; it should be pretty fast I would think, and far faster than my soft-coded library.
Nov 24 2015, 4:51 pm
In response to GatewayRa
GatewayRa wrote:
Had to retype this because I accidentally clicked BYOND's cancel button. -.-

Somepotato wrote:
Of note, STL implementations are often -garbage-.

Excuse me? The STL is a standard that compilers adopt and implement, and popular compilers like GCC and Visual Studio have been extensively tested for efficiency. Sometimes they're optimized in a way by the compiler that can't be done regularly. One example being exception pointers, although not part of the STL.

Standards compliant doesn't mean that its a good implementation. The standard is often vague.

Things like random number generation you should never use STL with especially in the case of games because the implementations are just terrible and inconsistent.

You don't know what you're talking about, so stop trying to pretend like you do. Each RNG is situational and has its strengths/weaknesses. If it's terrible, you're using it wrong.

What? Every STL implementation of RNG is different. That is bad, you want uniformity in games that can work across multiple platforms.

Stuff like lists/vectors and strings it makes more sense to use the STL with.

...

You can't say I'm wrong here. Here it makes more sense to use STL because they can use the operating system facilities to optimize things further.


BYOND is rather abstract in code and I really like that about it-- it shouldn't be that hard to use STL for some higher level things.

I dislike that about BYOND. I think it should abandon its outdated backend for the convenience and standards modern day offers. We'll see a performance increase, if done correctly, and we'll see a reduction in file size since the standard library is often dynamically linked.

Thats not what I mean-- the fact its abstracted well into classes means it can be updated without much issue.

I just don't think its wise to use an old regex library is the primary concern. Lack of features, potential security issues, and low speed are all concerns with it.

Ideally, the stable release should never be outdated. In the case of backwards compatibility, I'd prefer separate builds.

He specifically stated he was using an old regex library. But it will DEFINITELY be faster than the softcoded library (so in reality speed will likely not be much of a concern unless its just terrible). The security concerns are rather minuscule but for example if you look at the recent libpng overrun it shows that old libraries are still at prone to exploitation(fortunately libpng is still updated often)

Nov 24 2015, 5:28 pm
on a compeletely unrelated note there is this https://github.com/optimumtact/byond-regex as a wrapper over boost::regex if other codebases are interested in it.

It's LGPL code
Nov 24 2015, 5:34 pm
In response to Optimumtact
Optimumtact wrote:
on a compeletely unrelated note there is this https://github.com/optimumtact/byond-regex as a wrapper over boost::regex if other codebases are interested in it.

It's LGPL code

you should add the windows compiled dll as well as the linux compiled so
Page: 1 2