Jump to content

sleirsgoevy

Regular Member
  • Content Count

    37
  • Donations

    $0.00 
  • Joined

  • Last visited

  • Days Won

    13

sleirsgoevy last won the day on March 28

sleirsgoevy had the most liked content!

About sleirsgoevy


  • User Group: Regular Member


  • Rank: Member


  • Post Count: 37


  • Post Ratio: 0.39


  • Total Rep: 35


  • Member Of The Days Won: 13


  • Joined: 01/05/2020


  • Been With Us For: 95 Days


  • Last Activity:


  • Currently:


Clubs

Recent Profile Visitors

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

  1. I finally got myself onto it again, so I publish a new version. Changes from the previous version: * Background music is finally implemented via (sort of) MIDI player (The quality sucks though, and it eats almost 1MB of Java heap). * X key now sends both KEY_ENTER and KEY_RSHIFT, to allow running (sadly we're out of keys...) * Fixed the 1000x0 issue Download link: https://drive.google.com/file/d/1MIA8RyBcpM_6PQraKvfbWHlas9x_7cAl/view?usp=sharing (Side note on the key shortage: it may be possible, with some effort, to intercept the "Flick Left/Flick Right" events (+-15s on PS4, don't know if these can be easily triggered on other devices) and e.g. remap them to "prev/next weapon" to gain 2 more buttons.) EDIT: the port can now handle OOM in MUSFile constructor.
  2. 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.)
  3. 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.
  4. 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.
  5. 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.
  6. 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).
  7. 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.
  8. 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
  9. 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.
  10. 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.
  11. 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.
  12. 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?
  13. 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.
  14. 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.
  15. 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.
×
×
  • Create New...