Screen Size option in CONFIG.TXT
Moderator: Zyx
Forum rules
Please read the Forum rules and policies before posting.
Please read the Forum rules and policies before posting.
- Gambit37
- Should eat more pies
- Posts: 13766
- Joined: Wed May 31, 2000 1:57 pm
- Location: Location, Location
- Contact:
Screen Size option in CONFIG.TXT
Would it be possible to add a screensize option to the config.txt file? I play in 4x magnification, and would like CSBWin to startup at that size every time....
- Paul Stevens
- CSBwin Guru
- Posts: 4322
- Joined: Sun Apr 08, 2001 6:00 pm
- Location: Madison, Wisconsin, USA
- Gambit37
- Should eat more pies
- Posts: 13766
- Joined: Wed May 31, 2000 1:57 pm
- Location: Location, Location
- Contact:
I should have investigated the .bat files more thoroughly -- I didn't know there was a size switch. A bat file is fine for my needs.
However, when using the two size commands together (as you have done in the movie.bat), it doesn't work. The game starts at the right size and fullscreen, but once you enter either the prison or a loaded save game, the display reverts to the default size in the top left corner, and no other interface elements! Just the dungeon view!
It's OK if it's not fullscreen.
However, when using the two size commands together (as you have done in the movie.bat), it doesn't work. The game starts at the right size and fullscreen, but once you enter either the prison or a loaded save game, the display reverts to the default size in the top left corner, and no other interface elements! Just the dungeon view!
It's OK if it's not fullscreen.
- Paul Stevens
- CSBwin Guru
- Posts: 4322
- Joined: Sun Apr 08, 2001 6:00 pm
- Location: Madison, Wisconsin, USA
I don't know what batch file you mean. But don't use the
fullscreen option. That was for someone who was distracted
by the flashing controls, etc and wanted only the viewport
to show. If you use that you have to specify in the config
.txt where each piece of the screen goes and how big it should
be. Just use size=large (or whatever the words are).
fullscreen option. That was for someone who was distracted
by the flashing controls, etc and wanted only the viewport
to show. If you use that you have to specify in the config
.txt where each piece of the screen goes and how big it should
be. Just use size=large (or whatever the words are).
- Gambit37
- Should eat more pies
- Posts: 13766
- Joined: Wed May 31, 2000 1:57 pm
- Location: Location, Location
- Contact:
Also, could you give the detailed spec for how to use the Place command in the config file to move the elements around the screen?
Currently, the sample command seems to be for the viewport only, and I can only change it's position, not size. How do I make it larger and how do I get the other interface elements to show? Thanks.
Currently, the sample command seems to be for the viewport only, and I can only change it's position, not size. How do I make it larger and how do I get the other interface elements to show? Thanks.
- Paul Stevens
- CSBwin Guru
- Posts: 4322
- Joined: Sun Apr 08, 2001 6:00 pm
- Location: Madison, Wisconsin, USA
- Gambit37
- Should eat more pies
- Posts: 13766
- Joined: Wed May 31, 2000 1:57 pm
- Location: Location, Location
- Contact:
OK, thanks for the info -- that helped a lot and after some experimentation, I now have this in my CONFIG.TXT:
Segment E (program trace info) seems to be a special case as it doesn't use the same coordinates. The source has to be 0 0 for it to work properly -- this isn't consistent with the other segments, but I'm not complaining -- it's good to have the trace info available in larger screen sizes 
Actually, other than E, the segment identifiers seem redundant as I can swap the A for B and so on, and it doesn't affect anything -- clearly it's only the source, size and destination values that are important.
Code: Select all
; For 1280 x 960 screen:
; DUNGEON VIEW >>
Place A 4 0 21 e0 88 0 84
; CONTROLS >>
Place B 4 E0 21 60 88 380 84
; CHAMPIONS AT TOP >>
Place C 4 0 0 13F 21 0 0
; TEXT AREA >>
Place D 4 0 A9 13F 1F 0 2A8
; PROGRAM INFO >>
Place E 4 0 0 140 C7 0 324

Actually, other than E, the segment identifiers seem redundant as I can swap the A for B and so on, and it doesn't affect anything -- clearly it's only the source, size and destination values that are important.
- ChristopheF
- Encyclopedist
- Posts: 1588
- Joined: Sun Oct 24, 1999 2:36 pm
- Location: France
- Contact:
I copied this in my config.txt file, but nothing changed in the display. Is there something I am missing?
Christophe - Dungeon Master Encyclopaedia
- Paul Stevens
- CSBwin Guru
- Posts: 4322
- Joined: Sun Apr 08, 2001 6:00 pm
- Location: Madison, Wisconsin, USA
- ChristopheF
- Encyclopedist
- Posts: 1588
- Joined: Sun Oct 24, 1999 2:36 pm
- Location: France
- Contact:
Thank you Paul, it works fine with the command line parameter "size=full".
However, I found a few little bugs with the mouse cursor in this configuration:
1) When I put the cursor across the right limit of the viewport, if I move the mouse vertically, the cursor often gets split in two parts with only the left part moving (the one over the viewport). See case 1 in screenshot below.
2) When I put the cursor across the bottom line of the viewport or the movement arrows, a black line is displayed on top of the cursor. See case 2 in screenshot below.
3) When I make very fast mouse movements to the top or to the left of the screen, the mouse cursor is "blocked" by the edge of the screen/window. The standard windows cursor is displayed above the internal game cursor. This is not nice, but not important.
However, when I quickly move the mouse cursor to the right part of the screen, it is not blocked by the edge. It seems the windows cursor goes beyond that limit and is not visible. The problem is that the internal game cursor may be stopped way before the right limit of the screen. That cursor does not move anymore until the windows mouse cursor comes back into the window. I think this should be fixed if possible.

However, I found a few little bugs with the mouse cursor in this configuration:
1) When I put the cursor across the right limit of the viewport, if I move the mouse vertically, the cursor often gets split in two parts with only the left part moving (the one over the viewport). See case 1 in screenshot below.
2) When I put the cursor across the bottom line of the viewport or the movement arrows, a black line is displayed on top of the cursor. See case 2 in screenshot below.
3) When I make very fast mouse movements to the top or to the left of the screen, the mouse cursor is "blocked" by the edge of the screen/window. The standard windows cursor is displayed above the internal game cursor. This is not nice, but not important.
However, when I quickly move the mouse cursor to the right part of the screen, it is not blocked by the edge. It seems the windows cursor goes beyond that limit and is not visible. The problem is that the internal game cursor may be stopped way before the right limit of the screen. That cursor does not move anymore until the windows mouse cursor comes back into the window. I think this should be fixed if possible.

Last edited by ChristopheF on Sat Oct 20, 2007 10:49 pm, edited 3 times in total.
Christophe - Dungeon Master Encyclopaedia
- Gambit37
- Should eat more pies
- Posts: 13766
- Joined: Wed May 31, 2000 1:57 pm
- Location: Location, Location
- Contact:
I was wrong about the letters being interchangeable! They are quite specific due to the palette being darkened or not when the light levels change. My champion icons and inventory bars disappeared when going downstairs in the CSB prison with the old settings! This is what they should be:
Code: Select all
; For 1280 x 960 screen:
; DUNGEON VIEW >>
Place A 4 0 21 e0 88 0 84
; CONTROLS >>
Place C 4 E0 21 60 88 380 84
; CHAMPIONS AT TOP >>
Place D 4 0 0 13F 21 0 0
; TEXT AREA >>
Place B 4 0 A9 13F 1F 0 2A8
; PROGRAM INFO >>
Place E 4 0 0 140 C7 0 324
@Christophe: You did not say what placements you used.
Assuming that you used the ones published by Gambit37.
You left one line of pixels blank between the viewport and
the scrolling text area.
The viewport starts at 84 and is 88 high. So it ends
at 84 + 4*88 - 1 = 84 + 220 - 1 = 2a3
Then you left 2a4 empty.
Then you started the scrolling text area at 2a8.
So that one line you left blank is, shall we say, "blank".
As specified.
Assuming that you used the ones published by Gambit37.
You left one line of pixels blank between the viewport and
the scrolling text area.
The viewport starts at 84 and is 88 high. So it ends
at 84 + 4*88 - 1 = 84 + 220 - 1 = 2a3
Then you left 2a4 empty.
Then you started the scrolling text area at 2a8.
So that one line you left blank is, shall we say, "blank".
As specified.
- Paul Stevens
- CSBwin Guru
- Posts: 4322
- Joined: Sun Apr 08, 2001 6:00 pm
- Location: Madison, Wisconsin, USA
@Christophe.
1) I have fixed this. The whole thing a a bit of an
approximation. I did it better on the PocketPC and
I may move the code into the standard Windows version
if I ever get the urge to make it right.
2) User error - described above.
3) That is sort of the way it is. That is how the
Windowed display works, too. I am not going to
worry about this too much. The Windows mouse
messages are sorta hard to interpret correctly when
the mouse is outside the window. Naturally, the
Atari code had no provision for such a thing because
it was quite impossible.
1) I have fixed this. The whole thing a a bit of an
approximation. I did it better on the PocketPC and
I may move the code into the standard Windows version
if I ever get the urge to make it right.
2) User error - described above.
3) That is sort of the way it is. That is how the
Windowed display works, too. I am not going to
worry about this too much. The Windows mouse
messages are sorta hard to interpret correctly when
the mouse is outside the window. Naturally, the
Atari code had no provision for such a thing because
it was quite impossible.
- ChristopheF
- Encyclopedist
- Posts: 1588
- Joined: Sun Oct 24, 1999 2:36 pm
- Location: France
- Contact:
Thank you for your answers, Paul
About 3), I just wondered why the behavior is not identical with the left and top sides of the window on one hand, and the right and bottom sides on the other hand.
You're right, the same behavior applies while in window mode (not full screen). If you put the CSBwin window in the center of your screen and move the mouse outside and around the window in circles (well, rectangles), the CSBwin cursor follows the windows cursor only when the windows cursor is at the left or above the window, and not when it is at the right or below the window.
In most emulator programs, you can "capture" the mouse cursor: the windows mouse cursor disappears and you can only use the cursor inside the window. You have to press a key to "free" the mouse so it can move outside the emulator window. I don't know if it would be hard to implement such a thing in CSBwin?
About 3), I just wondered why the behavior is not identical with the left and top sides of the window on one hand, and the right and bottom sides on the other hand.
You're right, the same behavior applies while in window mode (not full screen). If you put the CSBwin window in the center of your screen and move the mouse outside and around the window in circles (well, rectangles), the CSBwin cursor follows the windows cursor only when the windows cursor is at the left or above the window, and not when it is at the right or below the window.
In most emulator programs, you can "capture" the mouse cursor: the windows mouse cursor disappears and you can only use the cursor inside the window. You have to press a key to "free" the mouse so it can move outside the emulator window. I don't know if it would be hard to implement such a thing in CSBwin?
Christophe - Dungeon Master Encyclopaedia