SMMU lacks sound

[printz]

When I download SMMU from http://www.soulsphere.org/projects/smmu/ I only get SMMU.EXE and SMMU.WAD. But with only this, sound won't work. What utilities or DLLs does it require for sound? I tried copying the DLLs shipped with Eternity, but no.

I wonder how easy would it be to reimplement some of its features back into Eternity (my build, no meddling), especially of course a modernized FraggleScript (which doesn't need compiling, unlike ACS)

With scripting and hubs it was like ZDoom, but sadly it didn't get enough user base. At least Eternity came in to reclaim it, but discovered that some SMMU features were probably badly written (I believe even fraggle said something like that) so they had to temporarily disable them...

[fraggle]

printz said:

When I download SMMU from http://www.soulsphere.org/projects/smmu/ I only get SMMU.EXE and SMMU.WAD. But with only this, sound won't work. What utilities or DLLs does it require for sound? I tried copying the DLLs shipped with Eternity, but no.

If you mean the Windows version, yes, I don't think it has sound.

I wonder how easy would it be to reimplement some of its features back into Eternity (my build, no meddling), especially of course a modernized FraggleScript (which doesn't need compiling, unlike ACS)

I kind of wish I could write a new FraggleScript interpreter. The code I wrote is horrible, I really had no idea what I was doing. It's very unlikely I'd ever do such a thing, though.

I find it a bit sad that currently Eternity doesn't seem to have a viable scripting language. FraggleScript is gone, and Small (now called "pawn") was supposed to replace it, but as I understand it there were some problems with that.

With scripting and hubs it was like ZDoom, but sadly it didn't get enough user base. At least Eternity came in to reclaim it, but discovered that some SMMU features were probably badly written (I believe even fraggle said something like that) so they had to temporarily disable them...

My opinion is that Eternity has kept all the good stuff (and added more good stuff on top of that). The stuff that's been removed wasn't really worth keeping. I believe the hubs feature was horribly broken, for example. I never got enough users to have found all the bugs. If I had, these things would hopefully have been reported and fixed.

I'd strongly urge against trying to use the SMMU codebase for anything. Quasar has spent the last 10 years fixing my mistakes, and Eternity is the spiritual successor to SMMU. If you feel the need to do something with the SMMU code, just use the Eternity code :)

[printz]

If you say so, then your discarded SMMU source code may be a great learning example on what not to practise.

[fraggle]

I learned a hell of a lot from doing it, but I wouldn't recommend it as an example of best practises.

[Gez]

printz said:

If you say so, then your discarded SMMU source code may be a great learning example on what not to practise.

Like Skulltag is a good learning example on how not to write netcode. :p

[printz]

So the big damn flagship multiplayer port turns out to be full of imperfections? Brilliant, and realistic.

[Graf Zahl]

fraggle said:

If you mean the Windows version, yes, I don't think it has sound.

I kind of wish I could write a new FraggleScript interpreter.

I believe the problem with that would be that due to the issues with the old one it'd create lots and lots of compatibility problems with existing scripts.

Which is the main reason that I didn't touch the actual parser and only cleaned up the higher level things for the GZDoom version.

[andrewj]

fraggle said:

I find it a bit sad that currently Eternity doesn't seem to have a viable scripting language. FraggleScript is gone, and Small (now called "pawn") was supposed to replace it, but as I understand it there were some problems with that.

Pawn was probably too simplistic (a single type, int, and no structures or classes, all it had was arrays iirc).

Last I heard Quasar was going to use Aeon.

[Gez]

andrewj said:

Pawn was probably too simplistic (a single type, int, and no structures or classes, all it had was arrays iirc).

May as well just use ACS then... Same limitations but without the worry about bitcode incompatibilities on 64-bit architecture, and with a good reason to implement it in the first place (Hexen support).

[printz]

Gez said:

May as well just use ACS then...

Yeah but innovation is a good thing, especially when working for free.

[_bruce_]

Hey - love the r_ripple magic!

[wesleyjohnson]

DoomLegacy still has fragglescript and I am trying to make it safer.
It has been massaged a few times and it does not give much trouble now.
It would be interesting to know exactly what you did wrong that would need changing (besides language interface which for compatibility reasons I would not change right now).
You make me wonder what hidden faults are in there.

[Graf Zahl]

wesleyjohnson said:

It would be interesting to know exactly what you did wrong that would need changing (besides language interface which for compatibility reasons I would not change right now).

The blunt answer would be 'everything' (and I think Fraggle agrees with this, judging from his remarks)

I mean the code clearly shows skill but it has 'beginner' written all over it.

The way the parser works is just weird and it does a lot of unnecessary work to analyze the code.

The expression evaluator doesn't really do what you would expect from a mathematically correct implementation. It works ok for simple expressions but there's a reason why such code is often littered with parentheses in scripts.

And let's not forget the overreliance on global variable to manage state and passing parameters.

wesleyjohnson said:

You make me wonder what hidden faults are in there.

Just spend a month analyzing it and you'll know. ;)
It took that much time to understand its inner workings and getting rid of the most serious problems for the GZDoom implementation.

[Gez]

And there are still some potentially serious ones that remain. See ModifyHUPic, ObjState, and PlayerSelectedWeapon are the worst offenders IIRC.

[Graf Zahl]

Don't even start with badly designed functions.

You know yourself why those won't be dropped. There's still maps using them so we are stuck with the problems they might cause.

Especially the ones closely tied to how data was organized in Doom.exe caused most problems in GZDoom and the current implementations are often hacks to replicate that. Can't do much about it.

[printz]

Looks like port maintaining is no easy work. Especially if you're not so experienced (like me) and over-enthusiastic.

[fraggle]

Graf Zahl said:

The blunt answer would be 'everything' (and I think Fraggle agrees with this, judging from his remarks)

I mean the code clearly shows skill but it has 'beginner' written all over it.

Yep. You've basically hit the nail on the head there.

I wrote FraggleScript when I was 17, and I had never studied or read about compiler design whatsoever. About the only thing I knew was the concept of tokenising, probably from knowing about the strtok() function in the C standard library. The actual algorithms for parsing and evaluating expressions were all of my own design, and although they mostly work, they're pretty much "how not to design a parser".

[printz]

fraggle said:

strtok()

Nice, I didn't know that existed already. I thought I had to do parsing manually...

[Quasar]

printz said:

Nice, I didn't know that existed already. I thought I had to do parsing manually...

strtok is useful for very little. It can be abused to do more than it ought, and the result will be unmaintainable code in my experience.

[Graf Zahl]

strtok is useful.

What it's not useful for is a decent parser though.

[printz]

How about keeping FraggleScript (with a bugfixed but not semantically fixed parser) in order to still run Legacy or SMMU/old Eternity maps, but derive a new "CraggleScript" that is similar, but more robust, scalable and mathematically correct? Of course, this isn't quite needed in GZDoom, but in other ports that would use FraggleScript code as base.

Can I look through the GZDoom FraggleScript parser code and take algorithms from it? Under what licence is it written? Is it compatible with GPLv2?

[Graf Zahl]

printz said:

Can I look through the GZDoom FraggleScript parser code and take algorithms from it? Under what licence is it written? Is it compatible with GPLv2?

It's GPLv2 with an exception that allows linking with GZDoom. However, it makes heavy use of C++ and some of ZDoom's internal classes so it won't be of much use to other ports that are still C and use the original way to define their data.

[printz]

Eternity is C++. I'm currently editing something based on Eternity. See below, second and third links. I'm not a professional (or even undergraduate) programmer so I may make some inefficiencies in the code, so forgive me in advance :) I usually try to fix them

[Graf Zahl]

As I said, it makes heavy use of ZDoom's class hierarchy, in particular the garbage collector, so that the notorious memory leaks of the FS code can be dealt with in some way at least.

Eternity doesn't have this stuff so you'd have to make changes to compensate for that.

[RestlessRodent]

For ReMooD I plan on building a micro-byte code compile for Legacy Scripts (Fragglescripts) while extending it to support new features (for ReMooD Script). The language itself is pretty basic but it has multiple drawbacks:

* Non C-like order of operations, there's really no good order. It does not even match PEMDAS.
* Some functions are terrible and weren't implemented good enough.
* The dot operator for "object-oriented feeling" was not a good idea, it just moves the first argument to the first parameter, it does not access an object.
* Direct execution of console commands (security risk).
* Text parsing is virtually everywhere in the code and there is no single spot for tokenization.

And problems from Doom Legacy:

* Half the stuff was not implemented. (like hubs, arrays, etc.)

I plan on changing a few things in ReMooD:

* Add new and improved exfunctions which would be more concise.
* Add real object mappings (such as thing:life = 14)
* Add real non-script functions.
* Compile to byte code before playing a level.

It will be awhile before I get around to it though.

[fraggle]

GhostlyDeath said:

* Non C-like order of operations, there's really no good order. It does not even match PEMDAS.

I don't disagree with your other points, but I'm pretty sure this at least isn't true. If you look at t_oper.c there's a list of operators that defines the precedence order. This matches C's operator precedence (table on that page is ordered the other way round). Parentheses are handled separately but work as you'd expect.

[Graf Zahl]

Sorry, to contradict you, but I have to agree with GhostlyDeath. The operator precedence is rather shaky. It tries to get it right in some points but as a whole, no, it doesn't work as it should.

I noticed this myself some time ago as well, but decided not to fix it because it might break existing scripts.

[printz]

How do you people program algebraic expression parsers? Do you create a data structure (tree) out of the expression, with the node depth a function of operator precedence?

[Graf Zahl]

Either using a formal grammar or recursively.
The parsing function for each operator would call the parsing function for the next highest operator to get its operands. Check out ZDoom's thingdef.exp for the DECORATE expression parser. That's pretty much the most straightforward way to implement it.

[fraggle]

Graf Zahl said:

Sorry, to contradict you, but I have to agree with GhostlyDeath. The operator precedence is rather shaky. It tries to get it right in some points but as a whole, no, it doesn't work as it should.

Interesting. I'd be intrigued to see an example script that demonstrates this if you have one.