Hello DosBox Fellas, theres is something i'd like to report about 0.62. Whenever i try to play a game in full screen mode, the games take only a half of the screen, while they where really full on 0.61. Tried every possible video configuration, but none of them worked. Thanks.

Are you using "fullfixed" and an old config file? The settings changed, it's no longer "fullwidth/height", but "fullresolution".
If in doubt, start with a newly generated config file and try again.

Qbix wrote:

2. User definable fonts don't work. Reported by jal ( try to confirm bug)

"work around"
2. use .61 (and tell us which programs!!)

I have a small test program, but in this forum I can't attach files (why is that, it seems to be possible in the other DOSbox forums?). If you can supply an e-mail address I can send it to you.

JAL

you can attach files now at this forum.

I try to run RRT deluxe, very strange with o.62 the northeast direction (shift+1) when building the track doesn't work. It worked fine with 0.61.

Why ??

Double buffering is now too slow to be usable... so it's put up with tear or put up with half the speed.

Any chance of having like a 0.62.1 or something, for fixing the obvious bugs, since time between official releases is SO long?

we're considering it. that's why i created this thread to locate all apparant bugs.

could you test if a different version of sdl (say the 0.61 one) helps for your double buffer slowness ?

Darkfalz: just being curious. Does double buffering helps you in any way?

I was playing Discworld with DOSBox 061, and with 062 everything is okay except one: when i go to new location, or just new screen shows there is a small graphic glitch, it looks like screen is drawing twice or something, you got to see it, its hard to explain here...

Maybe this is the same problem I have with Strike Commander in the video intro sequence. I think it's smacker format. Everytime a new "keyframe" is loaded there are graphic problems.

But maybe I'm wrong.

c ya
gdp2k

As with 0.61, on Slackware Linux 10.0, running X11R6.7.0, with an MGA G550, I'm still seeing a segfault when I try and use overlay support, and DosBox keeps falling back to surface when I try and use opengl or openglnb.

If you need a backtrace on that overlay problem, I'll run a search through the forum to the last time I posted about this, and try and get one for you.

When I load up opengl or openglnb support, I get this error:
SDL:OPENGL:No support for texturesize of 1024, falling back to surface

Maybe I should do a spot of research into how the SDL package for Slackware is compiled.... But, considering the fact that I have seen other SDL-based OpenGL programs run quite happily, I fail to see how that will help.

Magamo wrote:

As with 0.61, on Slackware Linux 10.0, running X11R6.7.0, with an MGA G550, I'm still seeing a segfault when I try and use overl […]
Show full quote

As with 0.61, on Slackware Linux 10.0, running X11R6.7.0, with an MGA G550, I'm still seeing a segfault when I try and use overlay support, and DosBox keeps falling back to surface when I try and use opengl or openglnb.

If you need a backtrace on that overlay problem, I'll run a search through the forum to the last time I posted about this, and try and get one for you.

When I load up opengl or openglnb support, I get this error:
SDL:OPENGL:No support for texturesize of 1024, falling back to surface

Maybe I should do a spot of research into how the SDL package for Slackware is compiled.... But, considering the fact that I have seen other SDL-based OpenGL programs run quite happily, I fail to see how that will help.

As for the overlay problem: Which scaler are you using? Does it happen instantly or when switching graphics modes? Are video players (like xine, mplayer) able to play videos using the "Xv" output method? Are they working when you compile them yourself?

Regarding OpenGL: Your hardware simply doesn't allow it. Other games have (in a certain way) lower requirements than dosbox, that's why they work. You can try setting fullresolution to 800x600 for example (I assume you are using fullfixed?), that should work.

Qbix wrote:

you can attach files now at this forum.

Ok, here's the testprogram. In DOSbox 0.61 it works fine (you'll see the correct Polish accents like ą, ś and ć. In DOSbox 0.62 the "original" value of the characters are displayed. I attached two screen dumps as well. Note that this program uses standard 256 character mode, not the extended 512 character mode (that didn't work correctly in 0.61 either).

JAL

Re: Overlay. I'm using the normal2x scaler. Dosbox segfaults when it attempts to display anything to the screen (after executing the [autoexec] section) Yes, xawtv, xine, and mplayer all work just fine with my card's BES, and Xv overlay. and I compile mplayer and xawtv myself.

Re: OpenGL

Not using fullfixed, and I tried setting that down to 800x600 anyway. No change, no effect, still gives the same 'no support for texturesize of 1024, falling back to surface' error.

I always start dosbox in a window, then switch to full screen when I feel the need.

well could you to compile dosbox yourself and see where it segfaults with gdb ?
just compile dosbox

gdb dosbox
run
when it crashes

bt
and post the results here.

1Program received signal SIGSEGV, Segmentation fault.
2[Switching to Thread 16384 (LWP 15146)]
3Normal_8_32 (src=0x979ad20 "") at render_templates.h:61
461                      dst[x]=pixel;LC[0][x]=pixel;
5(gdb) bt
6#0  Normal_8_32 (src=0x979ad20 "") at render_templates.h:61
7#1  0x080e2132 in VGA_DrawPart (lines=0) at vga_draw.cpp:191
8#2  0x080dc596 in PIC_RunQueue () at pic.cpp:357
9#3  0x0804e2b5 in Normal_Loop () at dosbox.cpp:123
10#4  0x0804d6e6 in DOSBOX_RunMachine () at dosbox.cpp:170
11#5  0x0804e63e in CALLBACK_Idle () at callback.cpp:66
12#6  0x0811347d in INT16_Handler () at bios_keyboard.cpp:382
13#7  0x0804e33c in Normal_Loop () at dosbox.cpp:127
14#8  0x0804d6e6 in DOSBOX_RunMachine () at dosbox.cpp:170
15#9  0x0804e7b8 in CALLBACK_RunRealInt (intnum=22 '\026') at callback.cpp:102
16#10 0x080b85e8 in device_CON::Read (this=0x9bd8ae8, 
17    data=0xbfffe175 "M\001@èÄ\001", size=0xbfffe0de) at dev_con.h:63
18#11 0x080bac87 in DOS_ReadFile (entry=0, data=0x979ad20 "", amount=0xbfffe29e)
19    at dos_files.cpp:267
20#12 0x0811d612 in DOS_Shell::InputCommand (this=0x9beae78, line=0xbfffe330 "")
21    at shell_misc.cpp:56
22#13 0x08119636 in DOS_Shell::Run (this=0x9beae78) at shell.cpp:199
23#14 0x0811a2a3 in SHELL_Init () at shell.cpp:397
24#15 0x08116d0a in Config::StartUp (this=0x979ad20) at setup.cpp:327
25#16 0x080f789a in main (argc=158969120, argv=0x979ad20) at sdlmain.cpp:1109

There's my backtrace. Looks as though it's the same culprit from back when I reported about this on April 19th of this year.

Any ideas? Could it be SDL, or my DRI drivers? *sighs* DosBOX itself?

I'm running Slackware 10.0 and seeing some differences between 0.61 and 0.62. I have an athlon xp 2500+
Any game that works in 640x480 resolution has problems with sound.
in 0.61, on my computer with frame skip of 6, they work very well, but in 0.62 the sound is jumpy even with frame skip of 10.
It's especially obvious in both gateway games. They're movies run in 320x200 and work flawlessly, but the moment the game continues, the resolution changes to 640x480 and the difference is really noticeable.
I compiled both dosbox version with the same settings and run them with the same configuration.

This is odd, could have swore it worked before but going back through earlier versions of dosbox it does not.

Ctrl+C and Ctrl+Break do not work at all. Just heart shaped ASCII character showing up.

Ctrl+C is almost a must for proper Dos operation. 😉

I know what you mean DosFreak. It should be there but it never was.
I know I want it in DOSBox especially for pause conditions that you are looped into if you forgot to put the CD in.
It never was in DOSBox from anytime that I can tell.
I forget exactly what Qbix said about doing it but I don't remember him saying it was easy to implement.

Btw if I remember correctly...
CTRL+Z = ^Z
and
CTRL+C = ^C
in DOS.

I remember running into them frequently when I used real DOS.