henne/bright-eyes

"Bright Eyes" is a variation of DOSBox with customized support for the CRPG "Das schwarze Auge 1 - Schicksalsklinge"

bright-eyes's Issues

Bright Eyes: Spell cast "Skelettarius" is corrupted

The spell cast "Skelettarius" does not show a zombie, but a copy of the sorcerer. As soon as the zombie should move, Bright Eyes crashes.

See bottom left in the screenshot:

traveling times for ship passages

I think I found a bug. Not a bug in the original game (there are many), but a bug in BrightEyes where the game behaves differently than the original one.

In BrightEyes, it occasionally happens that a sea passage is announced with a traveling time of 0 hours, which never happened to me in the original game. I observed that in these situations, negative numbers do show up in the computations in the function get_passage_travel_hours(..) in seg063.cpp. By trial and error, I was able to fix this in my fork. However, I don't understand what the real problem is and I would like to have a better understanding. It seems that BCC and gcc are interpreting some type cast in an incompatible way.

Also, I find this a bit scary. We trust BrightEyes in exactly reproducing the original game since BCC produces the same machine code from the BrightEyes C code. But as we've seen, it might happen that gcc has a different interpretation of the C code. Are there more places like this? It would be great to have an automated way to scan the BrightEyes code for potentially problematic places.

There is a second incompatibility concerning sea traveling times. In the original game, sometimes super slow passage times show up. People have witnessed announcements of 210 hours (route Prem-Hjalsingor), and real in-game traveling times of about 2 weeks, see the discussion around this post. In BrightEyes, I've never seen these excessively slow ship passages.
I've studied the BrightEyes code for the sea travel times quite a bit. As a conclusion, the highest possible announced travel time for Prem-Hjalsingor should be 70 hours. It might well be possible that the BrightEyes behavior is the one which was originally intended by the Attic programmers, and that the super slow ships are the result of a (typecasting?) bug. But of course, this buggy behavior should be reproduced by BrightEyes.
I've stared quite some time at the code to guess the potential source of this incompatibility, but to no avail so far. Maybe someone with better low level debugging skills might help me out ? (By looking at the development of the exact memory content during the computation of the travel times, once in the original game and once in BrightEyes...)

Infinite loop in FIG_choose_next_hero()

Under unclear circumstances we can get an infinite loop here.
A first idea is the variable at (hero + 0x83), which meaning is atm unknown.

Original-Bug: Compass disappeares

The compass does not get drawn, when a game is loaded from a temple and the savegame is in a dungeon.

If the savegame is in a city it works correct.
If the savegame is reloaded from within the dungeon, it works correct, too.

Bright Eyes: SDL.dll wrong?

The SDL.dll in the archive is different from the SDL.dll from the Heldenedition (297 KB compared to the original 438 KB).

As a consequence there seems to be an issue with number pad inputs: All number inputs are not shown correctly and not interpreted correctly, see screenshot where I actually typed in "10" but nothing is shown - even no underscores.

Tested under Windows 7 64bit.

repair of magical items even if it is not needed

Bright Eyes repairs some magical items even if it is not needed.
Bug Report: http://www.crystals-dsa-foren.de/showthread.php?tid=700&pid=114430#pid114430

Commit "M302de: repairs magical items" from Oct 28, 2012

Original-Bug: get_random_hero() can loop forever

The function get_random_hero() can loop forever, if all positions of the current group heros are greater than the number of heros in the group.

It can best figured out with one hero who is not in the first position.
If you walk through the city and trigger a city event (Thorwal 1%) you often get this endless loop.

saving in gen105

in gen105_seg002 update_hero_out() Zeile 1336
ersetze hero.attribs[0] durch hero.attribs[i]
for (i = 0; i < 14; i++) {
hero_writeb(0x1360 + i * 3 + 0, hero.attribs[0].normal);
hero_writeb(0x1360 + i * 3 + 1, hero.attribs[0].current);
hero_writeb(0x1360 + i * 3 + 2, hero.attribs[0].mod);
}

in gen105_seg002 save_chr() Zeile 2464
ersetze "w+" durch "wb" (oder "w+") um willkürliche Zeilenumbrüche zu verhindern.
/* here originally creat() was used */
fd = fopen(filename, "w+");

access to status bits

in v302de.h, there are functions for reading hero/monster status bits, like hero_dead(...). However, I cannot find functions for setting status bits. Is there a reason for this? It would be much nicer to have hero_unset_dead(hero) instead of and_ptr_bs(hero + HERO_STATUS1, 0xfe)

Thank you!

Build Error - Windows

Build Error with the new release. Perhaps with this error message?

1>BSCMAKE: error BK1506 : Datei ".\Release\hardware.sbr" kann nicht geöffnet werden: No such file or directory

http://www.crystals-dsa-foren.de/showthread.php?tid=700&pid=124349#pid124349

FIG_choose_next_enemy() can loop forever

Today I got an infinite loop in FIG_choose_next_enemy().
There is atm no reason to me why this had happened.

Typo-de: Magieresitenz

String 98: Magieresitenz -> Magieresistenz

How Ida to dosbox pseudo code is done?

I'm doing similar thing with my masm2c.
How did you converted ida/asm to dosbox pseudo instructions?

Original-Bug: Infinite Loop in loose_random_item()

Happens if the selected hero has nothing left to loose.

Original-Bug: permanent LE-damage is deleted on game end

If a hero suffered permanent LE-damage and finishes the game, the variable (hero + 0x7a) is set to 0.

The best soulution is to restore the hero completely.

Bright Eyes character generation stores CHR files in wrong directory

all new generated chars are not saved in the "DSA1 folder" but in the folder where the DOSBox.exe file is located.
In the game the new generated chars cannot be imported into the game.

Also the created CHR file has a different file size: 1757 bytes compared to 1754 bytes.

Tested under Windows 7 64bit.

Original-Bug: Infinite loop in GRP_switch_to_next()

1. split heros in two groups
2. break with one group into a house and get captured, the other group gets selected
3. break with this group into a house and get captured
4. infinite loop

Original-Bug: invalid number of items

DSA1 has a field to count the number of items a hero has.
This number gets out of sync and may result in crashes, when the savegame is imported in DSA2.

Bright-Eyes crashes if a enemy mage moves

Bright-Eyes crashes if a enemy mage moves

Bug Report 1: http://www.crystals-dsa-foren.de/showthread.php?tid=700&pid=114374#pid114374
Bug Report 2: http://www.crystals-dsa-foren.de/showthread.php?tid=700&pid=114487#pid114487