Closed szsascha closed 5 years ago
Hey there, thank you for your interest!
I can't think of a reason why it wouldn't work in Eclipse off the top of my head. I develop in Eclipse myself and it works for me. I'm assuming you're supplying the same command-line parameters?
I would suggest adding some debug lines and doing a side-by-side comparison of the working case and the not-working case. There must be some difference there.
For example:
buf.remaining()
after line 77.bytesToSkip
after line 80.width
and height
after line 120.Ok, yesterday I were stupid... (of course)
In the Terminal I used "GFX/STADTFLD.BSH" and in Eclipse I used "GFX/TIERE.BSH". So the problem isn't Eclipse or Mac OS. The problem seems to be TIERE.BSH. "GFX/STADTFLD.BSH" worked in Eclipse on Mac OS.
But "TIERE.BSH" doesn't work in Terminal AND Eclipse.
java main.AnnoReader "anno" "GFX/TIERE.BSH" Reading palette Bytes remaining (inner): 421684 Bytes to skip: 2876 Width: 54; Height: 55 Saved image: out/TIERE.BSH_0.png 418058 bytes remaining Width: 12; Height: 12 Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Coordinate out of bounds! at sun.awt.image.IntegerInterleavedRaster.setDataElements(IntegerInterleavedRaster.java:301) at java.awt.image.BufferedImage.setRGB(BufferedImage.java:1016) at main.AnnoReader.readImage(AnnoReader.java:151) at main.AnnoReader.read(AnnoReader.java:91) at main.AnnoReader.main(AnnoReader.java:256)
On your README you have a list with all GFX files. Did you test them all?
Could you try GFX/TIERE.BSH by yourself to check if you're getting the same Exception?
Thanks in advance!
I have just tested all BSH files. I got "Coordinate out of bounds!" for the following ones:
I can confirm I got the same errors as you for those files - guess I only tested the working ones!
I'd have to compare to SirHenry's Grafx Tool to figure out what's going on here. Unfortunately I'm unlikely to have time for this anytime soon, but if you wanted to take a look I'd be really interested to hear your findings. His source code is here: https://github.com/wzurborg/grafx1602
Are you sure that it's working correctly in SirHenry's repository?
Last week I already looked on several C/C++ repositories. Unfortunately I could not solve it yet. Maybe I'll look at it again this weekend. As soon as I have a solution, I will create a pull request.
But I was able to find out a bit more about the BSH file format. Below my current status:
For each bsh / sprite sheet (bsh / sprite sheet header)
01 42 B - HEADER
02 53 S - HEADER
03 48 H - HEADER
04 00 Separator - HEADER (currently not sure)
05 XX UNKOWN - HEADER
06 XX UNKOWN - HEADER
07 XX UNKOWN - HEADER
08 00 Separator - HEADER (currently not sure)
09 40 UNKOWN CONSTANT - HEADER (currently not sure)
10 00 Separator - HEADER (currently not sure)
11 XX UNKOWN - HEADER
12 XX UNKOWN - HEADER
13 XX UNKOWN - HEADER
14 XX UNKOWN - HEADER
15 40 UNKOWN CONSTANT - HEADER (currently not sure)
16 00 Separator - HEADER (currently not sure)
17 XX FILE LENGTH (without 20 byte header)
18 XX FILE LENGTH (without 20 byte header)
19 XX FILE LENGTH (without 20 byte header)
20 XX FILE LENGTH (without 20 byte header)
21 XX FIRST IMAGE OFFSET (Total number of images = FIRST IMAGE OFFSET / 4) descending order?
22 XX FIRST IMAGE OFFSET (Total number of images = FIRST IMAGE OFFSET / 4) descending order?
23 XX FIRST IMAGE OFFSET (Total number of images = FIRST IMAGE OFFSET / 4) descending order?
24 XX FIRST IMAGE OFFSET (Total number of images = FIRST IMAGE OFFSET / 4) descending order?
.. XX 4 byte's for every image (containing the begin of the offset)
.. XX 4 byte's for every image (containing the begin of the offset)
.. XX 4 byte's for every image (containing the begin of the offset)
.. XX 4 byte's for every image (containing the begin of the offset)
For each image (image header):
offset + 01 XX IMAGE WIDTH
offset + 02 XX IMAGE WIDTH
offset + 03 XX IMAGE WIDTH
offset + 04 XX IMAGE WIDTH
offset + 05 XX IMAGE HEIGHT
offset + 06 XX IMAGE HEIGHT
offset + 07 XX IMAGE HEIGHT
offset + 08 XX IMAGE HEIGHT
offset + 09 XX IMAGE TYPE
offset + 10 XX IMAGE TYPE
offset + 11 XX IMAGE TYPE
offset + 12 XX IMAGE TYPE
offset + 13 XX LENGTH (bytes? or maybe bytes per pixel?)
offset + 14 XX LENGTH (bytes? or maybe bytes per pixel?)
offset + 15 XX LENGTH (bytes? or maybe bytes per pixel?)
offset + 16 XX LENGTH (bytes? or maybe bytes per pixel?)
XX FE END OF LINE
XX FF END OF IMAGE
For each pixel:
01 XX TRANSPARENCY - How many of the following pixels on the x-axis are transparent?
02 XX COLORED PIXELS - How many colored pixels are following?
.. XX COLOR CODE - Color code of STADTFLD.COL color palette for each following pixel
First 2 numbers per Line: position Following 2 numbers per line: constant / value Following text: description
Maybe I will develop my own implementation and create my own repository and document the individual Anno 1602 formats there. (Just for the challenge) If I continue to follow it I will definitely fix the bug in your repository first.
Nice find!
Sir Henry's Grafx Tool claims it can read ALL graphics from the game, but it's been a long time since I've tried it.
I'd be really interested in any further findings you make or any related work you carry out. I've always wanted to recreate this game someday but sadly I don't have the time for such a big project.
Sounds nice! I'm interested in something similar, but I also have no time. :(
In my opinion, Anno 1602 still has a great multiplayer potential and makes multiplayer today still a lot of fun. A remake could make the multiplayer mode more stable, improve the combat system and fix many annoying bugs. In addition, I see a good future for this "simple" gameplay as a kind of browser game. Hopefully https://github.com/cmfcmf/Anno2018-js will fulfill our wishes. ;)
What ever. Unfortunately, I had no time this weekend. As soon as I have something new, I will keep you informed!
The multiplayer has a LOT of potential. I think it could use some more victory conditions and map customisation. Support for higher resolutions would be high up on my list as well.
Fingers crossed, this game will live on 🤞
Got it!
Today I've found time to look into it again. After almost exactly one month I fixed it now. I've created a pull request. See #2.
The main problem was the comment "More unknown bytes to follow but at least we know how many!". I guess because of that you did some incorrect things to get the next offset in readImage (See comment "Skip to the next offset that's divisible by 4"). Actually, it would have worked. But the BSH files are not always correct. Thanks to @roybaer's mdcii-engine I've learned that. (See https://github.com/roybaer/mdcii-engine/blob/master/src/generischer_bsh_leser.hpp)
But many thanks for your AnnoReader project! It's a great tool!
I've learned a lot about many different topics of programming with this little challenge. Now I also know pretty much how the bsh files are working. Maybe I will document it in a separate repository and start a small project as well.
For those interested: Please note that the above file description is not completely correct and incomplete.
@SaschaS93 - thanks so much for your contribution, I really appreciate you taking the time to fix this project! Please keep me updated with any Anno-related projects you decide to undertake :)
Hi!
Thank you for your great work!
Unfortunately I got some strange behaviour on my system. I copied the "AnnoReader" class into Eclipse and got the following output:
But if I compile it via javac in the terminal (as you describe) it works. Currently I don't understand why it doesn't work in Eclipse.
I suspect ByteOrder.LITTLE_ENDIAN. Maybe that works a bit differently on MacOS. Reading the color palette works fine.
Some informations about my System: macOS 10.14 Java JDK 1.8.0_111 Eclipse IDE for Java Developers Oxygen.3a Release (4.7.3a)
I would really appreciate a solution or a simple workaround!