Julian

I made this video a long time ago with old screenshots of the project. There's some stunning hell stuff in the end.

Very nice midi collection.

It's post like this that makes me proud of this community.

Anyway, I too thought of the problem like Graf Zahl did and I'm afraid a language will not be enough.

You'd need an OS that actually acts as the intermediate to assembly code translater of today's compilers. All apps on this OS would have to be written in a very high-level language with a degree of abstraction much more important than what we have today (don't ask me in which form, I have no clue, but probably exhibiting properties similar to Haskel) and an equally high-level standard library.

The idea is that the more high-level your program concerns are, the more opportunities for optimizations there is (somehow counter-intuitive but I think we, coders, tend to confuse having control and writing efficient code).

Oh well, anyway, just wanted to contribute to this fine discussion :)

Ragnor said:

I do see the humour in a mod sneakily changing your title though.

Yeah, I see you do ;)

So glad to hear it's going that well, Q :)

Gratz are in order.

17 years?!? Man, time flies.

Graf Zahl said:

Hardcore OOP purist code is probably the only thing that's worse than badly structured C. All that 'clean' encapsulation can easily end up more Spaghetti than gotos if you have to click through 10 or more getter functions to find out what it does. Been there, done that, no fun at all.

Yep. I find that the only way to judge code is from a maintenance point of you. Over-architectured OOP is no better than the hackaton mess the Doom code ended up to be.

Q, we had this conversation a looooong time ago. I still think converting the code progressively to C++ is the way to go. Start with the parts which you know will cause problems with the new C standard then continue on.

I never understood the idea that the Doom source code needed to stay in C and that pseudo-OO was a necessity. It's not. I'm always amazed to see how deadfully redirection-heavy (in function calls terms) the original code is while it is perfectly feasible to go the "object with inline methods way" 99% of the time... which would make the source code that much more maintainable and, paradoxically, more optimized (anyone still pretending C++ is slower obviouly has no idea how to code in it properly from a performance point of view).

The only issue I see turns around backward compatibility (ie. demos) but it's nothing you can't tackle provided you have a set of maps and assiciated demos to use as "unit tests".

God, I wish I had more time on my hands.

Best of luck with whatever decision you take, Eternity is still the source port I'm most in love with ;)

Could we get back to the OP's point and stop philosophing about what's "right" and "wrong" all the time? Or go right into drama for the sake of drama?

fp!

Yeah, I remember this version.

Glad you found it finally, Simon.

And the translations are as painful as it gets to a french ear :)

rf` said:

Guys don't stop, this [arguments about arguments] is turning me on.

+1

OR, if you're totally new to programming and you're good at gfx (I concur with Torn on the quality of the sprite sheet you linked to), you could consider pairing up with an experienced coder.

:(

Arf, too bad you limit yourself to midi for the music. Most limit removing ports can handle mp3s or oggs and I would have been delighted to participate.

Good luck on eveything anyway ;)

I was quite eager to see more of this but I'm afraid I'm a bit disapointed. I don't find those 15 screenshots impressive at all. They seem under-detailed and "fake" if you see what I mean. Maybe it's a question of lighting and textures, I don't know.

Hey Lutz! Welcome back! sup?

You can also let it there. With the heat of the screen, it should decay quite quickly. Remains should go away by scratching & pressing when it's done. If not, then it'll then be time to disassemble the monitor :/

Interestingly, I just got it while trying to reply to this post a first time to say I never got it. Seems like an advertiser has been blacklisted...

Well, you could call the new megawad Scythe2+ and voilà.

Seems to be a good idea to try & solve existing bugs. Question is: how many of those bugs were used in demos?

myk said:

SUPERCHARGE

Damnit, myk, I got used to seek for your previous avatar when I was in need of good trolling ! Damn you for making my life miserable ! :P

esselfortium said:

I'd like to know the same thing.

Same here (music department).

GhostlyDeath said:

YD: UFO Game?

http://en.wikipedia.org/wiki/UFO:_Enemy_Unknown

GhostlyDeath said:

LATB: I never really noticed the drums much since the guitar was pretty loud, but I could fix it sometime later.

All I can tell you here is practice, practice, practice, 'cause not taking into account drums while playing and/or programming an instrument line... well... honestly I dunno what to say. Would you listen to a band where everyone is playing his own thing without listening to the others?

So,

• YummyDarkness: I know you were aiming for an ambient one here, but the strings just get annoying very fast (I mean, I love repetitive tracks but still)... I suggest you give a listen to the UFO game soundtrack which was marvellous in that department
• LookAtTheBunnies: you do realize the guitar part keeps on desynchronizing/resynchronizing with the drums, right?

I don't wanna sound harsh or anything but, please, tell me this is the first time you made midi tracks.

Scuba Steve said:

Rofl, Urban Brawl.

Yeah and there's a link to a review but it seems broken.