Jump to content

sleirsgoevy

Regular Member
  • Content Count

    37
  • Donations

    $0.00 
  • Joined

  • Last visited

  • Days Won

    13

Everything posted by sleirsgoevy

  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.
  16. 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.
  17. I've just captured myself passing the first 2 levels of DOOM using the BD-J port. Unfortunately the game crashed after trying to load a save, so I couldn't demonstrate that saves do actually work. Now I'll need to download that save file in some way, so that I can debug it in VLC. Anyway, I've posted the video on Youtube here.
  18. Game saves are now properly written to the VFS persistent directory, and are retained across disc removes.
  19. I tried to join that, but Discord says that the link is invalid.
  20. It turned out that the gameplay bugs (broken elevators and E1M2 being impossible to pass) were caused by a Cibyl bug resulting in incorrect integer comparison. After fixing that bug, E1M2 can now be passed. I've uploaded a fixed binary build. No source code changes were necessary.
  21. It seems that I've found a bug in Cibyl (or in Cibyl's GCC, didn't check that yet) resulting in the code behaving incorrectly. The test case is as follows: int main() { volatile int a = 46; volatile int b = -2147483637; assert(!(a < b)); return 0; } As the transpiler seems to be unmaintained, I will probably have dig into that myself. EDIT: I figured out the cause of the problem. The transpiler effectively replaced a<b here with a-b<0, and that is true due to integer overflow. EDIT 2: FIXED. Github fork with the fix is here, and the modified xcibyl-translator can be downloaded here.
  22. I've updated the port to treat the R1 button the same as the up arrow.
  23. No, it is not supposed to render to the whole screen. 576x324 is including the unused area. added 1 minute later About the buttons: I mean that leaving some buttons unused (or with the same function as others) would create a shortage of buttons, as there are only 11 usable.
  24. Regarding the video, the DVBBufferedImage used as a framebuffer is just 576x324, and is blitted to the whole screen in a single drawImage. I actually keep the full HD resolution just to keep a fancy console font, and not make it look like an actual BIOS console. As for the controls, I thought of moving some of the movement buttons to L2/R2, however that would leave two directional buttons unused, and using some of them for movement and some for other actions seems too awkward. Maybe the 2 other buttons may be used to change weapons though. As for the sound, I think that creating such sound files may be illegal, as they will definitely be a derivative work of the DOOM Shareware .wad file, whose license only allows sharing the unmodified version. Is there really no way to play a sound file from memory? P.S. I think fixing bugs is still the top priority
  25. It seems I've (semi-)successfully ported DOOM I (1993) to BD-J, using Cibyl MIPS-to-Java transpiler. It basically works, however there are still bugs that don't allow to finish the second level. The porting process was relatively straightforward, except for several corner cases like unaligned access and different endianness, as the OS-dependent parts of the game are abstracted from the engine itself. However, as for now only video output and controller input have been implemented. The source code is on GitHub. P.S. Google says that DOOM source code has been published twice with different licenses, and the comments in the source imply that it's the non-free version. Because of this I don't know if it's even legal to publish a modified version on GitHub. P.P.S. I've uploaded a binary version of the port to Google Drive. The archive contains files from PS3 BD-J SDK and the compiled JAR.
×
×
  • Create New...