Jump to content

mr_lou

Developer
  • Content Count

    93
  • Donations

    $0.00 
  • Joined

  • Last visited

  • Days Won

    12

Reputation Activity

  1. Upvote
    mr_lou reacted to sleirsgoevy in DooM I (1993) running on Blu-Play   
    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. Upvote
    mr_lou reacted to sleirsgoevy in DooM I (1993) running on Blu-Play   
    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. Like
    mr_lou got a reaction from sleirsgoevy in DooM I (1993) running on Blu-Play   
    Any news?
     
    Is the project ready to be added to the Games section at blu-play.com yet? 🙂
  4. Upvote
    mr_lou reacted to sleirsgoevy in DooM I (1993) running on Blu-Play   
    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.
  5. Upvote
    mr_lou reacted to sleirsgoevy in DooM I (1993) running on Blu-Play   
    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.
     
     
  6. Upvote
    mr_lou reacted to sleirsgoevy in DooM I (1993) running on Blu-Play   
    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.
  7. Upvote
    mr_lou reacted to sleirsgoevy in DooM I (1993) running on Blu-Play   
    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).
  8. Upvote
    mr_lou reacted to sleirsgoevy in DooM I (1993) running on Blu-Play   
    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.
  9. Upvote
    mr_lou reacted to sleirsgoevy in DooM I (1993) running on Blu-Play   
    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
  10. Upvote
    mr_lou reacted to sleirsgoevy in DooM I (1993) running on Blu-Play   
    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.
  11. Upvote
    mr_lou reacted to sleirsgoevy in DooM I (1993) running on Blu-Play   
    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.
  12. Upvote
    mr_lou reacted to sleirsgoevy in DooM I (1993) running on Blu-Play   
    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.
  13. Upvote
    mr_lou reacted to sleirsgoevy in BD-J -- sound.bdmv does not play   
    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. Upvote
    mr_lou reacted to sleirsgoevy in DooM I (1993) running on Blu-Play   
    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. Upvote
    mr_lou reacted to sleirsgoevy in BD-J -- sound.bdmv does not play   
    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.
     
  16. Like
    mr_lou got a reaction from GregoryRasputin in Blu-Play Discord Server   
    A Blu-Play Discord server has been created.
     
    Feel free to drop by.
     
    https://discord.gg/qeQbMd
     
    https://discord.gg/7bkeJEP
  17. Upvote
    mr_lou reacted to sleirsgoevy in DooM I (1993) running on Blu-Play   
    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. Upvote
    mr_lou reacted to sleirsgoevy in DooM I (1993) running on Blu-Play   
    Game saves are now properly written to the VFS persistent directory, and are retained across disc removes.
  19. Upvote
    mr_lou reacted to sleirsgoevy in DooM I (1993) running on Blu-Play   
    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.
  20. Upvote
    mr_lou reacted to sleirsgoevy in Cibyl -- compile C to Java   
    A few other things I noticed while making that demo:
    Floating-point arithmetic in Cibyl is dog slow, as each operation involves 3 nested Java method calls. The same demo using doubles only gave 1-2 FPS. (Maybe it'll be a bit better if I use float instead of double). The transpiler doesn't handle GCC optimization levels larger than -O1 correctly. It does compile and run without crashing, but results in a black screen.
  21. Upvote
    mr_lou reacted to sleirsgoevy in Cibyl -- compile C to Java   
    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. Upvote
    mr_lou reacted to sleirsgoevy in DooM I (1993) running on Blu-Play   
    I've updated the port to treat the R1 button the same as the up arrow.
  23. Upvote
    mr_lou reacted to sleirsgoevy in DooM I (1993) running on Blu-Play   
    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.
  24. Upvote
    mr_lou reacted to sleirsgoevy in Cibyl -- compile C to Java   
    It's not mine of course, I just crafted a simple usage example that works, since some aspects are not trivial to figure out. Please note that on blu-play.com.
    Also you've set an incorrect date on the news. It's year 2020 now.
  25. Upvote
    mr_lou reacted to sleirsgoevy in Cibyl -- compile C to Java   
    I've prepared a small project that demonstrates the use of the Cibyl MIPS-to-Java compiler to run C code in the BD-J environment. This compiler may be useful for porting existing C games into Java. However the transpiled code is a bit slower than native Java code, so this is more for porting existing software, which is going to be troublesome as BD-J has only several megabytes of RAM, and new games should (probably) be developed directly in Java.
    Anyway, I've uploaded the example of using cibyl to GitHub.
×
×
  • Create New...