My latest MSX game: Westen House

Página 15/17
8 | 9 | 10 | 11 | 12 | 13 | 14 | | 16 | 17

Por shaiwa

Champion (392)

Imagen del shaiwa

09-05-2023, 20:35

@santiontanon, thank you for the fast response, did read that but didnt do that first (and forgot about it), there is an src/autogenerated folder in the original download.
Tried to run main.java with the latest javac from jdk but its giving "cannot find symbol errors"
My first time compiling with java (I'm used to c/c++) and seems simple but probably have to do some setup somewhere?

Por santiontanon

Paragon (1810)

Imagen del santiontanon

10-05-2023, 01:29

ah, yeah, if you do not have an IDE (Netbeans, Eclipse, IntelliJ, etc.) it's a bit of a pain. With an IDE it's super easy. I just open Netbeans, new project, add that "java/src" folder as the source folder, and then just "right click on Main.java -> Run" Smile If you just want to do it manually, without an IDE, the common way is to use "ant" (the equivalent of "make" in the C/C++ world).

In any case, I just tried to do this myself (cloned the github into an empty folder and run ./build). I think I see your problem. I did not include the "zx0" binary in the github project (as that is an OS-dependent binary). The "zx0" binary should be placed in the "java" folder, you can get the sources from this github repo to compile it: https://github.com/einar-saukas/ZX0

Once I put that zx0 file there, a working .rom was generated. So, it seems the files in GitHub are fine. But I might have to add a comment about zx0 :)

Por cjs

Expert (111)

Imagen del cjs

10-05-2023, 05:29

santiontanon wrote:

Once I put that zx0 file there, a working .rom was generated. So, it seems the files in GitHub are fine. But I might have to add a comment about zx0 Smile

Yeah, you do mention it in the README, but putting a comment in that file would also be helpful. You might also consider doing a set -e at the start so that the script doesn't try to continue after an error, and definitely a shebang (#!/usr/bin/env bash) would be a good idea.

The way I'd normally deal with this is to clone a copy of the dependency (zx0) and build it right there. I actually tweaked the build script to do this, but I don't recall now why I never carried through to the end of building the whole thing.

Note that the Makefile for zx0 wants to use owcc, the Open Watcom C Compiler, and the COPTS for it are different from those you'd use with GCC. I did something along the lines of make CC=gcc COPTS='' and it compiled, but it was somewhere shortly after that that I stopped, so I don't know if zx0 actually worked. (I don't see any reason it wouldn't, though. Without optimisation it might be slower, but that should be no big deal; it won't affect decompression speed.)

I suppose I could get back to working out a cleaner and more automated build, if there's any particular interest in it. (Doing build systems is a big part of my day job, so this stuff isn't particularly difficult for me, but some people find my code overly complex since I'm more focused on "make it work easily for people who don't use it frequently" than "minimise the code in the build system.")

Por shaiwa

Champion (392)

Imagen del shaiwa

10-05-2023, 14:22

Yes, Zx0 exe is mentioned in the readme and was placed in de jave dir like mentioned, rom generation was not a problem, but the rom did not work and is different with the working rom that was shipped with the source zip so thats why i did post the question if anyone did compile the source supplied on github.
Did already search and found a few java IDE so thnx for the tip, going to try Netbeans IDE this evening.

Por santiontanon

Paragon (1810)

Imagen del santiontanon

10-05-2023, 16:23

@cjs: ah, good suggestions on the set -e and the shebang! I'll add for the next projects!

@shaiwa: I am curious about the rom that you got produced that is different. Do you have a binary diff, or alternatively just put the rom somewhere so I can inspect? As mentioned above, I just checked out the github repo in a clean folder, added zx0 and built, and then I got an identical ROM to the official one. So, I am curious to see what could be happening

Por Grauw

Ascended (10772)

Imagen del Grauw

10-05-2023, 17:37

On a recent project I used lz4 (hc) because compressors are easily available on all systems and in programming language packages (e.g. Node.js has several), and the decompressor was also easy to write. Worked in one go, surprisingly.

Later I checked out some other compressors to see if I could save more space, based on them scoring higher in some compression size charts, amongst others zx0, pletter and lzsa2. But to my surprise on my particular data set (music and graphics data) the results were not as good as I was led to believe from those charts. They did better in some files worse in others, and overall most of the compressors I tried actually got a lower compression rate in total, or in one case only marginally better, just a few tens of bytes rather than the 25% difference I was expecting.

All this while more niche compressors like zx0 definitely have downsides, such as lack of availability in standard packages, lack of prebuilt binaries for certain OS-es, lack of documentation, much slower compression, and also the OWCC compiler dependency for zx0 is unusual and an additional obstacle to include it in a build process, not a big fan.

The lesson for me is, don’t take those charts as gospel, and lz4 is not necessarily compressing as badly as they make it seem. Test on your specific data of course, but really, to me they all seemed to get roughly similar results so choice of compression won’t matter that much in the grand scheme of things and you should also take into account other factors.

Por santiontanon

Paragon (1810)

Imagen del santiontanon

10-05-2023, 18:50

Very true!! I have seen that as well! In the Menace from Triton what I saw is that depending on the type of data (text, graphics, or maps) Pletter or ApLib were better, but none of them was better overall (I had not discovered zx0 by then), and maps in particular were most compressed by first compressing with pletter, and THEN with ApLib afterwards (I tried all combinations haha), and the savings were enough to justify including both decompressors in the game. So, I ended up using a combination, which was necessary to fit all in 48kb haha

Por Arjan

Paladin (787)

Imagen del Arjan

10-05-2023, 20:04

@Grauw: With LZ4 you mean this one: https://github.com/lz4/lz4 ?

LZ4 HC is activated by specifying option --best right?

I tried compressing some files (code, music, graphics) with LZ4 but the compressed files were all about 30% bigger than the results I got with ZX0. Of course the compression ratio can vary between tools depending on what kind of files you try to compress, but it's a bit strange you didn't observe such big differences.

LZ4 does compress fast though, that's nice. ZX0 is very slow (even when specifying option -q).

Por shaiwa

Champion (392)

Imagen del shaiwa

10-05-2023, 21:05

@santionanon, did some screenshots into a docx file and the compiled rom into a zip file here.
[edit]What kind of new project do you use in NetBeans? I'm unable to add a source folder under sources in the default properties.

Por cjs

Expert (111)

Imagen del cjs

10-05-2023, 21:44

Grauw wrote:

All this while more niche compressors like zx0 definitely have downsides, such as lack of availability in standard packages, lack of prebuilt binaries for certain OS-es, lack of documentation, much slower compression, and also the OWCC compiler dependency for zx0 is unusual and an additional obstacle to include it in a build process, not a big fan.

I don't think that OWCC is a dependency; it compiled fine for me with GHC (though I didn't actually compress anything with it). CC=owcc just happens to be what they defined in the Makefile.

But as far as which one to use, I'd say just have your build system try different builds with all of them and pick the best. :-)

Página 15/17
8 | 9 | 10 | 11 | 12 | 13 | 14 | | 16 | 17