[Ohrrpgce] Callipygous bug reports

[Ralph Versteegen]

On 16 April 2016 at 08:24, James Paige <Bob at hamsterrepublic.com> wrote:
> Idontknow reports:
>
> "I think I found a bug in the new ohr version, but I'm not sure how to
> replicate it
> I opened the game, edited some map tiles and went to test it and all my
> battle formations got deleted except for one
> So I freaked out and quit without saving
> I dont know how to replicate it because all I did was change a few tiles in
> the wallmap of a map"

I'm stumped as to the cause. I asked Idontknow some more questions and
he sent his c_debug_archive.txt file:
https://dl.dropboxusercontent.com/u/98107115/c_debug_archive.txt
(Various other interesting messages in there, as always. I wish I saw
people's debug logs more often. I see we still have sprite leaks in
Custom).
The log and what he said shows that the formation lump got truncated
to 6-7 formations (480-559 bytes, a range suspiciously including the
magic 512B sector size) and most of the rest of it was overwritten; he
said one enemy in formation 5 was all that was preserved. The
corruption happened after unlumping, otherwise fix_record_count would
have noticed it. He was also live previewing the game at the same
time, and fought a couple formation which later got erased. Maybe the
data was corrupted by Game.

Also, there are a few other suspicious file IO messages in the debug
log for a number of different sessions, including, immediately before
the LoadFormation errors:
! could not write record to
C:\Users\Conor\AppData\Roaming\OHRRPGCE\working0.tmp\\ohrrpgce.dt1

Maybe those various file IO errors are explained by harddisk errors or
bad RAM or some kind of unhandled OS error. Otherwise I would some
kind of memory corruption bug.

> Feenicks reports:
>
> "went to reimport some hero graphics and they got all messed up like:
> https://dl.dropboxusercontent.com/u/16909401/screenshots/someformofimportbug.png
> " (confirmed this was callipygous, not a more recent wip)

Feenicks clarified:
<Feenicks> And I think I was moving between the connected hero tiles
and the individual one when the bug hit.

After this, I realised that the corruption must have been caused by
Feenicks resizing the window (which you're not meant to be able to do
in the sprite editor, however I noticed last week that when you leave
full-spriteset mode the window becomes resizable, but didn't think of
the significance of that.)
You can see that the first 16*40=640 pixels (320 bytes, one scanline
of the video page) are OK, then it's followed by some garbage
corresponding to a videopage larger than 320x200, before getting to
the next scanline.
I've actually already rewritten the way that the sprite editor stores
graphics so that it's not affected by this problem!

Will check in a fix tomorrow morning.

> KFHarlock reports that the mouse-positioning bug isn't completely gone:
>
> "james - another kind of bug (maybe)
> is that in the tile editor, when i'm running custom in a maximized window
> sometimes the position of the tile selector "slips" up or down
> which, when i'm copying and pasting tiles, has a tendency to cause me to
> paste over tiles by accident
> i think it has something to do with the mouse cursor, which doesn't seem to
> track perfectly to the keyboard cursor, when you're using the keyboard
> cursor to move around"

This is easy to see, just move in a straight line with cursor keys and
you'll notice the mouse cursor moves along a slanted line. When
maximised gfx_directx does not use an integer scaling factor, although
it does preserve aspect ratio by default, by adding black bars either
to the top or sides. If you unhide the OS mouse cursor you can
actually see that the OS cursor position doesn't even match the one
drawn by Custom!