Jump to content

Website should be WWW-compatible


Gez

Recommended Posts

Freedoom's website uses various features not supported by WorldWideWeb, such as CSS style sheets. It also links to sites (Youtube, Google+, GitHub) using such non-vanilla browser features as Flash and JavaScript. More egregiously, a Gopher interface is not offered.

Share this post


Link to post

ha ha

Seriously though, MUS and OPL2 limitations are something to be considered if vanilla is the target. You might find it laughable to try addressing these issues, but I don't see the humor in it. Perhaps you'd be better off complaining (yet again) about the vanilla target than mocking my threads.

Share this post


Link to post
YukiHerz said:

Sprites and textures should only use colors available to their doom counterparts.

Um, no?

Share this post


Link to post
YukiHerz said:

Sprites and textures should only use colors available to their doom counterparts.

I thought you wanted Freedoom to have a unique identity.

Gez said:

Freedoom's website uses various features not supported by WorldWideWeb, such as CSS style sheets. It also links to sites (Youtube, Google+, GitHub) using such non-vanilla browser features as Flash and JavaScript. More egregiously, a Gopher interface is not offered.

Bah, no one cares.

Share this post


Link to post
Voros said:

I thought you wanted Freedoom to have a unique identity.

I think he's trying to mock what he perceives as my line of thinking, but I would never suggest what he said.

Voros said:

Bah, no one cares.

You do realize Gez was mocking this thread and wasn't being serious, right?

Share this post


Link to post
Blastfrog said:

You do realize Gez was mocking this thread and wasn't being serious, right?

Yes, I know, which is why I said no one cares.

Share this post


Link to post
Blastfrog said:

I think he's trying to mock what he perceives as my line of thinking, but I would never suggest what he said.

If it were something you'd actually suggest, it wouldn't be a mockery, now, would it? :p

The fetishism with limitations and making sure something is dumbed down enough to fit the least common denominator is a poison to this project. Quality control should be about quality, not about making sure it could run on hardware and software twenty years obsolete.

Share this post


Link to post

Mine was also mockery/sarcasm, i've seen certain people who work in certain areas of Freedoom suggest serious silly limitations which have begun to be taken into account, as the area in which they contribute isn't affected they don't feel any kind of weight on themselves, choosing vanilla compatible maps, although a good idea when looked at from the outside, was one of these silly suggestions that ended up being slapped on a freedoom aim update, completely out of nowhere.

Tl;dr the wad should weight exactly the same as vanilla doom 1.9's.

Share this post


Link to post

Honestly, I don't see the "need" for vanilla compatibility. I myself couldn't honestly see using freedoom in vanilla at all. After all. If FreeDM is allvanilla compatible already, then why not just use that as the iwad and load a mapset with that? And yes, i know you're going to mention freedoom1, but you figure that out.

Share this post


Link to post

Freedoom needs to only use the software renderer at 320x200 maximum resolution to preserve that authentic vanilla feel. No cheating features that are ruining the sanctity of the Doom experience either, like looking up or down or being able to run under flying monsters. Mandatory 35FPS cap too so it doesn't feel overly smooth and take away from the atmosphere.

Share this post


Link to post

Im pretty sure the vanilla goal was meant to for sourceport compatibility, such as Doomsday (no Boom support in that) and Chocolate Doom (no Boom support here either, for obvious reasons)

Share this post


Link to post
YukiHerz said:

Tl;dr the wad should weight exactly the same as vanilla doom 1.9's.

I agree and I'll go a step further: all lumps in the freedoom IWAD should be precisely the same size and order as those in the original IWAD. This will ensure that the zone allocation system functions identically and all overflow bugs activate in exactly the same manner.

Share this post


Link to post
Linguica said:

I agree and I'll go a step further: all lumps in the freedoom IWAD should be precisely the same size and order as those in the original IWAD. This will ensure that the zone allocation system functions identically and all overflow bugs activate in exactly the same manner.


Great! Now I wont need to bug entryway about demos on obscure vanilla maps desyncing when I play them back with different iwads.

Share this post


Link to post

This thread is really confusing.

Looks like my sarcasm meter is broken as FUCK.

Share this post


Link to post
Gez said:

Freedoom's website uses various features not supported by WorldWideWeb, such as CSS style sheets.

Does it at least display the text content, throw up elements it doesn't recognize, or does it error out completely? The main reason to use CSS is to separate the content from its presentation and unsurprisingly Freedoom's site works in this regard in both NCSA Mosaic and NN4 (i.e. the meaning is there, even if it doesn't look the same), at least in the versions on oldweb.today. (Sadly this site doesn't emulate WorldWideWeb. On the other hand, it also reminds me why we called a certain browser "Internet Exploder".)

More egregiously, a Gopher interface is not offered.

From what I understand, WorldWideWeb doesn't support the Gopher protocol either...

Share this post


Link to post

I think that, with the above restrictions also in place, the data should be manipulated until the MD5 hash collides with the actual IWAD, just so that the files cannot actually be told apart. This'll really be cool.

Share this post


Link to post
Linguica said:

I agree and I'll go a step further: all lumps in the freedoom IWAD should be precisely the same size and order as those in the original IWAD. This will ensure that the zone allocation system functions identically and all overflow bugs activate in exactly the same manner.

Quasar said:

I think that, with the above restrictions also in place, the data should be manipulated until the MD5 hash collides with the actual IWAD, just so that the files cannot actually be told apart. This'll really be cool.

Can you guys just stop already? Music playing back correctly in the target engine is a legitimate concern, these jokes you're making are nowhere near comparable to my MUS and OPL2 compatibility thread.

Share this post


Link to post
Guest
This topic is now closed to further replies.
×
×
  • Create New...