Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Kaiser

Doom64 EX (Feedback build) Now at v1.1c

Recommended Posts

Chronohunter45 said:

Just tried the latest SVN and there seems to be textures disappearing (similar to a HOM effect, but no shimmering; just shows sky texture)


Make sure you re-run wadgen to generate a new iwad. At some point I added texture hashing so custom textures wouldn't be a pain to add

Chronohunter45 said:

in widescreen resolutions of 16x9 at the left and right edges of the screen right before a wall goes out of view. In my case, 1920x1080. Can anyone else confirm this issue as well?


Several reasons why its like this, mainly because a) I am not a good programmer and I don't know how to properly do it and b) Other hardware based source ports does the same thing, which I feel that its rather a limitation on doing proper widescreen in Doom.

Share this post


Link to post
BryantG said:

and anyone know if it will end the outcast Levels.


More likely something broke and because it abuses the Doomsday engine a lot, it requires you to use a specific version of that engine. I believe that level is the last one anyways and ends after killing the cyberdemon/motherdemon

Share this post


Link to post

You know if samuel will add more maps, is that it was super cool as they made me very excited about the new levels and new enemies took ten years of playing this doom and my brother and I are good fans to these Dooms.

Share this post


Link to post

Hey kaiser, I was just taking a look at the wadgen source and noticed something I thought you'd like to know:

wadgen.c - WGen_ConvertN64Pal()

This palette data is not in some obscure format, it's actually the very common (at the time) B5G5R5 format. I don't think your method recreates the colour info accurately (although I didn't test). Here is the routine I wrote to convert this for my jDoom64 project:

#ifdef __BIG_ENDIAN__
#define BIGSHORT(x)         (x)
#else // Little-endian.
#define BIGSHORT(x)         ShortSwap(x)
#endif

// Borrowed from Doomsday.
short ShortSwap(short dat)
{
    return (((unsigned short)dat<<8) + ((unsigned short)dat>>8))&0xffff;
}

/**
 * Converts a Doom64 sprite palette into an RGB8 palette (like DOOM).
 *
 * Each palette entry in a Doom64 sprite palette is a big-endian,
 * 16 bit short as B5G5R5 (i.e. five bits per component in the order
 * BLUE, GREEN, RED).
 *
 * \important The dest buffer MUST be big enough to hold the unpacked
 *            palette (i.e. numEntries * 3 * 8 bits!)
 *
 * @param dest          Ptr to the buffer to hold the converted data.
 * @param src           Ptr to the palette to be converted.
 * @param numEntries    Number of entries (i.e., colours) in the @a src palette.
 */
void ConvertD64Palette(byte* dest, const byte* src, size_t numEntries)
{
    assert(dest && src && numEntries > 0);

    // For some reason there are eight bytes of pad at the start.
    // Any idea what they are used for (if anything)?   
    { const byte* p = src + 8;
    size_t i;
    for(i = 0; i < numEntries; ++i)
    {
        size_t palIDX = i * 3;
        short val;

        // Read the next packed short from the input buffer.
        val = *(short*) p; p+=2;
        val = BIGSHORT(val);

        // Unpack and expand to 8bpp, then flip from BGR to RGB.
        dest[palIDX++] = (val & 0x003E) << 2;
        dest[palIDX++] = (val & 0x07C0) >> 3;
        dest[palIDX]   = (val & 0xF800) >> 8;
    }}
}
EDIT: I just found the following in my notes on the N64 which might prove to be informative (taken from here http://pikensoft.com/docs/SpriteView_readme.txt):

N64 High/True color modes
-------------------
The two modes so far found are 32bit (256 levels of
red/green/blue/transparency) and 16bit (32 levels of red/green/blue and 1
level of transparency). Both are linear (no tiles), each row (variable size)
proceding left to right going, top to bottom. Complete transparency has a
value of 0. For 16bit, 1 is opaque. For 32bit, 255 is completely opaque. If
transparency is true (not opaque) and the other color values are greater
than 0, you get translucency (like the colored transparency you see in
stained glass). Before you can view the colors correctly, you must change to
the true color palette.

You may also find 8bit and 4bit linear graphics in certain N64 games. Since
I am not familiar with the details of that console (I only have one N64 game
compared to 30 SNES), I'm not certain about this, but most likely 4 & 8bit
graphics are expanded to high/true color before being used in rendering.

32bit pixel:
0 ..... 8 ..... 16 .... 24 ... 31
rrrrrrrrggggggggbbbbbbbbtttttttt
Byte 0 = Red
Byte 1 = Green
Byte 2 = Blue
Byte 3 = Transparency (255=opaque, 0=transparent)

16bit pixel:
0 ..... 8 .... 15
tbbbbbgggggrrrrr
Bit 0 = Transparency (1=opaque, 0=transparent)
Bits 1-5 = Blue
Bits 6-10 = Green
Bits 11-15 = Red

I wish Nintendo would make up their mind about the rgb order. For the SNES,
it's BGR with an unused top bit. For N64 high color, it's BGR with a used
bottom bit; and for true color, it's RGB and a used top byte.

As you can see there is a very good reason why Midway formatted this data the way they did.

Share this post


Link to post

No wonder I couldn't play this damn thing, on here it shows the card requirement as being 128MB, and mine is 96, the website for the project didn't state that one small detail. Oh well, least I know now, a big kudos to the project overall though.

Share this post


Link to post
BurningCadavre said:

No wonder I couldn't play this damn thing, on here it shows the card requirement as being 128MB, and mine is 96, the website for the project didn't state that one small detail. Oh well, least I know now, a big kudos to the project overall though.


This is on the front page:

System Requirements:
Windows 9x/Me/2000/XP/Vista
OpenGL 1.1 or higher
600mhz Processor or higher
64mb ram (128mb recommended)
32mb Graphics Card or higher
Doom64 N64 ROM (U), (J) or (E) versions only. (D64 EX does not include or offer the rom.)


Also I was wrong in guessing how much memory the GPU would need at first so thats why now the site says it only requires 32mb due to optimizations and whatnot after I switched over from Doom3D's directX renderer eons ago because when it DID use DirectX, it consumed craploads of texture memory.


Also, interesting find DaniJ

Share this post


Link to post

As AlysiumX suggested, asking here too...


@ Kaiser:

Looks like your domain http://kaiser.startan3.com/ is gone. Where to get the files linked in the starting post (e.g. Doom Builder 64) now? I could provide mirrors on my webspace if I can get them from elsewhere...

Share this post


Link to post

I might as well check and see if there is a fix for Builder64 that stops tags from removing sector lighting? :D

Share this post


Link to post
iori said:

I might as well check and see if there is a fix for Builder64 that stops tags from removing sector lighting? :D


Yeah, even that is starting to annoy me whenever I make a test map for debugging.

Share this post


Link to post
LigH said:

As AlysiumX suggested, asking here too...


@ Kaiser:

Looks like your domain http://kaiser.startan3.com/ is gone. Where to get the files linked in the starting post (e.g. Doom Builder 64) now? I could provide mirrors on my webspace if I can get them from elsewhere...


Old Doom Builder 64: http://www.speedyshare.com/files/25015673/Builder64_Old.7z

New Doom Builder 64
SRC: http://dl.dropbox.com/u/18609/Builder64_src.7z
Binaries: http://dl.dropbox.com/u/18609/Builder64.zip

Note that the new builder64 is up on Codeimp's SVN

Share this post


Link to post

Am I the only one having this issue?

Upon opening a previously saved map, Builder64 gets an unhandled exception error "Unable to read beyond end of stream".

Share this post


Link to post
footman said:

Am I the only one having this issue?

Upon opening a previously saved map, Builder64 gets an unhandled exception error "Unable to read beyond end of stream".


The old doom builder64 can't open maps saved by the new doom builder because of the texture hashing update.

Share this post


Link to post
Kaiser said:

The old doom builder64 can't open maps saved by the new doom builder because of the texture hashing update.

The new one can't open the very maps it saves.

Share this post


Link to post

If you've saved your map with no macros, you can add in the MACROS lump from any other map (like one of the ones in the IWAD) as a temporary solution, though your map will be saved without it and you'll run into problems reloading it again if you don't actually use one of the macros somewhere in your map.

Share this post


Link to post

I was using the latest svn build that Stroggos has up (D64Ex_Bin_r-740.7z) so I don't know if this has been fixed, but if you're holding down the run key and fire key at the same time, hitting forward doesn't move you forward.

Share this post


Link to post
sector666 said:

I was using the latest svn build that Stroggos has up (D64Ex_Bin_r-740.7z) so I don't know if this has been fixed, but if you're holding down the run key and fire key at the same time, hitting forward doesn't move you forward.


I'll look into that

Share this post


Link to post

Are you sure it isn't a hardware issue with your keyboard, sector666? Some keyboards have problems with certain key combinations, due to some sort of manufacturing cost-cutting maneuver. I forget if Doom64EX has an "always run" mode, but try that, or try rebinding one or more of the relevant actions to a different key as a test to see if the behavior changes.

Share this post


Link to post
sector666 said:

I was using the latest svn build that Stroggos has up (D64Ex_Bin_r-740.7z) so I don't know if this has been fixed, but if you're holding down the run key and fire key at the same time, hitting forward doesn't move you forward.


I tried repro'ing this on my end and I couldn't get this to happen. Not sure if this happened before though try double checking your bindings.

Share this post


Link to post

I've noticed that at very low resolutions, some textures and sprites aren't drawn properly, they "flicker" in and out of existence, and I can barely see some switches and lights. I can also occasionally see sprites through walls. Look at this image. There's supposed to be a switch there, but it only appears when I'm moving or very close to the wall. The resolution is set to 800x600, if that helps.

Share this post


Link to post

Might be an OpenGL Z-buffer issue when walls share exactly the same vertex coordinates, the Z-buffer has low resolution (only 16 bit), and patches are not drawn with a special OpenGL feature (Z-buffer offset).

If you can tweak your Z-buffer forced to 24 bit depth in your graphic driver (what kind of graphic card do you use, at all?), does that effect change?

BTW: Never upload uncompressed images like BMP or TGA, they waste much space and are not displayed in all web browsers directly, and not allowed as forum attachments often. Even freeware image viewers - like IrfanView or XnView - can convert them to lossless compressed PNG or lossy JPEG, and can be handled by all browsers and attached.

Share this post


Link to post
bgraybr said:

I've noticed that at very low resolutions, some textures and sprites aren't drawn properly, they "flicker" in and out of existence, and I can barely see some switches and lights. I can also occasionally see sprites through walls. Look at this image. There's supposed to be a switch there, but it only appears when I'm moving or very close to the wall. The resolution is set to 800x600, if that helps.


It helps if you set your depth size to 24

Share this post


Link to post
Kaiser said:

I tried repro'ing this on my end and I couldn't get this to happen. Not sure if this happened before though try double checking your bindings.

I tested this farther on another computer, and I think I figured out why other people haven't seen it. It does not happen if you use the mouse to fire.

Using the default bindings, it happens if you are holding either of the shift keys for run + either of the ctrl keys to shoot, and then you press forward. In that case you don't move forward.

If you're already moving forward before holding both keys at the same time, you do still keep moving forward. It's only if you try to move forward while already holding either shift + either ctrl that you can't move forward.

esselfortium said:

Are you sure it isn't a hardware issue with your keyboard, sector666? Some keyboards have problems with certain key combinations, due to some sort of manufacturing cost-cutting maneuver.

Yeah, I know some keyboards are really crappy. It happens if I use a gamepad as well, using JoyToKey to bind the ctrl and shift to gamepad buttons. So it can't be due to keyboard.

Thanks for the suggestion though.

esselfortium said:

I forget if Doom64EX has an "always run" mode, but try that, or try rebinding one or more of the relevant actions to a different key as a test to see if the behavior changes.

I tried binding L to run and P to fire, and using them movement worked like normal. I then unbound shift and ctrl from having anything assigned. Holding both ctrl and shift, even if they're unbound still prevents you from moving forward, unless you were already moving forward before you were holding both at the same time.

It's very strange. But it happened on both the winXP 32bit and win7 64bit PCs I checked on, and it's not a keyboard issue since like I mentioned it still happens checking on gamepad if I have ctrl and shift bound to gamepad buttons.

So bottom line it seems the problem is that holding ctrl+shift, no matter what's bound to them, won't let you move forward if you weren't already moving forward. Very odd.


Edit: I had forward bound to W the whole time I was testing, if that matters.

Share this post


Link to post
sector666 said:

I tested this farther on another computer, and I think I figured out why other people haven't seen it. It does not happen if you use the mouse to fire.


ah ha, okay I'll test that when I get home

Share this post


Link to post

I have now two versions of Doom Builder 2 for Doom 64 EX:

- The one Kaiser linked, 10. June 2010
- A slightly older via PM, 12. December 2009

I wonder if I missed something in the configuration, but both are unable to open DOOM64.WAD from Doom 64 EX.

After starting I get the following errors for both versions (but I believe they are just "work in progress" artifacts, nothing serious):

Unable to load the script configuration "ZDoom_ACS.cfg". Error: No such compiler defined: 'zdoom_acc'
Unable to load the script configuration "Skulltag_ACS.cfg". Error: No such compiler defined: 'skulltag_acc'
Could not load plugin "TrackBar.dll", plugin is missing the plug. This file is not supposed to be in the Plugins subdirectory.
Could not load plugin "Sharpzip.dll", plugin is missing the plug. This file is not supposed to be in the Plugins subdirectory.

When I open DOOM64.WAD, I have to select the Game Configuration "Doom 64" manually. But the list of maps available in this file stays empty.

If I add the DOOM64.WAD as ressource in the Game Configuration, opening the DOOM64.WAD automatically selects the Game Configuration "Doom 64", but still does not offer any maps.

At least I can open the maps I extracted as separate lumps (using XWE), as they are contained as "embedded IWADs" separately for each map, containing a MAP01 each.

Maybe I just expected too much. Then just tell me so, and I understand.

Share this post


Link to post
PaganRaven said:

so is this better than that Absolution TC? I'll check it out, I haven't played D64 in a long time.

Way better. This is Doom64, not a mod.

LigH said:

Maybe I just expected too much. Then just tell me so, and I understand.

It is so. It's clearly not finished and the limitations are evident. Time seems to be the issue here, or lack of it, and that is understandable.

Share this post


Link to post

@ PaganRaven:

Doom 64 EX tries to emulate the behaviour of the Nintendo 64 game as close as possible, requiring the original N64 ROM data even. I am testing the gaming experience of both Doom 64 EX and Doom 64 TC: Absolution and try to document the differences for the Doom Wiki, and I already found some quite obvious differences - in the level design (both sector and thing positions and behaviour) as well as in the available effects. Most obviously, Doom 64 TC does not support randomizing macros (e.g. MAP02: Terraformer - the teleported blue keycard), and does not support several lighting effects in the same way (e.g. MAP01: Staging Area - the rotating light column in front of the normal exit), probably not even the multiple out-of-order secret levels (which seems to be the reason why the TC rearranged the map order to a linear sequence, and returns to MAP01 after completing "Hectic").
__

@ iori:

Thank you. No problem. Now that I know I can at least get access to the single levels, I can continue my discoveries. I am far from creating own content anyway.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×