Using Custom under DosBox dosen't allow for browsing certain areas.

[ohrrpgce-bugbot]

[bz#78]

Using Custom under DosBox dosen't allow for browsing certain areas. Some of the areas are Text boxes, Enemy/Hero editors, Picture browser, shop editor, and anywhere resembling those areas. If you try to browse, it will begin to go backwards until it gets to 1 or 2. It's almost like an invisible hand were pushing on the Right arrow key.

From: @raekuul Reported version: unknown Operating system: DOSBOX Severity: minor

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

This is a bug in the current stable version of DosBox (0.63) I understand the problem has already been fixed in the unstable development version. The DosBox changelog at http://cvs.sourceforge.net/viewcvs.py/dosbox/dosbox/ChangeLog?rev=1.37&view=auto does not say anything specific about a bug like this, but it does say: "Lot's of small bug fixes" so hopefully this is one of them.

There are unofficial pre-0.64 builds of DosBox at http://cvscompile.aep-emu.de/dosbox.htm so maybe somebody who isn't using a Mac at the moment can test it out and see if the problem is fixed there.

[ohrrpgce-bugbot]

Comment author: @rversteegen

Not a bug in CUSTOM

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

I am re-opening this one for a couple reasons:

1) Although this has been fixed in Dosbox CVS for more than a year, the Dosbox devs seem dead-set against a new stable release, and dosbox 0.63 is still current

2) This bug also occurs in a regular dos box when running inside Qemu. Although DosBox and Qemu are both virtualization environments, they work in vastly different ways, and TTBOMK share no code at all.

Athough this bug is triggered by Dosbox and Qemu, I think it is still the OHRRPGCE's fault.

[ohrrpgce-bugbot]

Comment author: @pkmnfrk

Could it be that it's triggered by a really really tricky feature that the OHR uses? One that perhaps Qemu may not have gotten right yet, but the DosBox people did (sort of)?

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

The trouble code, as far as I can tell, is the extremely simple intgrabber function. It isn't doing any special magic that I can see...

I have a hard time even understanding what is happening here. When an integer menu item is selected, the intgrabber is called once for each program cycle. Each time it gets called, if the int is smaller than 2, it becomes 2, and if it is larger than 2 it decreases by 1. That is just crazy. Although it sometimes superficially appears that the left-arrow key is stuck down, that clearly isn't the case because of the stops-at-2 behavior.

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

I narrowed the problem down to the VAL() function in intgrabber. I made this simple test case:

PRINT "Testing VAL()..."

FOR i = -5 TO 10

s$ = STR$(i)

PRINT s$; VAL(s$)

NEXT i

in normal DOS under Windows 98 it produces the following output, as expected:

Testing VAL()...

-5-5

-4-4

-3-3

-2-2

-1-1

0 0

1 1

2 2

3 3

4 4

5 5

6 6

7 7

8 8

9 9

10 10

But when I run it in DOSBOX, I get the following results:

Testing VAL()...

-5-4.999999999999999

-4-4

-3-2.999999999999999

-2-2

-1-1

0 0

1 1

2 2

3 2.999999999999999

4 4

5 4.999999999999999

6 5.999999999999999

7 6.999999999999998

8 7.999999999999999

9 8.999999999999999

10 10

Running it under Qemu on my Mac produced even different results (which I don't have in front of me to paste here)

I am guessing that QuickBasic's VAL command is a wrapper arround some low level DOS interrupt that converts a string buffer into a number, and the Implementation of this interrupt is buggy in DosBox and Macintosh Qemu.

[ohrrpgce-bugbot]

Comment author: @pkmnfrk

So, to fix this, we need to round val? does QB have a ROUND function? I suppose we could just write one:

Function round(v!) 'we don't want to truncate it if v = int(v) then round = v: exit function if v - int(v) < .5 then round = int(v): exit function else round = int(v) + 1: exit function end if function

[ohrrpgce-bugbot]

Comment author: @pkmnfrk

No, I take that back. It's always X.9999999999999 and so forth, and it's already truncated, so what if we just add " + 1" to line 1485 of subs.bas?

[ohrrpgce-bugbot]

Comment author: @pkmnfrk

No, I take that back as well. We need to round, so we can handle negatives properly.

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

No, rounding won't fix it. I wish I had the output from Mac Qemu. It was even more wrong. "0" returned "2" for no reason.

I wrote a VAL replacement that I will be checking in shortly

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

I just commited a patch that adds str2int() and str2lng&() to replace all instances of VAL()

I tested, and it does solve the problem on DoxBox. I will test Mac/Qemu on monday.

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

Tested with Mac/Qemu, this fixes the problem.

Marking fixed.