jnmartin84 / 64doom Goto Github PK

Now that 64Doom is using DFS this would be a major improvement and not difficult, I can probably throw this together in one morning.

Directory listing, filter out everything that doesn't end in .WAD, select with controller, onto D_DoomMain

Can you please confirm which version of windows you have this running on please?
I've used your previous 2014 version successfully and I was thrilled to see a new release with enhancements but this is not working for me on Windows 10 64 bit today.

I tried this with the BAT file and that failed, it complained about an incompatible version of cygwin1.dll in x:\cygwin\bin - this is despite the fact that the same dll file is in the directory itself as well as in c:\cygwin\bin

I figured it was a 32/64bit issue so I installed both and it still fails with the same error message.

Now I figure I should just run the .SH file from within cygwin but it appears that my cygwin installation isn't working properly either and I can not figure out why just yet. I have reinstalled it dozens of times and its not working on either 32 or 64 bit with vastly different errors on both.

I'm not even able to get to the numbered menu to select which game to build. I see you have made another commit since the release but I'm confident it is not that significant.

Here's what it's complaining about.

i_video.c:56:16: error: implicit declaration of function 'display_get'; did you mean 'display_init'? [-Werror=implicit-function-declaration]
   56 |         return display_get();
      |                ^~~~~~~~~~~
      |                display_init
i_video.c:56:16: error: returning 'int' from a function with return type 'surface_t *' {aka 'struct surface_s *'} makes pointer from integer without a cast [-Werror=int-conversion]
   56 |         return display_get();
      |                ^~~~~~~~~~~~~
i_video.c:60:16: error: implicit declaration of function 'display_try_get' [-Werror=implicit-function-declaration]
   60 |         return display_try_get();
      |                ^~~~~~~~~~~~~~~
i_video.c:60:16: error: returning 'int' from a function with return type 'surface_t *' {aka 'struct surface_s *'} makes pointer from integer without a cast [-Werror=int-conversion]
   60 |         return display_try_get();
      |                ^~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

While playing Ultimate Doom, I noticed that sometimes switches do not show the 
correct state. You might activate a switch, but it does not visually show or 
audibly signal that it has been switched on/off. Not sure if this is also an 
issue in Doom 2 or the other supported game versions.

Original issue reported on code.google.com by [email protected] on 30 Oct 2014 at 5:58

F_DrawPatchCol still has a sneaky vertical offset in it (SCREENWIDTH>>4). It is non-obvious because it is a leftover from when I had compile-time support for 640×400 high-res. The bunny scroller after Doom 1 Episode 3 is broken. Fixing this.

I am trying to create a ROM as per the instructions in the README but I am getting an N64TOOL error. It says to check for other on-screen error messages but there are none so I have no idea what the issue might be.

Here is my compiler:

env IWAD_DIRECTORY="~/IWADS" IWAD_PREFIX="PLUTONIA" make
/opt/libdragon/bin/mips64-elf-ld -o PLUTONIA.elf obj/i_sound.o obj/endoom.o obj/dll.o obj/hash.o obj/lzfx.o obj/i_video.o obj/i_input.o obj/doomdef.o obj/doomstat.o obj/dstrings.o obj/i_system.o obj/i_net.o obj/r_draw.o obj/v_video.o obj/f_finale.o obj/f_wipe.o obj/d_main.o obj/d_net.o obj/d_items.o obj/g_game.o obj/p_saveg.o obj/m_menu.o obj/m_misc.o obj/m_argv.o obj/m_bbox.o obj/m_cheat.o obj/m_random.o obj/am_map.o obj/p_ceilng.o obj/p_doors.o obj/p_enemy.o obj/p_floor.o obj/p_inter.o obj/p_lights.o obj/p_map.o obj/p_maputl.o obj/p_plats.o obj/p_pspr.o obj/nodereorder.o obj/p_setup.o obj/p_sight.o obj/p_spec.o obj/p_switch.o obj/p_mobj.o obj/p_telept.o obj/p_tick.o obj/p_user.o obj/r_bsp.o obj/r_data.o obj/r_main.o obj/r_plane.o obj/r_segs.o obj/r_sky.o obj/r_things.o obj/w_wad.o obj/wi_stuff.o obj/z_zone.o obj/st_lib.o obj/st_stuff.o obj/hu_stuff.o obj/hu_lib.o obj/s_sound.o obj/info.o obj/sounds.o obj/i_main.o --gc-sections -G4 -g -L/opt/libdragon/mips64-elf/lib -ldragon -lc -lm -ldragonsys -Tn64.ld
/opt/libdragon/bin/mips64-elf-ld: obj/i_video.o: in function `lockVideo':
(.text.lockVideo+0x8): undefined reference to `display_get'
/opt/libdragon/bin/mips64-elf-ld: (.text.lockVideo+0x10): undefined reference to `display_try_get'
/opt/libdragon/bin/mips64-elf-ld: obj/i_video.o: in function `I_StartFrame':
(.text.I_StartFrame+0x8): undefined reference to `display_get'
make: *** [Makefile:121: PLUTONIA.elf] Error 1

I've made sure i'm using the unstable branch. What is happening?

Work-in-progress to fix this but the way the loops are nested in the mixer currently, every sample of mixed audio reads and modifies the output buffer once per channel.

Invert the loops and double-check in compiler output that channels are being mixed in a register. Only write output buffer once per mixed sample. Never read output buffer.

Doom uses lookup tables for fixed-point trig approximations.

I did an experiment in the past using cached vs uncached accesses for these and it performs the same which suggests to me if we can find a fast way to approximate in code, not using memory, it wont hurt anything and it might improve performance.

They are currently always accessed uncached in 64Doom. These accesses are hundreds of cycles.

Some of these may be able to be approximated in other ways.

I started by looking at the simplest case of tantoangle.

It can be fit with the following with acceptable results:
#define tantoangle(x) ((angle_t)((-47*((x)*(x))) + (359628*(x)) - 3150270))

3 multiplies, 1 add, 1 sub. Not hundreds of cycles.

Looking at the rest of the tables to see what can be done.

There is a bug in the implementation of "n64_memmove" that causes it to fail copying data correctly in certain situations.

Given the function prototype:
void *n64_memmove(void *dest, const void *src, size_t size)

When src and dest are both aligned, any bytes from src data after ((size >> 2) * 4) will not be copied into dest. Instead, an undefined value will be copied into dest[((size >> 2) * 4)] through dest[size].

I am running this on Windows 10 64bit for reference.

Please mention in the readme that in order for this to work on windows if you are getting a "'\r': command not found" error on multiple lines you must open MAKE_DOOM.sh in Notepad++ navigate to Edit->EOL Conversion->Unix then save the file and run MAKE_DOOM.bat and make sure you put your wads in the wadfiles directory.

CRT TVs would often show the image with a big amount of overscan - that means that edges of the image as rendered would actually show up outside of the TV's screen. For this reason, commercial game developers were advised to keep crucial HUD elements outside of the overscan area. The overscan area can be seen in red on this image (curtesy of the 240p test suite) and it comes out to roughly 10 pixels on each side.

64doom is currently not overscan safe and playing on a period CRT TV with overscan means some information is outside the visible area.
What would need to be done to account for overscan:

1. Item pickup messages in the top left need to be moved lower and further right.
2. The status bar needs to be moved higher or ideally redesigned entirely. Sources for inspiration include DOOM 64's HUD, Crispy Doom's transparent HUD, or Quake 64's HUD.

I realize that this issue is a combination of low priority and annoying to implement (because of how DOOM's message system works, in particular) but I wanted to list it for completeness.

I've tried building the game with multiple WADs now, all of which fail to launch on RetroArch with the ParaLLEl N64 and get as far as the screenshot below on Mupen64Plus-Next.

There are no logs in the RetroArch logs folder so I can't provide them.

The built ROM does however play using the emulator Simple64: https://github.com/simple64/simple64

Libdragon supports reading from the SD card, so it would be nice to support reading WADs from there as well, then there'll be no need to have one rom file per game.

Can reduce the size of the memset by 20 rows

Even better would be using an RDP filled rectangle

After building the ROM with the Makefile (so far, I tried Ultimate DOOM and DOOM 2), and launching, the game goes into "LibDragon inspector" after the InitTextures function call.

Built on latest unstable branch libdragon.

Sometimes the input handling gets into a weird state and strafing sticks.

Mostly noticed after doing the cheat input for iddqd + idkfa (L+R).