Jump to content


Regular Member
  • Content Count

  • Donations

  • Joined

  • Last visited

  • Days Won


sleirsgoevy last won the day on January 23

sleirsgoevy had the most liked content!

About sleirsgoevy

  • User Group: Regular Member

  • Rank: Member

  • Post Count: 26

  • Post Ratio: 1.37

  • Total Rep: 24

  • Member Of The Days Won: 8

  • Joined: 01/05/2020

  • Been With Us For: 19 Days

  • Last Activity:

  • Currently:


Recent Profile Visitors

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

  1. 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?
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. Game saves are now properly written to the VFS persistent directory, and are retained across disc removes.
  8. I tried to join that, but Discord says that the link is invalid.
  9. 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.
  10. 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.
  11. I've updated the port to treat the R1 button the same as the up arrow.
  12. 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.
  13. 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
  14. 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.
  15. 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.
  • Create New...