Doomworld Forums - Flat sizes

Doomworld Forums : Powered by vBulletin version 2.2.5

Doomworld Forums > Special Interest > Freedoom > Flat sizes

Pages (2): [1] 2 »

Author

All times are GMT. The time now is 12:51.

wesleyjohnson
Member

Posts: 447
Registered: 04-09

I need a some help, concerning what the requirements for flats are in Freedoom. Specifically, I have a bunch of questions concerning FLAT5_2, as used in Map21. It is the floor texture at the player 1 start position in Map21.

I have tried looking at this flat using prboom, Legacy, yadex, Zeth etc. and I get differing answers. Prboom and ZDoom have "improved" the texture handling so much that I get lost going through their code.
Prboom displays the texture well, but Legacy is displaying bits off the edge of the texture (multicolor dots).

FLAT5_2 appears to be a 64x64 texture, but has an odd lump size of 4680. A lump size of 4680, which is 8x5x9x13, could be 60x78.

Q1. Is 4680 the correct lump size for FLAT5_2 ??

Q2. What were the dimensions of FLAT5_2 before it was put in the wad ??

Q3. Are all Flats supposed to be square, like 128x128 down to 32x32 ??
And is FreeDoom adhering to such a restriction.

This could be a lump reading error, but it is the only texture I have found in the whole wad that has this odd size.

I have gone around the tutorials on Doom and have not found much info on flat restrictions, or at least have not found the one that I thought mentioned that some textures of Doom had to be square.

Of course this depends on whether FreeDoom has restrictions on flats being square, or has expanded the engine requirements by including flats that are not square.

I am trying to figure out if this is a wad bug, less restricted flats in FreeDoom, or something else.
The are too many possibilities for the "something else" right now, so I need some information to narrow it down.

Last edited by wesleyjohnson on 05-15-09 at 20:33

05-15-09 20:22 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 6450
Registered: 07-07

lolwut?

05-15-09 20:32 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

wesleyjohnson
Member

Posts: 447
Registered: 04-09

Got the Unofficial Doom Spec, it says 64x64, but FreeDoom uses prboom as a reference, so it may have been "improved" to any size flat.

The question is "What rules are the FreeDoom level designers following?", which I ask so I can eliminate the possibility of having to handle odd size flats in the engine.

05-15-09 20:43 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

andrewj
Senior Member

Posts: 1344
Registered: 04-02

Something has gone wrong while packing up (into the IWAD) the latest FreeDooms.

In version 0.6 the FLAT5_2 lump is 4096 bytes, as it should be.
In version 0.6.2 the lump is now 4680 bytes.

To answer the OP: it is definitely a mistake in the IWAD. All flats in FreeDoom should be 64x64 = 4096 bytes.

05-16-09 04:03 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

esselfortium
Cumulonimbus Antagonistic Posting

Posts: 5152
Registered: 01-02

Sounds like someone accidentally converted it from flat format into patch format. It's really easy to accidentally do this in XWE.

05-16-09 04:11 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

andrewj
Senior Member

Posts: 1344
Registered: 04-02

More info: there are TWO lumps for FLAT5_2, one in the F_START/F_END section (which is OK) and one outside of it (with a size very common for patches).

FLOOR7_2 has the same problem.

05-16-09 04:20 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

GreyGhost
a ghost... only grey

Posts: 5185
Registered: 01-08

wesleyjohnson said:
I need a some help, concerning what the requirements for flats are in Freedoom. Specifically, I have a bunch of questions concerning FLAT5_2, as used in Map21. It is the floor texture at the player 1 start position in Map21.

I have tried looking at this flat using prboom, Legacy, yadex, Zeth etc. and I get differing answers. Prboom and ZDoom have "improved" the texture handling so much that I get lost going through their code.
Prboom displays the texture well, but Legacy is displaying bits off the edge of the texture (multicolor dots).

For some odd reason Legacy is picking up and applying the wrong FLAT5_2 (probably using the first one it finds) which is why the floor looks strange. A quick fix for this problem is to delete the 4680 byte FLAT5_2. I just hope no-one's using it elsewhere as a texture.

05-16-09 05:54 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 6959
Registered: 01-03

GreyGhost said:
For some odd reason Legacy is picking up and applying the wrong FLAT5_2 (probably using the first one it finds) which is why the floor looks strange.

The 'odd' reason being thar Legacy never bothered to implement WAD namespaces properly, and because they were unable to make Flat lookup work without it they don't check F_START or F_END *AT ALL* for flats!
(No idea if 2.0 is better in that regard. The texture initialization code looks suspicious, too, but it's completely different than the one in 1.4.)

Why is Legacy the only ports where I ever find such gems?
The bottom line is: Although Legacy implements a lot of Boom features, it's in no way 'Boom compatible'. There's just too many inconsistencies and oddities there (yeah, I'm repeating myself...)

05-16-09 07:56 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

wesleyjohnson
Member

Posts: 447
Registered: 04-09

The next question is. "Why is there a FLAT5_2 patch, and is it used anywhere" ??

Is FreeDoom going to use the same names for flats and patches ??

Legacy has had to try to adapt to many different wads, which will not obey any consistent set of rules concerning use of the START and END. Many wads get released with missing tags, because they worked with the one engine the author was using.

After trying some of the various wads, I suspect that most of them are broken compared to someone else's rule set. Even the id levels broke their previous "rules", because they could use "accidental" features of the wad structure, because they had only one engine to consider.

It depends upon the evolution of the wad format. The flat START and END may have had more meaning at one time, then further developments may have made it pointless. I don't know right now to what level those tags are forcing.

If there is an evolution effect to be considered, it is that now pwads are allowed to change flats without changing the entire set of flats. This will have the same effect upon duplicate names in the wad. Every engine is making "improvements" like this, even prboom, and each one is going to expose previously invisible flaws in the structure of particular wads. What each engine developer needs to know is what wad rules are going to be adhered to, at least for this development team.

Last edited by wesleyjohnson on 05-18-09 at 18:55

05-18-09 18:26 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

andrewj
Senior Member

Posts: 1344
Registered: 04-02

FreeDoom is an IWAD and hence it's policy for flats is simple: all flats must appear between F_START and F_END. That will work for any engine using FreeDoom as an IWAD.

Some stuff you are talking about only applies to PWADs (and engines loading PWADs) and hence is not relevant to FreeDoom.

05-19-09 03:31 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Catoptromancy
Forum Regular

Posts: 713
Registered: 08-06

Freedoom git repos need some texture1 work. I added alot of patches for plutonia support. Checking repos this had nothing to do with FLAT5_2.

Legacy appears to support loading patches as flats, much like zdoom. But zdoom loads flats in flats section first before attempting for a patch.

Boom loads flats from flat list between markers. FLAT5_2 is a flat on Map21. It is nowhere a patch on Map21. If Legacy loads the patch instead of a flat, then Legacy is not Boom compatible.

That extra patch seems to be a bug in the wad.

05-19-09 04:41 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Jon
Freedoom Bloke

Posts: 1323
Registered: 09-00

wesleyjohnson said:
Legacy has had to try to adapt to many different wads, which will not obey any consistent set of rules concerning use of the START and END. Many wads get released with missing tags, because they worked with the one engine the author was using.

Many pre-port PWADs have mismatched or missing ?_START/?_END tags as this was a commonly used doom hack to support adding sprites or flats to PWADS. This was not normally supported: if you wanted to replace a flat or a sprite you had to replace *all* of them. Hence so many megawads being distributed with deusf and patching the IWAD before play. Omitting one of the start or end tags (I forget which) was sufficient to allow you to replace individual flats in a PWAD at least.

05-20-09 11:40 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

andrewj
Senior Member

Posts: 1344
Registered: 04-02

Jon said:
Omitting one of the start or end tags (I forget which) was sufficient to allow you to replace individual flats in a PWAD at least.

It's the start one, commonly renamed to FF_START, and you can have multiple flats there.

05-20-09 14:38 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

wesleyjohnson
Member

Posts: 447
Registered: 04-09

Thank you for the information about there being a patch of the same name.

I do not know what to fix at the moment, because Legacy got this way because of deliberate changes to adapt it to accept particular wads.
I do not want to break all that work trying to get it to accept something that is an error.

I still need to know ...
Q4: Are patches and flats allowed to have the same names, by anyones set of rules. ???

I have a faint memory of plans to reinstate the separate flat namespace for Legacy, at least I think it was Legacy.

06-05-09 03:38 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

GreyGhost
a ghost... only grey

Posts: 5185
Registered: 01-08

A quick scan of the Doom and Doom 2 resources didn't turn up any duplicate names and considering the undesirable side-effects that can cause, my set of rules would say - give them exclusive names.

06-05-09 05:53 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 4484
Registered: 08-00

Why you can add flats in a PWAD:

The global wad directory, with the IWAD+PWAD, looks like this:

code:
<misc IWAD lumps>
F_START           <- F_START in IWAD
<IWAD flats>
F_END             <- F_END in IWAD; this is overwritten below.
<misc PWAD lumps> <- Start of PWAD
FF_START          <- This is NOT recognized by DOOM.
<PWAD flats>
F_END             <- F_END in PWAD

When DOOM enumerates the flats, it looks for the F_START and F_END lumps, and then calls everything between them a flat. By not providing an F_START in the PWAD, you preserve the F_START in the IWAD portion of the directory. By providing an F_END, you overwrite the IWAD F_END. So enumeration proceeds from the IWAD's F_START to the PWAD's F_END.

Hope this provides some insight :)

06-05-09 19:24 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Jon
Freedoom Bloke

Posts: 1323
Registered: 09-00

wesleyjohnson said:
I do not know what to fix at the moment, because Legacy got this way because of deliberate changes to adapt it to accept particular wads.
I do not want to break all that work trying to get it to accept something that is an error.

You need a regression test suite. I was working on one for prboom (some of the code made it in, but the actual suite itself isn't done yet, sorry proff :() for demo playback.

06-08-09 11:24 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

wesleyjohnson
Member

Posts: 447
Registered: 04-09

Catoptromancy said:

Boom loads flats from flat list between markers. FLAT5_2 is a flat on Map21. It is nowhere a patch on Map21. If Legacy loads the patch instead of a flat, then Legacy is not Boom compatible.

Well.. Legacy can follow the Boom spec (2.02), but cannot do exactly everything that a particular Boom engine did, without being nothing more than a copy of that engine.

None of the ports access the WAD file in real-time. They all load the WAD into internal data structures. Those internal data structures are very implementation dependent, so there is no point in discussing how any particular engine uses them. The problem is how to interpret the F_START and F_END in the context of the IWAD and PWAD that used and abused them. The indexes that a port implements to search the name space are not created at level read time, but are created at first read of the wad, or pwad, so it makes little difference if a patch appears in a level, the name space is corrupted for all.

It appears, based upon how it reacted to a F_START in a PWAD, that original doom reacted to F_START by destroying any existing flat data (init or something). The newer ports do not do that, and can load PWAD flats individually. The original use of F_START has been weakened, .. so what functionality does it still have?

Q5. This forum has many members that write wads, so do any of you actually use the same name for a flat and a patch. If so, then that is a good reason to have separate name spaces for patches and flats.
Then the F_START defines the change to the "flat" name space. If not, then there is really no good reason to rush out and make separate name spaces for them.

Q6. If a separate name space for flats were enforced, and flat appearances in a level only searched the "flat" name space, then how would the PWAD without a F_START work. Flat names in such a pwad would not get entered in the "flat" name space, and where they ended up would be implementation dependent. With F_START missing in such PWAD then it cannot define the change to the "flat" name space.

As far as regression testing, it seems that the Doomworld archives are a regression test. So far I have about 30% failure rate on wads downloaded from Doomworld, some due to needed ZDoom or some other specific port, some which should work but have wad inconsistency failures (specific messages of a name not found). I am buried in regression test failures.

Last edited by wesleyjohnson on 06-08-09 at 22:06

06-08-09 21:53 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Jon
Freedoom Bloke

Posts: 1323
Registered: 09-00

wesleyjohnson said:
As far as regression testing, it seems that the Doomworld archives are a regression test. So far I have about 30% failure rate on wads downloaded from Doomworld, some due to needed ZDoom or some other specific port, some which should work but have wad inconsistency failures (specific messages of a name not found). I am buried in regression test failures.

If a WAD needs zdoom then it's hardly a regression for it not to work with Legacy: it never will have. A regression test should be a mostly-automated procedure to capture changes in the supported functionality as development continues.

06-09-09 19:39 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Catoptromancy
Forum Regular

Posts: 713
Registered: 08-06

Can use Search feature for Whole Textfile and type "legacy" for search term.

06-09-09 20:25 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

myk
webbed digits

Posts: 14316
Registered: 04-02

wesleyjohnson said:
It appears, based upon how it reacted to a F_START in a PWAD, that original doom reacted to F_START by destroying any existing flat data (init or something). The newer ports do not do that, and can load PWAD flats individually. The original use of F_START has been weakened, .. so what functionality does it still have?

The original use is that it's best not placed in a PWAD (hence FF_START is generally used to mark the start of the flats section so some WAD editing apps easily know where the flats are). Under Boom compatibility, F_START can be used in PWADs, but I think it's better to get people used to applying FF_START/F_END, instead, since it works just as well and is additionally vanilla compatible... especially when giving general advice or directives.

Note, though, that Freedom's WAD is an IWAD, so the use of F_START at the beginning of the flats section is necessary. The changes in how the marker is read in PWADs haven't changed the fact that the marker is required in the internal WAD.

Legacy can follow the Boom spec (2.02), but cannot do exactly everything that a particular Boom engine did, without being nothing more than a copy of that engine.

That's not a good excuse. Other engines which are definitely not just copies of Boom clearly do a better job at supporting Boom WADs.

06-10-09 05:14 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

wesleyjohnson
Member

Posts: 447
Registered: 04-09

Modifying how F_START is interpreted is an option that I shall investigate. I need to read the old documentation on this, so I am not going to do anything immediate. Also, if FreeDoom is going to fix the extraneous patch name, then the need really goes away.

I will not be copying code from the Dos version of Boom.

06-16-09 20:16 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Catoptromancy
Forum Regular

Posts: 713
Registered: 08-06

http://git.savannah.gnu.org/cgit/fr...0b71e6c8d59cc5f

It is still a Legacy bug. There are some pwads that use flats as patches to be able to also use same floor texture as wall.

06-16-09 23:18 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

GhostlyDeath
Forum Retard

Posts: 782
Registered: 08-05

I fixed the WAD Flats and Patch problem in ReMooD, revision 792 (http://remood.svn.sourceforge.net/r...iew=rev&rev=792). If you are too lazy to compile it from source http://remood.game-host.org/auto/ has some builds, 794 would be the right choice.

Basically, this just uses flats between F_START to F_END, FF_START to F_END, and FF_START to FF_END. For compatibility reasons (for possibly any Legacy WADs that don't use this), if a flat is not found it will search every single WAD and if it still isn't found, I added a -NOFLAT- texture.

EDIT: Seems I never closed the URL tag...

06-21-09 20:19 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

wesleyjohnson
Member

Posts: 447
Registered: 04-09

Found the problem in Legacy. All the code was there. Someone had commented out the normal Flat name search, which respected F_START and F_END, and substituted a whole wad search, so as to get Legacy to work with gothic2.wad.

I will submit a patch to Legacy sometime soon. After restoring the original code it now displays the flat correctly in the buggy FreeDoom wad (1.6.3) in spite of reused names. If I can find the gothic2.wad I can do a regression test, but I could not find it in doomworld.

Anyone hear of gothic2.wad ?? It must be a buggy wad, if someone had to take such drastic action to get it to work ?? Is it a desirable wad, such as to make it worth the work ??

Notes:
CleanWad seems to be a good reference for wad compatibility as they spent a good deal of time researching the subject.
CleanWad docs say it will change FF_START to F_START, as modern ports do not need this anymore (and many old ports did not recognize it).

I cannot see what using Flats as patches has to do with this problem, but thanks for the information. The patch code must be special to achieve that, but it would not affect the flat code.

Made trip to library to get FreeDoom-1.6.4. Disappointing as it seem to not have any of the changes mentioned recently, just an emergency release because of music. I always turn the music off, it was distracting.

Hello ReMooD. Sounds like my kind of port, not afraid to modify the play, add some new ideas. Not surprising that someone forked Legacy. I will be checking you out later.

Last edited by wesleyjohnson on 06-21-09 at 22:06

06-21-09 21:52 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

GhostlyDeath
Forum Retard

Posts: 782
Registered: 08-05

wesleyjohnson said:
Found the problem in Legacy. All the code was there. Someone had commented out the normal Flat name search, which respected F_START and F_END, and substituted a whole wad search, so as to get Legacy to work with gothic2.wad.

I will submit a patch to Legacy sometime soon. After restoring the original code it now displays the flat correctly in the buggy FreeDoom wad (1.6.3) in spite of reused names. If I can find the gothic2.wad I can do a regression test, but I could not find it in doomworld.

Anyone hear of gothic2.wad ?? It must be a buggy wad, if someone had to take such drastic action to get it to work ?? Is it a desirable wad, such as to make it worth the work ??

Notes:
CleanWad seems to be a good reference for wad compatibility as they spent a good deal of time researching the subject.
CleanWad docs say it will change FF_START to F_START, as modern ports do not need this anymore (and many old ports did not recognize it).

I cannot see what using Flats as patches has to do with this problem, but thanks for the information. The patch code must be special to achieve that, but it would not affect the flat code.

It depends on the ordering within the WAD, W_CheckNumForName() goes backwards. Because of this, if the patches are after the flats then the patch would get loaded instead of the flat.

and gothic2.wad is at http://www.doomworld.com/idgames/index.php?id=9318

06-21-09 22:02 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

wesleyjohnson
Member

Posts: 447
Registered: 04-09

Sorry but, what depends upon the ordering ? the patch code finding the correct patch or the flat code finding the correct flat. I saw that backwards search, and some other special ones, when I was trying to track down this bug in this thread. As I see it, because the flat code can only display flats, any reuse of the name is a problem, and it cannot use a patch as a flat either (at least not in a visually appealing way), and that is why limiting the search to F_START..F_END helps in those special wads.
But any multiple use of a lump, like using a flat as a patch, is a problem limited to such patch code, which looks like it is working correctly anyway.

Thank You, downloading gothic2.wad now. Couldn't find it in the 15 min the Library computer allowed. Of course, now I will be tied up for a while using this 56K dial-up modem.

Last edited by wesleyjohnson on 06-21-09 at 22:27

06-21-09 22:14 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

GhostlyDeath
Forum Retard

Posts: 782
Registered: 08-05

wesleyjohnson said:
Sorry but, what depends upon the ordering ? the patch code finding the correct patch or the flat code finding the correct flat. I saw that backwards search, and some other special ones, when I was trying to track down this bug in this thread. As I see it, since the flat code can only display flats, any reuse of the name is a problem, and that is why limiting the search to F_START..F_END helps in those special wads.
But any other reuse, like by patches, is a patch code problem, which looks like it is working correctly anyway.

W_CheckNumForName() searches the last WAD first, and the first WAD last. When searching inside the WAD, the names are checked from the last entry to the first entry. This is for PWADs that may overwrite existing lumps.

In Doom Legacy, since it checks every WAD for a matching lump by it's name, it will hit the last appearence of the name. If the real flat is second to last from the patch (which is last) then the patch will be read. If the patch is second to last from the flat (if it's last) then the flat will be used.

06-21-09 22:21 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

wesleyjohnson
Member

Posts: 447
Registered: 04-09

Yep, saw that, it had to be there to have PWADs override the IWAD. I understand that behavior. That is in the general name search functions and is not part of the problem.

I think my fix in Legacy is going to solve them problem. It just restores an existing line that was commented out. I assume you found the same code in ReMooD. Your fix sounds almost identical to mine. I will consider adding a default flat substitution if after re-searching the entire wad it still does not find the name. I really do not like resorting to I_ERROR, and have created a SOFTERROR that lets play continue (see Legacy patches).

I just do not think I need to worry about what the patch display code does in using a flat. The fix I applied is in a function that just loads flats by name, and if that function is used by the patch search code, then the correct search procedure should work just as well. If he had said "a patch can be used as a flat" then that would be entirely different, but "using a flat as a patch" is interesting, but cannot affect buggy flat search code in the flat display code. If you know how, you are going have to be much more explicit. They both use the same wad name search functions, but are not the same piece of code.

Last edited by wesleyjohnson on 06-21-09 at 22:53

06-21-09 22:45 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

GhostlyDeath
Forum Retard

Posts: 782
Registered: 08-05

wesleyjohnson said:
Yep, saw that, it had to be there to have PWADs override the IWAD. I understand that behavior. That is in the general name search functions and is not part of the problem.

I think my fix in Legacy is going to solve them problem. It just restores an existing line that was commented out. I assume you found the same code in ReMooD. Your fix sounds almost identical to mine. I will consider adding a default flat substitution if after re-searching the entire wad it still does not find the name. I really do not like resorting to I_ERROR, and have created a SOFTERROR that lets play continue (see Legacy patches).

I just do not think I need to worry about what the patch display code does in using a flat. The fix I applied is in a function that just loads flats by name, and if that function is used by the patch search code, then the correct search procedure should work just as well. If he had said "a patch can be used as a flat" then that would be entirely different, but "using a flat as a patch" is interesting, but cannot affect buggy flat search code in the flat display code. If you know how, you are going have to be much more explicit. They both use the same wad name search functions, but are not the same piece of code.

ReMooD is based off Doom Legacy. You said there was a bug in Doom Legacy and I found the same bug unfixed in ReMooD, so I fixed it. Didn't take long however.

06-21-09 23:18 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

All times are GMT. The time now is 12:51.

Pages (2): [1] 2 »

Doomworld Forums > Special Interest > Freedoom > Flat sizes

Show Printable Version |

Email this Page |

Subscribe to this Thread

Forum Rules:

You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON

< Contact Us - Doomworld >