Jump to content


Regular Member
  • Content Count

  • Donations

  • Joined

  • Last visited

  • Days Won


sleirsgoevy last won the day on February 6

sleirsgoevy had the most liked content!

About sleirsgoevy

  • User Group: Regular Member

  • Rank: Member

  • Post Count: 36

  • Post Ratio: 0.73

  • Total Rep: 34

  • Member Of The Days Won: 12

  • Joined: 01/05/2020

  • Been With Us For: 49 Days

  • Last Activity:

  • Currently:


Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. As for the current status: the multiplayer mode is already fully functional, so I think it can already be played by normal gamers. I decided to implement a tiny gamemode selector, so there is no need to modify cmdline.txt to switch between modes. (A side note on "normal gamers": I suppose that gamers used to "official" console shooters (if any non-dev is going to play this port) will hate the controls, and the port itself as a consequence. They're not devs, so may not understand that this is a platform limitation.)
  2. The difference actually comes from caching the whole file in memory, not from it being outside the JAR. The engine does seek a lot, and InputStreams obtained from getResourceAsStream() are unfortunately non-seekable.
  3. It can now boot in under 15 seconds! The WAD file is now placed directly in the directory tree, not inside the JAR. It now also gets cached within a DVBBufferedImage which further speeds up loading.
  4. Peer discovery is now available via UDP broadcast. The (made-up) command line for that is -net ?<nplayers>. Unfortunately this means that the protocol is no longer compatible with LinuxDOOM. P.S. The code was mostly rewritten from the IPXSETUP code and uses a similar protocol.
  5. It is co-op by default, but deathmatch can be activated with the -deathmatch flag. (That's the vanilla behaviour, I didn't alter it).
  6. Some progress in implementing network play. As of now, I've basically implemented the necessary system calls (socket, sendto, recvfrom) using java.net.DatagramSocket as a backend. The protocol should be exactly the same as in vanilla LinuxDOOM, as I did not modify any functional parts. To play a network game, add the proper command line parameters (-net <consoleplayer> <peer_ip_addr>...) into cmdline.txt file in the disc root. P.S. It turns out that the BD-J build can play against the native build, so there is no need for a second console. P.P.S. It's not the final version, of course.
  7. By the way, I've uploaded a new version with minor improvements. See the github commit for more info. P.S. HSound does have an advantage over javax.media.Player, as it allows loading sound files from a byte array, not from disc
  8. As far as I understand, the protocol basically sends whole IPX packets as UDP datagrams to a relay server. Shouldn't be hard to implement if I get the local network to work properly.
  9. Well, I think the main two major pieces that are still missing are background music and network play. Regarding the music, DOOM uses a proprietary MIDI-like format (it isn't implemented in the released source code, so need to find some description), which meens it can be played (do I miss something?) by simply having an HSound for each possible note and starting them at the right time. Regarding network play, I see several options: Leave the port purely singleplayer. Seems odd as most games nowadays are multiplayer ones. However that's not true for Blu-Play. Leave the networking as it currently is (hardcoded UDP peers) and just implement the low-level send/receive functions. Probably the easiest to implement. Implement DosBOX's IPX tunneling protocol and port the original ipxsetup. This would allow network play with Chocolate Doom peers. Invent a brand new transport for DOOM packets. UDP broadcast may be a good choice. P.S. I think the key for simultaneous sounds is the use of separate sound files, not HSound. I used HSound instead of javax.media.Player just because the latter doesn't have a stop() method.
  10. Sound effects now finally work, I've uploaded an updated version. Will probably record a video demo now. https://youtu.be/81DbMsr2Pxc Interestingly enough, I don't have any problems regarding playing multiple streams at once.
  11. As reported earlier, the PS4's Blu-Ray is itself a Java application. I'm almost sure there are some platform-specific APIs that can't be reproduced within the official BD-J API (e.g. there might be an API for capturing gamepad input). So, could somebody with a jailbroken PS4 dump that JAR from the console?
  12. I finally found out what's wrong with my sound.bdmv. I also used the soungen tool, however I've modified that to eliminate the dependency on external codecs. It turned out that I was calculating the number of frames incorrectly, and the player thought it has only 4 samples.
  13. Well, I copy-pasted this code into my Xlet, but there is still no sound. Maybe there is some obscure option I need to set in some config file? EDIT: It now works with the sound.bdmv from Ukko's journey, however it doesn't with my own sound.bdmv. Probably my sound file is broken.
  14. I've added a webserver on port 4444 that serves DOOM save files (doomsav*.dsg), so a buggy save can now be downloaded. Unfortunately the exact file format is architecture-dependent, so it isn't possible to load the same save on the PC build. Interestingly enough, the Xlet can access the public Internet, but any attempts to connect to a host in the local network just times out.
  15. I currently seem to be unable to play anything from the sound.bdmv file. Both HSound and MediaPlayer don't throw any exceptions, but there's no sound out of the speakers. The sound.bdmv file I'm using has been generated using soundgen from HD Cookbook, however the file from Ukku's Journey doesn't play either. I use bd://SOUND:00 as a URL.
  • Create New...